Re: On uploads and responsibilities

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):

> Christian, I'm very happy with your uploading l10n only changes so that
> translation updates don't take too long before reaching the archive. But
> when code changes are involved, maybe it would be better to poke people
> having pushed code so that they take responsibility for their changes,
> and so that you don't get to be pointed at when wondering who broke
> what.

I'm always balanced about this and, up to now, try to have a look at
code changes when I apply my "upload fast" policy. But, well, it's
also obvious that I'm too much disconnected from the current
development challengesand thus may miss important potential
breakages.

So, on one hand that would suggest more deep care and investigation
before uploading.

On the other hand, fast uploading should, at least theoretically,
reveal potential breakages (see recent debootstrap or base-installer
stories) and, indeed, it does. The main problem seems to be that
we desperately lack manpower to *process* reported breakagesand
thus take appropriate action (for what I've seen, Julien reverted the
debootstrap usr-merge changes but probably only after he noticed that
nobody else would take action).

I don't really know what to do, indeed. Continuing to upload quickly
is likely to lead to such situations. Poking people about their
changeswill I really commit to do this, I'm not sure, given the
(very limited) time I currently keep for this work. Stopping fast
uploads : I'm fairly sure this would lead to "commits wait for ages to
be uploaded" situations.

I might adapt to something like "check non uploaded stuff, except
l10n, on a weekly or monthly basis, and not daily". That would help
avoiding "too quick" uploads. I'm however quiute sure that I can't
commit to promise poking each and every person about their
changes.we also need everybody with commit rights to D-I git to be
responsible and try to anticipate the consequences of their changes.



signature.asc
Description: PGP signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):
> Christian PERRIER  (2016-11-19):
> > I now need to figure out where to make other changes.
> > 
> > One is in the installer build files (in the debian-installer package
> > itself) and is committed to git.
> 
> Maybe you forgot to push that part? I've mentioned it earlier when I
> noticed the rootskel-gtk upload (and only saw this thread afterwards):
>   https://lists.debian.org/debian-boot/2016/11/msg00178.html


That's right. I forgot pushing the commitwhich I found, today, was
done in an outdated copy of installer/ directory anyway (I keep my
copy of packages/ up-to-date, but not installer/)

I redid it cleanly today and just pushed.



signature.asc
Description: PGP signature

Bug#844579: console-setup: CyrAsia font missing Kazakh letter

[Baurzhan Muftakhidinov]

On Sun, Nov 20, 2016 at 4:14 AM, Cyril Brulebois  wrote:
> Hi,
>
> Baurzhan Muftakhidinov  (2016-11-17):
>> Package: console-setup
>>
>> Version: 1.153
>>
>> Dear maintainers,
>>
>> Recently I loaded CyrAsia font in console, and have noticed
>> that it misses one Kazakh letter:
>>
>> Ұ U+04B0 Cyrillic Capital Letter Straight U with Stroke
>> ұ U+04B1 Cyrillic Small Letter Straight U with Stroke
>>
>> I checked these codes in
>> https://anonscm.debian.org/cgit/d-i/console-setup.git/tree/Fonts/fontsets/CyrAsia.256
>>
>> Could you please add these to CyrAsia font definition?
>
> I'm not sure what's involved to add support for those. Maybe it's
> sufficient to add two lines with the codepoint to the file you
> mentioned?
>
> Maybe you could try patching console-setup locally and reporting back
> whether that fixed the bug?
>
>
> KiBi.

Hi,

I have recompiled the package and extracted CyrAsia-Fixed16.psf.gz font.
I can confirm that adding these two lines is enough for missing letter
to appear in font.

While we are at it, I wonder where these glyphs are taken from?
Because in build log I see that № symbol is missing from the resulting font.
In log file it says

WARNING: U+2116: no glyph defined

Also I see that currency symbols of some countries are added,
so I would like to add Kazakh tenge as well, its code is

₸ - Unicode Character 'TENGE SIGN' (U+20B8)

Thanks,

Re: Default theme for Stretch

[Aurélien COUDERC]

Le dimanche 20 novembre 2016, 03:23:02 CET Cyril Brulebois a écrit :
> Aurélien COUDERC  (2016-11-19):
>
> > Is there any way to easily test the rootskel-gtk theme ? Ideally I’d
> > also patch the GTK colors to match the banner but I don’t want to do
> > that without test.
> 
> I don't think we have anything for this at the moment… What I usually do
> when updating rootskel-gtk is: build its binaries, put them under
> build/localudebs in the debian-installer source tree, then (re)build the
> netboot-gtk image (see above).
> 
> Feel free to stage changes in a pu/theme branch or so in rootskel-gtk; I
> can pull from there, and share generated installation images if you like.

Done, please check the pu/theme branch in rootskel-gtk git.

I’ve also updated the GTK theme to match Softwaves colors.
Screenshots attached.


Cheers !
--Aurélien

Re: Bug#843775: jessie-pu: package mdadm/3.3.2-5+deb8u2

[Cyril Brulebois]

Control: tag -1 + confirmed - moreinfo

Jonathan Wiltshire  (2016-11-20):
> On Wed, Nov 09, 2016 at 01:52:25PM +0100, Jens Sauer wrote:
> > I prepared a package for mdadm to fix bug #840743
> > (https://bugs.debian.org/840743) which prevents a correct reshape
> > when only one 'spare' device and no backup-file is used. This can
> > result in a nonfunctional array.
> 
> Twitched too soon; mdadm has a udeb, so it needs a d-i ack first. Sorry,
> please wait.

I don't think d-i is hitting a “grow” / “-G” codepath, and a quick grep
seems to confirm that. So it looks to me a patch touching Grow.c should
have no consequences on d-i (famous last words).

=> Please go ahead.


KiBi.


signature.asc
Description: Digital signature

rootskel_1.121_amd64.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 20 Nov 2016 17:13:43 +0100
Source: rootskel
Binary: rootskel
Architecture: source amd64
Version: 1.121
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Samuel Thibault 
Description:
 rootskel   - Skeleton root filesystem used by debian-installer (udeb)
Closes: 844549
Changes:
 rootskel (1.121) unstable; urgency=medium
 .
   * Team upload
   * Fix starting screen in ssh when d-i is already running inside screen on
 serial port (Closes: #844549).
Checksums-Sha1:
 37726766e8a1de285b60afe7dd911bea4035e073 1704 rootskel_1.121.dsc
 172eff5712041a23d6d497c695394972aba29a1e 32232 rootskel_1.121.tar.xz
 0607f6804cc0fe80d004b1dfe7b86f3fae36 4348 rootskel_1.121_amd64.buildinfo
 2902ff48b84151f62867a7f3a6c6fec9fd68d2ea 9042 rootskel_1.121_amd64.udeb
Checksums-Sha256:
 2f4bbc05f3297c47cd4e3a940f0791a0398881a9a7a4a5bdbc178cbc5d71fc3c 1704 
rootskel_1.121.dsc
 ef59c4962c5a2c00b8509112625b750177170a168cf2cd9569668e39253863b1 32232 
rootskel_1.121.tar.xz
 be4a318732d024ee227363d65b83d73a3e2da19dde5a8e696cebc4482123347d 4348 
rootskel_1.121_amd64.buildinfo
 b125e1c78b941926636b27422d43b6b7a3893202f4dc943c420e7a01e834edef 9042 
rootskel_1.121_amd64.udeb
Files:
 9625add1d95cb875a7ce3a1546fb8f2a 1704 debian-installer standard 
rootskel_1.121.dsc
 1348fb24b94b7b67a4ca41e14304c7b0 32232 debian-installer standard 
rootskel_1.121.tar.xz
 4fe7c033ecac9de03c609eafdb036d6a 4348 debian-installer standard 
rootskel_1.121_amd64.buildinfo
 a96bbe373439d8799388151ffdd1c7bc 9042 debian-installer standard 
rootskel_1.121_amd64.udeb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE9jJ0zcYwCHPLPSnZ4+Uc6PtrLx0FAlgxzV0ACgkQ4+Uc6Ptr
Lx31fA/+Lxsj4KJC0OSBBxU05mzBXXVubJ/4abvZYMFR/a9kYIoeFHETTujXopy3
V8H0nhtM1NQQvvqJWsYu3RXmbjtJjo9p7pu9X2D0SSETmDFZwOgQhmUN82P4UIoM
fHrx7oj9cFQ5NDn6Jh6c1/miTrkLDKy1MLwOgEA2OtxpM6dFGI5VP4FoA4hvVkzm
skYjEDAOBy6zYaSMkW926nhNpGmPh6SsRELmTEzIC+fqcrm39uY9SzQZQdUsF0CT
GJoA9Yzv9F2unWN/1KfTd1S3u7Whg2aylF1t1dd8U8TrgG5MCXdCXPSU1FbhYcTR
ykbOhMDFTp0Gz6Zk5MGld+fMhegWO84ShYeX+jJkW9tBk+/fuw39hRUagJtzThSm
qqE/QAlbPVZ55BPHC1oBGUAYw3WMqpLijaZwO/U8kDCY7V85iugJc5uVeHzJGfmq
qY8Ibuy7skwpI4xQETqR95MQh3JE+m1SU+hAKXmKmQmstXTUOLLqRRPJHWTdZCI2
lZyz5Vad9UYGrf3tvo8w1LOkkBaUSJndttBeOWEfYwBIF3JSgvd7FM9vOrCPfukV
CvohbZSXDNk7wegeTbvXand7kNYnFq1n73GfVOiwF+LdYW2gS6uXl9rauhEIl55q
LOHsayT3hpLlgEUXLu0xRQ1RZylVCPLYz4tnvKKSMK1VMsGl7mY=
=THOf
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Bug#844549: marked as done (network-console broken: no screen to be resumed matching sh)

[Debian Bug Tracking System]

Your message dated Sun, 20 Nov 2016 16:35:04 +
with message-id 
and subject line Bug#844549: fixed in rootskel 1.121
has caused the Debian Bug report #844549,
regarding network-console broken: no screen to be resumed matching sh
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
844549: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844549
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: rootskel
Version: 1.119
Severity: serious
Tags: patch

Several users have reported to me that the network-console images are
broken.

Commit ec6d3c3d79 (Move screen support) moved the screen support
around and also changed the logic of when screen is used.
Unfortunately, that change broke all network-console images which now
lead to:

installer@192.168.0.102's password:
There is no screen to be resumed matching sh.
Connection to 192.168.0.102 closed.

This is because d-i is already running in screen on the serial console but
it's active and can't be resumed.

I believe below is the right fix, i.e. start screen when screen exists and
when we're on serial or when we're NOT on network.

Samuel, Roger, does that look correct?

diff --git a/src/lib/debian-installer.d/S70menu 
b/src/lib/debian-installer.d/S70menu
index 7b35fac..14cad7f 100644
--- a/src/lib/debian-installer.d/S70menu
+++ b/src/lib/debian-installer.d/S70menu
@@ -11,7 +11,7 @@ if [ -x "$bterm" ] && [ -e "$font" ] && [ -n "$TERM_UTF8" ] 
&& [ -n "$TERM_FRAME
set -e
 else
rm -f $font
-   if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
+   if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
# there's GNU/screen binary, run menu in it.
# call this script again with in GNU/screen, possibly in UTF-8 
mode
SCREEN_OPT=""

-- 
Martin Michlmayr
http://www.cyrius.com/
--- End Message ---
--- Begin Message ---
Source: rootskel
Source-Version: 1.121

We believe that the bug you reported is fixed in the latest version of
rootskel, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 844...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Samuel Thibault  (supplier of updated rootskel package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 20 Nov 2016 17:13:43 +0100
Source: rootskel
Binary: rootskel
Architecture: source amd64
Version: 1.121
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Samuel Thibault 
Description:
 rootskel   - Skeleton root filesystem used by debian-installer (udeb)
Closes: 844549
Changes:
 rootskel (1.121) unstable; urgency=medium
 .
   * Team upload
   * Fix starting screen in ssh when d-i is already running inside screen on
 serial port (Closes: #844549).
Checksums-Sha1:
 37726766e8a1de285b60afe7dd911bea4035e073 1704 rootskel_1.121.dsc
 172eff5712041a23d6d497c695394972aba29a1e 32232 rootskel_1.121.tar.xz
 0607f6804cc0fe80d004b1dfe7b86f3fae36 4348 rootskel_1.121_amd64.buildinfo
 2902ff48b84151f62867a7f3a6c6fec9fd68d2ea 9042 rootskel_1.121_amd64.udeb
Checksums-Sha256:
 2f4bbc05f3297c47cd4e3a940f0791a0398881a9a7a4a5bdbc178cbc5d71fc3c 1704 
rootskel_1.121.dsc
 ef59c4962c5a2c00b8509112625b750177170a168cf2cd9569668e39253863b1 32232 
rootskel_1.121.tar.xz
 be4a318732d024ee227363d65b83d73a3e2da19dde5a8e696cebc4482123347d 4348 
rootskel_1.121_amd64.buildinfo
 b125e1c78b941926636b27422d43b6b7a3893202f4dc943c420e7a01e834edef 9042 
rootskel_1.121_amd64.udeb
Files:
 9625add1d95cb875a7ce3a1546fb8f2a 1704 debian-installer standard 
rootskel_1.121.dsc
 1348fb24b94b7b67a4ca41e14304c7b0 32232 debian-installer standard 
rootskel_1.121.tar.xz
 4fe7c033ecac9de03c609eafdb036d6a 4348 debian-installer standard 
rootskel_1.121_amd64.buildinfo
 a96bbe373439d8799388151ffdd1c7bc 9042 debian-installer standard 
rootskel_1.121_amd64.udeb

-BEGIN PGP SIGNATURE-

Processing of rootskel_1.121_amd64.changes

[Debian FTP Masters]

rootskel_1.121_amd64.changes uploaded successfully to localhost
along with the files:
  rootskel_1.121.dsc
  rootskel_1.121.tar.xz
  rootskel_1.121_amd64.buildinfo
  rootskel_1.121_amd64.udeb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Bug#844549: network-console broken: no screen to be resumed matching sh

[Samuel Thibault]

Hello,

Philip Hands, on Sun 20 Nov 2016 12:20:38 +0100, wrote:
> Martin Michlmayr  writes:
> 
> > * Samuel Thibault  [2016-11-16 23:03]:
> >> But AIUI the intent was to have screen in ssh connections too.
> >
> > I'm not sure what the intent was.  I assume you're right because Roger
> > didn't exclude screen from the network-console images.  Personally,
> > I'm not sure I see the point of screen in that case because you can
> > always open a second SSH connection and open a terminal, but I don't
> > have strong feelings either way if there's an advantage of having
> > screen in such cases.
> 
> I'd think that the advantage is that one could start a serial install up
> to the point that the network comes up, and then hijack it onto the ssh
> session so that one gets to see the same install (as well as any other
> shells you might have started).

Mmm, that's a nice idea indeed.  I've eventually uploaded the -x fix,
which gives us that behavior, and also allowing several people to follow
the installation, interact, etc.

Samuel

Re: Bug#843775: jessie-pu: package mdadm/3.3.2-5+deb8u2

[Jonathan Wiltshire]

Control: tag -1 - confirmed + moreinfo

On Wed, Nov 09, 2016 at 01:52:25PM +0100, Jens Sauer wrote:
> I prepared a package for mdadm to fix bug #840743
> (https://bugs.debian.org/840743) which prevents a correct reshape when only 
> one
> 'spare' device and no backup-file is used.
> This can result in a nonfunctional array.

Twitched too soon; mdadm has a udeb, so it needs a d-i ack first. Sorry,
please wait.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#842630: localechooser: Should support separating language from localization

[Samuel Thibault]

Samuel Thibault, on Sun 30 Oct 2016 22:45:59 +0100, wrote:
> I have been told several times that it was a bit sad that the Debian
> installer basically imposess that the translations be the same as the
> locale, i.e. notably not being able to have all messages in english
> while using a non-english locale. Of course we don't want to add
> questions for the user to specify exactly for each LC_* which locale to
> be used, but the language part seems to be asked quite often, so it
> could be worth implementing it.

This is also notably a problem when installing e.g. from a serial
console, where the language choice is limited to English.  It might be
fine enough to have d-i untranslated, but that shouldn't impose using an
english locale for the whole system.

Samuel

Bug#842040: Please add https support

[Philipp Kern]

On 2016-11-20 12:10, Julien Cristau wrote:

I think until there's a ca-certificates-udeb, adding wget for https in
all images isn't reasonable, vs google rebuilding d-i with added wget
and the PEM bits you need.  I guess ca-certificates-udeb would need 
some

way to preseed a list of trusted CAs.


I have no problem working on that. Given that today ca-certificates only 
contains Mozilla's set I don't think it's necessarily required to 
provide that preseeding option (i.e. it could be added by someone who 
cared enough later).


The problem with rebuilding d-i is that you can't really do it from the 
source package in unstable, you need to do it from the VCS.


It boils down to the question if it's useful beyond just us. :)

Kind regards
Philipp Kern

Re: Default theme for Stretch

[Aurélien COUDERC]

Le dimanche 20 novembre 2016, 03:23:02 CET Cyril Brulebois a écrit :
> Aurélien COUDERC  (2016-11-19):
> > Here’s a patch.  Again not tested (tried a quick debuild but it fails)
> > so please take it with a pinch of salt.
> 
> You'll find attached a screenshot. I've built this in a sid chroot, with:
> 
> make -C build rebuild_netboot-gtk

Works, thank you.

> It feels a bit empty to me. But I've been seeing boot prompts for far too
> long, I'm certainly biased. ;)

We’ll see what we can do to avoid shocking long time d-i contributors… :-)
A first small improvement to avoid that-big-gap-at-the-top is to raise the menu 
a little. Trivial patch and result screenshot attached.

Also there’s a « _ » character at the beginning of the first menu line, that 
wasn’t there in Jessie.
It seems to be due to that :
./build/boot/x86/menu.cfg:4:menu title ${BEEP}Debian GNU/Linux installer boot 
menu

Any idea why / if it can be fixed ?

> > Is there any way to easily test the rootskel-gtk theme ? Ideally I’d
> > also patch the GTK colors to match the banner but I don’t want to do
> > that without test.
> 
> I don't think we have anything for this at the moment… What I usually do
> when updating rootskel-gtk is: build its binaries, put them under
> build/localudebs in the debian-installer source tree, then (re)build the
> netboot-gtk image (see above).
> 
> Feel free to stage changes in a pu/theme branch or so in rootskel-gtk; I
> can pull from there, and share generated installation images if you like.

Do you mean in the project’s git repo on Alioth ?
I would need commit right on the repo then, if you wouldn’t mind.


Cheers !
--Aurélien

diff --git a/build/boot/x86/stdmenu.cfg b/build/boot/x86/stdmenu.cfg
index 4a212b6..f37f478 100644
--- a/build/boot/x86/stdmenu.cfg
+++ b/build/boot/x86/stdmenu.cfg
@@ -8,7 +8,7 @@ menu color help		37;40 #ff00 # none
 # XXX When adjusting vshift, take care that rows is set to a small
 # enough value so any possible menu will fit on the screen,
 # rather than falling off the bottom.
-menu vshift 12
+menu vshift 9
 menu rows 10
 menu helpmsgrow 15
 # The command line must be at least one line from the bottom.

Bug#845110: installation-report: Installation appears to be succesful

[Jeroen N. Witmond]

Package: installation-reports
Version: 2.62
Severity: minor
Tags: d-i

Dear Maintainer,

-- Package-specific info:

Boot method: USB
Image version: 
http://cdimage.debian.org/cdimage/stretch_di_alpha8/amd64/iso-cd/debian-stretch-DI-alpha8-amd64-netinst.iso
Date: 2016-11-20 13:00 CET

Machine: custom build, Intel Core i3-6100 / 3.7 GHz - 3 MB cache, 8GB DDR4 RAM, 
275 GB SSD
Partitions: 
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   4030032   0   4030032   0% /dev
tmpfs  tmpfs   807984   17760790224   3% /run
/dev/sda1  ext4 215227656 4530056 199694928   3% /
tmpfs  tmpfs  40399008880   4031020   1% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
tmpfs  tmpfs  4039900   0   4039900   0% /sys/fs/cgroup
tmpfs  tmpfs   807980   0807980   0% /run/user/115
tmpfs  tmpfs   807980  12807968   1% /run/user/1000



Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O] Correctly found USB disk.
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

No problems during install.

Comments on installation report: 
https://d-i.debian.org/manual/en.i386/ch05s04.html#submit-bug asks me to 
install the installation-report and reportbug packages
but they already were installed. 
On the same page command reportbug installation-reports is wrong; should not 
have the final 's'.

Perhaps I should take the next item elsewhere: Once installation is complete, I 
cannot find Apper, nor can I get Discover to install
additional software.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20161031"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux zandbak 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Sky Lake Host 
Bridge/DRAM Registers [8086:190f] (rev 07)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Sky 
Lake Integrated Graphics [8086:1912] (rev 06)
lspci -knn: DeviceName:  Onboard IGD
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H 
USB 3.0 xHCI Controller [8086:a12f] (rev 31)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-H CSME HECI #1 [8086:a13a] (rev 31)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Device 
[8086:a102] (rev 31)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI 
Express Root Port #5 [8086:a114] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI 
Express Root Port #9 [8086:a118] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-H LPC 
Controller [8086:a143] (rev 31)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-H 
PMC [8086:a121] (rev 31)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD 
Audio [8086:a170] (rev 31)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:86c7]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-H SMBus 
[8086:a123] (rev 31)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
lspci -knn: 

Bug#844549: network-console broken: no screen to be resumed matching sh

[Philip Hands]

Martin Michlmayr  writes:

> * Samuel Thibault  [2016-11-16 23:03]:
>> But AIUI the intent was to have screen in ssh connections too.
>
> I'm not sure what the intent was.  I assume you're right because Roger
> didn't exclude screen from the network-console images.  Personally,
> I'm not sure I see the point of screen in that case because you can
> always open a second SSH connection and open a terminal, but I don't
> have strong feelings either way if there's an advantage of having
> screen in such cases.

I'd think that the advantage is that one could start a serial install up
to the point that the network comes up, and then hijack it onto the ssh
session so that one gets to see the same install (as well as any other
shells you might have started).

That way, if you think you've preseeded all the pre-network stuff, there
would be a session to look at via serial if it never gets to the
network.

Perhaps this is not a real scenario though (I've not played with SSH
connections to d-i, so I don't know what happens when you log in and
debconf is already active on the console)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#842040: Please add https support

[Julien Cristau]

On Sun, Nov 20, 2016 at 11:52:09 +0100, Philipp Kern wrote:

> On 20.11.2016 11:45, Cyril Brulebois wrote:
> >> But you are absolutely correct in for this to be universally useful,
> >> we'd also need a ca-certificates-udeb. I can take a look at that but I
> >> somewhat fear that it won't be that much smaller than the regular one
> >> (maybe ~150k udeb size).
> > 
> > If you're going to need another cpio archive with PEM files, can't you
> > just add the needed bits (wget & libraries) for https there?
> > 
> > Adding packages for every single image just so that Google people can
> > append a cpio archive with some CAs doesn't look too reasonable to me:
> > you need to do extra work on your end anyway, and everybody pays that
> > price without getting any advantage…
> 
> Well, I said why adding wget plus somehow determining the required
> libraries is harder than just adding some static content.[1] We also
> wouldn't need to do the PEM cpio dance if ca-certificates-udeb would be
> part of the image. We don't need to add an internal CA or something like
> that.
> 
I think until there's a ca-certificates-udeb, adding wget for https in
all images isn't reasonable, vs google rebuilding d-i with added wget
and the PEM bits you need.  I guess ca-certificates-udeb would need some
way to preseed a list of trusted CAs.

Cheers,
Julien

Bug#842040: Please add https support

[Philipp Kern]

On 20.11.2016 11:45, Cyril Brulebois wrote:
>> But you are absolutely correct in for this to be universally useful,
>> we'd also need a ca-certificates-udeb. I can take a look at that but I
>> somewhat fear that it won't be that much smaller than the regular one
>> (maybe ~150k udeb size).
> 
> If you're going to need another cpio archive with PEM files, can't you
> just add the needed bits (wget & libraries) for https there?
> 
> Adding packages for every single image just so that Google people can
> append a cpio archive with some CAs doesn't look too reasonable to me:
> you need to do extra work on your end anyway, and everybody pays that
> price without getting any advantage…

Well, I said why adding wget plus somehow determining the required
libraries is harder than just adding some static content.[1] We also
wouldn't need to do the PEM cpio dance if ca-certificates-udeb would be
part of the image. We don't need to add an internal CA or something like
that.

I understand the bit about paying the price, which is why I tried to
address that in my reply as well. Recent discussions on -devel showed
that there's a general interest in HTTPS enablement.

Kind regards
Philipp Kern

[1] Unless we rebuild d-i, which we could do.

Bug#842040: Please add https support

[Cyril Brulebois]

Philipp Kern  (2016-11-20):
> On 20.11.2016 05:52, Cyril Brulebois wrote:
> > Well, I think this is a crucial issue: what use case(s) are you trying
> > to fix? “We want https” isn't clear to me.
> 
> After d-i has installed the system, we use HTTPS with client
> certificates - using apt-transport-https. The use case there is
> authentication and be allowed to fetch packages from any network,
> including the Internet. During d-i we unfortunately still have to rely
> on network trust, where we run against the company policy of not having
> unencrypted services. Plus we'd need to have various non-HTTPS endpoints
> (packages, configuration, images[1]) in addition to the HTTPS ones we
> already have, which complicates maintenance. You'd think that we aren't
> the only ones who'd host configuration behind a HTTPS server, though[2].
> That we also serve all of the packages through HTTPS is just a byproduct.
> 
> > Besides wget supporting https, is there any work needed on the retriever
> > side? What about trust chains, do you have any bundled list of trusted
> > CAs? Do you want to be able to rebuild d-i with a specific trusted CA,
> > and trust none by default?
> 
> I can say what works for us: adding another cpio archive to the netboot
> that contains files in /etc/ssl/certs (PEM files plus the result of
> c_rehash). You can pass multiple initrds to the kernel and it will
> unpack them one by one, which easily allows to add more files and
> overwrite existing ones (but not to remove files, AFAIK). It's not
> really much worse than other bits of configuration, like preseeds.
> Embedding another binary like wget and not just scripts, however, is
> more tricky (getting dependencies right, fighting against mklibs
> removing symbols - which I guess was... fixed).
> 
> But you are absolutely correct in for this to be universally useful,
> we'd also need a ca-certificates-udeb. I can take a look at that but I
> somewhat fear that it won't be that much smaller than the regular one
> (maybe ~150k udeb size).

If you're going to need another cpio archive with PEM files, can't you
just add the needed bits (wget & libraries) for https there?

Adding packages for every single image just so that Google people can
append a cpio archive with some CAs doesn't look too reasonable to me:
you need to do extra work on your end anyway, and everybody pays that
price without getting any advantage…


KiBi.


signature.asc
Description: Digital signature

Bug#806984: debian-installer: FTBFS: File not found:libtextwrap.so.1

[Holger Levsen]

retitle -1 debian-installer: ftbfs because d-i needs network to build…
thanks

On Sun, Nov 20, 2016 at 11:10:11AM +0100, Cyril Brulebois wrote:
> This isn't a locale issue at all:
[...]
> FTBFS due to 4.7 vs. 4.8 kernel udebs is expected to be an issue (fixed
> in master where the ABI bump happened; but failing to download any udebs
> is a no-go, d-i needs to access a mirror during its build.

ah, ic, retitling the bug accordingly. Thanks.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#842040: Please add https support

[Philipp Kern]

On 20.11.2016 05:52, Cyril Brulebois wrote:
> Well, I think this is a crucial issue: what use case(s) are you trying
> to fix? “We want https” isn't clear to me.

After d-i has installed the system, we use HTTPS with client
certificates - using apt-transport-https. The use case there is
authentication and be allowed to fetch packages from any network,
including the Internet. During d-i we unfortunately still have to rely
on network trust, where we run against the company policy of not having
unencrypted services. Plus we'd need to have various non-HTTPS endpoints
(packages, configuration, images[1]) in addition to the HTTPS ones we
already have, which complicates maintenance. You'd think that we aren't
the only ones who'd host configuration behind a HTTPS server, though[2].
That we also serve all of the packages through HTTPS is just a byproduct.

> Besides wget supporting https, is there any work needed on the retriever
> side? What about trust chains, do you have any bundled list of trusted
> CAs? Do you want to be able to rebuild d-i with a specific trusted CA,
> and trust none by default?

I can say what works for us: adding another cpio archive to the netboot
that contains files in /etc/ssl/certs (PEM files plus the result of
c_rehash). You can pass multiple initrds to the kernel and it will
unpack them one by one, which easily allows to add more files and
overwrite existing ones (but not to remove files, AFAIK). It's not
really much worse than other bits of configuration, like preseeds.
Embedding another binary like wget and not just scripts, however, is
more tricky (getting dependencies right, fighting against mklibs
removing symbols - which I guess was... fixed).

But you are absolutely correct in for this to be universally useful,
we'd also need a ca-certificates-udeb. I can take a look at that but I
somewhat fear that it won't be that much smaller than the regular one
(maybe ~150k udeb size).

Kind regards and thanks
Philipp Kern

[1] We extended d-i to download image files of system installs.
[2] Thinking of preseed/url across the Internet. I used to need that for
s390x installs.

Bug#806984: debian-installer: FTBFS: File not found:libtextwrap.so.1

[Cyril Brulebois]

Hi,

Holger Levsen  (2016-11-20):
> On Sun, Nov 20, 2016 at 03:42:15AM +0100, Cyril Brulebois wrote:
> > Looking at your A02_user hook, I don't see anything locale-related (now or
> > in previous commits). I've tried setting LANG=fr_CH.UTF-8 and I don't see
> > debian-installer's master fail to build in a sid chroot.
> 
> when possible we don't modify the environment with pbuilder hooks but
> rather directly with our build script
> https://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/bin/reproducible_build.sh
> 
> have a look at lines 591-600 for the 1st build and 637-660 for the 2nd
> build.

This isn't a locale issue at all:
| I: pbuilder: network access will be disabled during build
[…]
| WARNING: mirror 'http://ftp.de.debian.org/debian' appears to be invalid; 
skipping
| WARNING: mirror 'http://ftp.de.debian.org/debian' appears to be invalid; 
skipping
| Using generated sources.list.udeb:
|deb [trusted=yes] copy:/build/1st/debian-installer-20161031/build/ 
localudebs/

> Upon replying I've scheduled rebuilds of src:debian-installer for
> (amd64|i386|armhf) on unstable+testing and the rebuilds have all already
> happened, all ftbfs…

FTBFS due to 4.7 vs. 4.8 kernel udebs is expected to be an issue (fixed
in master where the ABI bump happened; but failing to download any udebs
is a no-go, d-i needs to access a mirror during its build.


KiBi.


signature.asc
Description: Digital signature

Re: Planning for d-i Stretch Alpha 9

[Ben Hutchings]

On Sun, 2016-11-20 at 04:06 +0100, Cyril Brulebois wrote:
[...]
> [Actual question]
> 
> I'd like to know whether you already have some kind of planning for the
> next ABI bump(s?) on the linux side, so that we could align further d-i
> releases accordingly.
[...]

Yes, there will be an ABI bump in the next upload to unstable (probably
within the next week).

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing
anyway.



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

Bug#806984: debian-installer: FTBFS: File not found:libtextwrap.so.1

[Holger Levsen]

Hi,

On Sun, Nov 20, 2016 at 03:42:15AM +0100, Cyril Brulebois wrote:
> Looking at your A02_user hook, I don't see anything locale-related (now or
> in previous commits). I've tried setting LANG=fr_CH.UTF-8 and I don't see
> debian-installer's master fail to build in a sid chroot.

when possible we don't modify the environment with pbuilder hooks but
rather directly with our build script
https://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/bin/reproducible_build.sh

have a look at lines 591-600 for the 1st build and 637-660 for the 2nd
build.

> Can you please tell us whether this issue is still seen in your setup, and
> with which exact settings?

Upon replying I've scheduled rebuilds of src:debian-installer for
(amd64|i386|armhf) on unstable+testing and the rebuilds have all already
happened, all ftbfs…

the results are all be linked from 
https://reproducible.debian.net/debian-installer 

> I can't replicate it with my devel chroots,
> it's not seen on buildds, so I'm lowering the severity for the time being.
> It can be upgraded again if a relevant reproducer is found.

thanks!

> Thanks for your time.

likewise! :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#838504: marked as done (debian-installer: debconf-apt-progress fails to parse localized numbers and spams tty4)

[Debian Bug Tracking System]

Your message dated Sun, 20 Nov 2016 10:21:02 +0100
with message-id <20161120092102.gp21...@mraw.org>
and subject line Re: Bug#838504: debian-installer: debconf-apt-progress fails 
to parse localized numbers and spams tty4
has caused the Debian Bug report #838504,
regarding debian-installer: debconf-apt-progress fails to parse localized 
numbers and spams tty4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
838504: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838504
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-installer
Version: 20160630
Tags: l10n
Severity: minor

When installing a new Debian system using debian-installer and setting a
French locale, a large number of warning messages related to debconf are
visible in tty4 throughout the installation.  The messages are similar to
the following:

in-target: Argument "27,2727" isn't numeric in multiplication (*) at 
/usr/bin/debconf-apt-progress line 168,  line 29.

It looks like the French locale causes decimal numbers to be formatted as
"42,1337" instead of "42.1337" when passing data to debconf-apt-progress.
This seems incorrect: format localisation should only be used when
presenting text to humans, not when feeding data to other programs.

These messages are merely annoying, because it's almost impossible to read
the other kind of (more interesting) messages displayed in tty4.  On the
other hand, progress bars on the dialog frontend in tty1 do seem to work
normally, despite these messages.

This is using the Debian-installer Stretch Alpha 7 release (which
presumably uses debconf 1.5.59).  I was installing with the regular
text-based install, not the graphical one.

This bug looks a bit similar to #729699.

Regards,
--- End Message ---
--- Begin Message ---
Version: 20161031

Hi,

Baptiste Jonglez  (2016-09-21):
> Package: debian-installer
> Version: 20160630
> Tags: l10n
> Severity: minor
> 
> When installing a new Debian system using debian-installer and setting a
> French locale, a large number of warning messages related to debconf are
> visible in tty4 throughout the installation.  The messages are similar to
> the following:
> 
> in-target: Argument "27,2727" isn't numeric in multiplication (*) at 
> /usr/bin/debconf-apt-progress line 168,  line 29.
> 
> It looks like the French locale causes decimal numbers to be formatted as
> "42,1337" instead of "42.1337" when passing data to debconf-apt-progress.
> This seems incorrect: format localisation should only be used when
> presenting text to humans, not when feeding data to other programs.
> 
> These messages are merely annoying, because it's almost impossible to read
> the other kind of (more interesting) messages displayed in tty4.  On the
> other hand, progress bars on the dialog frontend in tty1 do seem to work
> normally, despite these messages.
> 
> This is using the Debian-installer Stretch Alpha 7 release (which
> presumably uses debconf 1.5.59).  I was installing with the regular
> text-based install, not the graphical one.

I can't reproduce this past Stretch Alpha 8 (I'm on a local build but
that shouldn't change much), en essayant en français moi aussi.

I think it's been fixed on the apt side in:
| commit 0919f1df552ddf022ce4508cbf40e04eae5ef896
| Author: David Kalnischkies 
| Date:   Tue Aug 23 15:11:20 2016 +0200
| 
| prevent C++ locale number formatting in text APIs (try 3)
| 
| This time it is the formatting of floating numbers in progress
| reporting with a radix charater potentially not being dot.
| 
| Followup of 7303e11ff28f920a6277c159aa46f80c007350bb. Regression of
| b58e2c7c56b1416a343e81f9f80cb1f02c128e25 in so far as it exchanging
| very effected with slightly less effected code.
| 
| LP: 1611010

which hit unstable then testing after an extra revision in early
September:

[2016-08-30] Accepted apt 1.3~rc3 (source) into unstable (Julian Andres 
Klode)
[2016-09-02] Accepted apt 1.3~rc4 (source) into unstable (Julian Andres 
Klode)
[2016-09-08] apt 1.3~rc4 MIGRATED to testing (Debian testing watch)

I'm closing this bug report accordingly, as Stretch Alpha 8 should have
the fix as well.


KiBi.


signature.asc
Description: Digital signature
--- End Message ---

Processed: Re: Bug#729401: debian-installer: xfsprogs not installed when using xfs filesystems

[Debian Bug Tracking System]

Processing control commands:

> tag -1 - d-i
Bug #729401 [debian-installer] debian-installer: xfsprogs not installed when 
using xfs filesystems
Removed tag(s) d-i.

-- 
729401: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729401
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#729401: debian-installer: xfsprogs not installed when using xfs filesystems

[Cyril Brulebois]

Control: tag -1 - d-i

Hi,

Jamin Collins  (2013-11-12):
> Package: debian-installer
> Severity: important
> Tags: d-i
> 
> I used the following installation media:
> 
> 6fba6fbf3ecfe38ec7f667f5da658df2  debian-live-7.2-amd64-xfce-desktop.iso
> 
> If XFS volumes are used during the installation the xfsprogs package is not
> installed on the target system.
> 
> This presents a problem as a filesystem check is forced on the first boot, but
> the necessary binary is not installed.  This renders the installed system
> unusable.

FWIW, a test with a post Stretch Alpha 8 image (local build) seems to
install just fine with / on XFS, and xfsprogs is installed; in tasksel,
only ssh task and standard task were selected.

It would be nice to know what the status on jessie is; maybe a fix is
needed there?


KiBi.


signature.asc
Description: Digital signature

Bug#768184: debian-installer: Progress indicator sometimes false

[Cyril Brulebois]

Martin Michlmayr  (2016-02-16):
> I'm copying the APT maintainers for comment:
> 
> * Stéphane Aulery  [2014-11-05 20:13]:
> > Package: debian-installer
> > 
> > After choosing the mirror, counter downloaded files is wrong on several
> > occasions. It displays :
> > 
> > Download file 1 of 1
> > Download file 2 of 2
> > Download file 3 of 3
> > 
> > instead of :
> > 
> > Download file 1 of 3
> > Download file 2 of 3
> > Download file 3 of 3
> 
> * Cyril Brulebois  [2014-11-05 22:48]:
> > ISTR apt's unable to count (possibly because it can't or at least
> > doesn't know in advance how many files it will need).
> 
> * Cyril Brulebois  [2014-11-07 15:57]:
> > Presumably correct while downloading debs, and incorrect while running
> > apt-get update? That would match what I was thinking about. I'm not
> > seeing any obvious bug reports from me against apt about this issue
> > though.

It seems less obvious now, but presumably because my tests are running
on a quicker machine… Anyway, I seem to have spotted this with a local
d-i build, so that might still be current at the moment.


KiBi.


signature.asc
Description: Digital signature

Processed: Re: Bug#744863: punjabi installation broken (or at least rescue mode)

[Debian Bug Tracking System]

Processing control commands:

> forcemerge 727043 -1
Bug #727043 [debian-installer] punjabi installation broken
Bug #744863 [debian-installer] punjabi installation broken (or at least rescue 
mode)
Severity set to 'important' from 'normal'
Marked as found in versions debian-installer/20131014.
Merged 727043 744863

-- 
727043: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727043
744863: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744863
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#744863: punjabi installation broken (or at least rescue mode)

[Cyril Brulebois]

Control: forcemerge 727043 -1

Holger Levsen  (2014-04-15):
> package: debian-installer
> 
> 
> [16:47] <  h01ger> | there seems to be a problem with punjabi which other 
> languages dont show: 
>   
> https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_rescue_punjabi/
> [17:37] < KiBi> it seems to loop on the keyboard options screen here
> [17:37] < KiBi> maybe setxkbmap/console-setup failing, and making it loop
> [17:37] < KiBi> (no traces in syslog afaict)

You filed this a while ago already…


KiBi.


signature.asc
Description: Digital signature