Re: from / to /usr/: a summary
* Darren Salt schrieb: > I fully intend to continue with lilo, separate /usr and no initramfs/initrd. > I *may* decide to stop using a separate /usr should I need to replace > hardware ??? but probably not before then. > > I will NOT use an initramfs just to have /usr mounted early enough. Seconded. The reasons for that separation in FHS are far more than just historical slowless/expensiveness of larger spindles. / should only contain things needed for boot up into singleuser, /usr should hold all the rest. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- 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/20111221043514.ga19...@mailgate.onlinehome-server.info
Re: Heads-up: Boost defaults changing from 1.46 to 1.48
On Mon, Dec 19, 2011 at 10:33:26PM +0100, Julien Cristau wrote: > On Sat, Dec 10, 2011 at 21:23:49 -0600, Steve M. Robbins wrote: > > > Hi, > > > > Boost 1.48 was uploaded to sid about 9 days ago so it should > > transition to "testing" in the next day or so. > > > > My plan is to update the default boost version to 1.48 immediately > > following this transition. > > > > I'd appreciate feedback on any build failures with 1.48 for > > boost-using packages. > > > I heard of at least two failures in the last couple of hours: > libreoffice (#652681), and wesnoth (#652677). As such, I'd appreciate > if you could: > - revert boost-defaults to 1.46 for the time being Done. > - test-build at least the most prominent reverse deps against 1.48 > before bumping it again > - contact debian-release before that bump, so we can coordinate a timing > that doesn't suck with regards to other ongoing transitions. OK, will do. -Steve signature.asc Description: Digital signature
Bug#652848: RFH: line6-usb -- Line 6 POD driver source
Package: wnpp Severity: normal I request assistance with maintaining the line6-usb package. The package description is: An experimental driver for the guitar amp, cab, and effects modeller PODxt Pro by Line6 (and similar devices), supporting the following features: . * Reading/writing individual parameters * Reading/writing complete channel, effects setup, and amp setup data * Channel switching * Virtual MIDI interface * Tuner access * Playback/capture/mixer device for any ALSA-compatible * PCM audio application * Signal routing (record clean/processed guitar signal, re-amping) -- 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/20111220234319.6874.9305.reportbug@localhost
Re: many packages fail to build twice in a row again
On Tue, Dec 20, 2011 at 09:36:47PM +0100, Lucas Nussbaum wrote: > On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote: > > With recent dpkg(-source) changes, many packages are again failing to > > build twice in a row, because of uncommitted upstream changes. Fixing > > this was a lenny release goal, maybe it should be one again?!? Most > > importantly, maybe someone who has access to one of those build grids > > can run the old tests again, because I feel by accidentally stumbling > > upon these problems we will not be able to find and fix many of them any > > time soon. > > Is it really worth it? There are many ways to work-around this, such as > using a temporary git repo to be able to 'git clean' and return to a > clean state before each build. If I'm fixing an RC bug, it's very convenient to be able to test a patch and then rebuild with a different patch if necessary. If the package doesn't build cleanly N times in a row, or if there are other problems with the packaging that make it difficult to fix, I usually go on to fix other bugs instead. Also, when I file a bug report, the harder you make it to fix your package, the less likely you are to receive a patch with that report, workaround or not. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: many packages fail to build twice in a row again
On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote: > With recent dpkg(-source) changes, many packages are again failing to > build twice in a row, because of uncommitted upstream changes. Fixing > this was a lenny release goal, maybe it should be one again?!? Most > importantly, maybe someone who has access to one of those build grids > can run the old tests again, because I feel by accidentally stumbling > upon these problems we will not be able to find and fix many of them any > time soon. Is it really worth it? There are many ways to work-around this, such as using a temporary git repo to be able to 'git clean' and return to a clean state before each build. Lucas -- 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/20111220203647.ga32...@xanadu.blop.info
many packages fail to build twice in a row again
With recent dpkg(-source) changes, many packages are again failing to build twice in a row, because of uncommitted upstream changes. Fixing this was a lenny release goal, maybe it should be one again?!? Most importantly, maybe someone who has access to one of those build grids can run the old tests again, because I feel by accidentally stumbling upon these problems we will not be able to find and fix many of them any time soon. -- 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/1324411304.8520.3.ca...@vanquo.pezone.net
Re: RTP
On Tue, Dec 20, 2011 at 06:06:45PM +0100, Suco wrote: > Hi, > I've found this program (http://jan.kneschke.de/projects/pxtools/) very > useful for my work, and its license is compatible with debian rules, so I > believe it would be a great idea to package it and preserver for the future. This is not the proper way to file a Request For Package. Start by running reportbug (or reportbug-ng) and choose the 'wnpp' package. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20111220190620.gd20...@decadent.org.uk
Bug#652827: ITP: hunspell-an -- Aragonese dictionary for hunspell
Package: wnpp Severity: wishlist Owner: Jordi Mallach * Package name: hunspell-an Version : 0.2 Upstream Author : Santiago Paricio Juan Pablo Martínez * URL : https://addons.mozilla.org/firefox/downloads/file/136466/corrector_ortografico_aragones-0.2-fx+tb+sm.xpi * License : (GPL-3.0+, LGPL-3+, MPL-1.1) Description : Aragonese dictionary for hunspell This is the Aragonese dictionary for use with the hunspell spellchecker. . The wordlist is built using free corpuses using Aragonese Wikipedia and Aragonese Apertium dictionaries. They are based on the Aragonese grammar as proposed by the Academia de l'Aragonés. -- 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/20111220182209.9908.20842.report...@aigua.oskuro.net
RTP
Hi, I've found this program (http://jan.kneschke.de/projects/pxtools/) very useful for my work, and its license is compatible with debian rules, so I believe it would be a great idea to package it and preserver for the future. Regards. -- Felix
Bug#652819: ITP: lico-update -- Machine update script for The New Linux Counter Project
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: lico-update Version : 0.3.17 Upstream Author : Alexander Mieland (Leader and Manager of The New Linux Counter Project) * URL : https://linuxcounter.net/ * License : GPL-2 Programming Lang: sh Description : Machine update script for The New Linux Counter Project This is the official machine-update script for LiCo - The New Linux Counter Project. This is used to create a new machine or to update an existent machine in your LiCo account. -- 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/20111220170129.25173.11536.report...@marcos.anarcat.ath.cx
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Tue, Dec 20, 2011 at 01:17:41PM +0100, J.A. Bezemer wrote: > > On Tue, 20 Dec 2011, Roger Leigh wrote: > >On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote: > >>On Mon, 19 Dec 2011, Roger Leigh wrote: > >> > >>[..] > >>> > >>>Regarding the objections above, which are primarily concerned with the > >>>creation of a non-generic initramfs, how does this alternative suggestion > >>>sound: > >>> > >>>- The addition of usr= options analogous to the root= options which > >>>permit the bootloader to specify the /usr filesystem to mount. By > >>>default would do nothing, but grub could be updated to generate > >>>such options on systems with a separate /usr. > >> > >>Nonsense, should come from /etc/fstab. > > > >Of course. In case it wasn't implicit from the above, this information > >would necessarily need to be taken from /etc/fstab by update-grub or > >its equivalent for other bootloaders when generating grub.cfg (or its > >equivalent). > > Apologies for not being clear enough: there should not be a usr= > parameter at all. Not in grub.cfg, and not anywhere else. The > initramfs itself can (i.e. should) easily read it directly from > /etc/fstab. OK, that does make sense. And it can remain entirely generic, without requiring any special bootloader support. /etc would be the exception to this, so I guess you would be happy with that being made into a separate option? This would be a rare choice, so just patching update-grub should be sufficient. Anyone else who wished to avail themselves of it could just edit the kernel command-line. > (As I remember seeing elsewhere in this discussion: you could define > a mount option "mount-in-initramfs" in /etc/fstab that the initramfs > should look for to find out which filesystems it has to fsck && > mount.) This is still a possibility. I discussed an initramfs option for /etc/fstab, but upstream would perfer us to use comment=initramfs or the new free-form x- options e.g. x-initramfs. Like /usr, this could be mounted after the rootfs, with the exception of /etc, as mentioned above. WRT fsck, I think we would continue to mount r/o prior to fsck, as for the rootfs, and then remount r/w afterward in checkroot. Regards, 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. -- 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/20111220165603.gg5...@codelibre.net
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Tue, 20 Dec 2011, Roger Leigh wrote: On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote: On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. Of course. In case it wasn't implicit from the above, this information would necessarily need to be taken from /etc/fstab by update-grub or its equivalent for other bootloaders when generating grub.cfg (or its equivalent). Apologies for not being clear enough: there should not be a usr= parameter at all. Not in grub.cfg, and not anywhere else. The initramfs itself can (i.e. should) easily read it directly from /etc/fstab. (As I remember seeing elsewhere in this discussion: you could define a mount option "mount-in-initramfs" in /etc/fstab that the initramfs should look for to find out which filesystems it has to fsck && mount.) Best regards, Anne Bezemer -- 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/pine.lnx.4.64.1112201247070.18...@wormhole.robuust.nl
Bug#652731: ITP: extsmail -- enables the robust sending of e-mail to external commands.
Package: wnpp Severity: wishlist Owner: oliv...@biniou.info Package name: extsmail Version : 1.4 Upstream Author : Laurence Tratt URL : http://tratt.net/laurie/src/extsmail/ License : BSD, MIT Programming Lang: C Description : enables the robust sending of e-mail to external commands. extsmail enables the robust sending of e-mail to external commands. extsmail masquerades as the standard UNIX "sendmail" program, reading messages, and later piping them to user-defined commands. In a sense, extsmail can be thought of as a very simple "tiny" sendmail. A typical use is to allow e-mail to be piped via SSH to external servers running a full sendmail-compatible MTA. extsmail is designed to have sensible defaults, and configuring it is a one-off, quick job. -- 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/20111220104307.31351.69245.report...@cthulhu.biniou.net
Re: uscan, watch files, and gihub tags
Hi Paul, Am Tue, 20 Dec 2011 09:12:13 +0800 schrieb Paul Wise : > On Tue, Dec 20, 2011 at 5:24 AM, Andreas Rütten wrote: > > > I assume the "tags as .tar.gz" feature is something special from > > github. Or could I use also tags from e.g. git.debian.de in a > > watchfile? > > git.debian.de doesn't exist so that would not work. you are absolutely right, I meant git.debian.org Sorry for the misconception. > As for non-github sites, gitweb doesn't appear to support this, but > cgit does: > > http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/refs/tags As far as I can see git.debian.org offers only http[s] access via gitweb so we don't have it there per default. But I found a snapshot feature in gitweb.conf (5) http://www.manpagez.com/man/5/gitweb.conf/ Looks like this could do the trick. Thanks, Andreas -- Andreas Rütten andreasruet...@gmx.de 4096R: 0x6C9DFFB2 / 8394 99DA 59BD BCE2 3FC8 3A9E 6633 0089 6C9D FFB2 signature.asc Description: PGP signature
Re: /etc/mtab and /lib/init/rw migration; libpam-mount breakage
> There's some obscure bug in the upstream src/Makefile.am though--it's
> missing libcryptsetup and OpenSSL libs when linking, which causes
> link failures. The actual Makefile looks like it's correct though,
> so not sure what's wrong. If anyone who uses is wants to fix that,
> that's all (I think) that's blocking their upload.
It was forgotten to link pmt-ehd against libcryptsetup if this was
available (I believe this has been triggered by the "new" linker
behaviour to imply --no-add-needed, so the dependency on libcryptsetup
has not been silently resolved by linking against libcryptmount anymore,
which itself is linked against libcryptsetup). Please find this issue
fixed in the attached patch.
However, libpam-mount is still missing Build-Depends on libmount-dev and
libblkid-dev.
Cheers,
Fabian
Author: Fabian Greffrath
Description: Link pmt-ehd against libcryptsetup if this is available
--- libpam-mount-2.13.orig/src/Makefile.am
+++ libpam-mount-2.13/src/Makefile.am
@@ -77,6 +77,9 @@ mount_crypt_LDADD = libcryptmount.la lib
pmt_ehd_SOURCES = ehd.c bdev.c misc.c spawn.c
pmt_ehd_LDADD = libcryptmount.la ${libHX_LIBS}
+if HAVE_LIBCRYPTSETUP
+pmt_ehd_LDADD += ${libcryptsetup_LIBS}
+endif
pmt_fd0ssh_SOURCES = fd0ssh.c
