headers
wnpp | 10 Feb 01:27
Picon
Favicon

Work-needing packages report for Feb 10, 2012

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 403 (new: 13)
Total number of packages offered up for adoption: 143 (new: 0)
Total number of packages requested help for: 59 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.

------------------------------------------------------------------------

The following packages have been orphaned:

   bochs (#659023), orphaned 2 days ago
     Description: IA-32 PC emulator
     Reverse Depends: bochs bochs-sdl bochs-svga bochs-term bochs-wx
       bochs-x
     Installations reported by Popcon: 2210

   catwalk (#658918), orphaned 3 days ago
     Installations reported by Popcon: 60

   openhackware (#658774), orphaned 4 days ago
     Description: OpenFirmware emulator for PowerPC
     Reverse Depends: qemu-system
     Installations reported by Popcon: 8215

   proll (#658886), orphaned 3 days ago
     Description: JavaStation PROM 2.x compatible replacement
(Continue reading)

Permalink | Reply | 0 comments |
headers
shirish शिरीष | 10 Feb 00:43
Picon
Gravatar

No release/transition to libpoppler 0.18 ?

Hi all,
A few weeks/months back libpoppler 0.18 got released. The version we
have in Debian (running sid) is 0.16.7 which was released in Jun 2011.
Please see  http://poppler.freedesktop.org/releases.html .
Subsequently a wishlist bug was filed.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644447 . If one sees
the bug then one can see Mr. Martin Pitt sharing debdiffs for
libpoppler when they are doing the same for ubuntu.

Now during that time-frame I have been seeing various errors while
viewing pdf's which I did suspect were due to the library being old.
The latest victims though is the Open Advice e-book.  Please see
https://github.com/lydiapintscher/Open-Advice/issues/41

I tried to see if the maintainer Monsieur Loic Minier had asked for
transition but was unable to find anything of value.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org;dist=unstable

I know that in couple of months (or a little more) we would be looking
at Freeze. Is there possibility of getting a fresh release in soonish
?

Looking forward to know more.
--

-- 
          Regards,
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mellissa Rowe | 9 Feb 20:19

raphaelhertzog.com Acquisition

We are representing a venture capital firm located in Silicon Valley
and would like to open up discussions about the possible acquisition
of raphaelhertzog.com.

They are interested in acquiring businesses in this niche that have
revenues above $150k per year or have traffic over 100k unique
visitors per month.

Offers are usually at multiples of trailing earnings, however, some
deals are based on brand, user base, and traffic.

If interested in entertaining an offer, please provide us with some
history of the online business and best time to reach you.


Best Regards,

Mellissa Rowe
mellissa.rowe <at> sitesalesspecialists.com
Acquisition Team Lead
Phoenix, Arizona
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Hanke | 9 Feb 20:20
Picon
Favicon

Bug#659282: ITP: eeglab -- electrophysiological data analysis

Package: wnpp
Severity: wishlist
Owner: Michael Hanke <mih <at> debian.org>

* Package name    : eeglab
  Version         : 11.0.0.0
  Upstream Author : Scott Makeig, Arnaud Delorme and others
* URL             : http://sccn.ucsd.edu/eeglab
* License         : GPL-2+
  Programming Lang: Matlab (Octave)
  Description     : electrophysiological data analysis

 This is sofwware for processing continuous or event-related EEG or other
 physiological data. It is designed for use by both novice and expert
 users. In normal use, the EEGLAB graphic interface calls graphic functions
 via pop-up function windows. The EEGLAB history mechanism can save the
 resulting calls to disk for later incorporation into scripts.
 .
 This package provides EEGLAB to be used with Matlab. Note that this package
 depends on Matlab -- a commercial software that needs to be obtained and
 installed separately.

Notes
-----

At this point this package basically only works with Matlab (hence
aiming at contrib). However, there is hope to enable an interesting
subset of non-GUI functionality to work with Octave. Upstream provides
a substantial unittest suite to help such an effort.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ole Streicher | 9 Feb 18:41

Bug#659269: ITP: starconf -- Starlink autoconf support

Package: wnpp
Severity: wishlist
Owner: Ole Streicher <debian <at> liska.ath.cx>
X-Debbugs-Cc: debian-devel <at> lists.debian.org

* Package name    : starconf
  Version         : 1.3
  Upstream Author : Norman Gray
* URL             : http://starlink.jach.hawaii.edu/starlink
* License         : TBD
  Programming Lang: Shell
  Description     : Starlink autoconf support
 This package contains the support m4 autoconf macros to build
 packages from the starlink project.

This package is built in preparation to build slalib
<http://bugs.debian.org/359003> and starlink-libast
<http://bugs.debian.org/657957>, which are then required to re-insert
saods9 <http://bugs.debian.org/655648>.
Permalink | Reply | 0 comments |
headers
Ondřej Surý | 9 Feb 10:15
Gravatar

MIA check for Robert Jordens and Mark A. Hershberger (anyone in contact with them?)

Mark A. Hershberger (all his packages are co-maintained; Vincent, are
you in contact with him?):

<mhershberger <at> intrahealth.org>: host mail2.intrahealth.org[207.254.211.2] said:
   550 No such user (mhershberger <at> intrahealth.org) (in reply to RCPT TO
   command)
Reporting-MTA: dns; mail.nic.cz
X-Postfix-Queue-ID: BD6A22A3086
X-Postfix-Sender: rfc822; ondrej.sury <at> nic.cz
Arrival-Date: Thu,  9 Feb 2012 10:00:34 +0100 (CET)

Final-Recipient: rfc822; mhershberger <at> intrahealth.org
Original-Recipient: rfc822;mhershberger <at> intrahealth.org
Action: failed
Status: 5.0.0
Remote-MTA: dns; mail2.intrahealth.org
Diagnostic-Code: smtp; 550 No such user (mhershberger <at> intrahealth.org)

Robert Jordens (all his packages are NMUed, so he is probably MIA)

<jordens <at> debian.org>: host master.debian.org[70.103.162.29] said: 550
   Unrouteable address (in reply to RCPT TO command)
Reporting-MTA: dns; mail.nic.cz
X-Postfix-Queue-ID: 3437C2A3107
X-Postfix-Sender: rfc822; ondrej.sury <at> nic.cz
Arrival-Date: Thu,  9 Feb 2012 10:00:36 +0100 (CET)

Final-Recipient: rfc822; jordens <at> debian.org
Original-Recipient: rfc822;jordens <at> debian.org
Action: failed
(Continue reading)

Permalink | Reply | 3 comments |
headers
Philip Ashmore | 9 Feb 09:45
Gravatar

history transparency

Hi there.

Looking at advances in storage that are on the horizon coupled with 
advances with processing power, it would appear that "something 
wonderful" is on the horizon.

It will be possible to build an entire Debian distribution in a matter 
of minutes.

This capability requires no changes to the way Debian "does things" 
right now.

But when it comes to old bug reports involving source packages in GIT or 
other version control systems,
it's already the case that older C/C++ code won't compile due to 
advances and increasing strictness in compilers.

Right now it's difficult/impossible to recreate a snapshot of Debian as 
it was (updates included) when the bug was reported.

I think Debian needs a way to be able to pick a point in history and 
obtain at least the versions + patches of all the source packages that 
would have been installed / available to reproduce the Debian system 
running on the users machine at the time they reported the bug.

With more and more source packages becoming available under publicly 
accessible version control, what needs to change in Debian to make this 
possible?

Regards,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Roger Leigh | 8 Feb 21:03

Comments on introducing a new Essential package: base-init?

This is regarding Bug #645540 ("Essential" package conflict between
sysvinit and systemd-sysv).

sysvinit is currently Essential.  In order to permit the replacement
of sysvinit with an alternative init system, I'd like to propose the
creation of a new Essential package "base-init", with a Depends on
"sysvinit | init", where "init" is a virtual package provided by all
packages providing /sbin/init.  This would be provided by sysvinit,
systemd, upstart, etc.

With this package in place, sysvinit could be removed from the
Essential set, but remain the default init system.  This would
permit alternative init systems to entirely replace sysvinit.

An alternative would be for an existing Essential package such as
base-files to provide the Depends, which would save the need for
a separate base-init package.  Is there any reason this would be
undesirable?  (I note that it currently has no depends other than
a pre-depends on awk.)

Any comments?

Thanks,
Roger

--

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Aron Xu | 8 Feb 18:22
Picon

Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

I want to speak up about endianness of data files, this is a
suggestion but not a flaw which I just want to discover the
possibility of improvement to current status by the chance of
implementing Multi-Arch in Debian.

Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all package if
endianness were not something to care about. AFAIK some maintainers
are not aware of endianness issues in their packages and then just
ignored it (not sure how many, but if any of them are discovered it
should lead to RC bug). It would be great to have some mechanism to
handle such kind of problems in Debian, to avoid forcing those data to
be placed into arch:any package.

--

-- 
Regards,
Aron Xu
Permalink | Reply | 7 comments |
headers
Ian Jackson | 8 Feb 18:00
Picon

Re: Please test gzip -9n - related to dpkg with multiarch support

Guillem Jover writes ("Re: Please test gzip -9n - related to dpkg with multiarch support"):
> On Wed, 2012-02-08 at 13:19:17 +0000, Ian Jackson wrote:
> > One thing which no-one yet seems to have suggested is to have
> > multiarch:same packages put the changelog in a filename which is
> > distinct for each architecture.  (It wouldn't have to be the triplet;
> > the shorter Debian arch would do.)  Perhaps there are obvious reasons
> > (which I have missed) why this is a terrible idea, but it seems to me
> > that it's something we should consider.
> 
> Instead of this, I'd rather see the shared files approach just dropped
> completely, and /usr/share/doc/ files for “Multi-Arch: same” packages
> be installed under /usr/share/doc/pkgname:arch/.

Right, that's kind of what I was suggesting although you've
generalised it.  It doesn't seem like an unreasonable idea to me.

Obviously it would mean that some (Debian-specific) software which
currently doesn't need to be multiarch-aware would need to be taught
about these new directory names.  But that seems like a reasonable
price to pay for solving the varying compressed shared files problem.

Another relevant question is whether there are other files that are
shared, and which don't want to move, besides ones in /usr/share/doc.
I haven't been following this in detail but if there are then we may
need to retain the possibility to have actually-identical shared
files.

Ian.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ian Jackson | 8 Feb 14:19
Picon

Re: Please test gzip -9n - related to dpkg with multiarch support

Russ Allbery writes ("Re: Please test gzip -9n - related to dpkg with multiarch support"):
> Another possible solution is to just give any package an implicit Replaces
> (possibly constrained to /usr/share/doc) on any other package with the
> same name and version and a different architecture.  This isn't as
> defensive, in that it doesn't catch legitimate bugs where someone has made
> a mistake and the packages contain different contents, but it also solves
> the binNMU issue (well, "solves"; the changelog will randomly swap back
> and forth between the packages, but I'm having a hard time being convinced
> this is a huge problem).

Well, it does mean that you might be lacking important information
because the other changelog wouldn't be present on the system.

One thing which no-one yet seems to have suggested is to have
multiarch:same packages put the changelog in a filename which is
distinct for each architecture.  (It wouldn't have to be the triplet;
the shorter Debian arch would do.)  Perhaps there are obvious reasons
(which I have missed) why this is a terrible idea, but it seems to me
that it's something we should consider.

Ian.
Permalink | Reply | 31 comments |

Gmane