Re: adventures in UEFI PXE land
Hi
[ grub-efi's actual package names are architecture dependent, my
explantions below use grub-efi-amd64 (64 bit UEFI for x86_64) for
examples, substitute it with grub-efi-ia32, grub-efi-arm or
grub-efi-arm64 where needed. ]
On 2015-03-05, Paul Wise wrote:
[...]
I had some adventures in UEFI land. I had an Intel NUC fried during a
lightning storm but the hard drive was fine so I wanted to get the hard
drive to boot within a new NUC. I didn't have any USB stick so I went
with PXE boot from my laptop. The existing system on the hard drive was
wheezy but the installer image I was using was jessie.
Once you're on jessie's version of grub-efi, I'd suggest to configure
grub-efi-amd64's debconf settings to include (unless you're dual booting
with an OS that reclaims /boot/efi/EFI/BOOT/ for itself, e.g. windows is
supposed to do this):
grub-efi-amd64 grub2/force_efi_extra_removable boolean true
This instructs (very recent) grub-efi packages to also install itself
to the default path (originally intended) for removable media, in other
words a fallback location the UEFI mainboard firmware can find and load
without an UEFI boot entry. This allows you to simply move the HDD to
another UEFI based system (of the same UEFI architecture) and boot from
that HDD directly (by selecting it from the boot manager included in
your mainboard's UEFI firmware). Some mainboard firmwares also tend to
forget UEFI boot entries after upgrading itself (some extremely buggy
ones forget it after each reboot)...
Using this fallback procedure allows to avoid using an external rescue
medium when moving harddisks to another system (or in the other
scenarios of broken mainboard firmwares depicted above), however it's
only a safe setting if no other operating systems claim that location
in dual-boot environments.
Even on wheezy (or jessie without grub2/force_efi_extra_removable being
set), it would have been possible to copy /boot/efi/EFI/debian/grubx64.efi
to /boot/efi/EFI/BOOT/BOOTX64.EFI and your mainboard's UEFI firmware
should have offered /boot/efi/EFI/BOOT/BOOTX64.EFI for booting the already
installed system without having to use an external rescue system, like
d-i (assuming the default MODULES=most in
/etc/initramfs-tools/initramfs.conf and no too special customisations).
[...]
Intel Visual Boot Manager had a question mark as the Debian icon instead
of the swirl and the name of the OS was debian instead of Debian.
[...]
Debian's grub packages, which are the ones steering efibootmgr to set up
the UEFI entries behind the curtain, enforce all-lowercase for the UEFI
boot entries.
/var/lib/dpkg/info/grub-efi-amd64.postinst:
[...]
grub-efi-ia32|grub-efi-amd64|grub-efi-ia64|grub-efi-arm|grub-efi-arm64)
bootloader_id=$(config_item GRUB_DISTRIBUTOR | tr A-Z a-z | \
cut -d' ' -f1)
[...]
GRUB_DISTRIBUTOR is defined in /etc/default/grub and must correspond
to the path used on the EFI System Partition, which is on a FAT32
filesystem. grub-efi requires /boot/efi/EFI/${GRUB_DISTRIBUTOR}/ to
pre-exist or it will silently skip invoking efibootmgr.
Regards
Stefan Lippers-Hollmann
pgpVvVWpRipn_.pgp
Description: Digitale Signatur von OpenPGP
Bug#779890: udhcpd: Support for multiple interfaces/udhcpd processes
Package: udhcpd Version: 1:1.20.0-7 Severity: wishlist The documentation seems to suggest udhcpd can only handle binding to one interface and using one IP address range per udhcpd process. Due to this, it would be handy if Debian's init scripts had support for starting/stopping multiple udhcpd processes (this would mean require multiple .conf and .pid files). When reading the man page I was wondering, could multiple configuration files be specified on udhcpd's command-line and would this have the effect of starting multiple udhcpd processes? (I rather doubt it, but the man page could be read that way) -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include stddisclaimer.h O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 -PGP- 41D1 B375 37D0 8714\_|_/___/5445 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150305235736.ga51...@scollay.m5p.com
Bug#779890: udhcpd: Support for multiple interfaces/udhcpd processes
Upon a bit more thinking about the situation, I must suggest the overlapping feature of adding a hook script to allow udhcpd to be started/stopped by `ifupdown` instead of only by init script. This ends up dovetailing into support for multiple interfaces. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include stddisclaimer.h O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 -PGP- 41D1 B375 37D0 8714\_|_/___/5445 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150306032746.ga52...@scollay.m5p.com
Re: Hints for d-i jessie RC2, part 1
Cyril Brulebois, le Thu 05 Mar 2015 07:07:27 +0100, a écrit : here's a first round of unblock/unblock-udeb hints for the upcoming d-i jessie RC2. Don't hesitate to ask questions if anything looks fishy. Can we also perhaps unblock tasksel/3.30? It removes old dependencies, fixes desktop preseeding and fixes accessibility of libreoffice. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150305083102.gm2...@type.youpi.perso.aquilenet.fr
adventures in UEFI PXE land
Hi all, I had some adventures in UEFI land. I had an Intel NUC fried during a lightning storm but the hard drive was fine so I wanted to get the hard drive to boot within a new NUC. I didn't have any USB stick so I went with PXE boot from my laptop. The existing system on the hard drive was wheezy but the installer image I was using was jessie. Initial attempts at PXE booting in UEFI mode failed, this turned out to be because I was booting pxelinux.0 instead of bootnetx64.efi. The installer manual needs to mention bootnetx64.efi in the PXE boot instructions in relation to UEFI so people know what to boot. The netboot.tar.gz doesn't have a symlink from bootnetx64.efi in the top-level directory to debian-installer/amd64/bootnetx64.efi. When I tried to do a grub reinstall, it failed. I did it manually and had to mount /boot/efi for it to work. On #debian it was mentioned that fixmbr needs to be fixed for this. Intel Visual Boot Manager had a question mark as the Debian icon instead of the swirl and the name of the OS was debian instead of Debian. I noticed that debian-installer-7.0-netboot-* packages are still in jessie even though they are(?) for wheezy. Any thoughts on what I should do with these observations? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Processing of flash-kernel_3.34~exp.1_source.changes
flash-kernel_3.34~exp.1_source.changes uploaded successfully to localhost along with the files: flash-kernel_3.34~exp.1.dsc flash-kernel_3.34~exp.1.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ytqbj-0007lr...@franck.debian.org
Processing of flash-kernel_3.33_source.changes
flash-kernel_3.33_source.changes uploaded successfully to localhost along with the files: flash-kernel_3.33.dsc flash-kernel_3.33.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ytqbj-0007lk...@franck.debian.org
Processing of flash-kernel_3.33_source.changes
flash-kernel_3.33_source.changes uploaded successfully to ftp-master.debian.org along with the files: flash-kernel_3.33.dsc flash-kernel_3.33.tar.xz Greetings, Your Debian queue daemon (running on host coccia.debian.org) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ytqwa-0004ks...@coccia.debian.org
Processing of flash-kernel_3.34~exp.1_source.changes
flash-kernel_3.34~exp.1_source.changes uploaded successfully to ftp-master.debian.org along with the files: flash-kernel_3.34~exp.1.dsc flash-kernel_3.34~exp.1.tar.xz Greetings, Your Debian queue daemon (running on host coccia.debian.org) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ytqwd-0004ky...@coccia.debian.org
Re: Hints for d-i jessie RC2, part 1
On 2015-03-05 12:16, Cyril Brulebois wrote: Samuel Thibault sthiba...@debian.org (2015-03-05): Cyril Brulebois, le Thu 05 Mar 2015 07:07:27 +0100, a écrit : here's a first round of unblock/unblock-udeb hints for the upcoming d-i jessie RC2. Don't hesitate to ask questions if anything looks fishy. Can we also perhaps unblock tasksel/3.30? It removes old dependencies, fixes desktop preseeding and fixes accessibility of libreoffice. Sure, no objections. Mraw, KiBi. Ok, added an unblock for tasksel/3.30 as well. ~Niels -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f86053.8040...@thykier.net
flash-kernel_3.34~exp.1_source.changes ACCEPTED into experimental
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 05 Mar 2015 07:00:54 + Source: flash-kernel Binary: flash-kernel flash-kernel-installer Architecture: source Version: 3.34~exp.1 Distribution: experimental Urgency: medium Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Ian Campbell i...@debian.org Description: flash-kernel - utility to make certain embedded devices bootable flash-kernel-installer - Make the system bootable (udeb) Changes: flash-kernel (3.34~exp.1) experimental; urgency=medium . * Merge up changes from 3.33 Checksums-Sha1: d6cb7619f4d101ce07e94bcf655e76ebe45eca5d 1881 flash-kernel_3.34~exp.1.dsc 3332f064d2fb40caa61195d75394a4fe60f3ec9d 58556 flash-kernel_3.34~exp.1.tar.xz Checksums-Sha256: b96e0812f1e250405101961f02eb016e091b6d6cf35452296a91f6d82d81242f 1881 flash-kernel_3.34~exp.1.dsc fd1295338c8a1ca61b5f06bebc5b466a3bcd57c64cf1eca68057f5db098b0206 58556 flash-kernel_3.34~exp.1.tar.xz Files: 363ce3bea72c91740caeb81caf930d83 1881 utils optional flash-kernel_3.34~exp.1.dsc 359b5c1b62f6d73ad1d7c9eab1068b01 58556 utils optional flash-kernel_3.34~exp.1.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU9/9/AAoJECouJZ9pWkbG48gQAJRvuhxiTgJnv4wuNx12Gx4y J8Mz4DCiHg+X1JgXH7t/oBJpmhgHrD7PAS432eimg5FwEfnosPpNDkmXvjXWclAF 95eMmIMI6SAZRW9co2q8NkWMvI54ZtucjtWcWWpiCM4fMCS0MmevSfxmv5mQ4Otw 3LQdAvjMRhc+uiimJBh1BykBWPmYoXz4491utK92msEfMgti0ECGIOL/ttiru9y0 QZs/h3d8gkv99s1NnglYmhCCBl8pw3bLLi43Yj62Yij4xILAU7sSOupNyEQK6kPN F1R+Qyi0orb1v2xIwE5h7mOs4SBqB5J99EmJLL+N39ADdh7XAIzfKV/uLv6NyPRU UZ5lgNgjltVQVqZ+3rEmwWjwvyZ0+5e0Y5U1O07vlmtRcg8xdTdqzaHuWPJhv61g 6F0eMLku5jSCgF8QemU1pk4i4L+kRXSmuefrFJ0LxlhM8MEw1nyIYI/fpgvh/edw uEjnsIr+z2UjNFatiPf8ypjAtoj2v4o3x6k6GRMJHV1qSa3JdWhmNJO/kqtBU5WS 37ojDRWOJTvGe51antboj5vehJKP3si5O1AN5Gubokya7Nt2vs80L1YnfHfY93By st2d/LOOWk2HPAI5wMMgraqfWUNvRc+oYyQuj/gNsy4GrfeFn7rPJLf7LvDQVHJ2 HKbQMMhbmncNwbVuYzrv =MwTv -END PGP SIGNATURE- Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ytrvp-hl...@franck.debian.org
flash-kernel_3.33_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 05 Mar 2015 06:56:34 + Source: flash-kernel Binary: flash-kernel flash-kernel-installer Architecture: source Version: 3.33 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Ian Campbell i...@debian.org Description: flash-kernel - utility to make certain embedded devices bootable flash-kernel-installer - Make the system bootable (udeb) Changes: flash-kernel (3.33) unstable; urgency=medium . [ Karsten Merker ] * Add a machine db entry for the LeMaker Banana Pro. Checksums-Sha1: 0bfc3010c7de11034425e966bc9aba1dc5579280 1857 flash-kernel_3.33.dsc 1c1dc741f2717a29e801910ab088c021f0603ab1 56244 flash-kernel_3.33.tar.xz Checksums-Sha256: d8eb588a0d2aab1a646a8826835206c6f9e88e6de3332f32e0b462f44f4a66c0 1857 flash-kernel_3.33.dsc 9b44d0117bdba7c497880b8a6e5b4e56fcfbddf5eb7380cf192e187881459726 56244 flash-kernel_3.33.tar.xz Files: fedb56457c43e00f33a36b6b5747af4d 1857 utils optional flash-kernel_3.33.dsc 43207cd3d1267fb1a23db65144af8e3c 56244 utils optional flash-kernel_3.33.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU9/59AAoJECouJZ9pWkbGc5kQAJpgtUlFwZzDM1anXhzloPmd NvMHzLHH9DgbrWZiYBshBPYHISzX1za3Tgki8hLt8kt0XHJf6tNI5w4B6dRivURW KKq7bt1T/El0WAvubNiMZVSSg4jEeN8AO4xok55FNWVoXrwXF09Z2VaolnAeAwnE c78mBFmvlWa4bj3dFpXVVBcYEDKXxWLlDjlhLEN6Ed5treWWtLKTPAQoajra4dNv TdEKQ8KtiMRwWs79vLDYYu5sjF4HDpgBhJlFBzVC+hx2VyQIU0ag1JxDPyD0hPIh A+G3HzCoF9o3EClfr3OvTMOAeNdGzLmojwwoirvO5ZeFNUTifd5tgDgF31NwmXJA YCXZjsM8gmXFDyJfhy0yYI0o0KDwWnxrL96WWDA4xx3fub1LFJFiEl+O6NGf8Ovq lqW7uz/LUd7N57SBwh9kuoJUdGXueQJ4riF2rHnB5IUvRiNxaEL7FqN5ePO/Okg7 FTBOHKyhEBMDCK1bKanKFy6gN0J69t3UNKEeFiOxd8Z18Wxs4rgboYj09pMlxU25 UnI+Ki2NhpG/3vYI38EUA05e1gw+B6wfBEqXU4JB8wdNB7nbpFCQ2zEqm9fKGd+e 7BkAwj7z3+2ecJQ3Ok7JdNZgvW8ZHafYc/8fc6uYoYdMltGHXj5rpg/ynvxPvUTm KK2KaV9FuS2J4R2n+zYT =sgf2 -END PGP SIGNATURE- Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ytrvk-gs...@franck.debian.org
Re: Hints for d-i jessie RC2, part 1
Samuel Thibault sthiba...@debian.org (2015-03-05): Cyril Brulebois, le Thu 05 Mar 2015 07:07:27 +0100, a écrit : here's a first round of unblock/unblock-udeb hints for the upcoming d-i jessie RC2. Don't hesitate to ask questions if anything looks fishy. Can we also perhaps unblock tasksel/3.30? It removes old dependencies, fixes desktop preseeding and fixes accessibility of libreoffice. Sure, no objections. Mraw, KiBi. signature.asc Description: Digital signature
Re: bastardizing packages or stepping down
Hi, Making no comment on the remainder of the mail: On 2015-03-05 10:38, Michael Tokarev wrote: And since I can't do my work, I'm stepping down from being busybox maintainer, and am kindly asking the release team to remove my name from debian/control file in busybox, so that people don't blame me for things I can't do. I don't believe it would be appropriate for us to do so. We have no control or say in who maintains packages (beyond that available to any other DD or interested contributor). Regards, Adam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3096c5baa7a53b477a9cf7fb151e7...@mail.adsl.funky-badger.org
Re: bastardizing packages or stepping down
Hi, Bah, so much for a quick response that I thought was simple and uncontroversial. :-) On 2015-03-05 12:08, Sam Hartman wrote: Adam, let's assume for the moment I've got that right. I'm trying to connect with the frustration I'd feel if I were told that I didn't even have the power to distance myself from something I couldn't in good conscious claim to support. I hope that there's some way that michael can approach stepping away from the package in jessie if he wants to. If what you're saying is that his proposed mechanism for doing that is the wrong one, would you be willing to help him out and suggest a mechanism you believe to be more appropriate? Yes, I'm specifically saying that I don't believe the Release Team has the authority to do what Michael is asking of us, nor do I believe we should do so. (Individual DDs who are part of the team can of course do so. Apologies if this seems like splitting hairs, but I think the distinction is important.) The way I'd expect a voluntary change of maintainership to be made would be via an upload either by the existing maintainer, another member of the maintainer team (where appropriate) or the new maintainer (or I guess $RANDOMDD as a QA upload with maintainer's consent or similar). I'm certainly not saying that Michael shouldn't be able to remove himself, simply that I'd feel uncomfortable with the Release Team as an entity doing so. (Perhaps you'd approve an ublock for an upload that simply changed maintainer to debian-qa?) For the record, the Maintainer: listed in the package is debian-boot; Michael's in Uploaders. If it's really that much of an issue then I imagine they could be persuaded to remove his name from the package and in that case I can't see that getting it migrated under those circumstances would be a huge problem. If what you're saying is that you see no mechanism for him to step away from a package he no longer feels he can maintain because he and the release team disagree with the desired contents of that package in Jessie I'm not sure the Release Team has expressed any particular opinion on the desired contents of the package beyond deferring to the d-i RM. I admit that I haven't gone back and checked through the full history of the unblock requests though, so I may have missed something. Regards, Adam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/31296833bbe23bf2ae79747b8b488...@mail.adsl.funky-badger.org
Re: bastardizing packages or stepping down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 05.03.2015 15:08, Sam Hartman wrote: Adam == Adam D Barratt a...@adam-barratt.org.uk writes: Adam Hi, Making no comment on the remainder of the mail: Adam On 2015-03-05 10:38, Michael Tokarev wrote: And since I can't do my work, I'm stepping down from being busybox maintainer, and am kindly asking the release team to remove my name from debian/control file in busybox, so that people don't blame me for things I can't do. Adam I don't believe it would be appropriate for us to do so. We Adam have no control or say in who maintains packages (beyond that Adam available to any other DD or interested contributor). michael, I'd like to ask if I'm hearing you correctly. So, what I'm hearing is very strong frustration. You had hoped that you would have the power to produce a package that you'd be happy being responsible for. However you don't believe that you have that power; you're saying that changes you consider essential to creating a busybox you're comfortable being responsible for are rejected. Am I hearing you correctly? Well. It is not about being happy or being powerful. It is about at least understanding the reasons why we should take bad and have more work instead of taking good and have peace. This is the main source of frustration, and this is the main question which went unanswered so far. The main changes I've made (this build-using thing plus a build-time glibc check) are _only_ needed for jessie, since after jessie this whole single issue will really be history, while for jessie it isn't history yet, like a story with buildds demonstrating. Another source of frustration is the fact that all the changes in question does not break things, it does not hurt anyone, and especially does not affect the D-I in any way whatsoever, but are being rejected on the D-I side. Another frustration comes because much more intrusive but much less needed changes are being happily accepted after the deadlines, even if here, I missed the deadlines because of factors not under my control, but trying my best. So, the main point is that apparently it is better to do more work and make everyone frustrated than to just accept already (hopefully well-) done work and continue peacfully. I don't see the reason WHY (hence I Cc'd ctte). It is not about power. Adam, let's assume for the moment I've got that right. I'm trying to connect with the frustration I'd feel if I were told that I didn't even have the power to distance myself from something I couldn't in good conscious claim to support. I hope that there's some way that michael can approach stepping away from the package in jessie if he wants to. If what you're saying is that his proposed mechanism for doing that is the wrong one, would you be willing to help him out and suggest a mechanism you believe to be more appropriate? (Perhaps you'd approve an ublock for an upload that simply changed maintainer to debian-qa?) There's no need to change maintainer, it is debian-boot (d-i team) and it remains like that, at least in busybox. In busybox my name is in Uploaders: field only. For mdadm, on the other hand, even if it is set as team-maintained, the sole maintainer is me, so that'd be appropriate to change maintainer to debian-qa. Both packages affects d-i, and for the reasons I already described, I can't do that myself, since I'll face the same unblock request process from the D-I team. More, I don't really want to keep my name as the author of last changelog entry in this case. If what you're saying is that you see no mechanism for him to step away from a package he no longer feels he can maintain because he and the release team disagree with the desired contents of that package in Jessie, then I respectfully ask you to reconsider that position. That sort of thing would likely drive me away from the entire project, not just one package. Actually this was my first reaction, but I thought I'd wait for a bit and just point out a possible defect in debian, possible request for discussion. Micahel, one final question to you. Are you firmly committed to the path of stepping away from busybox maintenance, or would you be willing to re-evaluate that decision after we see what comes of your request for understanding? I don't believe there's any other alternative actually. I dunno, it is difficult to think. I wanted to understand the WHY first, because clearly, as I tried to describe, I don't see, at all, why this is done. I don't really feel powerless, that's not the problem, after all no single person should have absolute powers (including Cyril, no matter how respectful I or anyone else is for him due to his work). After all I always have absolute power to continue maintaining the package locally, and that's what I definitely will do, because I depend on it and I don't want it to become in that really bad shape it was before me. But so
bastardizing packages or stepping down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I didn't really want to write this email, but it looks I now have to, even if, for reasons which whill be shown below, don't expect any good news from this. Trying to make the story short. For quite some time we had a bug in glibc in jessie which resulted in statically-linked applications malfunctioning when using any of nsswitch-related functionality (eg gethostbyname() etc), #757941. This glibc bug resulted in bugreport about busybox package -- #769190 (#757941 has been filed against busybox too, initially). The problem was that many busybox applets didn't work in static build. That bug was rather fun, because even if it is fixed in glibc, your package depends on the fixed version to be present on all buildds, or else the resulting binary will be buggy again. This is exactly what happened with #769190 -- to work around initial #757941 in bb, it has been bin-NMUed and rebuilt with a fixed glibc. But once I uploaded a next release of busybox to the archive, it was rebuilt using older, unfixed glibc, and the original problem reappeared. For added fun, since glibc package names are architecture-dependent, it is rather difficult to express all necessary build-depends correctly. Having all this, and having in mind that at least initially you don't know if this particular build of your package is affected or not, another bug has been filed against busybox -- #768876, requesting that busybox-static have a Built-Using field to allow seeing which glibc version it was built against, at least. This bugreport (#768876, built-using) is of serious severity and is tagged with jessie-ignore, not because it is irrelevant for jessie but because it is _difficult_ to fix and the package already received manual treatment to be rebuilt against a fixed glibc version. Understanding the actual severity of this problem, I tried to fix this before jessie, because I know it is important to do so (see below). I had fever at that time, and fixing it turned out rather difficult and required several iterations to finally get it right. I especially tried to fix that as fast as possible despite the fever, because it was near jessie freeze so, even if I was absolutely sure it wont be a problem to accept these changes to jessie, I didn't want to add more work for already busy enough release team to review and accept the changes. But at that time things didn't go right, because it turned out many buildds are still having old version of glibc and the resulting binary is buggy again. So I tried to add a versioned build-dependency on glibc, which too took several iterations because glibc package names are arch-specific and because I wanted to keep ability of busybox to be compiled against old version of glibc (eg for backports), both of which finally worked. Also I added a built-time test which builds a tiny static program which does getpwnam(root), to verify before build that the build environment is able to produce static executables at all. At least this should ensure we wont have known-broken binary after a successful build. All 3 changes -- the generation of Built-Using field, the build-time test to ensure static linking works, and addition of extra build-depends field -- are small and self-contained in d/rules (or d/control) file, easy to review or remove when it all really becomes history. Meanwhile I fixed another, unrelated, buglet in the package which annoyed me enough during these multiple uploads -- I changed d/rules so it does not produce arch-all package (busybox-syslogd) when asked only to produce arch-specific packages. This was a bit larger change in d/rules but is a well tested in other packages. Neither of these changes, and this is important point, -- neither of these changes affects the resulting binary packages on a system where glibc is fixed. The changes adds one extra field (Built-Using) to busybox-static package, ensures the build environment is able to produce a static binary and introduces a versioned build-depends on libc which allows us to build the package either with fixed glibc version or with glibc which does not have that bug yet. After all this it turned out that several buildds were still having issues with the new build-depends, so the package were attempted to build multiple times - some buildds had unfixed glibc so build-depends were impossible to satisfy. More, it turned out hurd-i386 build env is not able to produce a working statically-linked getpwnam(root) binary at all. So I pinged buildd maintainers asking to update glibc, I also contacted hurd people asking what to do (hurd is not a release arch but it is in buildd and if I can fix hurd before freeze so I wont need to add more work for the release team that'd be nice). But time was, ofcourse, ticking. (Btw, I received no replies to my inquires about release-goal buildds, however after numerous attempts buildd network finally was able to produce working busybox
Re: bastardizing packages or stepping down
Adam == Adam D Barratt a...@adam-barratt.org.uk writes: Adam Hi, Making no comment on the remainder of the mail: Adam On 2015-03-05 10:38, Michael Tokarev wrote: And since I can't do my work, I'm stepping down from being busybox maintainer, and am kindly asking the release team to remove my name from debian/control file in busybox, so that people don't blame me for things I can't do. Adam I don't believe it would be appropriate for us to do so. We Adam have no control or say in who maintains packages (beyond that Adam available to any other DD or interested contributor). michael, I'd like to ask if I'm hearing you correctly. So, what I'm hearing is very strong frustration. You had hoped that you would have the power to produce a package that you'd be happy being responsible for. However you don't believe that you have that power; you're saying that changes you consider essential to creating a busybox you're comfortable being responsible for are rejected. Am I hearing you correctly? Adam, let's assume for the moment I've got that right. I'm trying to connect with the frustration I'd feel if I were told that I didn't even have the power to distance myself from something I couldn't in good conscious claim to support. I hope that there's some way that michael can approach stepping away from the package in jessie if he wants to. If what you're saying is that his proposed mechanism for doing that is the wrong one, would you be willing to help him out and suggest a mechanism you believe to be more appropriate? (Perhaps you'd approve an ublock for an upload that simply changed maintainer to debian-qa?) If what you're saying is that you see no mechanism for him to step away from a package he no longer feels he can maintain because he and the release team disagree with the desired contents of that package in Jessie, then I respectfully ask you to reconsider that position. That sort of thing would likely drive me away from the entire project, not just one package. Micahel, one final question to you. Are you firmly committed to the path of stepping away from busybox maintenance, or would you be willing to re-evaluate that decision after we see what comes of your request for understanding? thanks for your consideration, --Sam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014be9d67c2a-235bd750-20d6-4195-86ca-98841d13dc39-000...@email.amazonses.com
Bug#779890: udhcpd: Support for multiple interfaces/udhcpd processes
06.03.2015 02:57, Elliott Mitchell wrote: Package: udhcpd Version: 1:1.20.0-7 Severity: wishlist The documentation seems to suggest udhcpd can only handle binding to one interface and using one IP address range per udhcpd process. Due to this, it would be handy if Debian's init scripts had support for starting/stopping multiple udhcpd processes (this would mean require multiple .conf and .pid files). I suggest using some more advanced dhcp servers for this, for example there's an excellent piece of software named dnsmasq which is small and has other useful functionality. Udhcpd scripts can be extended to support multiple interfaces, but I think at this time, it is better to use, say, systemd service files for that, which should be trivial to write and drop to the right location (and no, I don't know off my head how to do that ;). When reading the man page I was wondering, could multiple configuration files be specified on udhcpd's command-line and would this have the effect of starting multiple udhcpd processes? (I rather doubt it, but the man page could be read that way) One invocation handles one interface, I think. But you can try :) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f942ff.40...@msgid.tls.msk.ru
