Re: commit "Bump Linux kernel version from 4.3.0-1 to 4.4.0-1"

[Cyril Brulebois]

Martin Michlmayr  (2016-02-19):
> * Cyril Brulebois  [2016-02-19 11:07]:
> > Until now I've been waiting for linux to be built everywhere to flip
> > the switch. I'm fine with revisiting how we do things but I think it
> > should be discussed somehow.
> 
> I agree with you (unless there's one arch which takes a long time to
> get fixed).

(of course)

> Sorry, I was a little bit trigger happy yesterday.  I thought breaking
> some builds for a day or two wouldn't be a big problem, but I guess
> you're the one receiving all the build errors. ;-)

I have a specific monitoring for kernel bumps and d-i daily build
failures indeed. I almost was trigger-happy as well, but refrained from
doing so when I noticed some FTBFSes; which made it curious to get
notified about d-i daily build failures a few hours after that. ;)

> Anyway, I agree with your policy.  Ben made a new linux upload so
> hopefully all architectures will be there later today.

Indeed, all green so far.

I only remember one particular time (without any references whatsoever
because I'm not a memory guy) where we had to wait for a few iterations
since build failures were getting fixed… and other discovered, so it
took a few days, maybe weeks.


Anyway, back to the topic: Great, let's keep current practice. Of
course, it totally makes sense to jump the gun in some cases. What I
initially thought was that arm* folks were interested in recent fixes in
latest linux (this seems usual because well arm*…), and it seemed odd to
bump the version to depend on a linux version… that wasn't built. :)


KiBi.


signature.asc
Description: Digital signature

Limited involvement for a time

[Cyril Brulebois]

Hi,

Just to let you know: given heavy workload and given recent events at
home, I won't be spending the usual amount of time on Debian things
(d-i related or not), for a time.

Linux 4.4 only reached unstable a few days ago, and will probably need
a little time to mature there, so it's not like we're looking at a d-i
release right now anyway; there's also no block-udeb in place, so the
release team shouldn't have anything blocking on me.

I don't have any schedule yet, but I suspect things might get better
somewhen during March. No promises though.

Take care, everyone.


KiBi.


signature.asc
Description: Digital signature

Bug#815187: Bug debian-Installer jessie: Installation grub fails without error message

[Cyril Brulebois]

Hi François,

François POLASTRON  (2016-02-19):
> package: Debian-Installer
> Version: 20150422+deb8u3 
> 
> Dear Maintener,
> 
> I found a big bug in debian-Installer on a "BIOS Legacy" computer
> When trying to force grub installation in other device than primary disk, in 
> graphical mode the menu lets the user choose the device:
> /dev/sda
> /dev/sdb
> ...
> But when we choose one of a device debian-Installer don't install GRUB 
> WITHOUT 
> ERROR MESSAGE. 

This seems very strange to me. Any chance you have access to this computer
anyway, and can share the installer logs containing the failed attempt?
(/var/log/installer/syslog notably.)

> In fact we must enter the device with the keyboard taping "/dev/sda"... to 
> contourn the bug. 

(contourner = to work around)

> Excuse-me for my english language. I'm a french guy

Don't worry, we've seen worse messages. ;)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#679334: debian-installer: now in alpha3 system total freeze

[Martin Michlmayr]

* BasaBuru  [2016-02-18 21:46]:
> > basaburu, can you confirm things are working for you?
> 
> Yes, At last upgrade it's resolve

Ok, that's good.  Unfortunately, I cannot tell how BasaBuru's issue
relates to the one reported by KiBi originally, so I suggest KiBi
closes this bug if it's indeed fixed.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#679334: debian-installer: now in alpha3 system total freeze

[BasaBuru]

El Martes, 16 de febrero de 2016 20:40:51 usted escribió:
> * Steve McIntyre  [2015-10-28 21:44]:
> > >The bug is now more big, is not a minor bug
> > >
> > >The system is freeze when start.
> > >
> > >In my opinion the debian installer team need kill the bug NOW
> > >
> > >The newie users are very lost
> > 
> > We believe it's fixed in alpha 4 that was just released at the weekend
> > - please try that and see if if helps?
> 
> basaburu, can you confirm things are working for you?

Yes, At last upgrade it's resolve

-- 
Agur bero bat / a greeting

BasaBuru

  BASATU 

~  
basatia bihur zaitez
~

gako ID gnupg: F9044F8FC64B2544
hatz-aztarna: 13FF 7B28 D999 B957 F837 D566 F904 4F8F C64B 2544

Re: commit "Bump Linux kernel version from 4.3.0-1 to 4.4.0-1"

[Martin Michlmayr]

* Cyril Brulebois  [2016-02-19 11:07]:
> Until now I've been waiting for linux to be built everywhere to flip
> the switch. I'm fine with revisiting how we do things but I think it
> should be discussed somehow.

I agree with you (unless there's one arch which takes a long time to
get fixed).

Sorry, I was a little bit trigger happy yesterday.  I thought breaking
some builds for a day or two wouldn't be a big problem, but I guess
you're the one receiving all the build errors. ;-)

Anyway, I agree with your policy.  Ben made a new linux upload so
hopefully all architectures will be there later today.

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: D-I status on device tree based armel orion5x/kirkwood Buffalo Linkstation

[Martin Michlmayr]

* Roger Shimizu  [2016-02-20 00:42]:
> Another thing I want to mention is that it still need a command line
> to create RAID1 /boot partition:
>   mdadm --create /dev/md0 --level=1 --raid-devices=2 -e 0 /dev/sda1 missing
> Because partman-md only can create md device with metadata=1.2, which
> cannot be recognized by Linkstation's uboot (ARM bootloader)

I'm not very familiar with partman-md, but if there's no bug about
this yet, you may want to file one.

> I've been working on this for months, since device-tree patch to
> upstream kernel.
> I'm happy that finally those orion5x/kirkwood NAS boxes, which already
> or almost lost support from vendor, can be supported by Debian.
> 
> Thanks for your guiding and support!

Nice work!

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: [RFC] screen/tmux support for network-console

[Martin Michlmayr]

* Roger Shimizu  [2016-02-20 01:00]:
> So I'm wondering whether it's possible to add screen/tmux support.
...
> May it's a silly idea. So here's the RFC to hear other voice.

I often would like to have a second console.  I think it's actually
more a problem for netboot rather than network-console because you can
simply open a second SSH connection with the latter.

On the other hand, it's not clear how d-i can be started within
screen/tmux, but maybe you know.
-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#815187: Bug debian-Installer jessie: Installation grub fails without error message

[François POLASTRON]

package: Debian-Installer
Version: 20150422+deb8u3 

Dear Maintener,

I found a big bug in debian-Installer on a "BIOS Legacy" computer
When trying to force grub installation in other device than primary disk, in 
graphical mode the menu lets the user choose the device:
/dev/sda
/dev/sdb
...
But when we choose one of a device debian-Installer don't install GRUB WITHOUT 
ERROR MESSAGE. 

In fact we must enter the device with the keyboard taping "/dev/sda"... to 
contourn the bug. 

Excuse-me for my english language. I'm a french guy

debootstrap_1.0.79_i386.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 19 Feb 2016 07:23:59 +0100
Source: debootstrap
Binary: debootstrap debootstrap-udeb
Architecture: source all
Version: 1.0.79
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 debootstrap - Bootstrap a basic Debian system
 debootstrap-udeb - Bootstrap the Debian system (udeb)
Closes: 768102
Changes:
 debootstrap (1.0.79) unstable; urgency=medium
 .
   [ Samuel Thibault ]
   * hurd: move setting up dev and servers firmlink to setup_proc stage. Also
 firmlink proc there.  Thanks Gabriele Giacone for all the investigation!
 (Closes: #768102)
Checksums-Sha1:
 0ce6c294a121c7a27ebb06f4b580ffb7832a1170 1812 debootstrap_1.0.79.dsc
 4b7fa44d4535180204aee93680702031ed8c5c6e 64390 debootstrap_1.0.79.tar.gz
 eb87ad740d75f6ba4d4c6c37d9e3d7a0c8cc0317 18862 debootstrap-udeb_1.0.79_all.udeb
 094ff1596f1b73f9499d441340ad5def9b2bcdc4 66138 debootstrap_1.0.79_all.deb
Checksums-Sha256:
 7a0764bbcbf777e6ec9940db6d9d5494f2e30a7d3500cf693d56c0d627096146 1812 
debootstrap_1.0.79.dsc
 11ee0dca0c0e0b5ccb0f80c885f62467c67b90abcbdd7f48dd8ca66af4ec5fc0 64390 
debootstrap_1.0.79.tar.gz
 58c90234a23489bc8c079ac43364aa8807d8224445eebb95290dafc279bd2d32 18862 
debootstrap-udeb_1.0.79_all.udeb
 5139e48966cf557b093142b3c142ef30fcea0f928ced41994745e147b2e4e3d9 66138 
debootstrap_1.0.79_all.deb
Files:
 c8badc354b0808e4f71e26578a8ffcf0 1812 admin extra debootstrap_1.0.79.dsc
 5d2facd22ad3cad32529bf5704aa214b 64390 admin extra debootstrap_1.0.79.tar.gz
 48dae2747db960f5484fe5355678c249 18862 debian-installer extra 
debootstrap-udeb_1.0.79_all.udeb
 8d2b787af1e6a5c89376f2eb784d9f1e 66138 admin extra debootstrap_1.0.79_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWx1bgAAoJEIcvcCxNbiWoK64QAJuwvQNtDfrKjvLaKU26U9GA
9KBzPjvWpGu+XjsMU5pK7fTy0z9eI13N6vVZf0Krp/HLBOxrf0Pp1gYAyrSqlv8p
M/eX3CAsM9Hmg7Ym+CsOsr7d0wqk/IwvzxoIlJmdE6Rpfhw58te97RTBjaZ3W//W
79viqgLamxVIny9P6OvnmyZVElNwaiIvHl9ldThG4MyFd7z8aDxAS8Kou+o38nwL
mzCdajKS3amVrND3lTd6qF6JH+NUmMUNfj5hUCJ/aTDYBSvMQMAqsrS2xyWzk5Gg
LO3NSK0dQPBEyDVOH8ROhGM1Xq5NkDkfReDd13i2tOTnSwmE9yCrWgTR/AqQv8mD
tQbXmbrf8xVGcWu3UqAJdMl0Kd0NBcSmVKQmWNhKaGRbxKsm66mQOMvzoeKqsJWu
BkOxBVIoK8f8MAGwAHpI3gavrUEViA6rMBU1FLsBNhlMkLLPBVvjB0AGzlLX23SP
5rmw8/ohXrYTYK7edmMsL9m5h6iXMrLEpScsBNehoNNJAFY291vewhoBD1DawlZw
LbwfxIhLZZkxsvAlK+qzh6aBt5CbPx0E3SCSl668uo5Q1OyXhT9fNvo1AKt4WLE4
por0tE+LWCYX2Yr+GMaHHg/Isfbl/FpLyEHm6aH9lXt7ac0RR6VLxeK/498gw0KJ
h0k+r+D++fHgQ+9GTUs3
=xt+u
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of debootstrap_1.0.79_i386.changes

[Debian FTP Masters]

debootstrap_1.0.79_i386.changes uploaded successfully to localhost
along with the files:
  debootstrap_1.0.79.dsc
  debootstrap_1.0.79.tar.gz
  debootstrap-udeb_1.0.79_all.udeb
  debootstrap_1.0.79_all.deb

Greetings,

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

Processing of debootstrap_1.0.79_i386.changes

[Debian FTP Masters]

debootstrap_1.0.79_i386.changes uploaded successfully to ftp-master.debian.org
along with the files:
  debootstrap_1.0.79.dsc
  debootstrap_1.0.79.tar.gz
  debootstrap-udeb_1.0.79_all.udeb
  debootstrap_1.0.79_all.deb

Greetings,

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

Bug#768102: marked as done (debootstrap: start bind-mounting /proc on Hurd and add nobindmount variant)

[Debian Bug Tracking System]

Your message dated Fri, 19 Feb 2016 18:05:52 +
with message-id 
and subject line Bug#768102: fixed in debootstrap 1.0.79
has caused the Debian Bug report #768102,
regarding debootstrap: start bind-mounting /proc on Hurd and add nobindmount 
variant
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.)


-- 
768102: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768102
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debootstrap
Version: 1.0.64
Severity: wishlist

Dear Maintainer,

attached patch is pretty hurd-specific:

 - disconnect (orphan) TARGET/proc passive translator and start
   bind-mounting /proc along with /servers and /dev.
 - add "nobindmount" variant to create chroots without bind-mounting
   any filesystem. Main use case is chroot for subhurds [0].

[0] https://www.gnu.org/software/hurd/hurd/subhurd.html

Thanks for considering.

-- 
G..e
diff --git a/debootstrap b/debootstrap
index fef1ab5..9dced1e 100755
--- a/debootstrap
+++ b/debootstrap
@@ -100,7 +100,7 @@ usage()
  archive
   --variant=Xuse variant X of the bootstrap scripts
  (currently supported variants: buildd, fakechroot,
-  scratchbox, minbase)
+  scratchbox, minbase, nobindmount)
   --keyring=Kcheck Release files against keyring K
   --no-check-gpg avoid checking Release file signatures
   --no-resolve-deps  don't try to resolve dependencies automatically
diff --git a/debootstrap.8 b/debootstrap.8
index 2cf44ca..b448089 100644
--- a/debootstrap.8
+++ b/debootstrap.8
@@ -71,13 +71,14 @@ or apt, and that it is far better to specify the entire base system than
 rely on this option.
 With this option set, this behaviour is disabled.
 .IP
-.IP "\fB\-\-variant=minbase|buildd|fakechroot|scratchbox\fP"
+.IP "\fB\-\-variant=minbase|buildd|fakechroot|scratchbox|nobindmount\fP"
 Name of the bootstrap script variant to use.
 Currently, the variants supported are minbase, which only includes
 essential packages and apt; buildd, which installs the build-essential
 packages into
 .IR TARGET ;
-and fakechroot, which installs the packages without root privileges.
+nobindmount, which doesn't bind-mount any filesystem; and fakechroot,
+which installs the packages without root privileges.
 Finally there is variant scratchbox, which is for creating targets
 for scratchbox usage.
 The default, with no \fB\-\-variant=X\fP argument, is to create a base
diff --git a/functions b/functions
index 0d48390..07147c0 100644
--- a/functions
+++ b/functions
@@ -1064,10 +1064,13 @@ setup_devices () {
 
 setup_devices_hurd () {
 	# Use the setup-translators of the hurd package, and firmlink
-	# $TARGET/{dev,servers} to the system ones.
+	# $TARGET/{dev,servers,proc} to the system ones.
 	in_target /usr/lib/hurd/setup-translators -k
-	settrans -a $TARGET/dev /hurd/firmlink /dev
-	settrans -a $TARGET/servers /hurd/firmlink /servers
+	if ! doing_variant nobindmount; then
+		settrans -a $TARGET/dev /hurd/firmlink /dev
+		settrans -a $TARGET/servers /hurd/firmlink /servers
+		settrans -oa $TARGET/proc /hurd/firmlink /proc
+	fi
 }
 
 setup_devices_fakechroot () {
diff --git a/scripts/sid b/scripts/sid
index bf3404f..34089f7 100644
--- a/scripts/sid
+++ b/scripts/sid
@@ -1,7 +1,7 @@
 mirror_style release
 download_style apt
 finddebs_style from-indices
-variants - buildd fakechroot minbase scratchbox
+variants - buildd fakechroot minbase scratchbox nobindmount
 keyring /usr/share/keyrings/debian-archive-keyring.gpg
 
 if doing_variant fakechroot; then
--- End Message ---
--- Begin Message ---
Source: debootstrap
Source-Version: 1.0.79

We believe that the bug you reported is fixed in the latest version of
debootstrap, 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 768...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Perrier  (supplier of updated debootstrap package)

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


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 19 Feb 2016 

Bug#815166: preseed/url: correctly handle IPv6 addresses

[Hendrik Brueckner]

Package: preseed
Version: 1.70
Severity: normal
Tags: d-i patch

Dear maintainer,

trying to fetch a preseed URL using an IPv6 address fails.  For example,
consider the preseed/url setting:
http://[fd00:9:152:48:1822::162:199]/dir/preseed.cfg
which becomes
http://[fd00.example.org:9:152:48:1822::162:199]/dir/preseed.cfg

The problem is that "fd00" is treated as hostname without domain and, thus,
the domain name is appended resulting in "fd00.example.org".  Of course,
this is no longer a valid IPv6 address.

To solve this problem, I added a patch that enhances the auto-install.sh
to detect IPv6 addresses.  I also added few more unit test cases to cover
different URLs with IPv6 addresses with user, password, and port variations:

[...]
ok 11 - ftp with user/password, IPv4, and domain
ok 12 - ftp with user/password, IPv4, and domain and port
ok 13 - http with short IPv6 and domain
ok 14 - http with simple IPv6 and domain
ok 15 - http with IPv6 and domain
ok 16 - http with IPv6, port, and domain
ok 17 - http with user/password, IPv6 and domain
ok 18 - http with user/password, IPv6, port, and domain

Thanks and kind regards,
  Hendrik
>From dbc8bc790c781530954d2b58b0050472bbaef354 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner 
Date: Fri, 19 Feb 2016 11:23:50 +0100
Subject: [PATCH] auto-install: correctly handle IPv6 addresses

The auto-install does not properly detect IPv6 address when they
are specified in an URL.  Typically, the first IPv6 address part
is to be considered as the hostname and, if specified, a domain
name is appended.  For example,

http://[fd00:9:152:48:1822::162:199]/dir/preseed.cfg

becomes

http://[fd00.example.org:9:152:48:1822::162:199]/dir/preseed.cfg

which is no longer a valid IPv6 address.  To solve this problem,
enhance auto-install.sh and test for IPv6 addresses in URLs.
Also added few IPv6 unit test cases.

Signed-off-by: Hendrik Brueckner 
---
 auto-install.sh |5 +++-
 t/01-auto-install.t |   55 +++
 2 files changed, 59 insertions(+), 1 deletions(-)

diff --git a/auto-install.sh b/auto-install.sh
index a1551a1..e38ecf5 100755
--- a/auto-install.sh
+++ b/auto-install.sh
@@ -34,7 +34,10 @@ else
db_get auto-install/defaultroot && dir="$RET"
 fi
 
-if expr $host_port : [^.]*$ >/dev/null; then
+if expr "$host_port" : '^.*\[[:a-fA-F0-9]*\]' > /dev/null; then
+   # IPv6 address with or without port
+   :
+elif expr $host_port : [^.]*$ >/dev/null; then
db_get netcfg/get_domain && domain="$RET"
 
if [ -n "$domain" ] && [ "$domain" != "unassigned-domain" ] && [ 
"$domain" != "unnassigned-domain" ]; then
diff --git a/t/01-auto-install.t b/t/01-auto-install.t
index 10e6945..4822536 100755
--- a/t/01-auto-install.t
+++ b/t/01-auto-install.t
@@ -122,6 +122,61 @@ is(run_test('preseed/url'=>'ftp://foo/preseed.cfg',
'ftp:// is kept'
   );
 
+is(run_test('preseed/url'=>'ftp://user:pass@10.11.12.13/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=ftp://user:pass@10.11.12.13/foo/preseed.cfg',
+'ftp with user/password, IPv4, and domain'
+  );
+
+is(run_test('preseed/url'=>'ftp://user:pass@10.11.12.13:8080/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=ftp://user:pass@10.11.12.13:8080/foo/preseed.cfg',
+'ftp with user/password, IPv4, and domain and port'
+  );
+
+is(run_test('preseed/url'=>'http://[fe80::5054:ff:fe23:8018]/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=http://[fe80::5054:ff:fe23:8018]/foo/preseed.cfg',
+'http with short IPv6 and domain'
+  );
+
+is(run_test('preseed/url'=>'http://[::1]/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=http://[::1]/foo/preseed.cfg',
+'http with simple IPv6 and domain'
+  );
+is(run_test('preseed/url'=>'http://[fd00:9:152:48:1822::162:199]/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+'preseed/url=http://[fd00:9:152:48:1822::162:199]/foo/preseed.cfg',
+'http with IPv6 and domain'
+  );
+
+is(run_test('preseed/url'=>'http://[fd00:9:152:48:1822::162:199]:8080/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+
'preseed/url=http://[fd00:9:152:48:1822::162:199]:8080/foo/preseed.cfg',
+'http with IPv6, port, and domain'
+  );
+
+is(run_test('preseed/url'=>'http://user:pass@[fd00:9:152:48:1822::162:199]/foo/preseed.cfg',
+   'netcfg/get_domain' => 'example.org',
+  ),
+
'preseed/url=http://user:pass@[fd00:9:152:48:1822::162:199]/foo/preseed.cfg',
+'http with user/password, IPv6 and domain'
+  );
+

[RFC] screen/tmux support for network-console

[Roger Shimizu]

Dear Martin and D-I Maintainer,

I have a new idea on d-i/network-console: multi-console support (screen/tmux).

For d-i on normal PC, we can simply press alt-F2 to get a console
almost anytime during install, but it's not easy for current
network-console if there's no serial console.
So I'm wondering whether it's possible to add screen/tmux support.

But I have a few questions listed below:
- do I need to patch screen/tmux first to support udeb, and wait for
the udeb to hid unstable?
- is screen/tmux's deb is okay for local build of debian-installer image?
- I want to keep "network-console" and add a new type such as
"network-multiconsole", since there's already size issue on orion5x
qnap devices. But how do it? Do I need to fork network-console.git
repo?

May it's a silly idea. So here's the RFC to hear other voice.
Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#815164: check-missing-firmware can't mount fat32

[Laurent COOPER]

Package: debian-installer
Version: 20150422+deb8u3

What I've done :

for installing firmware (for wireless card), I put the on a USB stick
nowadays, the vast majority of USB stick is formatted FAT32, wich is
almost read by all OS

What was expected :
check-missing-firmware should have loaded the missing firmware

What happened :
Nothing

I managed the problem by using an old small key and formatting this key
in FAT

FAT32 support should be used by check-missing-firmware

D-I status on device tree based armel orion5x/kirkwood Buffalo Linkstation

[Roger Shimizu]

Dear Cryril, Martin, Iwamatsu-san,

I'm happy to inform you that I confirmed 2/19 daily d-i
network-console images are working fine on device tree based armel
orion5x/kirkwood Buffalo Linkstation devices.

I tried the following two devices:
- Linkstation LS-WTGL (orion5x with 64M memory)
- Linkstation LS-WVL (kirkwood with 256M memory)

It's worth mention that even the device with 64M memory can still run
d-i, though I tried a few times only once can really finish the
installation. (For the device with 256M memory, I didn't met much
problem.)

Another thing I want to mention is that it still need a command line
to create RAID1 /boot partition:
  mdadm --create /dev/md0 --level=1 --raid-devices=2 -e 0 /dev/sda1 missing
Because partman-md only can create md device with metadata=1.2, which
cannot be recognized by Linkstation's uboot (ARM bootloader)

Except two tested ones, other Linkstation devices should be supported includes:
- originally supported LS-GL(Pro/Live) / LS-WSGL(Mini) / LS-CHLv2 / LS-XHL
- newly added by me: LS-VL / LS-WSXL / LS-WXL

I've been working on this for months, since device-tree patch to
upstream kernel.
I'm happy that finally those orion5x/kirkwood NAS boxes, which already
or almost lost support from vendor, can be supported by Debian.

Thanks for your guiding and support!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#757861: confirming the bug

[Laurent COOPER]

Hello.

I can confirm the bug

Trying to netinstall on a HP Pavillion with the ipw2200 firmware.

The firmware loads well (once I put it on a FAT usb key, FAT32 doesn't work)

The WPA dialog box open, I can enter the SSID and the pass. But I get
bacjk to the auth page infinitly

Moving the network to WEP works.

So this is a wpa specific problem

Hope this reports helps

If there are any thing I can do to help improve

Laurent

Bug#815159: debian-installer: allow to specify UID/GID before any user is created (via preseed)

[Sandro Tosi]

Package: debian-installer
Severity: wishlist
Tags: d-i

Hello,
we have users and groups which evolved from an old systems, and now their
UIDs/GIDs are conflicting with the Debian default ones (as defined in
/etc/adduser.conf)

Given the debian packages users creation starts as early as during the
installation (for example, systemd users), it would be great if we could specify
FIRST/LAST_SYSTEM_UID/GID via preseed, so that we can specify a range not
conflicting with the internal ones.

There is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640651 where
something similar was asked to 'adduser' maints, but indeed this is better done
in the installation phase, hence this report (and the reason I'm CCing all those
who replied in #640651 to this report).

Thanks,
Sandro

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#815155: Detects impossible situation as bootable option

[Wouter Verhelst]

Package: os-prober
Version: 1.71
Severity: normal

Hi,

I have a backup of the Windows installation of an old laptop on an LVM
volume on a USB disk. This backup was taken by doing something along the
lines of "dd if= of=". Obviously this can
never boot; Windows doesn't support LVM.

However, when I have the USB disk in question connected to my laptop
when I perform a kernel update, os-prober detects that Windows
installation, resulting in a boot option for that Windows installation,
which obviously cannot work.

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages os-prober depends on:
ii  libc6  2.21-9

os-prober recommends no packages.

os-prober suggests no packages.

-- debconf information excluded

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "nl_BE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Processed: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> clone 751955 -1
Bug #751955 [console-setup] initramfs-tools: Warning: error while trying to 
store keymap file - ignoring request to install /etc/boottime.kmap.gz
Bug 751955 cloned as bug 815154
> reassign -1 gnome-control-center
Bug #815154 [console-setup] initramfs-tools: Warning: error while trying to 
store keymap file - ignoring request to install /etc/boottime.kmap.gz
Bug reassigned from package 'console-setup' to 'gnome-control-center'.
No longer marked as found in versions console-setup/1.134.
Ignoring request to alter fixed versions of bug #815154 to the same values 
previously set
> retitle -1 Removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard
Bug #815154 [gnome-control-center] initramfs-tools: Warning: error while trying 
to store keymap file - ignoring request to install /etc/boottime.kmap.gz
Changed Bug title to 'Removes XKBMODEL and XKBOPTIONS from 
/etc/default/keyboard' from 'initramfs-tools: Warning: error while trying to 
store keymap file - ignoring request to install /etc/boottime.kmap.gz'
> severity -1 serious
Bug #815154 [gnome-control-center] Removes XKBMODEL and XKBOPTIONS from 
/etc/default/keyboard
Severity set to 'serious' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
751955: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751955
815154: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815154
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#751955: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard

[Anton Zinoviev]

clone 751955 -1
reassign -1 gnome-control-center
retitle -1 Removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard
severity -1 serious
thanks

Hello,

I can confirm that gnome-control-center removes XKBMODEL from 
/etc/default/keyboard.  Steps to reproduce:

1. $ grep -q XKBMODEL /etc/default/keyboard && echo fine || echo broken
   -> fine
2. $ gnome-control-center
3. Go to "Region & Language"
4. Go to "Login Screen"
5. In the "Input Sources" section add some random keyboard layout
6. $ grep -q XKBMODEL /etc/default/keyboard && echo fine || echo broken
   -> broken

The test is done on a regular Jessie system.  The version of 
gnome-control-center 
is 1:3.14.2-3.

By the way, I was very surprised to find that gnome-control-center modifies a 
configuration file belonging to other package.  This is not something Debian 
policy permits.  Nevertheless, we do want the keyboard configuration to be user 
friendly, so I approve what gnome-control-center does, as long as it does it 
correctly. :)

By the way, I've found that gnome-control-centers doesn't remove the variables 
it 
doesn't understand.  Therefore, it seems the reason it removes XKBOPTIONS and 
XKBMODEL is that it tries to do something with these variables.

Anton Zinoviev

commit "Bump Linux kernel version from 4.3.0-1 to 4.4.0-1"

[Cyril Brulebois]

Hi,

I'm not sure how much we want to speed up syncing build/config/common
with whatever new ABI linux is uploaded with. As far as testing the
new kernel, that might looks like a good idea; but I'm not sure it
really helps if it triggers daily build failures because the linux
kernel is obviously missing builds (be it because mips* are slow, or
because arm* have FTBFSed).

Until now I've been waiting for linux to be built everywhere to flip
the switch. I'm fine with revisiting how we do things but I think it
should be discussed somehow.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#760993: console-setup: CHARMAP no longer set properly

[Anton Zinoviev]

On Thu, Feb 18, 2016 at 08:10:54PM +0100, Kurt Roeckx wrote:
> On Thu, Feb 18, 2016 at 06:16:26PM +0200, Anton Zinoviev wrote:
> > On Tue, Sep 09, 2014 at 08:18:01PM +0200, Kurt Roeckx wrote:
> > > Package: console-setup
> > > Version: 1.111
> > > Severity: important
> > > 
> > > In /etc/default/console-setup I have:
> > > CHARMAP="ISO-8859-1"
> > > 
> > > However, my console acts like it's in UTF-8 mode.
> > > 
> > > If I restart the console-setup service it does get properly set,
> > > so I'm guessing something else is overriding it.
> > 
> > Hello!
> > 
> > Do you remember if this system used systemd?
> > 
> > Did you use the standard the QWERTY layout?  I mean is it possible that 
> > the console was leaved unconfigured (not only the charmap, but also the 
> > keyboard) and the only reason you didn't notice this was that you used 
> > QWERTY layout?
> 
> I have no idea on which system this was.  At least on this one I
> don't have console-setup installed, and I think it's currently the
> only one without systemd.  I'm going to guess it was on this one
> anyway.
> 
> All my systems are using qwerty.  I might also have configured it
> to not touch the font.

It is a known bug that very often console-setup doesn't configure the console 
during the boot if the system is using systemd.  This bug is going to be fixed 
in 
a next release, so I asked you this question in order fo find out if the same 
fix 
is going to fix the bug you reported as well.

On one hand, you use qwerty layout and (sometimes) the system font.  This means 
if the bug was observed on a system with systemd then it seems very likely that 
the bug you reported is identical with the bug "console-setup doesn't configure 
the console on boot with systemd".  In this case we will be able to close both 
bugs.

On the other hand, you suspect that the bug was observed on the system you used 
to write your last email message.  You say that currently console-setup is not 
installed on this system.  Unfortunately, your original bug report doesn't 
contain information whether console-setup was installed at the time you 
reported 
the bug, or not.  If console-setup was not installed, then the symptoms you 
reported are expected even if keyboard-configuration was installed.

So, what do you prefer we do with this bug?

Anton Zinoviev