Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
On 25 January 2016 at 21:33, adrian15 wrote:
>
>
> El 25/01/16 a las 16:12, Michal Suchanek escribió:
>>
>> On 25 January 2016 at 03:05, adrian15 wrote:
>>>
>>> El 24/01/16 a las 16:51, Michal Suchanek escribió:
>>
>>
>>> What you are describing here is what it's actually implemented in my
>>> patch
>>> (Well, actually the first patch version because the current one enforces
>>> bootloader roles).
>>
>>
>> Actually, no.
>>
>> Nowhere in the description is any bootloader designated primary or
>> secondary or first or second. On purpose.
>
> Neither it is on my patch (initial implementation). Yes, the term
> PRIMARY_BOOTLOADER is used there for reusing old code. But using:
>
> --bootloaders=syslinux,grub-efi
>
> did not enforce syslinux to be in the first place or grub-efi to be in the
> second place.
>
> That's the specific part I meant.
>
>>
>>> So what about primary and secondary terms? Or first or
>>> second terms?
>>
>>
>> Both are broken and confusing.
>
> Ok...
>>>
>>>
>>> These terms are used in two places:
>>> * Internal variables and functions to handle bootloaders
>>> * Information shown to the final user
>>>
>>> I'm most convinced to use the first and non-first notation. So that the
>>> old
>>> code that referred to LB_BOOTLOADER can just refer to:
>>> LB_FIRST_BOOTLOADER.
>>
>>
>> For what piece of code we have does it make sense to reference
>> LB_FIRST_BOOTLOADER when not also referencing LB_SECOND_BOOTLOADER?
>> Will that be extended to LB_THIRD_BOOTLOADER once x86 grows support
>> for coreboot or l-b grows support for some other platform with many
>> firmware variants?
>>
>> If you set bootloaders like
>>
>> LB_BOOTLOADERS="syslinux grub-efi"
>>
>> then you can just do
>>
>> for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo
>
> Mostly what current path does but with commas instead.
IIRC multivalue options use mostly spaces for separator in l-b so far.
>>
>>
>> after you check that you have at most two bootloaders and if you have
>> more than one then only the latter one ends with -efi.
>
>
> This is not a good approach. You are requesting the bootloaders to end in
> "-efi". The current approach is to name them based on the Debian package
> name. These packages do not need to end in "-efi".
It so happens that bootloaders that support efi are packaged as
packages with -efi suffix (well, except elilo). Maybe there is some
intent there?
However, grub-pc is now split in grub-pc scripts that are meant to
install the bootloader in the system which you probably don't want and
grub-pc-bin which just includes the binaries. The situation is even
more complicated with the 32bit and 64bit efi packages. Also expect
that at some point the maintainers figure out some new completely
awesome way to split the bootloader into packages and then the package
sets will be different in stable/testing/oldstable.
So naming the l-b option *exactly* like the package is not that good idea.
>
> My use case is the following one. The final user requests:
>
> --bootloaders=grub-efi,syslinux
>
> so I show him:
>
> "Warning. You are using: syslinux as a non first bootloader. This might work
> but it is not advised."
>
> How do I know that I have to output this message?
for bootloader in $BOOTLOADERS ; do
# some bootloader foo
if echo $BIOS_BOOTLOADERS | grep "${bootloader}" >/dev/null; then
# a fixed list of bootloaders that load through legacy BIOS -
currently should be "syslinux grub-pc" although grub is not well
supported
case $MEDIA_TYPE in # or whatever the variable
iso*)
case "${BOOTLOADERS}" in
"${bootloader}"*);;
*) echo "Warning: it is recommended to specify
$bootloader first in bootloader list so it gets installed as first
el-torito boot entry."
;;
esac ;;
esac
fi
done
>
> Because I compare the internal variable:
>
> LB_FIRST_BOOTLOADER="grub-efi"
>
> with the bootloader name "syslinux" and I see they are not the same one.
>
> So, as you see I need to use:
>
> "non first bootloader" term
Why that has to be a term? Just say it should come first in the list
of bootloaders if specified at all.
> and
> LB_FIRST_BOOTLOADER variable.
what for?
>
> So...
>
> 1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER to
> another terminology which makes more technical sense.
> 2) I prefer this approach over yours (Michal) because it's the own
> bootloader which decides if it is more suited for "first bootloader" or not.
How does it decide that? It can install equally well in 1st, 2nd or
10th el-torito record. The only reason we want BIOS record first is
1) some tools for butchering bootable CDs expect it to be first.
2) it's the traditional place for it (since it was the only record for
a long time) and some ancient BIOSes might potentially break if it's
not first because somebody missed there *can* be multiple entries when
coding them.
So it only
Originele premiums voor uw beurs of evenement
Deze email nieuwsbrief werd in grafisch HTML formaat verzonden. Als u deze tekstversie ziet, verkiest uw email programma "gewone tekst" emails. U kan de originele nieuwsbrief online bekijken: http://ymlp7.com/zLROam Voor elk moment heeft HiepHiepKado een leuke giveaway. Bekijk de nieuwsbrief in de browser ( http://ymlp7.com/zLROam ) Val op in de menigte! Beurzen en conferenties komen eraan en iedereen probeert de aandacht van de bezoeker te trekken met opvallende stands, gifts en gedecoreerde giveaways om een blijvende indruk achter te laten. Voor elk moment heeft HiepHiepKado een leuke giveaway. Van duurzame en luxe tot originele en goedkope premiums. Alle producten kunnen voorzien worden van uw bedrijfslogo, boodschap en huisstijl. Kies uit een zeer uitgebreid assortiment van originele premiums en handige giveaways. Pennen ( https://www.hiephiepkado.be/pen-potlood/balpennen/?source=mailing260116 ) Pennen zijn uitstekende promotieartikelen en een blikvanger voor uw bedrijf. Het breedste assortiment pennen van Nederland vind u bij HiepHiepKado. Meer info ( https://www.hiephiepkado.be/pen-potlood/balpennen/?source=mailing260116 ) Lanyards ( https://www.hiephiepkado.be/premiums/lanyards/?source=mailing260116 ) Een echte topper onder de giveaways, verkrijgbaar in verschillende kleuren en maten. De lanyards zijn gemakkelijk te bedrukken met uw eigen bedrijfslogo of slogan. Meer info ( https://www.hiephiepkado.be/premiums/lanyards/?source=mailing260116 ) Sleutelhangers ( https://www.hiephiepkado.be/premiums/sleutelhangers/?source=mailing260116 ) Een functioneel en veelgebruikt relatiegeschenk zijn sleutelhangers, bijvoorbeeld met een winkelwagenmuntje, flesopener, lampje of logotop. Meer info ( https://www.hiephiepkado.be/premiums/sleutelhangers/?source=mailing260116 ) Tassen ( https://www.hiephiepkado.be/reizen-tassen/boodschappentassen/?source=mailing260116 ) Een tas wordt dagelijks gebruikt en is daarom een handig kado. Bedruk de tas met uw bedrijfslogo of slogan en deze zal veel worden gezien. Meer info ( https://www.hiephiepkado.be/reizen-tassen/boodschappentassen/?source=mailing260116 ) Notitieboeken ( https://www.hiephiepkado.be/kantoor/notitieboeken/?source=mailing260116 ) Wilt u altijd in het zicht blijven op het bureau van uw klant? Laat een blijvende indruk achter met een notitieboek met uw logo. Meer info ( https://www.hiephiepkado.be/kantoor/notitieboeken/?source=mailing260116 ) Post-it notes ( https://www.hiephiepkado.be/kantoor/post-it-notes/?source=mailing260116 ) Post-it notes zijn ideaal als promotiemateriaal of als giveaway. Plak de post-its overal op en u vergeet nooit meer iets! Meer info ( https://www.hiephiepkado.be/kantoor/post-it-notes/?source=mailing260116 ) HiepHiepKado · Maastrichterstraat 71 · 3500 Hasselt · België Contact opnemen ( https://www.hiephiepkado.be/contact.php ) _ Uitschrijven / Gegevens wijzigen: http://ymlp7.com/ughymwuwgsgjbmjegeumggusqqb Powered door YourMailingListProvider
Re: [Wicd-devel] wicd Debian patches to (not?) apply
Hi Tom, On Tue, Jan 26, 2016 at 06:22:33AM +0100, Tom Van Braeckel wrote: > > IIRC I read a commit somewhere which declared the changelog as > > obsolete. Why is it considered obsolete? Wasn't it only generated > > automatically anyways? > > Oh... Yes, it was generated automatically but I figured it wasn't very > useful because that information can also be found in the Bazaar > repository at Launchpad. > But okay, I understand it is convenient/necessary for you so I re-added it :-) Well, it's not a must (the "P" in the warning meant "pedantic" :-), but it's helpful for packagers (e.g. "Do I need to update any dependencies?") as well as users. At least on Debian, users are used to first lookup upstream changes in the installed package at /usr/share/doc/$package/changelog.gz (while the packaging changelog resides in /usr/share/doc/$package/changelog.Debian.gz), so it's indeed mostly convenience not having to figure out _where_ to lookup the bzr log. > I fixed the issues and updated the release .tar.gz at Launchpad: > https://launchpad.net/wicd/1.7/1.7.4/+download/wicd-1.7.4.tar.gz Appreciated, but please don't do that in the future anymore and give new tar balls a different name. It's considered bad practice to overwrite already published releases: Packagers may have already imported the old tar ball into their systems labeled "1.7.4" and now there is a different tar ball which would need the same label, e.g. a git tag. And deleting git tags to let them later point elsewhere is considered bad practice for the same reason. Additionally some tools may not even be able to cope with it. So I've imported that second tar ball now into the Debian packaging as version number "1.7.4+tb2". Another project I'm involved in had to fixup a tar ball recently, too, and they dubbed the second tar ball for the "0.9.6" release "0.9.6v2". Also a possibility. Anyways, the new tar ball looks much better and no more throws the warnings I sent you. Thanks! :-) Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News| a...@deuxchevaux.org (Mail) X See http://www.nonhtmlmail.org/campaign.html | a...@noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)
Re: [Wicd-devel] wicd Debian patches to (not?) apply
Got it, will do, thanks!
Bug#812709: marked as done (cvs-switchroot requires /bin/mksh but it is not installed)
Your message dated Tue, 26 Jan 2016 16:24:23 + (UTC) with message-id and subject line Re: Bug#812709: cvs-switchroot requires /bin/mksh but it is not installed has caused the Debian Bug report #812709, regarding cvs-switchroot requires /bin/mksh but it is not installed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 812709: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812709 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: cvs Version: 2:1.12.13+real-15 Severity: normal The cvs-switchroot program is a script but its interpeter is not installed. I assume that a dependency which should exist is simply missing. ~$ cvs-switchroot bash: /usr/bin/cvs-switchroot: /bin/mksh: bad interpreter: No such file or directory ~$ type cvs-switchroot cvs-switchroot is hashed (/usr/bin/cvs-switchroot) ~$ head -n 1 /usr/bin/cvs-switchroot #!/bin/mksh ~$ ls -l /bin/mksh /bin/ls: cannot access /bin/mksh: No such file or directory -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cvs depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.26 ii install-info 5.2.0.dfsg.1-6 ii libbsd0 0.7.0-2 ii libc6 2.19-18+deb8u1 ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u1 ii libkrb5-3 1.12.1+dfsg-19+deb8u1 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages cvs recommends: ii openssh-client 1:6.7p1-5 Versions of packages cvs suggests: pn mksh ii rcs 5.9.3-1 -- no debconf information --- End Message --- --- Begin Message --- James Youngman dixit: >The cvs-switchroot program is a script but its interpeter is not >installed. I assume that a dependency which should exist is simply >missing. No, it’s a contributed script which is of only some, limited, use and only bundled with cvs because not doing that would be even more awkward. mksh was originally in Recommends for this, but even that was deemed too much by several people, so it’s now in Suggests (cf. #631110). That’s enough to satisfy using it as interpreter for a not normally used script, and even lintian agrees. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)--- End Message ---
Processing of iroffer_1.4.b03-4_source.changes
iroffer_1.4.b03-4_source.changes uploaded successfully to localhost along with the files: iroffer_1.4.b03-4.dsc iroffer_1.4.b03-4.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org)
Processed: Bug#773176 marked as pending
Processing commands for cont...@bugs.debian.org: > tag 773176 pending Bug #773176 [snd-gtk] snd-gtk-alsa not available? Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 773176: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773176 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#773176: marked as done (snd-gtk-alsa not available?)
Your message dated Tue, 26 Jan 2016 22:03:55 + with message-id and subject line Bug#773176: fixed in snd 16.1-2 has caused the Debian Bug report #773176, regarding snd-gtk-alsa not available? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 773176: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773176 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: snd-gtk Severity: wishlist Is there a reason an alsa build of snd-gtk is not provided? (considering snd is built with alsa, I don't think it's a technical limitation). -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Source: snd Source-Version: 16.1-2 We believe that the bug you reported is fixed in the latest version of snd, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 773...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. IOhannes m zmölnig (Debian/GNU) (supplier of updated snd package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 26 Jan 2016 21:31:13 +0100 Source: snd Binary: snd snd-doc snd-gtk-jack snd-gtk-pulse snd-nox Architecture: source Version: 16.1-2 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers Changed-By: IOhannes m zmölnig (Debian/GNU) Description: snd- Sound file editor snd-doc- Sound file editor (documentation) snd-gtk-jack - Sound file editor (GTK+ user interface - JACK) snd-gtk-pulse - Sound file editor (GTK+ user interface - PulseAudio) snd-nox- Sound file editor (cmdline) Closes: 773176 Changes: snd (16.1-2) unstable; urgency=medium . * Made snd-git-jack provide an ALSA backend (Closes: #773176) * Mentioned this in the package description * Made snd-nox use both ALSA/OSS and JACK. * Mentioned this in the package description * Made snd frontends co-installable * Added flavour suffix to the binaries * Use update-alternatives to handle 'snd' * Fixed conflicts to allow co-installation * Dropped dependencies on anything pre-old-old-stable * Prevent creating of unused /etc/X11 directory * Regenerated debian/copyright_hints Checksums-Sha1: 7bde7987b75a19bcf82ee9fa3156314e8015b082 2420 snd_16.1-2.dsc 57168795e578ab7051e64e91377416860666f3ce 18768 snd_16.1-2.debian.tar.xz Checksums-Sha256: 485c291ead84b5fe4c43738eebf26c9250ca54e09bb6e3ed3ad5928b0fbc 2420 snd_16.1-2.dsc 824d4d2e039a728594512b9f70a5779a8665beb1cd004973f82d294e09da9768 18768 snd_16.1-2.debian.tar.xz Files: 557d2765a2a48740d83befcc0b29eb01 2420 sound optional snd_16.1-2.dsc b728225ca2bb51f8f90fd4a5429c9bb2 18768 sound optional snd_16.1-2.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWp9n0AAoJELZQGcR/ejb4A/wP/jC585ExQHJn9lUEZDk+rVOU PyeltMYSOLlPDxNCjcelP0h385bI8FXBcb50YkQYJkJq17XwiHGfl4EJ0jN2g5ly 3xKIeJm+1/D5g/hqC5pwDVsZwMdb+R4bT41Yn6zHFU/OqrzJ8jb650jIh5L/lQ7G 1l6kFWeLDJbdqS4F8K25mdKnUDaD01ub7Ui0WY9P442J1jJiZir3VKxfmQczpp2f ZW7mKnIaOZrncZIynXSTZaLSf2e/GcQcLwppOJrbd+nu1SNRiXq3X4yXLGlzaDJN IY/ubjEs5sf2gUdZLsuVWNlmw0QO8xawLoDjeG3LZdRVF8hgrV3rZ1nO/Pz9K9ng ifkreSIq2lj25N9XObahB1dg84dWlqj9/w8vwtiqMMzyaOZTjQ87LsZkB3xafefA FCmL9uoBjX8HlM/xVq/Xbmid1mNOHdarOAYl1uqxWhLbVFYI7G5LtgAo5aYZRjIu wlTymfbcqLLvC4AdBZvf4JHG6hpgCXChMRRQRAodwNHYaBncuf+WIwu+28OXge6X NAUtG8Fn1RC3OOBRSYjinFjPrWXt+SwRL/w82j7OoscOLVU7qWqz/z/h9pfmvKQM i+BIqSw7q0upPKx+Ow9l4Xw+yY6IjFqitQuYdwaruhOBYw06My+DHdg9n98+cbzE RBPI67DKVszXGhwD1Bht =PjZr -END PGP SIGNATURE End Message ---
iroffer_1.4.b03-4_source.changes ACCEPTED into unstable
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Tue, 26 Jan 2016 15:55:30 -0200
Source: iroffer
Binary: iroffer
Architecture: source
Version: 1.4.b03-4
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group
Changed-By: Joao Eriberto Mota Filho
Description:
iroffer- IRC file distribution bot
Changes:
iroffer (1.4.b03-4) unstable; urgency=medium
.
* QA upload.
* Set Debian QA Group as maintainer. (see #61)
* Migrations:
- debian/rules to new (reduced) format.
- DebSrc to 3.0 format.
- DH level to 9.
* debian/clean: created to remove some files forgotten after build.
* debian/control:
- Added the ${misc:Depends} variable to Depends field.
- Bumped Standards-Version to 3.9.6.
- Removed the obsolete field Dm-Upload-Allowed.
* debian/patches/01_avoid_direct_changes.patch: added to avoid inadequate
changes in upstream source code.
* debian/watch: created.
Checksums-Sha1:
0f975161a28c5af8990a3600d685ad95229c3165 1768 iroffer_1.4.b03-4.dsc
d61b69349957f246a3848500cf930d4ac284e4fc 4784 iroffer_1.4.b03-4.debian.tar.xz
Checksums-Sha256:
728e6524ea863c82a6d9058204b02b0203dbc2b3a0ef3d42956e369d051a1c8f 1768
iroffer_1.4.b03-4.dsc
5fbc6ba3dede5cadb6aaf46335a900fd10dd8f711aadf00a7682c284cbdcbf9a 4784
iroffer_1.4.b03-4.debian.tar.xz
Files:
8373857cf1a80a69eaa917bbb9cebe53 1768 net extra iroffer_1.4.b03-4.dsc
11f4e886f329d5e1c2577d2450eb26d3 4784 net extra iroffer_1.4.b03-4.debian.tar.xz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJWp9GQAAoJEN5juccE6+nvNbgP/3X73NzrEuHSxqmmfow966Tv
fwmLE27MCcNYAGnyz4jN0R/gbIOzGJo0wnFTK0PkZ8mV/j1Z/XAIHwVFw2yVpeMf
C64vhY2NLkwrbybXxb+rWvudS9RtsdkNF5x5EzZv2qclKgUmYaI0GNcloP1i8HS3
GRm1nqvd3aJUzfManxczY5ucXWOEa6DxP6qqSFXJ39BEIYuXxrNRbJL/hnkeTYgH
F+fuva3bWx7t06Zb8hsr1mEGdlEKJkBfjc8YHMpAkheZRIMBdI2SkYW9PIgmfQXv
lPRua20e06aPzbn8zGKRPRDDLDb2Zr37hox95Nwq136rA2HA3AlbL4wtqcEXTvG9
1e2guiE3pjcxdiPxsnYONIATb0hhH0pP23pVEaGo0NmwtZg++7MLo8ufBMClCEAM
AUJA7jL8gU3kLPc6etaw9IwOirlbaTlAg7bzpP7Zq55CiGWRMPD7ahtcPUR0S1zh
RGVqGBnJzj7EZTz9n6sUJTS09Z8svg1knLvEjSzFGx+SFmscMkuHD+UPcslxp/YP
JZfZ3AeysCrHxca/ThSeB2v01bO5PhrKIzJ9llHBVxVDuvTBtLxZVf6tU0C8sV6h
m+h67y4uPM99YlU8fyjFGLBMqC3KX1YFAYIrFcrUG6c+hTp/NCZtozRMSjvHWJ2W
3xAm4RPUFumBOlrnFPWa
=o8lC
-END PGP SIGNATURE-
Thank you for your contribution to Debian.
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 26/01/16 a las 10:18, Michal Suchanek escribió:
If you set bootloaders like
LB_BOOTLOADERS="syslinux grub-efi"
then you can just do
for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo
Mostly what current path does but with commas instead.
IIRC multivalue options use mostly spaces for separator in l-b so far.
dba requested it like this. I agree on that criteria for doing so. You
are not obliged to use quotes when defining bootloaders on the command
line or scripts.
What are these multivalue options so that I take a look at them? Having
to deal with IFS it's not ideal but I think using commas it's the way to
go... although I'm not 100% convinced.
after you check that you have at most two bootloaders and if you have
more than one then only the latter one ends with -efi.
This is not a good approach. You are requesting the bootloaders to end in
"-efi". The current approach is to name them based on the Debian package
name. These packages do not need to end in "-efi".
It so happens that bootloaders that support efi are packaged as
packages with -efi suffix (well, except elilo). Maybe there is some
intent there?
However, grub-pc is now split in grub-pc scripts that are meant to
install the bootloader in the system which you probably don't want and
grub-pc-bin which just includes the binaries. The situation is even
more complicated with the 32bit and 64bit efi packages. Also expect
that at some point the maintainers figure out some new completely
awesome way to split the bootloader into packages and then the package
sets will be different in stable/testing/oldstable.
So naming the l-b option *exactly* like the package is not that good idea.
dba commited a change (
https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=f93fa286d5e7348150aab4874794f7d96dac0894
) for that behaviour. I think the reasoning of that was avoid file
naming collisions in the future because package names are not repeated.
My use case is the following one. The final user requests:
--bootloaders=grub-efi,syslinux
so I show him:
"Warning. You are using: syslinux as a non first bootloader. This might work
but it is not advised."
How do I know that I have to output this message?
for bootloader in $BOOTLOADERS ; do
# some bootloader foo
if echo $BIOS_BOOTLOADERS | grep "${bootloader}" >/dev/null; then
# a fixed list of bootloaders that load through legacy BIOS -
currently should be "syslinux grub-pc" although grub is not well
supported
case $MEDIA_TYPE in # or whatever the variable
iso*)
case "${BOOTLOADERS}" in
"${bootloader}"*);;
*) echo "Warning: it is recommended to specify
$bootloader first in bootloader list so it gets installed as first
el-torito boot entry."
;;
esac ;;
esac
fi
done
Here you are creating a new variable: $BIOS_BOOTLOADERS which will have
to be updated manually each time a new bios bootloader binary_ file is
added.
The grep part should be improved to avoid problems (e.g. syslinux is
inside syslinux-efi).
Because I compare the internal variable:
LB_FIRST_BOOTLOADER="grub-efi"
with the bootloader name "syslinux" and I see they are not the same one.
So, as you see I need to use:
"non first bootloader" term
Why that has to be a term? Just say it should come first in the list
of bootloaders if specified at all.
"It should come first". "It should not come first". Ok. I can do that
and ditch the "non first bootloader" or "first bootloader" from my messages.
and
LB_FIRST_BOOTLOADER variable.
what for?
For two reasons:
1) Being able to use current live-build code which used LB_BOOTLOADER in
the past.
Check what it's in current alioth git (Seach for LB_PRIMARY_BOOTLOADER
on there):
https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_hdd?id=1ccb41623046f2a8f823d62a5f417cdae724c22b
https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_iso?id=1ccb41623046f2a8f823d62a5f417cdae724c22b
https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/functions/defaults.sh?id=1ccb41623046f2a8f823d62a5f417cdae724c22b
2) Not having to use awk each time I need to compare a first / default
bootloader... when I can just use a variable with previous (once only)
calculated value.
So...
1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER to
another terminology which makes more technical sense.
2) I prefer this approach over yours (Michal) because it's the own
bootloader which decides if it is more suited for "first bootloader" or not.
How does it decide that? It can install equally well in 1st, 2nd or
10th el-torito record. The only reason we want BIOS record first is
Inside the binary_bootloader file by running a function that shows that
warning. The author of the binary_bootloader it's who decides where it's
