Re: Busybox 1.27 breaks kernel cmdline preseeding
Hi, On Mon, 27 Nov 2017, Mathieu Trudel-Lapierre wrote: > On Mon, Nov 27, 2017 at 3:08 PM, Raphael Hertzog <hert...@debian.org> wrote: > [...] > > I pushed a pu/kernel-cmdline-preseed branch implementing the preseeding > > out of /proc/cmdline. It's more elaborate than Mathieu's patch > > (https://paste.ubuntu.com/26034695/) in that it is able to handle > > multi-word values. > > > > I tested it locally and it fixes the rescue mode for me. For > > consistency, I renamed the command and the udeb, but the only place > > where it matters is in "debian-installer" itself where we have to update > > the package name. > > That will work on most arches, but not on kfreebsd/*. That said, the > easy fix would be to look at both environment and /proc/cmdline. We wants to stop using the environment because busybox hides it from us... I don't see the point of continuing to use it. Can you elaborate on what's wrong with /proc/cmdline on kfreebsd? We know that it exists. Are you saying that it doesn't contain the actual parameters passed on the kernel command line at boot time? I put debian-bsd@lists.debian.org in copy to have their feedback/advice. Is there any other way to get the parameters passed on the kernel command line? > I *think* you only really need -e 's/\([^ =]*=[^ "]\)/\n\1/g' -e > "s/\([^ =]*=[^ ']\)/\n\1/g" to multiline the entries and appropriately > handle any multiword. With my limited testing it seemed to work well, > and would be less complex than your solution ;) > > Did I miss some important corner-case? At least it does not cope well with parameters without any "=". Try adding words like "quiet" in the middle of your parameter list. They do not end up on a line of their own. I freely admit that my solution is complex but I was not able to find a simpler one that works well enough with my test case: language=fr_FR long?='1 2 3' rescue/enable="true" my/description="un message" --- quiet Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Bits from the Release Team: Architecture health check
On Wed, 29 Jan 2014, Russ Allbery wrote: aren't as large of a porting issue). Rather, the question is whether it is actually viable to separate those services from systemd as init and port logind to non-Linux, whether that work will be done in time for jessie, and who is going to do it. Steve Langasek believes that logind can be separated from systemd (using the code base in systemd v204) but even in that version, logind does rely on cgroups heavily and so it is not portable to kfreebsd. So the console kit path seems like the only option so far (unless someone ports logind to use some other freebsd technology). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140130071532.gb29...@x230-buxy.home.ouaza.com
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On Mon, 23 Dec 2013, Guillem Jover wrote: The problem is that something messes with dpkg's standard output and error, and it fails when doing the fflush() and ferror() check on it in m_output() I think. But this seems to be coming from something lower than dpkg or apt, perhaps a change in glibc or the kernel. As I've tried with downgraded versions matching the ones in stable, and it still fails. I've not tested further. The last thing reported from dpkg to apt through the status-fd channel is: status: git : error : error writing to 'standard output': No such file or directory This is not without reminding me of this years old bug on launchpad (with hundreds of duplicates) that we never clearly understood: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/545790 I don't know if they are related but if that's the case, then it's good to finally have a way to reproduce it more reliably. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131223073257.gb9...@x230-buxy.home.ouaza.com
Re: Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
reassign 585767 type-handling 0.2.23 thanks Hi Kyle, On Sun, 13 Jun 2010, Kyle Moffett wrote: Package: dpkg Version: 1.15.7.2 Severity: important User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe I'm actually a little unsure if this is a dpkg bug or a package bug, but I have had build failures from several packages which have Build-Depends like the following: (trimmed example from the gvfs-1.6.2-1 source package) libudev-dev (= 0.139) | not+linux-gnu, libfuse-dev | hurd, libhal-dev (= 0.5.10) | linux-gnu, libgdu-dev (= 2.29.0) | not+linux-gnu, libgudev-1.0-dev (= 001) | not+linux-gnu, libbluetooth-dev (= 4.0) | not+linux-gnu, libimobiledevice-dev (= 0.9.7) | hurd Unfortunately it seems like the powerpcspe and armel architectures do not provide the virtual packages linux-gnu and they do provide the virtual package not+linux-gnu, although if I change those deps to linux and not+linux then they behave as expected. This seems to be related to the fact that the triplettable entries for those architectures map them as linux-gnuspe and linux-gnueabi respectively, instead of linux-gnu. Those virtual packages are provided by the type-handling packages so I reassign it there if the provides are incorrect. On the other hand, I'm not entirely certain those package dependencies are compliant with current Debian Policy. I believe those package dependencies should be written as follows: libudev-dev (= 0.139) [linux-any], libfuse-dev [!hurd-any], libhal-dev (= 0.5.10) [!linux-any], libgdu-dev (= 2.29.0) [linux-any], libgudev-1.0-dev (= 001) [linux-any], libbluetooth-dev (= 4.0) [linux-any], libimobiledevice-dev (= 0.97) [!hurd-any] So I guess the question is whether the linux-gnu vs. not+linux-gnu behavior is correct, or alternatively whether or not it violates policy. You're right that it's best to use the real architectutre wildcards nowadays (#530687 it will be in policy soon). If the latter, perhaps dpkg-buildpackage should be patched to issue very loud warnings when those dependencies are detected as they are known to have incorrect behaviour on some platforms. That's rather a task for lintian. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100613191231.gb17...@rivendell
Bug#538558: Source format 3.0 (quilt) allowed in testing/unstable
[ Same message sent in bcc to all remaining FTBFS with new source format ] Hello, the new source format 3.0 (quilt) is now allowed in testing/unstable and having all packages buildable with the new format is a release goal (http://wiki.debian.org/ReleaseGoals/NewDebFormats). Thus it would be nice to see this bug fixed. If you want, you can directly fix the bug by switching the package to use the new format. In order to help you in this process, I have put some advice on the project page and will continue to complete it with answers to your questions: http://wiki.debian.org/Projects/DebSrc3.0#FAQ If you need help, please tag the bug help and someone might provide you a patch. Ask explicitely if you want a patch to convert the package to the new source format. The few packages that contain multiple tarballs in the .orig tarball should (ideally) be converted to the new format by using the multiple upstream tarball feature that it offers. I also recommend switching to quilt if you use another patch system since it's now the patch system that is endorsed by the dpkg maintainers. If you have questions, please ask. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#452279: type-handling: Invalid Provides: header on amd64
Package: type-handling Version: 0.2.21 Severity: important (I'm reporting this from an i386 host but the problem concerns amd64 primarily) Since dpkg-dev 1.14.8, on any amd64 system with type-handling installed, dpkg-checkbuildeps is reporting a warning: can't parse dependency x86_64-linux-gnu This is generated while parsing /var/lib/dpkg/status, more precisely while parsing the Provides: field of type-handling. x86_64-linux-gnu is not a valid package name and is thus rejected by the parser included in the Dpkg::Deps perl module. Please transform _ in - or simply remove the entry in the provides field. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages type-handling depends on: ii dpkg-dev 1.14.9 package building tools for Debian type-handling recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Hurd and Debian GNU/*BSD
Hi, Le Sat, Mar 09, 2002 at 03:03:46PM +0100, Robert Millan écrivait: What is your personal opinion on those ports? I'm in favor of those ports, and as such I'm willing to make the required changes. However I'm not sure they can get done for woody+1 considering that we are targetting on a shorter release. :-) But it is a work that should certainly start now because I guess that it will be a long-lasting effort. Anyway, I have to admit that I have used neither The Hurd nor any BSD. But I have several friends who switched from Debian to FreeBSD and I would like to provide them a Debian BSD. The BSD kernels also have a strong reputation and they look like good pieces of code; I don't see why they couldn't have their place within Debian. The Hurd is already integrated within Debian, and I wish it can continue its progress with those changes. Will you support the above mentioned changes? Yes. Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Formation Linux et logiciel libre : http://www.logidee.com pgpgyYdcsXgZf.pgp Description: PGP signature
