Bug#1017555: Let's drop win32-loader from amd64/i386 and multiarch CDs

[Didier 'OdyX' Raboud]

Package: debian-cd
Version: 3.1.35
Severity: normal
Tags: d-i
X-Debbugs-Cc: win32-loa...@packages.debian.org

Following the recent discussion on d-boot [1], it seems we agreed to drop
win32-loader from the Debian CDs, as it's not likely to be very useful these
days.

win32-loader seems also present on debian-installer [2], I'll therefore clone
the bug.

As for the win32-loader package, its network version [3] is still probably
useful, and doesn't take much space on mirrors; let's keep it.

Best,
OdyX

[1] https://lists.debian.org/debian-boot/2022/07/msg00083.html
[2] https://d-i.debian.org/daily-images/amd64/20220817-00:19/build_cdrom_gtk.log



-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (100, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debian-cd depends on:
ii  apt2.5.2
ii  bc 1.07.1-3+b1
ii  bzip2  1.0.8-5
ii  cpp4:12.1.0-3
ii  curl   7.84.0-2
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.21.9
ii  genisoimage9:1.1.11-3.4
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.21.9
pn  libfile-slurp-perl 
ii  libyaml-libyaml-perl   0.83+ds-1+b1
ii  lynx   2.9.0dev.10-1
ii  make   4.3-4.1
ii  perl [libdigest-sha-perl]  5.34.0-5
ii  tofrodos   1.7.13+ds-5
ii  wget   1.21.3-1+b2
ii  xorriso1.5.4-2

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
pn  hfsutils 
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.33-1+really4.0.32-1
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

Time to drop win32-loader ?

[Didier 'OdyX' Raboud]

Hello there,
(please CC me on replies, I'm not on these lists)

(live from the d-i/debian-cd BoF)

as some of you likely remember, win32-loader is shipped on d-i and debian-cd 
images, and is added in autorun.inf for automated launch on Windows machines, 
when USB/CDs are plugged in. What it does is allow a machine booted in Windows 
to download a d-i image, put a grub image and d-i in C:/debian-installer, and 
fiddle with the (old?) Windows bootloader to allow selection of d-i upon 
reboot. It either works from the image, or downloading stuff from internet.

I haven't checked (as I don't have access to Windows machines...), but I'm 
quite confident that the Windows Bootloader fiddling is quite unlikely to work 
on modern (Secure Boot ?) machines.

That brings two sides of the question:
* should it still be shipped on amd64 netinsts, CD's, other images?
* should it still be offered on the mirrors ?
  on https://deb.debian.org/debian/tools/win32-loader/stable/
  (where it lands via dak's byhand handling upon uploads; but is manually 
  moved by ftp-master on migrations and release days)

(I orphaned win32-loader back in September, and it still doesn't have an 
official maintainer; but I'd be happy to work towards ditching it away :-P)

Best,
  OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Keyboard Layout configuration wizard - Swiss localization

[Didier 'OdyX' Raboud]

Hello Mark,

Le mercredi, 24 février 2021, 21.31:43 h CET hispeedhsx a écrit :
> I'm new to Debian and I switch from centos but I have seen this problem for
> now several years and in several distributions even I think freebsd has it
> wrong (in my opinion).
> 
> So I'm from Switzerland and I use a "Swiss Keyboard". We have people who are
> talk and write in french and italian. There are also several people writing
> rumantsch which is a little bit special.

Swiss DD here; cc'ing debian-switzerland@ for further comments if needed

> When I see the keyboards layouts in the installer from
> debian-10.8.0-amd64-netinst I see there that Debian has a "Schweizerisches
> Französisch / Swiss French" and a "Schweizerdeutsch / Swiss German"
> keyboard layout.
> 
> There is one problem with this: In Switzerland we only have 1 hardware
> keyboard layout. Italian, German and French speaking people use this
> layout.

Although Switzerland indeed has only one hardware keyboard layout (the 
keyboard markings can be identical), it has (at least) two software 
interpretations, around the right part of the keyboard.

Specifically, the en_US "; / :" key will be:
 - "é / ö" in the Swiss French variant
 - "ö / é" in the Swiss German variant

There at least two other keys with such fr <> de swaps.

See
https://en.wikipedia.org/wiki/
QWERTZ#Switzerland_(German,_French,_Italian,_Romansh),_Liechtenstein,_Luxembourg

> In short there is only one keyboard and this has to be called: Swiss =
> Schweiz

No.

> If a Swiss person is only writing in french and they don't write often
> german so they will use the AZERTY keyboard which is the same as the French
> people are using for example.

That's really not true. At the very least, it's not _universally_ true for 
french-speaking Swiss people.

As one example, I have learned (in the nineties) and still type on Swiss-
french QWERTZ keyboards, with the é under my right pinky, and so do all the 
people I know from Suisse romande (besides the obvious IT people who might 
have switched to BÉPO or en_US QWERTY). I really don't know of anyone raised 
in Suisse romande typing on AZERTY.

> I will thank you for your responses and inputs. In my opinion this is a bug
> and should be fixed even it just for the small Switzerland.

It should not be fixed, as it's not a bug. Much to the contrary, it is OK as-
is; dropping the french variant of the Swiss QWERTZ keyboard would clearly 
alienate the french-speaking swiss (and the italian-speaking swiss too 
apparently), and deprive them from using their (valid) keyboard layout.

Hereby closing the bug report.

Best regards from Vevey, in Suisse romande.
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#982838: RoM: win32-loader must not migrate automatically

[Didier 'OdyX' Raboud]

Source: win32-loader
Version: 0.10.5
Severity: serious
X-Debbugs-Cc: debian-boot@lists.debian.org, debian-rele...@lists.debian.org

win32-loader is one of the rare packages always blocked, because it has a
'byhand' counterpart per release: `/debian/tools/win32-loader/{release}`, and
therefore needs a manual action by FTP masters in sync ("around the time of")
with the unblock.

This bug exists to manually block any src:win32-loader migration without a
manual sync from FTP masters.

It'll be updated to be marked "found" in the latest version, and "notfound"
in any version allowed to migrate.

Best, for the win32-loader maintainers,
  OdyX

Bug#982606: unblock: win32-loader/0.10.4

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-boot@lists.debian.org

Please unblock package win32-loader in its 0.10.4 version

[ Reason ]
win32-loader is one of the rare packages always blocked, because it has a
'byhand' counterpart per release: `/debian/tools/win32-loader/{release}`, and
therefore needs a manual action by FTP masters in sync ("around the time of")
with the unblock.

[ Impact ]
It's been since 0.10.1 (September 2020) that it hasn't been migrated, and I (as
co-maintainer), want the 0.10.4 changes in for Bullseye.

[ Tests ]
There are no significant error reports for the version in unstable, I deem
this version as really safe to migrate. If it were a normal package, it would
have migrated for every version.

Please CC ftpmas...@debian.org when granting this unblock, for them to proceed
with their magic.

Best regards, and thanks for your work,
OdyX

unblock win32-loader/0.10.4

P.S. Yes. That's an almost verbatim copy of #967048

Bug#967048: unblock: win32-loader/0.10.1

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-boot@lists.debian.org

Please unblock package win32-loader in its 0.10.1 version

[ Reason ]
win32-loader is one of the rare packages always blocked, because it has a
'byhand' counterpart per release: `/debian/tools/win32-loader/{release}`, and
therefore needs a manual action by FTP masters in sync ("around the time of")
with the unblock.

[ Impact ]
It's been since 0.9.5 (March 2019) that it hasn't been migrated, and I (as
co-maintainer), want the 0.10* changes in for Bullseye.

[ Tests ]
There are no significant error reports for the version in unstable, I deem
this version as really safe to migrate. If it were a normal package, it would
have migrated for every version.

Please CC ftpmas...@debian.org when granting this unblock, for them to proceed
with their magic.

Best regards, and thanks for your work,
OdyX

unblock win32-loader/0.10.1

Re: win32-loader upload

[Didier 'OdyX' Raboud]

Le dimanche, 12 juillet 2020, 14.09:52 h CEST Holger Wansing a écrit :
> Hi Didier,
> 
> I noticed we have some translation updates pending-upload for win32-loader.
> Since there were no new changelog entries for other changings, I thought
> it's a translation-update-only upload, and that would be no issue/risk.
> 
> However, now I realized that there were several other changings done in the
> last months (contributed by Thomas Gaugler).
> 
> I have added the (missing) changelog entries for them now.
> 
> Would an upload be ok nevertheless?
> 
> (I don't know how to contact Thomas Gaugler as contributor of the relevant
> changings.)

I'll proceed with an upload now as I trust Thomas to have provided with good 
patches. As for the missing changelog entries, he apparently followed my usual 
"use git-dch at release time" way of maintaining the d/changelog file, which 
might not be the common d-boot way of doing things. Sorry for that. 

0.10.1 should really get migrated to Bullseye at some point (needs a manual 
unblock, and a file copy by FTP-masters), I'll care for this in 5-10 days.

-- 
OdyX

Bug#953809: tasksel 3.59: it needs to delete task-print-server and task-print-service

[Didier 'OdyX' Raboud]

Le vendredi, 13 mars 2020, 23.39:53 h CEST Cyril Brulebois a écrit :
> Hi,
> 
> Сергей Фёдоров  (2020-03-13):
> > Package: tasksel
> > Version: 3.59
> > Severity: normal
> > 
> > When upgrading any of the packages from version 3.58 to 3.59:
> >task-cyrillic
> >task-desktop
> >task-russian
> >task-xfce-desktop
> >tasksel
> >tasksel-data
> > 
> > it needs to delete packages version 3.58
> > 
> >task-print-server
> >task-print-service
> > 
> > but their version 3.59 is not available.
> 
> Yes, that's been in removed in the latest version. See the latest
> changelog entry (sorry, one needs to scoll until “Changes:”):
>  
> https://tracker.debian.org/news/1107708/accepted-tasksel-359-source-into-un
> stable/
> 
> So I don't think there's anything to fix here. Looping in Didier to make
> extra sure.

Thanks for the followup, everything looks fine!

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#950553: Remove task-print-{server,service}

[Didier 'OdyX' Raboud]

Le mardi, 10 mars 2020, 08.46:24 h CET Laurent Bigonville a écrit :
> On Mon, 03 Feb 2020 14:48:35 +0100 Didier 'OdyX' Raboud
> 
>  wrote:
>  > Hello,
>  > 
>  > 
>  > If that'd help for transition measures, I'd be happy to add a Provides:
>  > task-print-service on cups.
> 
> The changelog says that cups is "pulled by the concerned desktop
> environments".
> 
> AFAICS, only cinnamon is explicitly pulling cups/cups-daemon, other have
> indirect (soft) dependencies against cups.

Hmm.

KDE pulls cups through a print-manager Recommends.
Others have system-config-printer.
I don't know what has GNOME.

> Could you please open bugs for this for the different desktop? or make
> the task-desktop depends on cups directly?

My point, when removing the task-print-service tasksel package, was that it is 
pointing directly to CUPS only, and a confusing select in d-i.

But you're right, removing it makes several packages with dangling relations, 
and I'll file bugs against these.

As for the desktop environments, I don't really want to impose on them _new_ 
dependencies on CUPS; as pulling it or not is really a design/strategy choice.

Regards,
-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#950553: Remove task-print-{server,service}

[Didier 'OdyX' Raboud]

Package: tasksel
Version: 3.58
Severity: important
Tags: patch

Hello,

in the context of trying to reduce the number of printing-related packages
installed (see discussion starting at [0], I looked at what's pulled by the
task-print-server and task-print-service packages.

Initially, my patch would have been to replace the "Recommends" with
"Suggests", but then it seems that the package is mostly a void shell to
install "CUPS".

To be honest, I think "print-server" in todays' terms means "cups", and I
never really saw the point of having this option in d-i or tasksel.

So I'd propose to completely remove these two packages; as I think anyone who
would use d-i to install CUPS, would just do so, and wouldn't (shouldn't)
blindly rely on the task-print-service.

If that'd help for transition measures, I'd be happy to add a Provides:
task-print-service on cups.

Cheers,
OdyX

[0] https://lists.debian.org/3876697.1jamxip...@odyx.org


-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tasksel depends on:
ii  apt 1.8.4
ii  debconf [debconf-2.0]   1.5.73
ii  liblocale-gettext-perl  1.07-4
ii  perl-base   5.30.0-9
ii  tasksel-data3.58

tasksel recommends no packages.

tasksel suggests no packages.

-- debconf information excluded
diff --git a/debian/control b/debian/control
index 5f5c2bca..803cae49 100644
--- a/debian/control
+++ b/debian/control
@@ -323,34 +323,6 @@ Recommends:
apache2-doc,
analog,
 
-Package: task-print-service
-Architecture: all
-Description: print service
- This task sets up your system to provide print services. It is required to
- use printers plugged into your system, network printers, or to make available
- printers plugged into this system to other network systems.
-Provides: task-print-server
-Depends: ${misc:Depends},
-   cups
-Recommends:
-   foomatic-db-engine,
-   printer-driver-all,
-   hplip,
-   hp-ppd,
-   openprinting-ppds,
-
-Package: task-print-server
-Architecture: all
-Section: oldlibs
-Description: print service -- transitional package
- This task sets up your system to provide print services. It is required to
- use printers plugged into your system, network printers, or to make available
- printers plugged into this system to other network systems.
- .
- This is a transitional package, task-print-server was renamed to
- task-print-service.
-Depends: ${misc:Depends}, task-print-service
-
 Package: task-ssh-server
 Architecture: all
 Description: SSH server
diff --git a/tasks/print-service b/tasks/print-service
deleted file mode 100644
index 8778e381..
--- a/tasks/print-service
+++ /dev/null
@@ -1,6 +0,0 @@
-Task: print-service
-Relevance: 4
-Section: user
-Test-desktop: 1
-Key:
- task-print-service

Re: Bug#934928: Bug#933829: win32-loader: Checksums need to be updated for new stable release, download fails to validate Release file.

[Didier 'OdyX' Raboud]

Le mercredi, 21 août 2019, 10.44:51 h CEST Adam D. Barratt a écrit :
> Control: tags -1 -moreinfo +confirmed
> 
> On 2019-08-21 09:14, Didier 'OdyX' Raboud wrote:
> > Le mardi, 20 août 2019, 16.55:47 h CEST Adam D. Barratt a écrit :
> >> Control: tags -1 + moreinfo
> >> 
> >> [Recipients changed to use the p-u bug rather than the win32-loader
> >> one]
> 
> >> On 2019-08-16 07:55, Didier 'OdyX' Raboud wrote:
> [...]
> 
> >> > +win32-loader (0.9.3+deb10u1) buster; urgency=medium
> >> > +
> >> > +  * Rebuild in stable to embed the latest debian-archive-keyring
> >> > +(Closes: #933829)
> >> > +
> >> > + -- Didier Raboud   Fri, 16 Aug 2019 08:53:00 +0200
> >> > +
> >> > 
> >> >  win32-loader (0.9.3) unstable; urgency=medium
> >> >  
> >> >[ Thomas Gaugler ]
> >> 
> >> This wants to be against 0.9.4, which is the version in buster. It
> >> will
> >> also want an unblock-udeb for the 0.9.5 upload in unstable, so that
> >> reaches testing before the point release.
> > 
> > Ah, indeed; thanks for the check.
> > 
> > +win32-loader (0.9.4+deb10u1) buster; urgency=medium
> > +
> > +  * Rebuild in stable to embed the latest debian-archive-keyring
> > +(Closes: #933829)
> > +
> > + -- Didier Raboud   Fri, 16 Aug 2019 08:53:00 +0200
> 
> Better. :-) Please go ahead.

Uploaded.

> > As for the unblock-udeb; do you need another bug, or were you asking
> > debian-
> > boot@ for approval?
> 
> My understanding was that it's blocked at your request rather than
> -boot's, to ensure that it doesn't get out of sync with the files in
> tools/ on mirrors. I can happily add the unblock-udeb, but we'll need to
> make sure that ftp-master also do the relevant magic on their side. (If
> that's still manual intervention.)

(Thanks for the unblock :-) )

As far as I'm concerned, it can stay unblocked outside of the freeze. I don't 
care _enough_ for the testing win32-loader.exe to be in sync to warrant always 
needing to unblocking this package manually.

Where would it make sense to document that the win32-loader /tools/ 
counterpart needs to be copied from unstable to testing at freeze time and for 
each subsequent upload only, but that we're fine with having it out-of-sync 
outside of the freeze?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#933829: win32-loader: Checksums need to be updated for new stable release, download fails to validate Release file.

[Didier 'OdyX' Raboud]

Le mardi, 20 août 2019, 16.55:47 h CEST Adam D. Barratt a écrit :
> Control: tags -1 + moreinfo
> 
> [Recipients changed to use the p-u bug rather than the win32-loader one]
> 
> On 2019-08-16 07:55, Didier 'OdyX' Raboud wrote:
> > So win32-loader needs a stable update.
> > 
> > debian-boot@ / debian-release@: can I upload src:win32-loader in source
> > only
> > with the following diff?
> > 
> > diff -Nru win32-loader-0.9.3/debian/changelog
> > win32-loader-0.9.3+deb10u1/
> > debian/changelog
> > --- win32-loader-0.9.3/debian/changelog 2019-01-02 18:38:43.0
> > +0100
> > +++ win32-loader-0.9.3+deb10u1/debian/changelog 2019-08-16
> > 08:53:00.0
> > +0200
> > @@ -1,3 +1,10 @@
> > +win32-loader (0.9.3+deb10u1) buster; urgency=medium
> > +
> > +  * Rebuild in stable to embed the latest debian-archive-keyring
> > +(Closes: #933829)
> > +
> > + -- Didier Raboud   Fri, 16 Aug 2019 08:53:00 +0200
> > +
> > 
> >  win32-loader (0.9.3) unstable; urgency=medium
> >  
> >[ Thomas Gaugler ]
> 
> This wants to be against 0.9.4, which is the version in buster. It will
> also want an unblock-udeb for the 0.9.5 upload in unstable, so that
> reaches testing before the point release.

Ah, indeed; thanks for the check.

+win32-loader (0.9.4+deb10u1) buster; urgency=medium
+
+  * Rebuild in stable to embed the latest debian-archive-keyring
+(Closes: #933829)
+
+ -- Didier Raboud   Fri, 16 Aug 2019 08:53:00 +0200

As for the unblock-udeb; do you need another bug, or were you asking debian-
boot@ for approval?

OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#933829: win32-loader: Checksums need to be updated for new stable release, download fails to validate Release file.

[Didier 'OdyX' Raboud]

Le dimanche, 4 août 2019, 08.43:49 h CEST Yetoo Happy a écrit :
> Dear Maintainer,
> 
> Checksums need to be updated for new stable release, download fails to
> validate Release file. I built package using Debian 10.0 intending to embed
> the new checksum and testing the built package found the error didn't occur 
> when downloading in the executable.

I just tested a rebuild in a buster chroot and can confirm that the rebuilt 
win32-loader.exe can download the release correctly.

So win32-loader needs a stable update.

debian-boot@ / debian-release@: can I upload src:win32-loader in source only 
with the following diff?

diff -Nru win32-loader-0.9.3/debian/changelog win32-loader-0.9.3+deb10u1/
debian/changelog
--- win32-loader-0.9.3/debian/changelog 2019-01-02 18:38:43.0 +0100
+++ win32-loader-0.9.3+deb10u1/debian/changelog 2019-08-16 08:53:00.0 
+0200
@@ -1,3 +1,10 @@
+win32-loader (0.9.3+deb10u1) buster; urgency=medium
+
+  * Rebuild in stable to embed the latest debian-archive-keyring
+(Closes: #933829)
+
+ -- Didier Raboud   Fri, 16 Aug 2019 08:53:00 +0200
+
 win32-loader (0.9.3) unstable; urgency=medium
 
   [ Thomas Gaugler ]




Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 4 mars 2019, 22.28:38 h CET Margarita Manterola a écrit :
> Hi,
> 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > The winners are:
> >  Option M `middle`
> >  Option H `hard`
> > 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > Dear Marga, as Chair, could you please make use of your casting vote to
> > break this tie?
> 
> I'm using my casting vote to vote in favor of M `middle` (i.e. consider
> that the desirable situation at the time of bullseye is that both directory
> schemes are allowed, all packages can be built on either).
> 
> My rationale for taking this decision is as follows:
> 
> Right now we are not ready to migrate to building on merged-usr systems in
> Debian, there are still 29 known packages that are broken and need to be
> fixed.  My expectation is that those packages will be fixed in the not so
> distant future (i.e.  before bullseye) and that after that, the buildd
> profile in debootstrap will default to having a merged /usr, so that new
> buildd chroots will use that setup.
> 
> However, we have no control over how fast individual developers and
> derivative distributions will migrate to the new format. It's possible that
> more time will be required until everyone is ready to migrate.
> 
> Additionally, as of our current understanding of the issue, there are no
> known problems for building on a non-merged system. Supporting this
> setup does not imply additional work from the point of view of our
> maintainers (for now).
> 
> In the future, it would be a bug if a problem is discovered with building a
> package on a non-merged /usr system. I understand that this would mean
> additional work to the maintainers of such a package, but at least as of
> today this is a non-issue. Eventually, when fixing such bugs becomes a
> significant burden for our maintainers, it can be decided that the setup is
> no-longer supported, but my personal recommendation would be to wait at
> least until bullseye+1. That's why I'm voting "Middle" for bullseye.

I have announced this decision on debian-devel-announce:
https://lists.debian.org/debian-devel-announce/2019/03/msg1.html

I am therefore hereby closing this bug.

Thank you to all involved parties!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 25 février 2019, 14.58:09 h CET Didier 'OdyX' Raboud a écrit :
> I call for vote immediately on the following resolution.
> 
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye`
> is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either
> classical or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
> such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

Dear all,

with 6 votes in, and one week gone, the outcome of this vote is still in 
doubt; here's an abstract of the vote calculation (a clearsigned verbose 
version is attached):

/--WMHF
V: 3214 odyx
V: 2134 bremner
V: 4213 gwolf
V: 3124 ntyni
V: 2134 marga
V: 4213 fil
  Option
  W M H F 
===   ===   ===   === 
Option W0 2 4 
Option M  6   3 6 
Option H  4 3   6 
Option F  2 0 0   

Option W Reached quorum: 4 >= 2
Option M Reached quorum: 6 >= 2
Option H Reached quorum: 6 >= 2

Option W passes Majority.   2.000 (4/2) > 1

  Option M defeats Option W by (   6 -0) =6 votes.
  Option H defeats Option W by (   4 -2) =2 votes.
  Option W defeats Option F by (   4 -2) =2 votes.
  Option M defeats Option F by (   6 -0) =6 votes.
  Option H defeats Option F by (   6 -0) =6 votes.

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option M `middle`
 Option H `hard`

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


So. We have a tie, and the voting period is over. I am quite confident we can 
neither continue discussing (FD lost to M and H unanimously, and to W by 2), 
nor allow smcv to vote (the voting period is over). We're left with the 
Chair's casting vote (as per §6.3.2). So…

Dear Marga, as Chair, could you please make use of your casting vote to break 
this tie?

Cheers,
OdyX-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Starting results calculation at Mon Mar  4 15:34:31 2019

/--WMHF
V: 3214 odyx
V: 2134 bremner
V: 4213 gwolf
V: 3124 ntyni
V: 2134 marga
V: 4213 fil
Option W "`weak`: both directory schemes are allowed, but packages should only 
be built on hosts with classical directory schemes (or in such chroots)"
Option M "`middle`: both directory schemes are allowed, and packages (including 
official packages) can be built on hosts with either classical or "merged 
`/usr`" directory schemes"
Option H "`hard`: both directory schemes are allowed, but packages should only 
be built on hosts with "merged `/usr`" directory schemes (or in such chroots)"
Option F "Further Discussion"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  W M H F 
===   ===   ===   === 
Option W0 2 4 
Option M  6   3 6 
Option H  4 3   6 
Option F  2 0 0   



Looking at row 2, column 1, M
received 6 votes over W

Looking at row 1, column 2, W
received 0 votes over M.

Option W Reached quorum: 4 >= 2
Option M Reached quorum: 6 >= 2
Option H Reached quorum: 6 >= 2


Option W passes Majority.   2.000 (4/2) > 1


  Option M defeats Option W by (   6 -0) =6 votes.
  Option H defeats Option W by (   4 -2) =2 votes.
  Option W defeats Option F by (   4 -2) =2 votes.
  Option M defeats Option F by (   6 -0) =6 votes.
  Option H defeats Option F by (   6 -0) =6 votes.


The Schwartz Set contains:
 Option M "`middle`: both directory schemes are allowed, and packages 
(including official packages) can be built on hosts with either classical or 
"merged `/usr`" directory schemes"
 Option H "`hard`: both directory schemes are allowed, but packages 
should only be built on hosts with "merged `/usr`" directory schemes (or in 
such chroots)"



- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 

Re: win32-loader_0.9.4_source.changes ACCEPTED into unstable

[Didier 'OdyX' Raboud]

Le samedi, 9 février 2019, 21.43:19 h CET Cyril Brulebois a écrit :
> Holger Wansing  (2019-02-09):
> > According to
> > https://qa.debian.org/developer.php?login=debian-boot%40lists.debian.org
> > win32-loader is still blocked from migrating to testing because of udeb
> > block.
> > 
> > This should be lifted now, right?
> 
> It's a little different… there's a specific hint for this package[1]:
> | # doesn't actually produce udebs, but blocked RoM (not d-i RM): it gets
> | handled by the ftp team so make sure the package migrates at the same
> | time it gets copied into debian/tools/$suite. block-udeb win32-loader
> 
>  1. https://release.debian.org/britney/hints/freeze
> 
> The maintainer usually checks with the ftp team and tells the release
> team or me when an unblock-udeb makes sense.

win32-loader 0.9.4 should really enter buster, it contains bootcfg.nsh 
improvements from Thomas Gaugler (NSIS maintainer), uploaded in mid-January;

https://salsa.debian.org/installer-team/win32-loader/compare/0.9.2...0.9.4

Then, the ./debian/tools/win32-loader/unstable/ directory has to be copied by 
FTP masters to the …/testing/ counterpart (and then to stable around release 
day). This is tracked a #916447.

@Cyril: can we get 0.9.4 in testing?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Dear Technical Committee members,

I call for vote immediately on the following resolution.

=== Resolution ===

The Technical Committee resolves to decline to override the debootstrap
maintainers.

Furthermore, using its §6.1.5 "Offering advice" power, the Technical
Committee considers that the desirable solution at the time of `bullseye` is:

* W: `weak`: both directory schemes are allowed, but packages should only
 be built on hosts with classical directory schemes (or in such
 chroots)

* M: `middle`: both directory schemes are allowed, and packages (including
   official packages) can be built on hosts with either classical
   or "merged `/usr`" directory schemes

* H: `hard`: both directory schemes are allowed, but packages should only
 be built on hosts with "merged `/usr`" directory schemes (or in
 such chroots)

* FD: Further Discussion

=== End Resolution ===



=== Rationale ===

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between
`/` and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what
_needs_ to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards "merged
`/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system
files in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example
i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for
simply dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks
by default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues 

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le jeudi, 21 février 2019, 15.28:23 h CET Ian Jackson a écrit :
> Back in the wider world, of course many people build packages on
> Debian systems for installation `somewhere else'.  I have done it
> myself and probably many of the people reading this message have too.
> 
> What is implicitly going on here is that it is mostly-tacitly[2] being
> assumed (or declared) that `I built this .deb on my laptop[1] and gave
> it to my friend' is wrongheaded.

I don't think it is wrongheaded, but I do think that assuming that it is meant 
to work consistently under any circumstances, is.  There are _so many_ 
circumstances that make this exercise error-prone:

"I built this amd64 .deb and gave it to my friend for use on their RasbperryPi 
arm64 host"

"I built this .deb on my laptop on which I had installed a /usr/local/bin/
grep"

"I built this .deb an gave it to my friend who runs CentOS"

etc
 
> I don't think doing that is wrongheaded.  Certainly it is extremely
> common; we don't have any public pronouncements saying it is somehow
> wrong; and we have had little discussion where we as a project decided
> that this was now a use case which we feel free to just break.

Frankly, while it's not _broken_ per se, it is and has always really been 
fragile.  True, merged-/usr arguably worsens _one_ aspect of building packages 
on one's host, but in ways that are really easy to detect, and warn for.

> Personally I think that this is a very important thing to keep
> working.  It is the very core of users' collective software freedom.

You seem to be conflating "building on one's host" with "outside of any 
chroot", and equating this with "users' collective software freedom" is really 
making your point a disservice.  Being able to improve, build and share binary 
artifacts of free software is _vital_, and the whole point of building 
software distributions in the first place, but insisting that these rights are 
only "truly" exercised when builds are done outside of chroots is 
disingenuine. .deb packages already have to be built using certain tools, so 
we do set the limit (of what minimal set of tools are mandatory) somewhere, 
and my point is that this limit might not be at the right place. I'd be 
totally OK with saying "the only supported way to build .deb packages from 
buster on is using by pdebuild; however, you _can_ use dpkg-buildpackage 
alone, but be aware (and you'll get warnings) that this can lead to building 
.deb packages with undesireable properties."  The second half of the sentence 
is already true, and has always been; we probably just failed at communicating 
it sufficiently clearly.

> And that software freedom needs to be easy to exercise in practice.
> Despite a lot of excellent tooling, chroots are still not entirely
> trivial to set up and maintain.

Then that's maybe what we should be fixing.  

> I would invite the TC to read this manpage, which is trying to explain
> to a Debian user how to change the programs on their own computer
>   https://manpages.debian.org/stretch-backports/dgit/dgit-user.7.en.html
> and then consider how much even worse it would be if we had to write
> about chroots too.

Perhaps dpkg-buildpackage should be grown to build in a chroot by default? Or 
get an option to do that?

Really, I think we should stop considering that .debs built outside of 
"controlled environments" are more than temporary software transports. Our 
"standard" package building tools should build in such environments by 
default.

> To TC members who are minded to uphold the current approach, I would
> ask: can you please explicitly state your opinion on this ?  That is:
> 
>   Is it OK for a Debian user to build .deb on their laptop and give it
>   to their friend ?

Yes; provided that said .deb is built in a sane (sanitized / controlled) 
environment.  As you're talking about non-chroot builds; it is OK, provided 
that the tools warn about that. In that area, I think the "Build-Tainted-By" 
are steps in the right direction.

>   If it is OK, how will we make sure that it does not pointlessly break ?

As it is already broken in many ways, your question is biased. But I think the 
good way is to normalize "proper builds", by making sure our standard tools 
"do the right thing" by default.

> I readily admit that there are many ways that this can produce a
> result significantly different to the official Debian package,
> particularly because the package build system may configure itself
> differently in the the presence of unexpected.  The resulting package
> is probably not going to be suitable for wide distribution.
> 
> But those kind of problems are (a) not serious in practice
> (b) generally have obvious symptoms and (c) are easily worked around
> by various means.  Working around a usrmerge-generated failure is
> difficult; it usually involves doing serious violence to the upstream
> build system, or perhaps horrific rules file bodges.

Given a Build-Tainted-By flag in the binary 

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le mardi, 19 février 2019, 01.59:18 h CET Steve McIntyre a écrit :
> While I'm not necessarily disagreeing with the overall point(s) here,
> some of the points in this list of arguments seem dubious at
> best. Maybe you could expand?

Sure. Sorry for publishing a new ballot before answering.

> >* booting with `/` only is not systematically tested in Debian anymore;
> 
> I'm assuming you mean "/ without /usr" here?

Yes. Clarified this point by merging it with the "separate / and /usr" one 
above.

> >* the packaging infrastructure to install files outside of `/usr` is not
> >  standard and represents technical debt:
> 
> I have no idea what you're suggesting here.

Same here (clarified in the ballot). What I'm trying to say here is that 
installing (e.g.) libs to /lib instead of /usr/lib is usually a deviation from 
standard software building (either in upstream packaging, or in debian/rules), 
that needs to be maintained on the long-term.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 18 février 2019, 08.58:53 h CET Didier 'OdyX' Raboud a écrit :
> Dear Technical Committee members,
> (CC'ed to submitter, and debootstrap maintainers for information and
> feedack)
> 
> Here's the current state of the draft resolution; which `master` is at
> https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ball
> ot.md
> 
> I will submit it to vote on Friday 22.; the discussion period is open!

Thank you for the various comments. I have amended the ballot (which is more a
"explanation text + short ballot" incorporating the suggestions from the IRC
meeting as well as taking into accounts remarks on this bug.

I intend to answer some mails on that bug, and call for a vote on Sunday I
guess.

See: 
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md
for the markdown-rendered version; and below:

# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between `/`
and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what _needs_
to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system files
in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example i386
requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for simply
dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues f

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Dear Technical Committee members,
(CC'ed to submitter, and debootstrap maintainers for information and feedack)

Here's the current state of the draft resolution; which `master` is at
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md

I will submit it to vote on Friday 22.; the discussion period is open!

# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents (/usr/{bin,sbin,lib*}).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
  booting without initramfs onto a minimal root filesystem that carried just
  enough to mount the `/usr` filesystem later in the boot process. Given the
  evolution of physical hosts' capabilities, initramfs'es have been default in
  Debian (and elsewhere) for a long time, and most systems no longer have an
  intermediate state during boot in which they have only `/`, but not `/usr`,
  mounted.
* another use-case is to be able to share an identical `/usr` over a network
  link; hence booting an initramfs, mounting a local `/`, then mounting `/usr`
  over the network. It seems that an initramfs with everything needed to mount
  a filesystem over a network link directly actually has a smaller footprint.
* booting with `/` only is not systematically tested in Debian anymore;
* the packaging infrastructure to install files outside of `/usr` is not
  standard and represents technical debt:
* given its status as remnant "folklore", the distinction between what _needs_
  to be shipped in `/` and what can stay in `/usr` is often interpreted
  arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
  paths can confuse common understanding of paths precedence.

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing views
  of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and dpkg
  doesn't support this situation cleanly
  [#134758](https://bugs.debian.org/134758).

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The compatibility symbolic links `/lib` → `/usr/lib` and
`/lib64` → `/usr/lib64` are required by the various CPUs' platform ABIs (for
example i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and
amd64 requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove
them altogether. Similarly, removing `/bin` is not under consideration because
it would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only considered
for implementation with symlinks (there are no proposals for simply dropping
`/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
  [usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
  default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/` and
replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues have arisen.
Due to the fact that some buster/sid hosts have the "merged `/usr`" symlinks in
place, it has been observed that some binary packages carried some traces of
these differences (notably official packages built on Debian buildd hosts which
had been resetup).
Some such differences can actually render the built packages unuseable on
non-"merged `/usr`" systems.
For example, if `cat` is detected at build-time in `/usr/bin/cat` (where
coreutils ships `/bin/cat`), a binary hardcoding that path will try to use
`/usr/bin/cat` after installation, but that path doesn't exist in
non-"merged `/usr`" systems.
In order to mitigate this, debootstrap has been modified to let its "buildd"
variant be non-"merged `/usr`", the Debian buildds have been resetup and the
affected packages 

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Didier 'OdyX' Raboud]

Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
> Therefore I raise the question if win32-loader is really supposed
> to work on a secure boot EFI system?

No. This was never implemented. win32-loader needs a new maintainer who is 
willing to tackle exactly these types of problems, and I'm not that person. 
:-/

> If such a system is detected, maybe a warning could be added?

Sure. I suggest this would be done very early, but have no clue how to detect 
such a system. This would also make sense in time for buster. Could you work 
on a patch? Thomas; an idea?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#919023: Simplification of BOOTCFG_CreateGUID function

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le vendredi, 11 janvier 2019, 22.42:13 h CET Thomas Gaugler a écrit :
> The conversion of an UUID value into a string can be achieved by just
> using the g (GUID) type of the System plug-in. As a consequence the
> Win32 API calls could be eliminated.

Looks good to me; uploaded.

Would you be interested in taking over win32-loader? It needs a knowledgeable 
maintainer, I have mostly lost interest, you look like the ideal person to 
maintain win32-loader (in conjunction with nsis); what do you say of this?

 :-)

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: #914897: debootstrap, buster: Please disabled merged /usr by default

[Didier 'OdyX' Raboud]

Dear Hideki, dear src:debootstrap maintainers,

tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
default now, or are you OK letting the TC decide on this subject?

Longer version:

As you might be aware, #914897 (initially filed on src:debootstrap) has now 
been reassigned to the Technical Committee.  As, formally, the Maintainer of 
src:debootstrap is "debian-boot@l.d.o and the current Uploaders", I would like 
to make sure that the TC is not going to overrule unnecessarily.

Hideki, if I read the debootstrap history correctly, you enabled "merged /usr" 
by default in debootstrap 1.0.102.  Given the recent discussion in debian-
devel@ (starting at [0]) and on #914897, could you (or anyone speaking as with 
a "debootstrap maintainer" hat on) state if, either of:

* you would be willing to toggle the "merged /usr" default in debootstrap in a
  subsequent upload;
* you maintain that the "merged /usr" default (to yes) is here to stay.

Many thanks in advance for your consideration,

OdyX

[0] https://lists.debian.org/debian-devel/2018/11/msg00354.html

P.S. I'm aware that this might sound formal, or dismissive of Julien's
 statements.  I just _really_ don't want the TC to eventually overrule
 "the debootstrap maintainers" without need.

Re: Bug#902226: debian-installer-netboot-images: FTBFS in stretch, even when allowing network access

[Didier 'OdyX' Raboud]

Hi theres,

Le lundi, 25 juin 2018, 01.33:38 h CEST Cyril Brulebois a écrit :
> Cyril Brulebois  (2018-06-24):
> > At first glance, it seems to me this bug could be addressed in two
> > different ways, which don't seem to be too convoluted. The first way
> > would be to try the s-p-u download and fall back to s download, for each
> > and every download. But this could (probably only theoretically) lead to
> > inconsistent downloads, mixing bits and pieces from s-p-u and from s.
> > Plus plenty of errors when the default location isn't the right one.

Exactly. If a pure s-p-u build fails, it's because the s-p-u debian-installer 
isn't built on all architectures, so the d-i-n-i s-p-u build should really 
fail. (acronyms ftw)

> > I suppose a better way would be to figure out with an early test if the
> > target version is available in s-p-u or in s, and then pick the right
> > suite for all downloads. Patches for this second approach are welcome.

That seems more fool-proof and consistent: download from a single suite: 
either from s-p-u or from stretch only, and for all archs.

> I've pushed a prospective branch (pu/fix-ftbfs-in-stretch) with two commits:
> https://salsa.debian.org/installer-team/debian-installer-netboot-images/com
> mit/86f910f8e1e60e308747a7f53045862705b0a132
> https://salsa.debian.org/installer-team/debian-installer-netboot-images/com
> mit/eb2e5b3fb437b288c4c83427fb1c0d213f7b5a5e

Looks good to me, given that strategy.

> Only checked with the first few architectures (still on limited bandwidth),
> but that seems to do the trick. Slightly not happy about having that check
> and fallback done for each and every architecture (instead of once and for
> all), which could again lead to bits and pieces from both sources mixed
> together); but I guess that's a reasonable compromise (no big changes needed
> in the code).

I've tried for some time to (ab)use make targets to modify DISTRIBUTION 
depending on partial calls to get_images, but failed.

Given my failed attempts, I suspect your patches are the lesser evilfor 
solving this. But I'm not convinced that solving this is better than ensuring 
we only ever build "pure-stretch" or "pure-stretch-proposed-updates" d-i-n-
i's.

> I'll let others comment on this bug report plus proposed solution; Didier
> maybe?

Thanks for the explicit ping; I'm not on top of Debian things these days.

Cheers,
OdyX

Re: RFC: Switching guided partitioning to LVM by default?

[Didier 'OdyX' Raboud]

Le samedi, 5 août 2017, 22.20:21 h EDT Geert Stappers a écrit :
> When we take LVM as default (which is fine for me)
> then we should have the courage to have free PE.
> So not assign all diskspace.

Yes. I just tried on a stretch mini.iso, if you pick "Guided - use a whole 
disk with LVM" , the default partitioning you get is "All files in one 
partition" :
254.8 Mb /boot on ext2
107.1 Gb lvm in which …
1.1 Gb of swap
106 Gb /

If we go the LVM by default route, I'd at least consider making the LVM not 
entirely filled, and maybe also swap the default to a separate /home.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#864973: stretch-pu: package win32-loader/0.8.3+deb9u1

[Didier 'OdyX' Raboud]

Le dimanche, 25 juin 2017, 22.53:27 h CEST Cyril Brulebois a écrit :
> Looks good to me, feel free to upload, thanks.
> 
> By the way, we probably shouldn't be using “stable” in URLs, but the
> target distribution (stretch here)?

Uploaded.

I noticed 0.8.4 hasn't migrated to testing, which might cause an issue though: 
do we need to put 0.8.3+deb9u1 in testing, or migrate 0.8.4 (with the ftp-
master dance) ?

Cheers,
OdyX

Bug#864973: stretch-pu: package win32-loader/0.8.3+deb9u1

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

As discussed on debian-boot starting from
https://lists.debian.org/4374235.3xk2uo9...@odyx.org , win32-loader
(in stretch) still doesn't use the deb.debian.org agreed-upon mirror.
Also, as it's standalone version embeds multiple other packages (as
listed on
https://deb.debian.org/debian/tools/win32-loader/stable/win32-loader.txt
), the 0.8.3 version as released with Stretch still contains jessie's
debian-archive-keyring.

Specifically, we held this upload back then because we were waiting on
gnupg's 2.1.18-8 (which pu request is tracked in #863734)

It would be good to have an updated win32-loader in Stretch; the
possible debdiff would be attached.

Cheers,
OdyX
diff -Nru win32-loader-0.8.3/branch.nsi win32-loader-0.8.3+deb9u1/branch.nsi
--- win32-loader-0.8.3/branch.nsi   2017-01-01 11:40:06.0 +0100
+++ win32-loader-0.8.3+deb9u1/branch.nsi2017-06-18 10:21:47.0 
+0200
@@ -63,7 +63,7 @@
   StrCpy $base_path_images  "netboot/debian-installer/hurd-$arch"
 ${EndIf}
   ${Else}
-StrCpy $base_url "http://httpredir.debian.org/debian/dists/stable/;
+StrCpy $base_url "http://deb.debian.org/debian/dists/stable/;
 ${If} $kernel == "linux"
   ; Only Debian GNU/Linux will have a stable branch for the stretch cycle
   StrCpy $base_path_hashes"main/installer-$arch/current/images/"
diff -Nru win32-loader-0.8.3/debian/changelog 
win32-loader-0.8.3+deb9u1/debian/changelog
--- win32-loader-0.8.3/debian/changelog 2017-04-19 18:03:11.0 +0200
+++ win32-loader-0.8.3+deb9u1/debian/changelog  2017-06-18 10:25:41.0 
+0200
@@ -1,3 +1,10 @@
+win32-loader (0.8.3+deb9u1) stretch; urgency=medium
+
+  * Drop bz2 compression for source
+  * Replace all mirror urls with deb.debian.org
+
+ -- Didier Raboud   Sun, 18 Jun 2017 10:25:41 +0200
+
 win32-loader (0.8.3) unstable; urgency=low
 
   * The « Pippita » release
diff -Nru win32-loader-0.8.3/debian/rules win32-loader-0.8.3+deb9u1/debian/rules
--- win32-loader-0.8.3/debian/rules 2017-04-19 18:03:11.0 +0200
+++ win32-loader-0.8.3+deb9u1/debian/rules  2017-06-18 10:21:47.0 
+0200
@@ -13,7 +13,7 @@
 PACKAGES_LIST := $(shell set -e; \
for p in ${B_D_PACKAGES}; \
do \
-   dpkg-query --showformat='$${source:Package;-25} 
$${source:Version;-25} 
http://ftp.debian.org/debian/pool/main/$${source:Package;1}/$${source:Package}\\n'
 --show $$p; \
+   dpkg-query --showformat='$${source:Package;-25} 
$${source:Version;-25} 
http://deb.debian.org/debian/pool/main/$${source:Package;1}/$${source:Package}\\n'
 --show $$p; \
done)
 
 BUILT_USING_LIST := $(shell set -e; \
diff -Nru win32-loader-0.8.3/debian/source/options 
win32-loader-0.8.3+deb9u1/debian/source/options
--- win32-loader-0.8.3/debian/source/options2014-08-28 20:34:04.0 
+0200
+++ win32-loader-0.8.3+deb9u1/debian/source/options 1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-# Compress source using bz2
-compression = bzip2
diff -Nru win32-loader-0.8.3/Makefile win32-loader-0.8.3+deb9u1/Makefile
--- win32-loader-0.8.3/Makefile 2017-03-20 20:56:38.0 +0100
+++ win32-loader-0.8.3+deb9u1/Makefile  2017-06-18 10:21:47.0 +0200
@@ -181,7 +181,7 @@
   $(NULL)
genisoimage -r -J -o $@ netboot/daily
 
-BASE_URL=http://ftp.nl.debian.org/debian/dists/stable/main
+BASE_URL=http://deb.debian.org/debian/dists/stable/main
 netboot/download-stable-stamp:
mkdir -p netboot/stable/install.{386,amd}/gtk
wget 
$(BASE_URL)/installer-i386/current/images/netboot/debian-installer/i386/linux \

Re: [pkg-gnupg-maint] Last chance for d-i changes in stretch

[Didier 'OdyX' Raboud]

Le mardi, 30 mai 2017, 12.56:29 h CEST Daniel Kahn Gillmor a écrit :
> I've just filed unblock request #863734, which will hopefully achieve
> this result.

Ah great. Will keep an eye and upload as soon that's granted :-)

-- 
OdyX

Re: Last chance for d-i changes in stretch

[Didier 'OdyX' Raboud]

Le samedi, 27 mai 2017, 17.17:10 h CEST Didier 'OdyX' Raboud a écrit :
> win32-loader should be arch:all-rebuilt (aka uploaded) with a versionned
> Build-Depends on the  latest debian-archive-keyring. It would therefore
> also embed the latest versions of all the other binaries its standalone
> version embeds.

For all packages with the same version in unstable and testing, it's not an 
issue (and doesn't need an explicit B-D version); it's the case for all but 
one of the packages win32-loader has a Built-Using value for: src:gnupg2 is 
currently in 2.1.18-8 version in unstable and -6 in testing.

If I upload win32-loader now, it will embed gpgv-win32 2.1.18-8, no matter 
which gnupg2 version will be part of stretch. There are three alternatives, in 
decreasing order of preference:
* get gnupg2 in testing, upload win32-loader to unstable, migrate it
* upload win32-loader to unstable, upload it _too_ (with a different version?) 
in testing-proposed-updates to get rid of the version discrepancy
* upload win32-loader to unstable, migrate it (and too bad for the version 
difference)

> It also currently uses httpredir.debian.org as only mirror, so we should
> decide if it makes sense to consolidate onto deb.debian.org for win32-
> loader too.

I've staged a change of all mirror references to deb.debian.org. The 
previously-discussed source compression change away from .bz2 would also be 
part of that upload. I'm waiting for directions regarding gnupg2 :-)

Cheers,
OdyX
-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Last chance for d-i changes in stretch

[Didier 'OdyX' Raboud]

Le vendredi, 26 mai 2017, 19.04:13 h CEST Cyril Brulebois a écrit :
> Hi,
> 
> You might have noticed final preparations for d-i Stretch RC 4 are
> underways. A new debian-installer upload (or a binNMU) will need to
> happen before the first stretch release (aka. r0). If there's anything
> you want or would like to include in r0, now is the time to mention it.
> 
> Right now, the last upload/binNMU will be needed:
>  - to account for updated keys in debian-archive-keyring;
>  - to include pending netcfg changes (IPv6 vs. rdnssd);
>  - to possibly include a last choose-mirror update;

win32-loader should be arch:all-rebuilt (aka uploaded) with a versionned 
Build-Depends on the  latest debian-archive-keyring. It would therefore 
also embed the latest versions of all the other binaries its standalone 
version embeds.

It also currently uses httpredir.debian.org as only mirror, so we should 
decide if it makes sense to consolidate onto deb.debian.org for win32-
loader too.

Opinions?

Cheers,
OdyX

Re: Bug#861729: unblock: win32-loader/0.8.3

[Didier 'OdyX' Raboud]

(Dropping the bug, only writing to d-boot)

Le mercredi, 3 mai 2017, 11.54:16 h CEST Cyril Brulebois a écrit :
> A couple of things (feel free to follow up only to debian-boot and me):
>  - debian/files is left over after building a source package; while I
>know mostly nothing about dpkg-genbuildinfo, it feels a bit weird
>compared to all other d-i packages which leave a clean git tree after
>a source build;

This seems like a bug in dpkg-genbuildinfo to me, as I'm not doing anything 
spethial in win32-loader with regards to this. I noticed this 'debian/files' 
leftover in plenty of my packages, but didn't find time to properly 
investigate.

>  - does it make sense to force bzip2 for the source tarball? It dates
>back to 2011, so was probably an improvement over gz, but now that we
>have xz, just using that would probably make sense?

Oh yes, absolutely. Is it a change we want in stretch?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#861729: unblock: win32-loader/0.8.3

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock-udeb package win32-loader 0.8.3 as it fixes an FTBFS
on i386 in stretch (and is always blocked because of the manual migration to
be done by ftpmasters):

> * Fix FTBFS on i386: use gawk to prepare README file (Closes: #860695)

(This is a bug in mawk, reported as #860751)

debdiff is attached.

ftpmaster: please copy debian/tools/win32-loader/unstable into …/testing 

unblock-udeb win32-loader/0.8.3

Cheers, OdyX
diff -Nru win32-loader-0.8.2/debian/changelog 
win32-loader-0.8.3/debian/changelog
--- win32-loader-0.8.2/debian/changelog 2017-03-20 21:23:59.0 +0100
+++ win32-loader-0.8.3/debian/changelog 2017-04-19 18:03:11.0 +0200
@@ -1,3 +1,11 @@
+win32-loader (0.8.3) unstable; urgency=low
+
+  * The « Pippita » release
+
+  * Fix FTBFS on i386: use gawk to prepare README file (Closes: #860695)
+
+ -- Didier Raboud   Wed, 19 Apr 2017 18:03:11 +0200
+
 win32-loader (0.8.2) unstable; urgency=medium
 
   * The « Iao » release
diff -Nru win32-loader-0.8.2/debian/control win32-loader-0.8.3/debian/control
--- win32-loader-0.8.2/debian/control   2017-03-20 21:12:00.0 +0100
+++ win32-loader-0.8.3/debian/control   2017-04-19 18:03:11.0 +0200
@@ -10,6 +10,7 @@
  mingw-w64,
  libgcrypt-mingw-w64-dev, libgpg-error-mingw-w64-dev,
  librsvg2-bin, icoutils,
+ gawk,
  gettext,
  grub-pc-bin (>= 1.99~rc1-3),
  imagemagick,
diff -Nru win32-loader-0.8.2/debian/rules win32-loader-0.8.3/debian/rules
--- win32-loader-0.8.2/debian/rules 2017-03-20 21:10:08.0 +0100
+++ win32-loader-0.8.3/debian/rules 2017-04-19 18:03:11.0 +0200
@@ -39,9 +39,9 @@
dh_auto_build

# Prepare the README file
-   awk '{sub(/@PACKAGES_LIST@/,"$(PACKAGES_LIST)")}1 \
- {sub(/@NSIS_VERSION@/,"$(NSIS_VERSION)")}1 \
- {sub(/@W32_VERSION@/,"$(W32_VERSION)")}1' \
+   gawk '{sub(/@PACKAGES_LIST@/,"$(PACKAGES_LIST)")}1 \
+ {sub(/@NSIS_VERSION@/,"$(NSIS_VERSION)")}1 \
+ {sub(/@W32_VERSION@/,"$(W32_VERSION)")}1' \
debian/win32-loader_doc.txt > $(W32_BYHAND_NAME).txt
cat debian/copyright >> $(W32_BYHAND_NAME).txt
 endif

Bug#860695: win32-loader: FTBFS on i386: segmentation fault

[Didier 'OdyX' Raboud]

Control: clone -1 -2
Control: reassign -2 mawk 1.3.3-17
Control: reopen -2 o...@debian.org
Control: retitle -2 mawk: segfaults on i386 during win32-loader build
Control: severity -2 serious

Le mercredi, 19 avril 2017, 17.31:26 h CEST Didier 'OdyX' Raboud a écrit :
> Le mercredi, 19 avril 2017, 15.44:00 h CEST Sven Joachim a écrit :
> > >> Relevant part (hopefully):
> > > Actually:
> > >> > # Prepare the README file
> > >> > awk
> > >> > (…)
> > >> > Segmentation fault
> > > 
> > > `awk` segfaults here. This seems to be an awk bug, or problem. Is the
> > > command- line for it too long, or is it something else?
> > 
> > Possibly it's the same problem as #158481.  A workaround is to use
> > original-awk or gawk instead of awk (and build-depend on it, of course).
> > 
> > I don't feel like debugging this issue, since mawk in Debian is
> > unmaintained. :-(
> 
> Thanks for the information; I've successfully reproduced the awk segfault in
> a  i386 porterbox, and I can confirm the gawk replacement fixes that.

Hereby cloning, reopening and reassigning to mawk, with a severity: serious. 
Will see if I can reproduce with a simpler test-case.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#860695: win32-loader: FTBFS on i386: segmentation fault

[Didier 'OdyX' Raboud]

Control: tags -1 -moreinfo +pending

Le mercredi, 19 avril 2017, 15.44:00 h CEST Sven Joachim a écrit :
> >> Relevant part (hopefully):
> > Actually:
> >> > # Prepare the README file
> >> > awk
> >> > (…)
> >> > Segmentation fault
> > 
> > `awk` segfaults here. This seems to be an awk bug, or problem. Is the
> > command- line for it too long, or is it something else?
> 
> Possibly it's the same problem as #158481.  A workaround is to use
> original-awk or gawk instead of awk (and build-depend on it, of course).
> 
> I don't feel like debugging this issue, since mawk in Debian is
> unmaintained. :-(

Thanks for the information; I've successfully reproduced the awk segfault in a 
i386 porterbox, and I can confirm the gawk replacement fixes that.

I will upload a simple fix later today.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#860695: win32-loader: FTBFS on i386: segmentation fault

[Didier 'OdyX' Raboud]

Control: tags -1 +moreinfo +help

Le mercredi, 19 avril 2017, 09.28:30 h CEST Lucas Nussbaum a écrit :
> During a rebuild of all packages in stretch (in a stretch chroot, not a
> sid chroot), your package failed to build on i386.

win32-loader is a arch:all package, and is "usually" built on amd64 buildds, 
on which it builds fine. This i386-specific FTBFS has been visible through the 
reproducible builds infrastructure for a while:


https://tests.reproducible-builds.org/debian/rb-pkg/testing/i386/win32-loader.html

> Relevant part (hopefully):

Actually:

> > # Prepare the README file
> > awk
> > '{sub(/@PACKAGES_LIST@/,"grub2 2.02~beta3-5  
> > http://ftp.debian.org/debian/pool/main/g/grub2\ncpio  
> > 2.11+dfsg-6   http://ftp.debian.org/debian/pool/main/c/cpi
> > o\ngzip  1.6-5 http://ftp.debian.o
> > rg/debian/pool/main/g/gzip\ngnupg22.1.18-6
> >   http://ftp.debian.org/debian/pool/main/g/gnupg2\ndebian-archive-keyr
> > ing2014.3http://ftp.debian.org/debian/pool/main/d/
> > debian-archive-keyring\nloadlin   1.6f-5  
> >   http://ftp.debian.org/debian/pool/main/l/loadlin\nipxe  
> > 1.0.0+git-20161027.b991c6
> > http://ftp.debian.org/debian/pool/main/i/ipxe\nnsis  
> > 2.51-1http://ftp.debian.org/debian/pool/main/n/nsis\nl
> > ibgcrypt20   1.7.6-1   http://ftp.debian.org/d
> > ebian/pool/main/l/libgcrypt20\nlibgpg-error  1.26-2   
> >  http://ftp.debian.org/debian/pool/main/l/libgpg-error\n;)}1 \
> > {sub(/@NSIS_VERSION@/,"2.51-1+b1")}1 \
> > {sub(/@W32_VERSION@/,"0.8.2")}1' \
> > debian/win32-loader_doc.txt > win32-loader_0.8.2_all.txt
> > Segmentation fault

`awk` segfaults here. This seems to be an awk bug, or problem. Is the command-
line for it too long, or is it something else?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#859084: unblock: win32-loader/0.8.2

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock-udeb package win32-loader 0.8.2 as it fixes a FTBFS
in stretch (and is always blocked because of the manual migration to
be done by ftpmasters):

>   * Fix dpkg-query calls to use source:* for Version and Package directly
> - Add Build-Dependency on dpkg (>= 1.16.2) for that support
> - Fixes the FTBFS revealed by loadlin's binNMU
> (Closes: #858104)

debdiff is attached.

ftpmaster: please copy debian/tools/win32-loader/unstable into …/testing 

unblock-udeb win32-loader/0.8.2

Cheers, OdyX
diff -Nru win32-loader-0.8.1/debian/changelog 
win32-loader-0.8.2/debian/changelog
--- win32-loader-0.8.1/debian/changelog 2016-12-29 20:57:22.0 +0100
+++ win32-loader-0.8.2/debian/changelog 2017-03-20 21:23:59.0 +0100
@@ -1,3 +1,14 @@
+win32-loader (0.8.2) unstable; urgency=medium
+
+  * The « Iao » release
+
+  * Fix dpkg-query calls to use source:* for Version and Package directly
+- Add Build-Dependency on dpkg (>= 1.16.2) for that support
+- Fixes the FTBFS revealed by loadlin's binNMU
+(Closes: #858104)
+
+ -- Didier Raboud   Mon, 20 Mar 2017 21:23:59 +0100
+
 win32-loader (0.8.1) unstable; urgency=medium
 
   * The « poipoi » release
diff -Nru win32-loader-0.8.1/debian/control win32-loader-0.8.2/debian/control
--- win32-loader-0.8.1/debian/control   2016-12-29 19:06:06.0 +0100
+++ win32-loader-0.8.2/debian/control   2017-03-20 21:12:00.0 +0100
@@ -4,6 +4,7 @@
 Maintainer: Debian Install System Team 
 Uploaders: Robert Millan , Didier Raboud 
, Christian Perrier 
 Build-Depends:
+ dpkg (>= 1.16.2),
  debhelper (>= 9),
  nsis (>= 2.48), nsis-pluginapi,
  mingw-w64,
diff -Nru win32-loader-0.8.1/debian/rules win32-loader-0.8.2/debian/rules
--- win32-loader-0.8.1/debian/rules 2016-12-29 20:06:05.0 +0100
+++ win32-loader-0.8.2/debian/rules 2017-03-20 21:10:08.0 +0100
@@ -13,23 +13,13 @@
 PACKAGES_LIST := $(shell set -e; \
for p in ${B_D_PACKAGES}; \
do \
-   if test `dpkg-query --showformat='x$${Source}x' --show $$p` = 
"xx"; \
-   then \
-   dpkg-query --showformat='$${Package;-25} 
$${Version;-25} 
http://ftp.debian.org/debian/pool/main/$${Package;1}/$${Package}\\n' --show 
$$p; \
-   else \
-   dpkg-query --showformat='$${Package;-25} 
$${Version;-25} 
http://ftp.debian.org/debian/pool/main/$${Source;1}/$${Source}\\n' --show $$p; \
-   fi; \
+   dpkg-query --showformat='$${source:Package;-25} 
$${source:Version;-25} 
http://ftp.debian.org/debian/pool/main/$${source:Package;1}/$${source:Package}\\n'
 --show $$p; \
done)
 
 BUILT_USING_LIST := $(shell set -e; \
for p in ${B_D_PACKAGES}; \
do \
-   if test `dpkg-query --showformat='x$${Source}x' --show $$p` = 
"xx"; \
-   then \
-   dpkg-query --showformat='$${Package} (= $${Version}), ' 
--show $$p; \
-   else \
-   dpkg-query --showformat='$${Source} (= $${Version}), ' 
--show $$p; \
-   fi; \
+   dpkg-query --showformat='$${source:Package} (= 
$${source:Version}), ' --show $$p; \
done)
 
 NSIS_VERSION  := $(shell dpkg-query -f='$${Version}' -W nsis )

Bug#850801: unblock: win32-loader/0.8.1

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
X-Debbugs-Cc: win32-loa...@packages.debian.org, ftpmas...@ftp-master.debian.org
Usertags: unblock

Please unblock-udeb package win32-loader 0.8.1. as it has some useful
stretch'ification (and is always blocked because of the manual
migration to be done by ftpmasters):

>  * As NSIS doesn't support downloading from https (#819092), and as
>d-i dailies are now on an https-enforced hosts: don't allow branch
>or kernel selection
>  * Replace the Lines screenshot by a recent softWaves screenshot

ftpmaster: please copy debian/tools/win32-loader/unstable into …/testing 

unblock-udeb win32-loader/0.8.1

Cheers, OdyX

Bug#819092: #819092 win32-loader cannot load dailies because NSISdl doesn't support https

[Didier 'OdyX' Raboud]

tags -1 +help

Le mercredi, 23 mars 2016, 16.41:21 h CET Didier 'OdyX' Raboud a écrit :
> As the title says, win32-loader currently can't download dailies, as
> d-i.debian.org has moved to enforced https.
> 
> That's a limitation of the NSISdl NSIS builtin plugin. It could be replaced
> with the Inetc plugin [0], but it isn't packaged. 
> 
> No dailies means no kfreebsd/hurd too, unfortunately.

So I've spent a good part of today trying to fix that problem.

The path I've picked was to try to in-Debian build the Inetc plugin, and then 
use that in win32-loader to download d-i assets over https securely. 
Unfortunately, that didn't work out well enough:
* the inetc plugin is not properly licensed, but assuming it is under Zlib …
* it (kinda-)builds under Debian,
* it supports the NSIS 3.0 API,
* but I couldn't manage to make it work in win32-loader, as I was having 
errors such as "Dialog error (1812)", and then "Connection error", which I 
couldn't debug.

Anyway. Here's the nsis-plugin-inetc packaging:
https://anonscm.debian.org/cgit/collab-maint/nsis-plugin-inetc.git/

As for the bug at hand, I will upload a new win32-loader targetted at stretch 
that doesn't permit dailies or alternative architectures' download (as they 
later fail anyway), and get that into stretch.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#830951: Support usb dongles via usb-modeswitch and network-manager during installation

[Didier 'OdyX' Raboud]

Le lundi, 26 décembre 2016, 14.42:08 h CET Pirate Praveen a écrit :
> I wanted to install using a Tata Photon mobile broadband, but it was not
> detected. Will this be addressed for stretch? (I have retitled the bug).

No. Not for stretch.

This needs at least usb-modeswitch{,-data} & pppd as udebs, and that's only to 
have the needed binaries in the d-i context.

Your best option is probably to start with a Live CD.

That's unfortunate, indeed, but it needs someone to work on that at the 
beginning of the development period, not its end (and I don't have bandwidth 
for that kind of work currently).

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#847253: Updating the debian-installer-netboot-images Uploaders list

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Hi Tobias, hi Otavio,

Le mardi, 6 décembre 2016, 21.10:26 h CET Tobias Frost a écrit :
> Otavio Salvador  wishes no longer to be uploader of
> debian-installer-netboot-images.

Otavio, you'll be missed; thanks for you past work on d-i-n-i! I wish you good 
paths with, or without Debian!

I've now pushed the removal of your address from d-i-n-i's Uploaders field, it 
will be part of the next upload.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#845254: unblock: win32-loader/0.8.0

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package win32-loader 0.8.0. win32-loader is special in that it
is always 'block'ed, because it needs manual ftpmaster intervention on
migration:

> # doesn't actually produce udebs, but blocked RoM (not d-i RM): it gets
> # handled by the ftp team so make sure the package migrates at the same time
> # it gets copied into debian/tools/$suite.
> block-udeb win32-loader

0.8.0 is long overdue in stretch, please let it migrate. ftpmaster: please
copy debian/tools/win32-loader/unstable into …/testing 

unblock win32-loader/0.8.0

Cheers, OdyX

Re: Planning for d-i Stretch Alpha 9

[Didier 'OdyX' Raboud]

Just replying regarding the general "d-i Stretch Alpha 9" question: I'd like 
to get win32-loader 0.8.0 into stretch for the next d-i alpha.

There's more win32-loader work needed, but 0.8.0 is a pile of changes that are 
long needed in stretch.

-- 
Cheers,
OdyX

Re: Bug#839747: debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found)

[Didier 'OdyX' Raboud]

Le mercredi, 5 octobre 2016, 00.32:19 h CEST Santiago Vila a écrit :
> On Wed, Oct 05, 2016 at 12:22:31AM +0200, Cyril Brulebois wrote:
> > It might make sense to start uploading it to unstable since we're
> > slowly approaching freeze time. Say: starting with the next d-i
> > release.

Works for me, don't hesitate to ping if needed.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#830951: Support usb dongles via usb-modeswitch and network-manager during installation

[Didier 'OdyX' Raboud]

Le mercredi, 13 juillet 2016, 12.38:03 h CEST Pirate Praveen a écrit :
> I installed a desktop system using jessie 8.5 cd 1 image. Even though
> desktop was selected, I was booted into a text terminal because I could not
> use my usb dongle during installation. After the system is installed, I
> still could not use the dongle. After connecting my android phone and usb
> tethering, I could install usb-modeswitch and use internet.

d-i _could_ make use of usb-modeswitch{,-data} without too much hassle, but 
that would just make the GSM modems appear. Then there's modemmanager as 
interface for it, and 3gpp is also needed. This makes for a lot of packages 
needed to be installed to get a network connection *during d-i*.

> I think graphical system with synaptic should be installed on CD 1.( …)
> 
> Can we install gdm3 and synaptic on CD1?

You are mixing two entirely unrelated questions here:

* d-i context. It currently has (somewhat limited) WiFi support; we could 
discuss mobile broadband support (and this is the subject of your bugreport)
* what is installed by CD-1; you are arguing that usb-modeswitch{,-data} 
should be.

I can agree two both wishlist ideas, but they are unrelated.

-- 
Cheers,
OdyX

Bug#782845: debian-installer-netboot-images: FTBFS with a checksum mismatch

[Didier 'OdyX' Raboud]

Hi Cyril,

Le vendredi, 22 avril 2016, 20.18:23 Cyril Brulebois a écrit :
> > Le samedi, 18 avril 2015, 20.02:15 Cyril Brulebois a écrit :
> > > Not sure what's happening but I can't seem able to build d-i-n-i,
> > > with either httpredir.debian.org, localhost (a local mirror which
> > > is uptodate), ftp.fr.debian.org (its upstream) or ftp.debian.org;
> > > I'm attaching a build log for reference.
> > 
> > So this happens when d-i has not migrated to testing: the
> > get-images.sh script will try to download debian-installer_*.deb
> > from the mirror and compare its sha256sum against the Packages.gz
> > from its DISTRIBUTION.
> > 
> > Arguably, it should check the version first, and fail if theres' a
> > mismatch.
> 
> This seems to be fixed in git master (bfd32f1eb3). Seeing variables
> there, and checking what happened in the previous commit (7842e76a6d),
> I'm not sure I get what's done there. Why do we need to be able to
> override all those variables?

MIRROR is really useful when building this package.
DISTRIBUTION & KFREEBSD_KERNEL_MAJOR are convenient for upload tests, 
but are not really mandatory.

> Another question: any reason why MAJOR_VERSION hasn't been made
> overridable along with the others?

Because the packages as listed in debian/control contain this 
MAJOR_VERSION in the binary package name. Changing the MAJOR_VERSION 
implies regenerating debian/control, and a tour through NEW.

> Also, changelog entries explaining commits would be nice.

Aww, sorry. These are artifacts of my usual gbp-dch workflow. 

-- 
Cheers,
OdyX

Bug#819586: debian-installer-netboot-images: unhelpful handling of GPG errors

[Didier 'OdyX' Raboud]

Hoy KiBi,

Le vendredi, 22 avril 2016, 19.57:55 Cyril Brulebois a écrit :
> Adam D. Barratt  (2016-03-30):
> > Whilst a failure to verify the Release signature does mean that we
> > don't attempt to build an image using untrusted inputs, the package
> > build continues with no sign of a problem having occurred until the
> > binary packages are examined.
> 
> Thanks for the catch!
> 
> Didier, I see you have committed a fix in git master, so I'm tagging
> this bug report accordingly. Did you test it (e.g. by faking a Release
> file corruption)?

Yes, right. I hacked on that bug, but forgot to update the buglog; sorry
for that.

> This seems like something we should cherry-pick in
> stable branches, but I don't want to do so without a confirmation
> first.

The following patch makes the build fail indeed:

diff --git a/get-images.sh b/get-images.sh
index caea03d..31f25bf 100755
--- a/get-images.sh
+++ b/get-images.sh
@@ -159,6 +159,9 @@ unpack_installer () {
 wget -c $MIRROR/dists/$DISTRIBUTION/Release.gpg -O $RELEASE_FILE.gpg
 wget -c $MIRROR/dists/$DISTRIBUTION/Release -O $RELEASE_FILE
 
+# Corrupt the release file
+echo "Break the signature" >> $RELEASE_FILE
+
 gpgv --keyring /usr/share/keyrings/debian-archive-keyring.gpg 
$RELEASE_FILE.gpg $RELEASE_FILE
 
 get_di_built_using $1


-- 
Cheers,
OdyX

Bug#819092: win32-loader cannot load dailies (therefore can't setup non-stable arches) because NSISdl doesn't support https

[Didier 'OdyX' Raboud]

Package: win32-loader
Version: 0.7.14
Severity: important
Tags: d-i

As the title says, win32-loader currently can't download dailies, as
d-i.debian.org has moved to enforced https.

That's a limitation of the NSISdl NSIS builtin plugin. It could be replaced
with the Inetc plugin [0], but it isn't packaged. 

No dailies means no kfreebsd/hurd too, unfortunately.

Cheers, 

OdyX

[0] http://nsis.sourceforge.net/Inetc_plug-in

Bug#818997: gpgv.exe linked dynamically against zlib1, doesn't allow proper signature verification

[Didier 'OdyX' Raboud]

Package: gpgv-win32
Version: 1.4.20-4
Severity: serious
Tags: d-i

Dear maintainers,

I've noticed that gpgv.exe fails its CI test (debian/tests/gpgv-win32) in
version 1.4.20-4 (-3 and previous work fine):

(This is after adding WINEDEBUG=err+all as prefix to the latest line):

err:menubuilder:init_xdg error looking up the desktop directory
err:module:import_dll Library zlib1.dll (which is needed by 
L"Z:\\usr\\share\\win32\\gpgv.exe") not found
err:module:LdrInitializeThunk Main exe initialization for 
L"Z:\\usr\\share\\win32\\gpgv.exe" failed, status c135

It seems gpgv-win32 is dynamically linked against zlib1.dll, where it should
probably be statically linked. This appears to be a problem in the dependency
chain.

(By the way, the CI seems to have never run successfully in the last months:
https://ci.debian.net/packages/g/gnupg/unstable/amd64/ …)

Cheers, OdyX


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-proposed-updates'), (500, 
'proposed-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

gpgv-win32 depends on no packages.

gpgv-win32 recommends no packages.

Versions of packages gpgv-win32 suggests:
ii  wine  1.8.1-2

-- no debconf information

Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way

[Didier 'OdyX' Raboud]

Le vendredi, 18 mars 2016, 18.43:41 Didier 'OdyX' Raboud a écrit :
> C) Get coreutils build a hashsums-win32 package containing cross-
>compiled win32 executables (as we're doing for gpgv-win32 and cpio-
>win32). It could also provide these files through byhand, to allow
>users to check images on Windows platforms themselves too [3].

Here would be the patches to build a (partial-) coreutils-win32 package. 
The first patch's needed to make sure the two builds don't conflit with 
eachother.
The second patch tries to cross-build everything, fails (as more patches 
would be needed, but we don't care if we're only to build the *sum.exe 
binaries), then builds the executables we want.

The package seems functional, at least under wine.

BUT… Making coreutils B-D-I on mingw-w64 is not really the type of 
circular build dependency we enjoy, although this patch can certainly be 
enhanced with build-profiles. 

I'll see if I can follow Stephen's recommendation to use libgcrypt, 
then, and file a formal bug against coreutils if that's the only way.

-- 
Cheers,
OdyX>From e37afe1dfb02af7c9b14b1b3f91ecefcdd8d70d1 Mon Sep 17 00:00:00 2001
From: Didier Raboud <o...@debian.org>
Date: Fri, 18 Mar 2016 22:06:23 +0100
Subject: [PATCH 1/2] Use --builddirectory argument to dh_* to build
 out-of-tree

---
 debian/rules | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/rules b/debian/rules
index 5b9a6bd..a7c3e48 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,10 +19,11 @@ BIN_PROGS = cat chgrp chmod chown cp date dd df dir echo false ln ls mkdir \
 d=debian/coreutils
 
 override_dh_auto_configure:
-	dh_auto_configure -- --enable-install-program=arch 
+	dh_auto_configure --builddirectory -- \
+		--enable-install-program=arch
 
 %:
-	dh  $@ 
+	dh $@ --builddirectory
 
 override_dh_auto_clean:
 	make distclean || true
@@ -31,7 +32,7 @@ override_dh_auto_test:
 	# tests fail a lot on the buildds
 
 override_dh_auto_install:
-	dh_auto_install --destdir=$(d)
+	dh_auto_install --builddirectory --destdir=$(d)
 
 override_dh_install-arch: 
 	dh_install -a
-- 
2.8.0.rc3

>From bbe47b3062801325ab14dcef9cc8e75c0a23d2ad Mon Sep 17 00:00:00 2001
From: Didier Raboud <o...@debian.org>
Date: Fri, 18 Mar 2016 22:29:12 +0100
Subject: [PATCH 2/2] Cross-build some hashsum executables to win32, in a
 coreutils-win32 package

---
 debian/control | 10 
 .../win32/00_allow_configure_to_succeed.patch  | 31 
 debian/rules   | 55 --
 3 files changed, 93 insertions(+), 3 deletions(-)
 create mode 100644 debian/patches/win32/00_allow_configure_to_succeed.patch

diff --git a/debian/control b/debian/control
index 55b3f83..eae03bf 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Section: utils
 Priority: required
 Standards-Version: 3.9.6.0
 Build-Depends: gettext (>= 0.10.37), debhelper (>= 9.20120115), autotools-dev, texinfo (>= 4.2), groff, libattr1-dev [linux-any], libacl1-dev [linux-any], libselinux1-dev (>= 1.32) [linux-any], gperf, bison
+Build-Depends-Indep: mingw-w64
 
 Package: coreutils
 Architecture: any
@@ -28,6 +29,15 @@ Description: GNU core utilities
  uniq unlink users vdir wc who whoami yes
 Homepage: http://gnu.org/software/coreutils
 
+Package: coreutils-win32
+Architecture: all
+Priority: extra
+Suggests: wine
+Description: selected GNU core utilities (win32 build)
+ This package contains some GNU core utilities built for Windows.
+ .
+ It contains md5sum.exe, and sha*sum.exe
+
 Package: mktemp
 Pre-Depends: coreutils (>= 7.4-1)
 Depends: ${misc:Depends}
diff --git a/debian/patches/win32/00_allow_configure_to_succeed.patch b/debian/patches/win32/00_allow_configure_to_succeed.patch
new file mode 100644
index 000..0bfb19c
--- /dev/null
+++ b/debian/patches/win32/00_allow_configure_to_succeed.patch
@@ -0,0 +1,31 @@
+Description: Let the configure call finish
+Author: Didier Raboud <o...@debian.org>
+Last-Update: 2016-03-18
+
+diff --git a/configure b/configure
+index 4a6177f..8a98c2b 100755
+--- a/configure
 b/configure
+@@ -40686,7 +40686,8 @@ $as_echo "#define MOUNTED_INTERIX_STATVFS 1" >>confdefs.h
+ fi
+ 
+ if test -z "$ac_list_mounted_fs"; then
+-  as_fn_error $? "could not determine how to read list of mounted file systems" "$LINENO" 5
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: could not determine how to read list of mounted file systems" >&5
++$as_echo "could not determine how to read list of mounted file systems" >&6; }
+   # FIXME -- no need to abort building the whole package
+   # Can't build mountlist.c or anything that needs its functions
+ fi
+diff --git a/m4/ls-mntd-fs.m4 b/m4/ls-mntd-fs.m4
+index 49f11be..91a420e 100644
+--- a/m4/ls-mntd-fs.m4
 b/m4/ls-mntd-fs.m4
+@@ -348,7 +348,7 @@ if test -z 

Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way

[Didier 'OdyX' Raboud]

Package: win32-loader
Version: 0.7.14
Severity: important
Tags: d-i
Control: blocks 818463 by -1

win32-loader (its standalone version, available from debian/tools/ ) currently
relies exclusively on MD5 and SHA1 to trustfully download the d-i images.

Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way

[Didier 'OdyX' Raboud]

Control: tags -1 +help

Le vendredi, 18 mars 2016, 16.25:10 Didier 'OdyX' Raboud a écrit :
> win32-loader (its standalone version, available from debian/tools/ )
> currently relies exclusively on MD5 and SHA1 to trustfully download
> the d-i images.

After some more checking, this doesn't appear to be a quick and easy 
fix, and here's why:

plugins/sha1sum.c is an NSIS plugin file, inheriting from Werner Koch's 
sha1sum.c [0,1], itself inheriting from GnuPG 1.3.92. It has the 
advantage of allowing win32-loader.exe to proceed with the verification 
inline, without any Windows-specific dependency.

Here are the possibilities I see:

A) Package, and then use an NSIS plugin leveraging the Windows CryptoAPI
   [2]:
  - http://nsis.sourceforge.net/Crypto_plug-in
(doesn't support SHA256, last updated in 2013)
  - http://nsis.sourceforge.net/NsisCrypt_plug-in
Does support various hashes
First and only version in 2010
License quite unclear
https://sourceforge.net/projects/angabin/files/Version%201.0.0/

B) Write a new standalone sha256sum.c NSIS plugin from one of the
   existing implementations:
  - libgcrypt: cipher/sha256.c (LGPLv2.1+)
  - coreutils: lib/sha256.c (GPLv3+)
  - e2fsprogs: lib/ext2fs/sha256.c (GPLv2)
  - wget: lib/sha256.c (GPLv3+)
  - glibc: crypt/sha256.c (LGPLv2.1+)
  - … plenty of others

Given that win32-loader is GPLv3 +, this excludes e2fsprogs', but others 
should be fine.

C) Get coreutils build a hashsums-win32 package containing cross-
   compiled win32 executables (as we're doing for gpgv-win32 and cpio-
   win32). It could also provide these files through byhand, to allow
   users to check images on Windows platforms themselves too [3].

I don't like the first option, as it relies on outdated glue software; 
the second option probably provides the cleanest solution from the 
win32-loader point of view, at the cost of yet another sha256 
implementation. The third option feels like the correct way to do it, at 
the risk of adding win32 compilers in the bootstrap circle, through 
coreutils.

I'll see whether I can produce a patch to do C), and keep this bug 
posted.

-- 
Cheers,
OdyX

[0] https://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html
[1] ftp://ftp.gnupg.org/gcrypt/binary/sha1sum.c
[2] https://en.wikipedia.org/wiki/Microsoft_CryptoAPI
[3] 
https://lists.fedoraproject.org/pipermail/infrastructure/2009-November/008052.html

signature.asc
Description: This is a digitally signed message part.

Re: Bug#806036: Privilege escalation and code execution vulnerabilities in generated NSIS installers

[Didier 'OdyX' Raboud]

Dear Security Team,
Dear Debian-Boot,

Andre has reported this bug on Nov 24, and I've now uploaded the new 
NSIS version to unstable that fixes this bug.

In Debian, there's at least one NSIS installer shipped in packages: 
win32-loader, that is shipped on our CDs and from the mirrors.

Would it be useful to upload a fixed NSIS to {oldold,old,}stable, and 
rebuild win32-loader on all affected suites?

Cheers,

OdyX

Le mardi, 24 novembre 2015, 16.18:57 Andre Heinecke a écrit :
> Installers generated by NSIS 2.46 are vulnerable to attacks that can
> lead to code execution and privilege escalation (if the installer is
> running with elevated privileges).
> 
> This has been reported to us at Gpg4win (www.gpg4win.org) which is
> built under Debian GNU/Linux. We saw no other option to mitigate the
> attacks then to patch our version of NSIS.
> 
> We've also reported this upstream today:
> https://sourceforge.net/p/nsis/bugs/1125/
> 
> Background: Windows loads Libraries that are not "Known DLL's" from
> the directory of the executable first. As NSIS uses direct loading
> though LoadLibrary / LoadLibraryEx system calls, and links a not
> "Well Known" library (version.dll) placing Libraries with standard
> names like shfolder.dll or version.dll in the same Folder as an NSIS
> Installer (usually the Downloads folder) will load those libraries in
> the context of the installer. An attacker could cause these Libraries
> to be executed in the context of the installer.
> 
> This is especially problematic for signed Installers and Installers
> that require Elevated (Administrator) Privileges for installation. As
> this bypasses the signature validation and can be used for a
> privilege escalation.
> 
> Additionally NSIS uses an insecure temporary directory that can be
> modified with normal User access rights in case of an elevated
> installation. This can be used to modify plugins in that directory
> which then will be loaded with higher privileges. There is also a
> temporary file race on uninstallation where the uninstaller is copied
> into a temporary directory and afterwards executed with elevated
> privileges.
> 
> More details and descriptions about how we mitigate these attacks are
> available in the NSIS bug report.
> 
> Attached are the patches we are planning to use with NSIS to prepare
> our next gpg4win release. They can be applied in the Order of their
> names to the debian version of NSIS and compile on wheezy and jessie.


signature.asc
Description: This is a digitally signed message part.

Bug#807168: debian-installer-netboot-images: required resources not declared as build-dependencies (fetches via network)

[Didier 'OdyX' Raboud]

Control: tags -1 +wontfix

Le dimanche, 6 décembre 2015, 18.02:48 Jonas Smedegaard a écrit :
> debian-installer-netboot-images source package is less than 6k in
> size. Clearly the main part of the resulting binary packages come
> from fetching resources over the network (apparently using wget).
> Debian Policy includes the following in §4.2:
> > If build-time dependencies are specified, it must be possible to
> > build the package and produce working binaries on a system with
> > only essential and build-essential packages installed and also
> > those required to satisfy the build-time relationships (including
> > any implied relationships).
> 
> I can only interpret above as disallowing fetching resources over the
> network using wget.

d-i-n-i does (it's own) trust-path checking upon download, and it's 
doing so because there's (currently) no way to have these files local 
through Build-Depends.

The specificity of the resulting packages is that they are arch-all 
while containing arch-specific files. Their value comes from the fact 
that you can install netboot images for all Debian architectures 
(through arch:all packages) on any Debian architecture, without having 
to add add these archs through multiarch.

So the alternative would be to build these arch:all packages in the 
debian-installer build-arch target, but that wouldn't pass the incoming 
processing, as far as I know, as dak currently considers that there will 
be only one arch:all changes file per source.

Now talkin' crazy; we could also (ab)use byhand processing to produce 
these packages on the archive side; but using the archive to produce 
packages isn't really something we want to dive into.

So, the situation is known to not be Policy-compliant, but at least 
there's trust-path checking. In this specific case, I value the 
existance of these packages in their current form higher than Policy-
compliance, thereby tagging +wontfix. But I'm open to ideas!

What would you propose?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: win32-loader_0.7.11_source.changes ACCEPTED into unstable

[Didier 'OdyX' Raboud]

Hi Cyril,

Le mardi, 1 décembre 2015, 20.57:21 Cyril Brulebois a écrit :
> Debian FTP Masters  (2015-11-30):
> > Accepted:
> > (…)
> > Binary: win32-loader

> This change is:
> -Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/win32-loader.git
> +Vcs-Browser: https://anonscm.debian.org/git/d-i/win32-loader.git
> 
> I don't have anything against such changes in general, but I think it
> would make sense to have them done on all d-i packages at the same
> time (maybe after discussion/checks, see debhelper bump a while ago).
> But anyway, this particular change is not OK:

Good points, sorry. Reverted.

Btw, I've just filed https://bugs.debian.org/806853 for a problem on the 
FTP-Master side, I'll upload with that revert when it's fixed.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#806853: byhand-win32-loader script TARGET directory wrong for uploads to sid

[Didier 'OdyX' Raboud]

Package: ftp.debian.org
Severity: important

Dear FTP Masters,

I recently uploaded win32-loader 0.7.11 to unstable with a _source.changes,
resulting in an automated arch:all build.

For a reason not relevant to this bugreport, the final _all.changes as uploaded
by the buildd had 'sid' as suite, and the two "byhand" files
(win32-loader.{exe,txt}) landed in debian/tools/win32-loader/sid/ instead of
…/unstable/.

> # NOTE: it may be better to pass this to the script as a parameter!
> SUITE="$(grep "^Distribution:" "$CHANGES" | awk '{print $2}')"
> case $SUITE in
> "")
>   echo "Error: unable to determine suite from Changes file"
> exit 1
>   ;;
> unstable|sid)
>   : # nothing to do

A simple fix would be to `TARGET="unstable"` here.

>   ;;
> *)
>   SUITE="${SUITE}-proposed-updates"
>   ;;
> esac

I'm likely to upload 0.7.12 soon to fix a premature VCS-Browser change, I'll
therefore wait for this fix, as a test-case.

Cheers,

OdyX

Re: URGENT BUG !!!

[Didier 'OdyX' Raboud]

(Answering in french, although this is an english-speaking list)

Le dimanche, 6 septembre 2015, 12.06:06 cristian cristian a écrit :
> aujourd'hui j'ai voulu télécharger une image ISO pour installer Debian
> "stable" mais le lien que vous donnez sur votre site pointe vers un
> répertoire inexistant !!
> 
> http://cdimage.debian.org/debian-cd/8.2.0/
> 
> Le répertoire "8.2.0" n'existe pas.

Les CDs sont en train d'être construits, mais malheureusement le site a 
été mis à jour trop hâtivement.

Deux solutions: attendre quelques heures et ré-essayer; ou télécharger 
le CD 8.1.0 et mettre à jour à l'issue de l'installation, le résultat 
est strictement identique.

Salutations,
OdyX

Re: [RFC] Architecture detection patches in multiarch CDs

[Didier 'OdyX' Raboud]

OdyXLe samedi, 15 août 2015, 16.52:41 Didier '' Raboud a écrit :
 After three DebConfs discussing this (but only actually using DebConf
 space/time to actually work on it), and taking the opportunity of the
 immediate post stretch-alpha2 period, I'd like to discuss two
 architecture detection patches for a smarter boot of multiarch CDs.
 
 * 0001-Add-syslinux-machinery-to-use-ifcpu64.c32-on-multi-a.patch
 
 This is a patch against installer.git, (…)

After discussing this patch with KiBi, I've went ahead and fixed a 
series of small issues (catched thanks for the additional eyeballs!) and 
pushed to master.

 * 0001-Add-management-of-arch-detection-from-d-i-in-isolinu.patch
 
 This is a patch against debian-cd.git.

Now I need to find Sledge! :-)

Cheers,
OdyX

Re: gpgv udebs

[Didier 'OdyX' Raboud]

Le mercredi, 12 août 2015, 02.39:23 Cyril Brulebois a écrit :
 And thanks for getting in touch with us.

Indeed.

 Daniel Kahn Gillmor d...@fifthhorseman.net (2015-08-11):
  i believe the installer relies on gpgv for archive manifest
  signature verification.  we have gpgv-udeb for that purpose, i
  think.
 
 That's the idea, yeah. Grepping through all of our packages → see the
 results below my signature; that's basically base-installer and
 net-retriever which depend on gpgv-udeb.
 
 For the record, last time we've seen changes in gpgv, that was in:
   https://lists.debian.org/debian-boot/2014/01/msg00129.html
 
 which eventually led to: #753985. Skimming through it again, it seems
 win32-loader was somewhat affected as well. Adding Didier in the loop
 explicitly just to be on the safe side.

Exactly. win32-loader embeds gpgv.exe, shipped in gpgv-win32, under 
/usr/share/win32/gpgv.exe; this embedding happens at (arch:all) build-
time, and only concerns the win32-loader.exe that is shipped on the 
Debian mirrors: 
http://httpredir.debian.org/debian/tools/win32-loader/unstable/win32-loader.exe 
. We discussed in #778877 the addition 
of an autopkgtest be added in gpg so that we could make sure gpgv.exe is 
kept in a working state. This doesn't seem to have made its way to the 
archive though.

Anyway, I'm digressing.

From the win32-loader point of view, all it needs is a gpgv.exe that can 
check Release.gpg files, when run under Windows (wine being a good test 
though). If that gpgv.exe is GnuPG 1 or 2 doesn't matter. :)

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#793120: Multiarch menu: 32 bits speech options (gtk non-gtk) have the same text

[Didier 'OdyX' Raboud]

Package: debian-installer
Version: 20150718
Severity: normal

Hi,

in the 'Advanced options' of the multiarch CD, the speech synthesis
install options for 32 bits have the same text regardless if they are
for the GTK or non-GTK flavours.

Cheers, OdyX


-- 
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/20150721131959.9410.3279.reportbug@gyllingar

Bug#793118: Multiarch menu missing the 32-bits Rescue entries in 'Advanced options'

[Didier 'OdyX' Raboud]

Package: debian-installer
Version: 20150718
Severity: normal
Tags: pending

Hi,

the version as shortly releases lacks the 'Rescue' entries for the 32
bits flavours of the multiarch CD, in the 'Advanced options' sub-menu.

The fix for this has already been committed to git, hence the pending.

Cheers, OdyX


-- 
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/20150721131753.8939.91645.reportbug@gyllingar

Bug#784081: debian-installer-8-netboot-amd64: expert netboot install hangs at step install_packages (tasksel): uninitialized value in vec at /usr/bin/debconf-apt-progress

[Didier 'OdyX' Raboud]

Control: reassign -1 debconf 1.5.56
Control: tags -1 +moreinfo

Hi Hendrik,

 expert netboot install hangs at step install_packages (tasksel):
 uninitialized value in vec at /usr/bin/debconf-apt-progress

This is most certainly a bug either in debconf or in the package it was 
configuring, but not in debian-installer-8-netboot-*. 

You might want to add more information to your bug, it's really too 
terse to even start investigating.

Cheers,
OdyX


-- 
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/2431132.FygXILKaCl@gyllingar

Re: Bug#783358: installation-reports: Debian 8 CD - Graphical install is not the default (installation guide says it should be)

[Didier 'OdyX' Raboud]

Le dimanche, 3 mai 2015, 22.22:17 Cyril Brulebois a écrit :
 Hello,
 
 Holger Wansing li...@wansing-online.de (2015-05-03):
  So, shall I revert the manual back to text install is default?
 
 Yes please. I asked Didier to keep an eye on it but he pretended being
 busy with other topics. ;)

Ah sorry, I didn't understand your request that way. :)

The current status is that jessie has the text install by default, and 
we're most probably not going to toggle this now that jessie is out. 

I see you've changed the manual to reflect this, thanks.

As for stretch, I've pushed the change to the installer to make the 
graphical installer the default, so we'll need to update the manual in 
due time.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#783647: win32-loader: please make the build reproducible

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le mardi, 28 avril 2015, 19.59:55 Jérémy Bobbio a écrit :
 While working on the “reproducible builds” effort [1], we have noticed
 that win32-loader could not be built reproducibly.
 
 The attached patch—based on Git master—fixes timestamps related
 variations from the build system. Once applied, win32-loader can be
 built reproducibly in our current experimental framework.

Yay, wonderful, thanks!

I've applied your patch (split in different patches) to master and will 
upload 0.7.10 quickly!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#783206: unblock: debian-installer-netboot-images/20150422

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package debian-installer-netboot-images, as it mirrors the d-i
in the same version. It's probably best to have it available in Jessie before
it becomes stable :-)

unblock debian-installer-netboot-images/20150422

As it drops two binary packages, it also needs manual decruft from FTP
Masters, I'll let you contact them to make this happen.

Cheers, OdyX

Debdiff is as follows:

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+debian-installer-netboot-images (20150422) unstable; urgency=high
+
+  * Drop kfreebsd-{amd64,i386} from supported architectures
+
+ -- Didier Raboud o...@debian.org  Thu, 23 Apr 2015 14:51:10 +0200
+
+debian-installer-netboot-images (20150418) unstable; urgency=high
+
+  * Update to 20150418 images.
+  * Use httpredir.d.o as mirror
+
+ -- Didier Raboud o...@debian.org  Sun, 19 Apr 2015 11:17:56 +0200
+
 debian-installer-netboot-images (20150324) unstable; urgency=medium
 
   * Update to 20150324 images.
diff --git a/debian/control b/debian/control
index 84c53e8..7fdc266 100644
--- a/debian/control
+++ b/debian/control
@@ -67,26 +67,6 @@ Description: Debian-installer network boot images for i386
  This package contains images of the Debian Installer for the i386
  architecture.
 
-Package: debian-installer-8-netboot-kfreebsd-amd64
-Architecture: all
-Depends: ${misc:Depends}
-Provides: debian-installer-netboot-kfreebsd-amd64, debian-installer-netboot
-Suggests: tftpd-hpa
-Built-Using: ${d-i:built-using}
-Description: Debian-installer network boot images for kfreebsd-amd64
- This package contains images of the Debian Installer for the kfreebsd-amd64
- architecture.
-
-Package: debian-installer-8-netboot-kfreebsd-i386
-Architecture: all
-Depends: ${misc:Depends}
-Provides: debian-installer-netboot-kfreebsd-i386, debian-installer-netboot
-Suggests: tftpd-hpa
-Built-Using: ${d-i:built-using}
-Description: Debian-installer network boot images for kfreebsd-i386
- This package contains images of the Debian Installer for the kfreebsd-i386
- architecture.
-
 Package: debian-installer-8-netboot-mips
 Architecture: all
 Depends: ${misc:Depends}
diff --git a/debian/rules b/debian/rules
index b843454..1c3d1b7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,13 +2,13 @@
 
 export MAJOR_VERSION=8
 export DISTRIBUTION=jessie
-export MIRROR=http://ftp.debian.org/debian
+export MIRROR=http://httpredir.debian.org/debian
 export VERSION=$(shell dpkg-parsechangelog | sed -n 's/^Version: //p')
 export KFREEBSD_KERNEL_MAJOR=10
 
 # Don't forget to recreate debian/control after editing these lines: $
 # debian/rules debian/control
-SUPPORTED_ARCHITECTURES = amd64 arm64 armel armhf i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el
-UNSUPPORTED_ARCHITECTURES = hurd-i386 s390x sparc
+SUPPORTED_ARCHITECTURES = amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el
+UNSUPPORTED_ARCHITECTURES = hurd-i386 kfreebsd-amd64 kfreebsd-i386 s390x sparc
 
 %:
dh $@


-- 
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/20150423202954.13129.74581.reportbug@gyllingar

Bug#782845: debian-installer-netboot-images: FTBFS with a checksum mismatch

[Didier 'OdyX' Raboud]

Control: reopen -1
Control: retitle -1 debian-installer-netboot-images: Can FTBFS with a checksum 
mismatch when there should be a version mismatch FTBFS earlier on

Le samedi, 18 avril 2015, 20.02:15 Cyril Brulebois a écrit :
 Not sure what's happening but I can't seem able to build d-i-n-i,
 with either httpredir.debian.org, localhost (a local mirror which is
 uptodate), ftp.fr.debian.org (its upstream) or ftp.debian.org; I'm
 attaching a build log for reference.

So this happens when d-i has not migrated to testing: the get-images.sh
script will try to download debian-installer_*.deb from the mirror and
compare its sha256sum against the Packages.gz from its DISTRIBUTION.

Arguably, it should check the version first, and fail if theres' a mismatch.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#776928: unblock: debian-installer-netboot-images/20150107

[Didier 'OdyX' Raboud]

Hi all,

Le dimanche, 8 février 2015, 21.54:04 Cyril Brulebois a écrit :
 Niels Thykier ni...@thykier.net (2015-02-06):
  A debhelper compat is an explicit no-go per the freeze policy.
  
  Otherwise, looks good to me.
 
 It's a bit unfortunate that d-i-n-i is huge and not too useful to
 upload during the release cycle in that we get to only notice this
 kind of things (woops, we bumped the debhelper version compat in
 that package too but it never reached testing) during the freeze;
 sorry about that.
 
 Since d-i-n-i is basically about collecting files in packages (see
 get-images.sh), and about shipping them through various binaries, this
 kind of things is /possibly/ harmless, but I really didn't check
 anything. It would probably be helpful to double check that dh 7 and
 dh 9 lead to identical binaries, and maybe think about letting this
 change slide with the rest (but so far I really have no opinion on
 this).

So I've gone and done that (twice), the result of all debdiffs is exactl 
identical:

 File lists identical (after any substitutions)
 
 No differences were encountered between the control files

This show that the change (but also that the revert) is harmless. 
Frankly, I'd find the explicit no-go therefore imposing a revert quite 
silly in this specific case.

 In case the explicit no-go stays (which I'd consider fair, to be
 honest), I'd rather avoid doing nasty things with the release version
 numbering (see Holger's reply), and get the revert through an upload
 matching RC 2. Which means getting d-i-n-i even later in testing but
 that would probably be safer.

That's technically correct. I'd find it quite sad to postpone a 
migration to testing for d-i-n-i, especially as every d-i upload [or at 
the very least, the final d-i] will impose a d-i-n-i upload and 
migration, again.

 On a slightly different note: Why we're still using a non-debian.org
 mirror (MIRROR in debian/rules) is still beyond me.

Using http.debian.net accelerates my builds by a big margin. I don't 
care enough though, so feel free to commit a change.

Cheers,
OdyX


--
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/1526927.S1h565oRuT@gyllingar

Re: Please update debian-installer's copyright file

[Didier 'OdyX' Raboud]

Le mardi, 30 décembre 2014, 14.25:45 Cyril Brulebois a écrit :
 thanks for updating the artwork in debian-installer.git as well; could
 you please also update its copyright file with the relevant
 information?

Just pushed, sorry for the omission and my unresponsiveness.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: rootskel-gtk_1.31_source.changes ACCEPTED into unstable

[Didier 'OdyX' Raboud]

Le lundi, 29 décembre 2014, 17.08:42 Cyril Brulebois a écrit :
 Where do I learn more about this?
 
 kibi@arya:~/debian-installer/packages/rootskel-gtk$ git describe
 warning: tag 'debian/1.31' is really '1.31' here
 debian/1.31
 
 kibi@arya:~/debian-installer/packages/rootskel-gtk$ git show 1.31
 tag debian/1.31
 Tagger: Didier Raboud o...@debian.org
 Date:   Mon Dec 22 21:48:18 2014 +0100

Aww. My tagging script always tags as debian/$version, and I just ran 
`mv .git/refs/tags/…` to rename the tag; that doesn't work as I thought 
it would. :)

I've just re-tagged and re-pushed. Took the opportunity to re-tag 1.27 
too

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#772898: win32-loader testing and newer fails with TRANSLATE error

[Didier 'OdyX' Raboud]

Hi Bernhard,

Le dimanche, 14 décembre 2014, 15.47:47 Bernhard Übelacker a écrit :
 So probably the solution could be only these 2 steps?
 
 - to rebuild package nsis-common with the current g++-mingw-w64-i686
 package
 
 - rebuild win32-loader with the newly built nsis-common package
 installed

I could assess post-upload on a Windows 7 VM that this was the correct 
strategy; thank you very much for this thorough analysis!

Cheers,
OdyX


--
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/2483242.xzA1SJgkhr@gyllingar

Re: win32-loader icon update?

[Didier 'OdyX' Raboud]

Le mercredi, 10 décembre 2014, 05.56:22 jnqnfe a écrit :
 In relation to bug #772691 (autorun.inf not displaying a custom Debian
 icon from setup.exe aka win32-loader.exe when a Debian install
 disc/iso is loaded in a Windows environment, unlike Ubuntu) which I
 just reported, I created a small collection of possible replacement
 icons for win32-loader.exe (simple, clean, smart and in a range of
 colours!). I thought I would offer them up here in case you're
 interested.

Thanks for these, and the quite large choice palette. I'm not a great 
fan of the rounded alternatives though; icons are usually square and 
what we want to be seen is the Debian swirl, not a circle, IMHO.

Iff we change the win32-loader .ico icon (that might then also be 
displayed as a CD icon on Windows hosts), we should aim at using the 
picked Lines desktop theme:

https://wiki.debian.org/DebianArt/Themes/Lines

The current icon has 5 embedded icon sizes (16,24,32,48,256), but is not 
generated at build-time; ideally, we'd have a 512 pixels-sized svg, 
generate the correctly-sized png's using rsvg-convert and create the 
final swirl.ico (name can be changed of course) out of these.

Are you interested in creating a Lines-themed square svg ? I could 
manage the build-time creation.

Cheers,
OdyX


--
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/3682468.SPJ6suavI0@gyllingar

Re: Bug#772898: win32-loader testing and newer fails with TRANSLATE error

[Didier 'OdyX' Raboud]

Control: clone -1 -2
Control: retitle -2 nmu: nsis_2.46-9
Control: user -2 release.debian@packages.debian.org
Control: usertag -2 +binnmu

(Release Team, please see below :) )

Hi Bernhard  Cyril,

Many thanks for the detailed analysis!

Le dimanche, 14 décembre 2014, 15.47:47 Bernhard Übelacker a écrit :
 Looks similar to bug #654380. (There mingw defaulted to produce dlls
 depending also on some other mingw dlls)
 
 There the upstream bug report [2] mentions that plugins must not
 depend on a shared libgcc.
 
 So I assume that the plugins must not depend on a shared
 libwinpthread-1.dll either.
 
 The package build of win32-loader uses this file
 /usr/share/nsis/Plugins/NSISdl.dll which comes from packge
 nsis-common.
 
 If plugins must not depend on other dlls, then also other projects or
 users are affected, who want to build their installers with
 Jessie/testing.
 
 However, when I try to rebuild package nsis-common I get a nsisdl.dll
 which does not suffer from this dependency.
 
 Unfortunately I cannot find a build log for amd64, just for i386 [3].
 That one was build with g++-mingw-w64-i686 i386 4.9.0-2+13.
 My attempt uses g++-mingw-w64-i686 amd64 4.9.1-7+14.2.
 
 The changelog for g++-mingw-w64-i686 [4] shows this entry:
 
 gcc-mingw-w64 (14) unstable; urgency=medium
 
   * Provide compilers using Windows and POSIX threads. The default
 setup uses Windows threads, thus avoiding the dependency on the
 pthreads DLL (Closes: #748353, #750741).
 
 So probably the solution could be only these 2 steps?
 
 - to rebuild package nsis-common with the current g++-mingw-w64-i686
 package

This looks like it, indeed. I'm hereby cloning this bug into an NSIS
binNMU request:

@Release Team, could we please schedule binNMUs for nsis ?

nmu nsis_2.46-9 . ALL . -m Rebuild with gcc-mingw-w64 14 to ensure 
that NSISdl.dll doesn't depend on a shared libwinpthread-1

 - rebuild win32-loader with the newly built nsis-common package
 installed

I'll upload win32-loader when nsis is available from the mirrors.

Many thanks, cheers,
OdyX


--
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/78814985.3kYXE0y7E4@gyllingar

Bug#772898: win32-loader testing and newer fails with TRANSLATE error

[Didier 'OdyX' Raboud]

Le lundi, 15 décembre 2014, 19.20:07 Adam D. Barratt a écrit :
 On Mon, 2014-12-15 at 10:09 +0100, Didier 'OdyX' Raboud wrote:
  @Release Team, could we please schedule binNMUs for nsis ?
  
  nmu nsis_2.46-9 . ALL . -m Rebuild with gcc-mingw-w64 14 to ensure
  that NSISdl.dll doesn't depend on a shared libwinpthread-1
 Done.

Sorry for the unnecessary binNMU; NSISdl comes from nsis-common/all, and 
is not rebuilt in binary-arch builds. /o\

I will upload a new nsis version, adding the test proposed by Bernhard 
to trigger a build failure if that ever appears again.

Cheers,
OdyX


--
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/1592624.gkHtJ7EzoG@gyllingar

Bug#772898: win32-loader testing and newer fails with TRANSLATE error

[Didier 'OdyX' Raboud]

Hi all,

Le vendredi, 12 décembre 2014 10.03:10, vous avez écrit :
 Le jeudi, 11 décembre 2014, 17.15:49 Jimmy Kaplowitz a écrit :
  I got this error:
  
  Error:
  http://d-i.debian.org/daily-images/amd64/daily//MD5SUMS/TRANSLATE;
 
 This error is an artifact of the failure of the win32-loader
 executable to load the Nsisdl dll.
 
 I was testing win32-loader on a Windows 7 VM yesterday and was exactly
 debugging this. How lucky ! :) I _think_ the problem is with nsis
 having statically linked libgcc and win32-loader being built with a
 later gcc (mingw-*) version.
 (…)
 Can you try the two executables zipped in attachement? I hope the
 results will be as follows:

So as these were both compiled in my unclean environment, they 
apparently both work. I could also test with binaries built in clean 
environments (pbuilder or schroot on barriere.debian.org) and none of 
these works. I'm at loss of ideas for now. /o\

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: win32-loader_0.7.7

[Didier 'OdyX' Raboud]

Le mardi, 18 novembre 2014 07.33:45, vous avez écrit :
  win32-loader (0.7.7) unstable; urgency=medium
  .
The « Lineus longissimus » release

Apparently this build has a problem; I just re-tested from the mirrors 
and it doesn't download correctly. I suspect a too-clean chroot. I'll 
re-upload when I can.

Sorry for the mess, cheers,
OdyX


--
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/1687988.qk28hQbZON@gyllingar

Re: debian-installer-netboot-images_20141002_amd64.changes is NEW

[Didier 'OdyX' Raboud]

Dear FTP Masters,

Le mardi, 28 octobre 2014 12.35:23, vous avez écrit :
 Your package has been put into the NEW queue, which requires manual
 action from the ftpteam to process. The upload was otherwise valid
 (it had a good OpenPGP signature and file hashes are valid), so
 please be patient.

Please REJECT debian-installer-netboot-images_20141002_amd64 as we want 
to re-upload with the same version, but different binary packages names 
(see #766960 for the discussion), namely moving from -8.0- to -8- .

TIA, and sorry for my unneeded hurry,

OdyX


--
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/2584737.1FQKy1oDNU@gyllingar

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Didier 'OdyX' Raboud]

Hi all,

Le lundi, 27 octobre 2014, 11.57:33 Cyril Brulebois a écrit :
 Didier 'OdyX' Raboud o...@debian.org (2014-10-27):
  Le lundi, 27 octobre 2014, 11.23:23 Cyril Brulebois a écrit :
* kfreebsd-amd64's images fetching logic fails because there is
  no un-numbered /netboot/ directory under which we could
  automagically
  take netboot.tar.gz as for other architectures. I think this
  should be fixed in the installer through providing a symlink
  towards the default version but can't really find where this
  should go.
   
   There's only a single version now. Not sure having to care about a
   symlink in debian-installer is worth it. Won't stop you from
   looking
   into it though.
  
  The current logic in d-i-n-i is to fetch …/netboot/netboot.tar.gz
  and  …/netboot/gtk/netboot.tar.gz for all architectures. On those
  where it fails, it will download …/MANIFEST and try downloading
  everything which is under …/netboot/ and use that in the package.
  
  The problem with kfreebsd's numbered directories is that it forces
  d-i- n-i to add this kernel version number in its logic, for no
  good reason. That's why I'd prefer to have kfreebsd's either have a
  /netboot/ symlink pointing to the preferred numbered /netboot-$n/
  directory or (given it currently only has one version, which is
  likely to be jessie's state), rename that directory to be
  un-numbered. As far as I understood, the latter is a matter of
  renaming some files in build/config/kfreebsd-*/ .
 
 I understand the reasoning but I am not keen on moving files around at
 this very late stage; if adding a symlink works, this would probably
 be better.

I've given more thought to this, and I think we should get d-i-n-i 
through NEW rather sooner than later (all binary package names get 
changed). Also, this change is jessie-specific (as d-i-n-i downloads the 
netboot images from testing), so I've gone ahead and implemented a 
workaround in d-i-n-i directly.

Unless there are objections, I will upload this later today towards NEW.

 Otherwise, maybe move back files under an unversioned directory and
 keep a symlink from the versioned directory. Not sure how
 {well,badly} tftp servers deal with symlinks anyway…

Afaik, the tftp servers are not involved here, we're talking about the 
layout on mirrors.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Didier 'OdyX' Raboud]

Le mardi, 28 octobre 2014, 13.56:33 Cyril Brulebois a écrit :
 Since there were no 8.x uploads at all during the release cycle, it
 might have been an opportunity to move away from X.0 versioning…

As long as it's not out of NEW, we can still change our minds.

The main argument in favour of x.0 versioning was the possibility (see 
#682656) to co-install versions across multiple releases. Dropping the 
major version number from the package name would defeat this; were you 
arguing to move from x.0 to x or dropping the versioning altogether?

I'm in favour of the status-quo as oldstable and stable have x.0 
already and moving to x would be confusing, IMHO.

Cheers,
OdyX


--
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/3798752.4FrXC9DpgG@gyllingar

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Didier 'OdyX' Raboud]

Le mardi, 28 octobre 2014, 14.43:50 Cyril Brulebois a écrit :
 Didier 'OdyX' Raboud o...@debian.org (2014-10-28):
  The main argument in favour of x.0 versioning was the possibility
  (see #682656) to co-install versions across multiple releases.
  Dropping the major version number from the package name would
  defeat this; were you arguing to move from x.0 to x or dropping
  the versioning altogether?
 The former (of course).
 
  I'm in favour of the status-quo as oldstable and stable have x.0
  already and moving to x would be confusing, IMHO.
 
 Because having jessie versioned 8, netboot images versioned 8.0, and
 installation images versioned 8.0.0 is not confusing?

It is; let's settle on 8 for the netboot images then; I'll re-upload 
later today.

Cheers,
OdyX


--
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/2746950.jCcZYdBsvY@gyllingar

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Didier 'OdyX' Raboud]

Le lundi, 27 octobre 2014, 09.56:38 Petter Reinholdtsen a écrit :
 Source: debian-installer-netboot-images
 Version: 20130613+deb7u2.b3
 Severity: important
 User: debian-...@lists.debian.org
 Usertags: debian-edu
 
 Hi.  Will there be netboot images for Debian Jessie (version 8)
 available?

We should be doing this soon, indeed.

The following diff would be mostly what's needed:

--- a/debian/rules
+++ b/debian/rules
@@ -1,12 +1,12 @@
 #!/usr/bin/make -f
 
-export MAJOR_VERSION=7.0
-export DISTRIBUTION=wheezy
+export MAJOR_VERSION=8.0
+export DISTRIBUTION=jessie
 export MIRROR=http://http.debian.net/debian
 export VERSION=$(shell dpkg-parsechangelog | sed -n 's/^Version: //p')
 
 # Don't forget to recreate debian/control after editing these lines: $ 
debian/rules debian/control
-SUPPORTED_ARCHITECTURES = amd64 armel armhf i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc sparc
+SUPPORTED_ARCHITECTURES = amd64 arm64 armel armhf i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el sparc
 UNSUPPORTED_ARCHITECTURES = hurd-i386 s390 s390x
 
 %:

I'm having currently two problems with this:

* http.debian.net redirection for installer-arm64; aka  accessing
  debian/dists/jessie/main/installer-arm64/20141002/images/SHA256SUMS
  through http.debian.net sometimes fails, bug is there :
  https://github.com/rgeissert/http-redirector/issues/54
  This is easily circumvented by using a fixed mirror.
* kfreebsd-amd64's images fetching logic fails because there is no un-
  numbered /netboot/ directory under which we could automagically take
  netboot.tar.gz as for other architectures. I think this should be
  fixed in the installer through providing a symlink towards the default
  version but can't really find where this should go.

Cheers,
OdyX


--
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/1548959.0eHgEb5EvC@gyllingar

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Didier 'OdyX' Raboud]

Le lundi, 27 octobre 2014, 11.23:23 Cyril Brulebois a écrit :
  * kfreebsd-amd64's images fetching logic fails because there is no
un-numbered /netboot/ directory under which we could automagically
take netboot.tar.gz as for other architectures. I think this
should be fixed in the installer through providing a symlink
towards the default version but can't really find where this
should go.
 
 There's only a single version now. Not sure having to care about a
 symlink in debian-installer is worth it. Won't stop you from looking
 into it though.

The current logic in d-i-n-i is to fetch …/netboot/netboot.tar.gz and 
…/netboot/gtk/netboot.tar.gz for all architectures. On those where it 
fails, it will download …/MANIFEST and try downloading everything which 
is under …/netboot/ and use that in the package.

The problem with kfreebsd's numbered directories is that it forces d-i-
n-i to add this kernel version number in its logic, for no good reason. 
That's why I'd prefer to have kfreebsd's either have a /netboot/ symlink 
pointing to the preferred numbered /netboot-$n/ directory or (given it 
currently only has one version, which is likely to be jessie's state), 
rename that directory to be un-numbered. As far as I understood, the 
latter is a matter of renaming some files in build/config/kfreebsd-*/ .

Opinions?

Cheers,
OdyX


--
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/1470388.VZvvNOiPn6@gyllingar

Re: Time for Jessie Beta 2?

[Didier 'OdyX' Raboud]

Le vendredi, 26 septembre 2014, 21.05:07 Cyril Brulebois a écrit :
 I'll probably skip syslinux vs. multi-arch this time, mostly due to
 lack of time and other large ongoing changes: let's see if we can get
 debian-cd to cope with latest tasksel changes soon.

I have a patch suite almost there, but it makes no sense to try squeeze 
it in Beta2 now. Let's push it early for Beta3

 
  → I'd like to know whether some bugs need special attention/fixes
  
(besides what's in unstable already).
  
  I haven't looked at recent bugs lately but I think we might be
  missing at least a ttf-cjk-compact-udeb upload (which might explain
  some issues reported against debian-edu IIRC), and I failed to
  upload choose-mirror for the past release (Aurelien uploaded it 10
  days ago though, to get updated arch lists).
 
 Since the kernel is now a candidate for migration, I'll probably start
 urgenting more packages into testing during the weekend (all
 l10n-only updates, for a start), try to figure out which packages to
 additionally migrate, and freeze udeb-producing packages.

Thanks for your work.

Cheers, OdyX
-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#762478: redundant desktop selection

[Didier 'OdyX' Raboud]

Le mercredi, 24 septembre 2014, 11.00:50 Joey Hess a écrit :
 Then next release of tasksel will know about defaulting to xfce on
 hurd and freebsd, so it will be unncessary for win32-loader to do so
 at that point.

Okay, I'll just drop the desktop-related logic completely then, thanks 
for tasksel!

Cheers,
OdyX


--
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/2599182.piPIr4scNP@gyllingar

Bug#762478: redundant desktop selection

[Didier 'OdyX' Raboud]

Le lundi, 22 septembre 2014 14.31:19, vous avez écrit :
 tasksel allows selecting the desktop now, so the selection in
 win32-loader is unncessary (the list there is also incomplete).

Thanks for the heads'up, patch in the pipes.

 I think that default_desktop=xfce might still be passed for kfreebsd
 installs, to override the current default of gnome. That can still be
 passed through. Although it might make more sense to move that logic
 to tasksel eventually.

For now I've patched win32-loader to keep enforcing this; the resulting 
preseed configuration file is the following:

tasksel tasksel/desktop multiselect gnome-desktop
tasksel tasksel/desktop seen false
d-i debian-installer/locale string $WindowsLocale
d-i netcfg/get_domain string $WindowsDomain
d-i netcfg/get_domain seen false
d-i console-keymaps-at/keymap select $WindowsKeymap
d-i console-keymaps-at/keymap seen true
d-i netcfg/get_hostname string $WindowsHostname
d-i netcfg/get_hostname seen false
d-i passwd/user-fullname string $WindowsLogin
d-i passwd/user-fullname seen false
d-i mirror/http/proxy seen true

Does that still look valid?

Cheers,
OdyX


--
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/1466782.BQ14DESLPm@gyllingar

Re: (Almost) Time for Jessie Beta 2?

[Didier 'OdyX' Raboud]

Hi,

Le mercredi, 10 septembre 2014, 00.18:14 Cyril Brulebois a écrit :
 Some things got set into motion, like syslinux menu overhaul (mainly
 discussion around the switch to graphical by default, didn't see any
 patch yet) …

My current work is attached, I wanted to cleanup the things (swap amd64 
and i386, mention 32 bits for i386, let amd64 be default) before 
attacking the enhanced multiarch question, for which I have successfully 
tested ifcpu64.c32 . I've been VAC two weeks but will be returning to 
Debian matters in the next days. If someone could comment on these 
patches (and/or their primary intent), that'd be a useful base for the 
further overhaul.

Thanks for your push towards more releases though!

Cheers,
OdyXFrom 1fdd8e3d19f3de3fb220ca1e4ddd2d007f046344 Mon Sep 17 00:00:00 2001
From: Didier Raboud o...@debian.org
Date: Fri, 29 Aug 2014 21:16:01 -0400
Subject: [PATCH 1/2] Swap amd64 and i386 to let the first be the norm and the
 latter be the special case

---
 build/boot/x86/386adgtk.cfg | 12 
 build/boot/x86/386adtxt.cfg |  9 +
 build/boot/x86/386gtk.cfg   |  4 
 build/boot/x86/386rqgtk.cfg |  4 
 build/boot/x86/386rqtxt.cfg |  4 
 build/boot/x86/386spgtk.cfg |  4 
 build/boot/x86/386spk.cfg   |  4 
 build/boot/x86/386txt.cfg   |  6 ++
 build/boot/x86/adgtk.cfg| 15 ++-
 build/boot/x86/adtxt.cfg| 15 +--
 build/boot/x86/amdadgtk.cfg |  9 -
 build/boot/x86/amdadtxt.cfg | 12 
 build/boot/x86/amdgtk.cfg   |  4 
 build/boot/x86/amdrqgtk.cfg |  4 
 build/boot/x86/amdrqtxt.cfg |  4 
 build/boot/x86/amdspgtk.cfg |  4 
 build/boot/x86/amdspk.cfg   |  4 
 build/boot/x86/amdtxt.cfg   |  6 --
 build/boot/x86/desktop/386agdt.cfg  | 11 +++
 build/boot/x86/desktop/386atdt.cfg  |  8 
 build/boot/x86/desktop/386gtkdt.cfg |  4 
 build/boot/x86/desktop/adgtkdt.cfg  | 11 ---
 build/boot/x86/desktop/adtxtdt.cfg  | 11 +++
 build/boot/x86/desktop/amdagdt.cfg  |  8 
 build/boot/x86/desktop/amdatdt.cfg  | 11 ---
 build/boot/x86/desktop/amdgtkdt.cfg |  4 
 build/boot/x86/desktop/amdspkdt.cfg |  4 ++--
 build/boot/x86/desktop/amdtxtdt.cfg |  4 ++--
 build/boot/x86/desktop/amspgtdt.cfg |  4 ++--
 build/boot/x86/desktop/gtkdt.cfg|  4 ++--
 build/boot/x86/desktop/spkdt.cfg|  4 ++--
 build/boot/x86/desktop/spkgtkdt.cfg |  4 ++--
 build/boot/x86/desktop/txtdt.cfg|  4 ++--
 build/boot/x86/gtk.cfg  |  6 +++---
 build/boot/x86/menu.cfg | 12 ++--
 build/boot/x86/rqgtk.cfg|  6 +++---
 build/boot/x86/rqtxt.cfg|  6 +++---
 build/boot/x86/spk.cfg  |  6 +++---
 build/boot/x86/spkgtk.cfg   |  6 +++---
 build/boot/x86/txt.cfg  | 10 +-
 build/config/x86.cfg|  6 +++---
 41 files changed, 139 insertions(+), 139 deletions(-)
 create mode 100644 build/boot/x86/386adgtk.cfg
 create mode 100644 build/boot/x86/386adtxt.cfg
 create mode 100644 build/boot/x86/386gtk.cfg
 create mode 100644 build/boot/x86/386rqgtk.cfg
 create mode 100644 build/boot/x86/386rqtxt.cfg
 create mode 100644 build/boot/x86/386spgtk.cfg
 create mode 100644 build/boot/x86/386spk.cfg
 create mode 100644 build/boot/x86/386txt.cfg
 delete mode 100644 build/boot/x86/amdadgtk.cfg
 delete mode 100644 build/boot/x86/amdadtxt.cfg
 delete mode 100644 build/boot/x86/amdgtk.cfg
 delete mode 100644 build/boot/x86/amdrqgtk.cfg
 delete mode 100644 build/boot/x86/amdrqtxt.cfg
 delete mode 100644 build/boot/x86/amdspgtk.cfg
 delete mode 100644 build/boot/x86/amdspk.cfg
 delete mode 100644 build/boot/x86/amdtxt.cfg
 create mode 100644 build/boot/x86/desktop/386agdt.cfg
 create mode 100644 build/boot/x86/desktop/386atdt.cfg
 create mode 100644 build/boot/x86/desktop/386gtkdt.cfg
 delete mode 100644 build/boot/x86/desktop/amdagdt.cfg
 delete mode 100644 build/boot/x86/desktop/amdatdt.cfg
 delete mode 100644 build/boot/x86/desktop/amdgtkdt.cfg

diff --git a/build/boot/x86/386adgtk.cfg b/build/boot/x86/386adgtk.cfg
new file mode 100644
index 000..a81dd3d
--- /dev/null
+++ b/build/boot/x86/386adgtk.cfg
@@ -0,0 +1,12 @@
+menu hshift 9
+menu width 58
+
+label expertgui
+	menu label Graphical expert install
+	kernel ${386_KERNEL}
+	append desktop=%desktop% priority=low ${VIDEO_MODE_GTK} initrd=${386_INITRD_GTK} -- ${CONSOLE}
+include ${SYSDIR}386rqgtk.cfg
+label autogui
+	menu label Graphical automated install
+	kernel ${386_KERNEL}
+	append desktop=%desktop% auto=true priority=critical ${VIDEO_MODE_GTK} initrd=${386_INITRD_GTK} -- quiet ${CONSOLE}
diff --git a/build/boot/x86/386adtxt.cfg b/build/boot/x86/386adtxt.cfg
new file mode 100644
index 000..388e17b
--- /dev/null
+++ b/build/boot/x86/386adtxt.cfg
@@ -0,0 +1,9 @@
+label expert
+	menu label 

Re: debian installer -win32 loader ????

[Didier 'OdyX' Raboud]

Hi b.

Le lundi, 25 août 2014, 12.14:33 b.betz a écrit :
 Norton gives a trojan warning when I download the installer from
 goodbye-microsoft.com or wiki with your mirror
 
 my question is :
 
 is this a false negative??

win32-loader is built entirely from sources available in Debian and 
doesn't embed any foreign binary.

On the other hand, win32-loader _is_ executing Windows system tools and 
_will_ modify the Windows bootloader, so it's far from surprising that 
it triggers anti-virus warnings.

So, my answer is yes, it is a false negative.

Cheers, 

OdyX


--
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/2273914.VjAMjWR1kC@gyllingar

Re: Bug#485586: debian-installer: Default to graphical install

[Didier 'OdyX' Raboud]

Hoy,

Le mardi, 19 août 2014, 01.17:02 Cyril Brulebois a écrit :
 The default is Install right now, which installs i386. The topic of
 this bug report is switching to Graphical install by default, but
 shouldn't we also promote amd64 by default while we're at it? This
 would mean having 64 bit graphical install as the default.
 
 = debian-boot/cd@: do we want amd64 by default?

While I don't have a definitive opinion on the ordering of the menu 
choices, I definitively think amd64 should be picked by default on amd64 
architectures. Especially since multiarch, there's no good reason left 
for installing i386 on amd64-capable machines AFAIK.

Now, the ideal would be to use syslinux' ifcpu/ifcpu64 c32 modules to 
determine the menu order depending on the machine (see [0]): no 64 bit 
option on 32 bit machines, hidden or down the menu 32 bit option on 
64 bit-capable machines.

I'd be happy to iron out some proposals during DebConf, if that idea 
seems interesting.

OdyX

[0] https://bugs.debian.org/707844#45

signature.asc
Description: This is a digitally signed message part.

Re: Final steps for Jessie Beta 1

[Didier 'OdyX' Raboud]

Hi Cyril,

Le mardi, 12 août 2014, 01.33:37 Cyril Brulebois a écrit :
 two parts in this mail: information for everyone, and action for
 debian-cd@ at the end.

I wonder (but it's certainly too late now) whether it would make sense 
to unblock (+byhand FTP-Master's dance) win32-loader for the next Beta 
release: 0.7.4.10 only contains translation updates and dh+Vcs updates.

 As you can see a few lines above, we can wait for netcfg but that's a
 bug we already had in wheezy, so we can add an errata entry for it; so
 if you can start a build in the morning I don't see a reason for an
 extra 12-hour delay. If you're only available in the afternoon or in
 the evening, we might get netcfg fixed for free, which I'm also OK
 with. :)

Can we add win32-loader to the load?

Cheers,
OdyX


--
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/18793619.yLpRgy0Hy8@gyllingar

Bug#473144: provide {loadlin,gzip,cpio}.exe for dynamic use

[Didier 'OdyX' Raboud]

Hi Cyril,

Le lundi, 17 mars 2014, 02.33:03 Cyril Brulebois a écrit :
 any opinion on the following (rather old) bug report?

Yes; thanks for pinging.

 Robert Millan r...@aybabtu.com (2008-03-28):
  Currently, win32-loader is linking in loadlin.exe, gzip.exe and
  cpio.exe statically into the executable, which is less than ideal
  for the propagation of upgraded versions.
  
  This patch adds them in their own win32-loader/ directory, so that
  newer versions can get these files from there instead.

While this would be certainly possible and possibly interesting in the 
context of the installer, win32-loader.exe now also ships to 
/debian/tools/win32-loader on the mirrors where it now additionally 
bundles debian-archive-keyring and gpgv.exe to actually verify that the 
things it downloads can be trusted.

So, while working on this could _reduce_ the bundling of win32-loader 
with {loadlin, gzip, cpio}.exe, it still needs to be bundled with 
gpgv.exe and debian-archive-keyring for another variant. All-in-all, 
given that a arch:all upload isn't that hard afterall, I'd rather be in 
favour of uploading these more frequently (to bundle the changes in 
these other sources) and tag this bug +wontfix.

Cheers,
OdyX


--
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/1568956.VVRQXeU1fk@gyllingar

Re: Damage to Windows C: drive from boot CD

[Didier 'OdyX' Raboud]

Le dimanche, 23 février 2014, 22.06:30 Bill Corwin a écrit :
 Then it automatically did a bunch of things ending with
   Debian-Installer loader: Completed
 and then I discovered that it disturbed my C: crive!

Apparently you used clicked through the Windows executable that puts the 
debian-installer at the root of your C:\ partition. It did its best to 
minimize its impact, as you can see: all files are in C:\win32-loader.

 Created uninstaller: C:\win32-loader\Uninstall.exe
 Copy to C:\win32-loader\linux
 Copy to C:\win32-loader\initrd.gz
 Generating C:\win32-loader\grub.cfg
 Extract: C:\win32-loader\cpio.exe
 Extract: C:\win32-loader\gzip.exe
 Appending preseeding information to C:\win32-loader\initrd.gz
 Copy to C:\g2\dr
 Copy to C:\g2ldr.mbr

The only system-related change was this line:

 Registering in NTLDR

Which says that the debian-installer image was registered to the Windows 
bootloader.

 How do I resore my C: drive to Windows only?  Other people reboot
 this machine when they need it and I do not want them to choose
 the 'finish installing Debian Linux'!  I have hidden what I thought
 was a boot CD for Linux; is this enough to prevent further damage?

Just run the win32-loader uninstaller; you should be able to find it in 
Windows' programs list or launch it directly from where it was 
mentionned to be installed:

 Created uninstaller: C:\win32-loader\Uninstall.exe

Running this uninstaller will restore your C:\ partition to its pristine 
state.

Cheers,

OdyX


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5109736.Z4OXAOMEZt@gyllingar

Re: Building d-i using wheezy-backports bits

[Didier 'OdyX' Raboud]

Hi Cyril,

Le jeudi, 30 janvier 2014, 02.51:48 Cyril Brulebois a écrit :
 as mentioned earlier this month, I had a little proof of concept for
 Paris Mini-DebConf 2014[1]. I've polished a few things, so here we go.
 
  1. https://lists.debian.org/debian-boot/2014/01/msg00239.html

Thanks for the report; your progress on that front is really awesome!

 I. How to build and run images
 ==
 
 At least 2 source packages need updating:
 
  1. debian-installer, so that one can upload to wheezy-backports, and
 get extra bits set up, in order to pull the kernel and some kernel
 modules from wheezy-backports. You can find a few patches for this in
 my wheezy-backports-v3 branch:
 (…
 QUESTION: How to specify which extra bits to pull from
   wheezy-backports?

The most logical place to store this information would be in build/pkg-
lists/, with either version specifiers ( lowmemcheck=1.40~bpo70+1 ) or 
target release specifiers ( lowmemcheck/wheezy-backports ). That's for 
storing the information; but that involves patching various tools. The 
first I've encountered was get-packages (patch attached).

As far as I could test, the attached patch is sufficient to allow either 
of the syntaxes in build/pkg-lists/ to build netboot-gtk on amd64.

(Now that's probably unrelated, but mini.iso fails on me with Kernel 
panic - not syncing: No init found.)

  2. net-retriever, which needs to pull regular bits from wheezy, and
 kernel module udebs from wheezy-backports. Unfortunately, contrary
 to the above, anna is used here, instead of apt. That means using an
 overlay (not self-contained) suite like wheezy-backports isn't
 possible by default.
 (…)
 I'm not yet convinced about “resolve conflicts with backports”
 vs. “resolve conflicts with stable”. 
 (…)
 QUESTION: Should we pick a different policy? If we were to pick a
   handful of packages from backports, how to do that?
   [Also, see above question.]

(Easier said than done, but) I would tend to think that making anna 
understand both of the above syntaxes would empower it most. Now, that's 
certainly quite a bunch of work and I think your approach of merging the 
Packages* files is good for now. As for conflicts resolution, I agree 
with your current resolve conflicts with backports, given that most 
udebs are uploaded by -boot (meaning that udebs in backports are there 
for a reason).

The next step (as you wrote) would be to allow suite or version 
specifications to be consumed by the Packages* files merger, which is 
still quite easier than patching anna's resolver I guess.

 II. How to install a backported kernel
 ==
 (…)
  Now here's another way which doesn't look so scary:
 
  1) Make sure the kernel installation step still installs stable's
 kernel (which might not be functional, but having it shouldn't
 hurt; and not changing such critical code doesn't look too
 bad…), and make sure it stores the package name somewhere for
 later use.

Sure. Having the stable kernel installed in all cases is definitely 
good.

 2) Patch apt-setup so that wheezy-backports gets automatically
 enabled when such an installation medium is detected
(e.g. /etc/udeb-backports-source exists).

That would be patching /usr/lib/apt-setup/generators/93backports to 
ignore apt-setup/services if the flagfile exists; patch attached.

 QUESTION: Is there any saner/more straightforward/better option here?
 
 QUESTION: How do we make sure we pull the relevant patched packages at
 this point? (apt-setup comes to mind, ditto for the package possibly
 containing the finish-install script.)

Hrm. base-installer/library.sh 's pick_kernel makes sure that one gets 
the currently running kernel image installed. It might be easier to 
let that happen and _then_ make sure stable's kernel is installed… Note 
that it uses `apt-cache search ^linux-image` in the target to find the 
needed packages…

I'm not navigating very easily through these installation steps, so I'll 
let someone else chime with better ideas here…

 IV. How to maintain wheezy-backports compared to master
 ===
 
 Since master both gets kernel config updates (which we want for
 backports) and many other irrelevant stuff, I'm a bit undecided on how
 to keep track of wheezy-backports: either cherry-pick relevant stuff
 from master; or merge regularly, reverting unnecessary bits. I would
 tend to go with the former.

It looks like a matter of intent: either we want stable d-i + kernel 
from backports + glue or testing d-i built against stable + kernel 
from backports. The first is less risky for what d-i is concerned, 
while the latter allows a wider testing of the jessie d-i… The latter is 
what you have in your branch currently, no?

As for maintaining the branches, I'd rather go for cherry-picking what's 
relevant on a branch based on the latest 

Re: Bug#697331: Please add the first created user to lpadmin

[Didier 'OdyX' Raboud]

Control: reopen -1
Control: reassign -1 user-setup-udeb 1.38
Control: tags -1 +patch

Hi all,

apparently this bug slipped through and got closed as installation-
report although the request hasn't been fulfilled as far as I could see.

To tell a long story short; the first created user should be made member 
of the lpadmin group to make sure printers can easily be created through 
the CUPS webinterface http://localhost:631/.

I've installed several Wheezy laptops for friends and everytime I was 
testing printing through the webinterface, it took me some time to 
realize that the user first had to be added to lpadmin. I think it's 
unnecessarily complicated and should be done straight away for the first 
user.

(straightforward) Patch attached.

Le mardi, 8 janvier 2013, 13.02:49 Brian Potkin a écrit :
 On Tue 08 Jan 2013 at 07:14:26 +0100, Christian PERRIER wrote:
  Quoting jswmb01x (jswmb...@mobistarmail.be):
   Clarification :
   Adding user1 to the lpadmin group was required to add the
   printer in CUPS (otherwise after entering the user name and
   password the operation is forbidden), not for printing. 
  Hmmm, well, then I would say this is cups that changed its behaviour
  and made it a requirement to have privleges in order to add a
  printer, even plug n' play toys. Which makes sense to me. Indeed,
  even on Windows, unprivileged users cannot add local printers to
  the system (but most Windows users don't notice as they always
  virtually work as root on their machines).
 
 The requirement has been present for the past 10+ years when using the
 web interface of CUPS to add a printer.
 
  That makes it less of a requirement to have the first created user
  in
  lpadmin, after more thinking.
  
  This bug could then even be wontfix.
 
 Given the existing status of using group membership in d-i to grant
 the first created user limited privileges, I think the issue revolves
 round whether there is something special about the lpadmin group
 which would militate against adding it to the first user account.
 
 A Cc: has been sent to debian-printing to allow them to comment on the
 usefulness and wisdom of putting lpadmin in user-setup-udeb.

Answering to that quite late, but I do agree it should be done.

Cheers,

OdyXFrom eb0d1f0dcab3b875efa95d3c094eca21d4abac55 Mon Sep 17 00:00:00 2001
From: Didier Raboud o...@debian.org
Date: Sat, 4 Jan 2014 14:17:33 +0100
Subject: [PATCH] Add first user to lpadmin group to allow her to add printers
 through the CUPS webinterface (Closes: #697331)

---
 debian/changelog | 7 +++
 debian/user-setup-udeb.templates | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index f8a1f32..31d3fe3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+user-setup (1.55) UNRELEASED; urgency=medium
+
+  * Add first user to lpadmin group to allow her to add printers through
+the CUPS webinterface (Closes: #697331)
+
+ -- Didier Raboud o...@debian.org  Sat, 04 Jan 2014 14:17:09 +0100
+
 user-setup (1.54) unstable; urgency=low
 
   [ Updated translations ]
diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates
index 822e8a6..603325f 100644
--- a/debian/user-setup-udeb.templates
+++ b/debian/user-setup-udeb.templates
@@ -19,7 +19,7 @@ Description: for internal use only
 # Allow preseeding the groups to which the first created user is added
 Template: passwd/user-default-groups
 Type: string
-Default: audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth debian-tor
+Default: audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth debian-tor lpadmin
 Description: for internal use only
 
 Template: passwd/root-login
-- 
1.8.5.2



signature.asc
Description: This is a digitally signed message part.

Bug#695500: d-i-n-i: #695500 is apparently a grub-mkimage (or debian-installer) bug

[Didier 'OdyX' Raboud]

Control: reassign -1 src:debian-installer 20120828 , grub-common 1.99-27
Control: tags -1 -moreinfo
Control: affects -1 +debian-installer-7.0-netboot-kfreebsd-i386
Control: affects -1 +debian-installer-7.0-netboot-kfreebsd-amd64

Hi all,

I spent some more time debugging this RC bug by setting up my server and 
testing the PXE boot of kfreebsd-i386 on two different laptops; the 
results are:

* the error: prefix is not set error always appears when using the 
wheezy grub2pxe; it also happens with the current sid grub2pxe [0];
* the resistance to this error apparently depends on the PXE 
implementation:
  - my acer Aspire One displays the error and then proceeds to
displaying grub, then allowing the boot of the kfreebsd-i386
installer;
  - my ThinkPad X220 displays the error and stops;
  - kvm launched locally with [1] proceeds to grub;

[0] 
http://http.debian.net/debian/dists/sid/main/installer-kfreebsd-i386/20130430/images/netboot/grub2pxe
[1] kvm -m 256 -net nic -net -
user,bootfile=/grub2pxe,tftp=/usr/lib/debian-installer/images/7.0/kfreebsd-amd64/gtk/

As debian-installer-netboot-images is only copying these files from the 
mirrors, I don't think it is the correct source package to track this 
bug. The above tests now make me think that this is either a problem of 
debian-installer calling grub-mkimage wrongly in 
build/config/kfreebsd.cfg or a bug in grub-mkimage not incorporating the 
prefix correctly when creating a PXE image. I'm therefore hereby 
reassigning this bug to both these packages (in their wheezy versions) 
and marking it as affecting the correct d-i-n-i binary packages.

Cheers,
OdyX


signature.asc
Description: This is a digitally signed message part.

Re: Feel free to let win32-loader/0.7.4.9 into testing

[Didier 'OdyX' Raboud]

Hi Cyril,
(adding ftpmaster in CC).

Le lundi, 7 octobre 2013 01.57:42 Cyril Brulebois a écrit :
 looking at the testing summary page for d-i, I noticed win32-loader is
 blocked from automatic migration. I'm not sure whether we want to
 keep it that way but at least the 0.7.4.9 release currently in sid
 shouldn't hurt AFAICT; some bits of modernity on the source side,
 and updated Built-Using field on the binary side, so it should be OK
 to get testing in sync.

Sure, no problem for me. FTP-Masters need to copy (shortly after the 
migration of the package ideally) tools/win32-loader/unstable to 
tools/win32-loader/testing , see #710514.

Cheers,

OdyX


-- 
OdyX


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2626879.XAnzoYzleD@gyllingar

Re: Debian Installer 7.0 RC2 release

[Didier 'OdyX' Raboud]

Hi shirish,

Le dimanche, 28 avril 2013 11.40:05, shirish शिरीष a écrit :
 Hi all,
 Thank you for making the RC2 available. Please CC me while replying as
 I'm not subscribed to the list.

Done.

 I'm trying to download the RC2 DVD 1 via jigdo . I looked at the jigdo
 file time-stamp which is given as 18:13
 on 23rd April 2012 .
 
 http://cdimage.debian.org/cdimage/wheezy_di_rc2/amd64/jigdo-dvd/
 
 I'm using http://snapshot.debian.org/archive/debian/20130423T153728Z/
 as the debian mirror link as it's nearest one on both as far as time
 is concerned .

Why are you doing that ? Jigdo is supposed to work with any up-to-date Debian 
mirror. Does it fail with http://http.debian.net/debian ? Also, the jigdo file 
mentions this timestamp: 20130420T155816Z, so that would be the one to use, if 
at all.

Cheers,

OdyX


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201304281159.29157.o...@debian.org

Re: Gnome installability vs. GNU/kFreeBSD

[Didier 'OdyX' Raboud]

Hi all,

Le jeudi, 18 avril 2013 12.55:09, Steven Chamberlain a écrit :
 On 09/04/13 19:15, Didier 'OdyX' Raboud wrote:
  - gdm3 … doesn't finish loading. It fullscreen-says Oops, an error
  occured. - lightdm + Gnome: same.
  - lightdm + Gnome classic: same.
 
 Many thanks for testing that.
 
 It would be really helpful if you are able to test again with pulseaudio
 (+ libpulse0) patched with:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=kfreebsd-bug70
 5435.patch;att=1;bug=705435
 
 For me, it fixes all of the issues above.

Indeed; compiled pulseaudio with that patch and could then successfully start 
gdm3 and then Gnome. Couldn't reliably test the audio though.

It's in any case an improvement over what's now in kFreeBSD, I suggest to NMU 
pulseaudio with it soon.

Cheers,

OdyX


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201304191717.03531.o...@debian.org

Bug#695500: d-i-n-i: #695500 Works locally at least

[Didier 'OdyX' Raboud]

Hi all,

I can reliably test that the layout of files in debian-installer-netboot-
images' debian-installer-7.0-netboot-kfreebsd-amd64 is functional locally
using kvm:

$ kvm -m 256 -net nic -net 
user,bootfile=/grub2pxe,tftp=/usr/lib/debian-installer/images/7.0/kfreebsd-amd64/gtk/

(and s/gtk/text/ of course works too.. )

I think this bug should be reassigned to either debian-installer if that's a
problem of the layout of files within kfreebsd-* netboot, or the respective
PXE servers that fail to work with the layout as it is, but it really appears
to be a configuration problem rather than something fixable on d-i's side.

Cheers,

OdyX


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201304180911.40054.o...@debian.org

Re: Boot broken on latest debian iso's?

[Didier 'OdyX' Raboud]

Le jeudi, 18 avril 2013 09.01:21, Godwin Monis a écrit :
 Hi,
 
 I have downloaded the latest debian squeeze 6.0.7 DVD iso's from
 http://cdimage.debian.org/debian-cd/6.0.7/ia64/iso-dvd/. After downloading
 the ISO's I checked the md5 for debian-6.0.7-ia64-DVD-1.iso. This md5sum
 (7fb1cb78f8dd06111a52db95896b6792) matches the md5 given on the site at
 http://cdimage.debian.org/debian-cd/6.0.7/ia64/iso-dvd/MD5SUMS.
 
 However I am unable to boot from the image.

You most certainly want to use the amd64 [0] image, and not the ia64 [1] 
images, as Itanium processors are quite rare out there. Quoting [2]:

Intel Itanium Architecture (formerly IA-64) is Intel's *other* 64-bit 
architecture. Itanium processors are primarily found in HP Integrity servers 
and are supported by Debian's ia64 port (http://www.debian.org/ports/ia64/). 
It is not the same as the AMD64 / Intel 64 / x86-64 chips used in PCs (…).

Cheers,

OdyX

[0] http://en.wikipedia.org/wiki/AMD64
[1] http://en.wikipedia.org/wiki/Ia64
[2] http://ircbots.debian.net/factoids/factoid.php?key=ia64


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201304180916.10666.o...@debian.org

Re: Gnome installability vs. GNU/kFreeBSD

[Didier 'OdyX' Raboud]

Le mardi, 9 avril 2013 19.29:23, Steven Chamberlain a écrit :
 During wheezy development, GNOME 3 was so broken for us that xfce was
 chosen as a default for new installs.  Multiple show-stopper issues got
 fixed during the freeze though.  At this point I believe it 'should
 work' but so few people have probably tried a full GNU/kFreeBSD Wheezy
 GNOME desktop yet, and neither have I...

I just did (in kvm/qemu) and the result isn't great (for Gnome):

- lightdm + xfce just works for what I could test.
- gdm3 … doesn't finish loading. It fullscreen-says Oops, an error occured.
- lightdm + Gnome: same.
- lightdm + Gnome classic: same.

I can provide logs and file bugs if it helps.

OdyX


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201304092015.49092.o...@debian.org

Bug#684128: failure to communicate

[Didier 'OdyX' Raboud]

Hi Thomas,

Le vendredi, 5 avril 2013 17.52:19, Thomas Goirand a écrit :
 On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote:
  And all of these features will only land for the next cycle
  with a release in ~= 2 years time.
 
 I really hope that it wont be the case. That it doesn't go into
 Debian 7.0.0, I would understand, but at least, we need it
 for a point release.

Are you seriously arguing in favour of pushing a behavioural change into a 
stable point release? I doubt the stable release team would accept that, but 
I'm not under their hats.

 And at least, we need things written in the release notes about it, if not a
 message in the installer itself (Christian, don't kill me... ;).

I disagree. It has worked that way for a long time (and many releases in that 
timeframe), so it is probably not that broken.

I'm not saying the bug isn't valid of course, just that it's severity is IMHO 
correct.

 Could we stop the winning and have this bug fixed please,
 or the patch rejected (with a valid motivation)?

Could we stop the useless bikeshedding and have Wheezy released please?

The patch doesn't need rejection: it is a valid patch for a valid bug. It just 
affects d-i, which is quite an important piece of software for sane Debian 
releases. As you know, d-i is critically low on manpower.

You want that bug fixed? Great: test the patch, document your tests, upload to 
experimental with the patch, gather feedback, get involved, etc. For a fix to 
land in Wheezy, this should have happened 8 months ago. Now is the time to 
release Wheezy, not the time to add cosmetic and disruptive fixes to it. (And 
again, I think the changes are probably worthwhile, it's only the timing which 
is wrong.)

OdyX


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201304051816.11079.o...@debian.org