Re: MBF alert: packages with very long source / .deb filenames
On Fri, 25 Mar 2011, Steve McIntyre wrote: > On Fri, Mar 25, 2011 at 12:28:54PM -0400, Joey Hess wrote: > >Steve McIntyre wrote: > >> There are uses I've heard about, including (apparently quite common) > >> using CDs and DVDs to seed a mirror on a Windows server. > > > >If I had to chose between that working, and not needing to worry about > >filename lengths, I'd choose the latter. > > We already have arbitrary limits on filename length (~200 bytes or so > on RockRidge), even before this. I'm just proposing to lower them for > a common use case. Do we really care about supporting *very* long > names here? I think so. The package with long names tend to follow a naming policy that sort of imposes the long name... so if we put a too-short limit then we're asking them to make an exception in the naming policy. > >One approach then would be to omit joliet filenames for the few long > >packages. This would not even impact your use case above much, since > >any mirror seeded from files from CDs needs a further sync step. > > I'd be much happier to not have to special case yet another thing in > the CD scripts. That way potentially leads to unforeseen bugs in the > future, for very little gain. What happens if you try to put too-long filenames on the CD with Joliet enabled? Does it fail to build? Are there options to rename the files automatically? If it means we have some unexpected filenames for long filenames on Windows, it's not a big deal IMO. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110326075614.ga29...@rivendell.home.ouaza.com
Re: ddebs
On Fri, Mar 25, 2011 at 11:43 PM, Emilio Pozuelo Monfort wrote: > The way I did it was one .ddeb per source package, not per binary. So it is > $src-ddeb. You can reject them if they are not for $src package (or if $src > package doesn't exist in the archive). To simplify the archive processes i would prefer having a ddeb per binary package instead of source package. It must have the name $binary-ddeb and must have the same version as $binary. The ddebs will get separate Packages files similar to the udebs. It is even easier for our users that they don't need to find out the source package name. Can we agree on that? Cheers, Torsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinQanOtm_Ua_=usmudt9mpfuttykggr6d_ih...@mail.gmail.com
Re: ddebs
On 26/03/11 08:07, Torsten Werner wrote:
> On Fri, Mar 25, 2011 at 11:43 PM, Emilio Pozuelo Monfort
> wrote:
>> The way I did it was one .ddeb per source package, not per binary. So it is
>> $src-ddeb. You can reject them if they are not for $src package (or if $src
>> package doesn't exist in the archive).
>
> To simplify the archive processes i would prefer having a ddeb per
> binary package instead of source package. It must have the name
> $binary-ddeb and must have the same version as $binary. The ddebs will
> get separate Packages files similar to the udebs. It is even easier
> for our users that they don't need to find out the source package
> name. Can we agree on that?
I have just skimmed over the dicussions from 2009 where we decided that it
should be one ddeb per source package, and it seems that everyone preferred one
ddeb per binary package except the ftpmasters :) So that's fine with me.
I'd add to the requirements that foo-ddeb needs to Depend on foo (=
${binary:Version}).
I'd also mandate the use of build-ids for .ddebs and add refcounting support
(like has been done for multiarch AFAIK) to dpkg for them, so we don't need to
worry about Conflicts / Replaces.
Cheers,
Emilio
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8da614.30...@debian.org
oldstable-security signing key
Hi, Ben Hutchings recently discovered that old lenny CDs (5.0.0) currently fail to install. Phil Kern discovered that this was because they couldn't validate the security signing key (which was rolled over after they were released). Originally, lenny security updates were signed with the old ftpmaster key: sec 4096R/55BE302B 2009-01-27 [expires: 2012-12-31] uid Debian Archive Automatic Signing Key (5.0/lenny) As this key is still valid and present in debian-archive-keyring (even in unstable) and will be so until well after the end of lenny security support (which as we understand it is due on 2012-02-06), we intend to change the lenny security repository to be signed by this key rather than the current ftpmaster key which is: pub 4096R/473041FA 2010-08-27 [expires: 2018-03-05] uid Debian Archive Automatic Signing Key (6.0/squeeze) If anyone has any objections to this, can they let us know? I intend to implement the changes necessary to make this work in dak immediately, but won't change the key over for a couple of days to give people time to raise objections. Thanks, Mark -- Mark Hymers "Well, the thing about a black hole - it's main distinguishing feature - is it's black. And the thing about space, your basic space colour is black. So how are you supposed to see them?" Holly, Red Dwarf Series III - Marooned signature.asc Description: Digital signature
Re: ddebs
On Sat, 26 Mar 2011, Emilio Pozuelo Monfort wrote: > I'd also mandate the use of build-ids for .ddebs and add refcounting support > (like has been done for multiarch AFAIK) to dpkg for them, so we don't need to > worry about Conflicts / Replaces. For multi-arch, it's the _same_ package (but just another architecture of it) that can share _identical_ files and where we have refcounting. This can't be generalized to just any package, it's just contrary to the logic of our packaging tools. When do you have such conflicts? I hear when you have the same binary in multiple package... but in that case both packages already conflict and you can just copy the existing conlict field and add the -ddeb suffix. Otherwise maybe there's a way to include the package name in the path to avoid such conflicts? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110326091057.gb32...@rivendell.home.ouaza.com
Build-Essential
Hi, there are currently two ways to indicate what Debian considers "Build-Essential". There is the package build-essential and there is also a flag in the packages files. We think it was used to be able to calculate the B-E packages by "just looking at the packages files", but we do not see a good reason to have it so. Simply installing the build-essential package plus dependencies should do the trick too. As far as we know currently the main user of this field seems to be debootstrap in its buildd variant mode. If anybody else is using this it would be useful if we could know about it, but currently we don't see any reason to keep the flag, it is just useless extra maintenance to have two places. As such we intend to drop the B-E flag after Squeeze is removed from the main archive, which means all tools starting with Wheezy using the flag should cope with using the package. -- bye, Joerg cat /dev/urandom > /dev/dsp zobel: das nennt sich "metal" oder "techno", je nachdem Ganneff: apocalyptica? youam: nein, das is random, nich urandom :) pgplgptnsQjw9.pgp Description: PGP signature
Re: ddebs
On 26/03/11 09:10, Raphael Hertzog wrote: > On Sat, 26 Mar 2011, Emilio Pozuelo Monfort wrote: >> I'd also mandate the use of build-ids for .ddebs and add refcounting support >> (like has been done for multiarch AFAIK) to dpkg for them, so we don't need >> to >> worry about Conflicts / Replaces. > > For multi-arch, it's the _same_ package (but just another architecture of it) > that > can share _identical_ files and where we have refcounting. > > This can't be generalized to just any package, it's just contrary to the > logic of our packaging tools. > > When do you have such conflicts? I hear when you have the same binary in > multiple package... but in that case both packages already conflict and > you can just copy the existing conlict field and add the -ddeb suffix. Not necessarily, e.g. you can have the same binary in different paths, or with different names. > Otherwise maybe there's a way to include the package name in the path > to avoid such conflicts? I don't think so. Otherwise gdb wouldn't know where to look for it. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8db383.7010...@debian.org
Re: MBF alert: packages with very long source / .deb filenames
On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote: > > We already have arbitrary limits on filename length (~200 bytes or so > > on RockRidge), even before this. I'm just proposing to lower them for > > a common use case. Do we really care about supporting *very* long > > names here? > I think so. The package with long names tend to follow a naming policy > that sort of imposes the long name... so if we put a too-short limit > then we're asking them to make an exception in the naming policy. Right, that's certainly true for the lib.*-perl packages, and I wouldn't know how we should rename them in a sane way. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Peter Jones: I Can Feel You signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
On Sat, 2011-03-26 at 15:18 +0100, gregor herrmann wrote: > On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote: > > > > We already have arbitrary limits on filename length (~200 bytes or so > > > on RockRidge), even before this. I'm just proposing to lower them for > > > a common use case. Do we really care about supporting *very* long > > > names here? > > I think so. The package with long names tend to follow a naming policy > > that sort of imposes the long name... so if we put a too-short limit > > then we're asking them to make an exception in the naming policy. > > Right, that's certainly true for the lib.*-perl packages, and I > wouldn't know how we should rename them in a sane way. I don't think the longstanding naming policy for Perl binary packages has resulted in these very long names. (I believe I once had the longest-named binary package in the archive with libmaypole-plugin-authentication-usersessioncookie-perl, but that was still only 55 characters.) The really absurdly long names Steve found seem to be used for secondary source tarballs for some v3 source packages, where the file name essentially includes two full Perl module names. If that's specified in current Perl policy, it should be fixed (and can be fixed without confusing users). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: MBF alert: packages with very long source / .deb filenames
Am Freitag 25 März 2011, 21:59:31 schrieb Rene Engelhard: > Hi, > > On Fri, Mar 25, 2011 at 09:48:15PM +0100, Adam Borowski wrote: > > On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote: > > > Hi, > > > > > > On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote: > > > > The longest is: > > > > > > > > libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.d > > > > eb > > > > > > > > at 71. > > > > > > Good, then any bug against openoffice.org is not needed, as that > > > obviously will be + wontfix wheezy-ignore, because it simply can't be > > > fixed as we need the transitional packages :) > > > > It still can have a version number much shorter than 1.0.3+LibO3.3.1-1. > > And there's no package out of openoffice.org which has that style of > version. > > And no, it cannot have a shorter version in libreoffice (e.g. you simply > can't remov the +LibO3.3.1-1 unless you get problems in versioning as the > version before the + doesn't necessarily change between releases) At least the "LibO" can be dropped. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103261453.10548.p...@hendrik-sattler.de
Is BTS down?
Hi, I've not been able to connect to BTS using reportbug and only got the "Unable to connect to Debian BTS" message. Is BTS down? Regards, ST -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8dfb1f.40...@polyu.edu.hk
Re: Is BTS down?
On Sat, Mar 26, 2011 at 15:41, LUK ShunTim wrote: > I've not been able to connect to BTS using reportbug and only got the > "Unable to connect to Debian BTS" message. Is BTS down? I had similar problems minutes ago, but now it seems working. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=zbba8vzgvh8bgzran5v575le...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV wrote: >> That's not our problem, is it? > > It is, if we are trying to be as compatible as possible. Compatible with what? Bugs in other implementations? What does that really gain us? -- Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=fhm8tko5mv9pcu9-r8ua23yw2hqsn2ckyq...@mail.gmail.com
Bug#619740: ITP: libdist-zilla-plugin-podspellingtests-perl -- Release tests for POD spelling
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-podspellingtests-perl Version : 1.103491 Upstream Author : Marcel Gruenauer , Harley Pig * URL : http://search.cpan.org/dist/Dist-Zilla-Plugin-PodSpellingTests/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Release tests for POD spelling Dist::Zilla::Plugin::PodSpellingTests is Perl modulem, providing an extension of Dist::Zilla::Plugin::InlineFiles. This modules contains the following file: xt/release/pod-spell.t - a standard Test::Spelling test Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103261819.02534.domi.dum...@free.fr
Re: MBF alert: packages with very long source / .deb filenames
On Sat, 26 Mar 2011 14:32:27 +, Ben Hutchings wrote: > > > I think so. The package with long names tend to follow a naming policy > > > that sort of imposes the long name... so if we put a too-short limit > > > then we're asking them to make an exception in the naming policy. > > Right, that's certainly true for the lib.*-perl packages, and I > > wouldn't know how we should rename them in a sane way. > The really absurdly long names Steve found seem to be used for secondary > source tarballs for some v3 source packages, where the file name > essentially includes two full Perl module names. Thanks for the pointer, I admit that I have missed this detail. For the two packages listed in Steve's mail that gives us: libcgi-application-basic-plugin-bundle-perl_0.5-1.debian.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5-1.dsc libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Dispatch-2-17.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-AutoRunmode-0-17.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ConfigAuto-1-32.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-DBH-4-00.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-DebugScreen-0-06.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-DevPopup-1-06.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ErrorPage-1-21.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-FillInForm-1-15.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-Forward-1-06.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-LogDispatch-1-02.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-Redirect-1-00.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-Session-1-03.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-Stream-2-10.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ViewCode-1-02.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Standard-Config-1-01.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig.tar.gz libcgi-application-plugin-authorization-perl_0.07-1.debian.tar.gz libcgi-application-plugin-authorization-perl_0.07-1.dsc libcgi-application-plugin-authorization-perl_0.07.orig-driver-activedirectory.tar.gz libcgi-application-plugin-authorization-perl_0.07.orig.tar.gz > If that's specified in > current Perl policy, it should be fixed (and can be fixed without > confusing users). AFAIK the submodule names were just made up and can be shortened (in fact, for the second package it's already a "made-up" name). (Not that this gives us much room -- in the second case we're already down to 84 characters ...) Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Dire Straits: Brothers In Arms signature.asc Description: Digital signature
e2fsprogs as Essential: yes?
Hi folks, Currently the e2fsprogs package is marked Essential: yes in the archive. Is this a historical holdover? I believe e2fsprogs used to ship /sbin/fsck, but since 2009 (i.e., util-linux (>= 2.15~rc1-1), which e2fsprogs has a pre-depends on), this has been provided by util-linux instead. The remaining programs provided by e2fsprogs are all specific to the ext* family of filesystems, so I don't think meet the definition of Essential any longer - their presence is certainly important if you have an ext[234] filesystem, but while this is the default, you can have systems that don't use ext* at all, which makes e2fsprogs no more essential in nature than the other per-filesystem fsck tools. Now that the transition to util-linux is done in a stable release, is it time for us to drop the Essential: yes flag from e2fsprogs? This will benefit those targetting embedded systems that don't use ext, where the package will be dead weight; the risk of any packages assuming availability of these e2fs-specific interfaces without a dependency is quite low; and we're at the right point in the cycle to make changes to the Essential set, where we have time to deal with any unexpected fallout. Thoughts? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: oldstable-security signing key
Mark Hymers wrote: > Ben Hutchings recently discovered that old lenny CDs (5.0.0) currently > fail to install. Phil Kern discovered that this was because they > couldn't validate the security signing key (which was rolled over after > they were released). I ran into this problem yesterday. Thank you for working to fix it. Bob signature.asc Description: Digital signature
Re: ddebs
Le samedi 26 mars 2011 à 08:38 +, Emilio Pozuelo Monfort a écrit : > I have just skimmed over the dicussions from 2009 where we decided that it > should be one ddeb per source package, and it seems that everyone preferred > one > ddeb per binary package except the ftpmasters :) So that's fine with me. You already know that, but for those who haven’t followed the discussions: several binaries built from the same source package can share the same build ID (which cannot happen in different source packages). Hence the need for what follows. > I'd also mandate the use of build-ids for .ddebs and add refcounting support > (like has been done for multiarch AFAIK) to dpkg for them, so we don't need to > worry about Conflicts / Replaces. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301175428.6724.107.camel@pi0307572
Sanjem savu Daavanu karti!...
i-virtuve (virtualaa) ienak ari juusu majaas - izveido burgerus sev pieejamajaa datoraa , bet notiesaa tos iistaa restoranaa! http://www.docorciscount6betshop.ca.pn/jd9eu.html - protams, tev jaaspiezh tur, lai visu uzzinaatu! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0lio00al4o2s2...@relay1.stonline.sk
Re: e2fsprogs as Essential: yes?
On Sat, 26, Mar, 2011 at 11:47:08AM -0700, Steve Langasek spoke thus.. > Hi folks, > > Currently the e2fsprogs package is marked Essential: yes in the archive. Is > this a historical holdover? I believe e2fsprogs used to ship /sbin/fsck, > but since 2009 (i.e., util-linux (>= 2.15~rc1-1), which e2fsprogs has a > pre-depends on), this has been provided by util-linux instead. Hi, The only other thing I can see is that e2fsprogs contains lsattr and chattr - a quick grep through my local /var/lib/dpkg/info shows that chattr is used in the postfix postinst without an explicit dependency. I wonder if there are more instances of that? Mark -- Mark Hymers "But Yossarian *still* didn't understand either how Milo could buy eggs in Malta for seven cents apiece and sell them at a profit in Pianosa for five cents." Catch 22, Joseph Heller -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110326224209.ga11...@hymers.org.uk
Re: e2fsprogs as Essential: yes?
On Sat, Mar 26, 2011 at 10:42:09PM +, Mark Hymers wrote: > > The only other thing I can see is that e2fsprogs contains lsattr and > chattr - a quick grep through my local /var/lib/dpkg/info shows that > chattr is used in the postfix postinst without an explicit dependency. > I wonder if there are more instances of that? What to do with lsattr and chattr is actually a somewhat interesting question. They are most definitely ext2/3/4 specific, and the ext2/3/4 development team still adds new flags to it from time to time, so we had no plans moving those two commands out of e2fsprogs any time soon. On the other hand, other file systems, including reiserfs and btrfs, have used the same ioctl and command line interface, and we do coordinate flags to prevent conflicts. So other users of other file systems will still need lsattr and chattr. There are similar, although less serious, issues with filefrag -v (which will work on other file systems), but which also has some ext2/3/4 specific code it in. Another binary which is used by other packages includes the logsave utility, which is also in e2fsprogs, and which is used by /etc/init.d/checkfs.sh and /etc/init.d/checkroot.sh in the initscripts package. Regards, - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110326230729.gg2...@thunk.org
Bug#619784: ITP: eigen3 -- Eigen 3 is a lightweight C++ template math library for vector and matrix math.
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: eigen3 Version : 3.0.0 * URL : http://eigen.tuxfamily.org * License : (GPL, LGPL) Programming Lang: (C, C++) Description : Eigen 3 is a lightweight C++ template library for vector and matris math New version 3.0 is available. New package is requited not to break eigen2-oriented packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110326234141.5243.62189.reportbug@localhost6
Bug#619785: Please move logsave to sysvinit-utils
Package: sysvinit-utils Severity: wishlist * Ted Ts'o [2011-03-26 19:07 -0400]: > There are similar, although less serious, issues with filefrag -v > (which will work on other file systems), but which also has some > ext2/3/4 specific code it in. badblocks is also linked against libext2fs. > Another binary which is used by other packages includes the logsave > utility, which is also in e2fsprogs, and which is used by > /etc/init.d/checkfs.sh and /etc/init.d/checkroot.sh in the initscripts > package. Debian supports (or rather will probably support) three init systems: * systemd does not use logsave to save the fsck log if /var/log is not mounted yet, but instead "just pipes the stdout of fsck to syslog which ends up in dmesg if syslog is not yet running" (thanks to whoever explained this in #systemd). * sysvinit and upstart depend on the package initscripts, which depends on sysvinit-utils. logsave does not use any libraries except libc. Provided that Ted Ts'o agrees, please consider moving logsave to sysvinit-utils. Regards Carsten P.S.: There is already a bug about essentialness filed against e2fsprogs: #474540 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110327001926.ga12...@furrball.stateful.de
