debian-installer-utils_1.127_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 12 Feb 2018 18:47:47 +0100
Source: debian-installer-utils
Binary: di-utils-shell di-utils-reboot di-utils-exit-installer di-utils 
di-utils-mapdevfs di-utils-terminfo
Architecture: source
Version: 1.127
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 di-utils   - Miscellaneous utilities for the debian installer (udeb)
 di-utils-exit-installer - Exit installer (udeb)
 di-utils-mapdevfs - mapdevfs utility for the debian installer (udeb)
 di-utils-reboot - Reboot (udeb)
 di-utils-shell - Execute a shell (udeb)
 di-utils-terminfo - Terminfo entries needed by newt/slang in debian installer 
(udeb)
Changes:
 debian-installer-utils (1.127) unstable; urgency=medium
 .
   [ Updated translations ]
   * Hebrew (he.po) by Yaron Shahrabani
   * Serbian (sr.po) by Слободан Симић(Slobodan Simić)
   * Tajik (tg.po) by Victor Ibragimov
Checksums-Sha1:
 3e2b419a5e974ecaf8610513fd4d04c9ce73d0ba 2234 debian-installer-utils_1.127.dsc
 de74aa409b13412bc1287565da09390a9fd328e4 98816 
debian-installer-utils_1.127.tar.xz
Checksums-Sha256:
 aadf993b5ce7a910721038720db7c4b40882b0c7f1c89d7c53bc2086c772a49b 2234 
debian-installer-utils_1.127.dsc
 4b6d6af18c63f9389e2cff4ff7cf82de93ebdc43c1beb34ad06dd0f701a283c3 98816 
debian-installer-utils_1.127.tar.xz
Files:
 6922e90e44ddb1cec514975430de6b42 2234 debian-installer standard 
debian-installer-utils_1.127.dsc
 2d9230cc8d3fe00d48b5febeb6ad6530 98816 debian-installer standard 
debian-installer-utils_1.127.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE1cL5v8oSi7oip3IYhy9wLE1uJagFAlqCdRsACgkQhy9wLE1u
JahtghAAhXYRJTktOfKWRyP/0irxsrfuvWHjmN0eF5kLz9hcW0fdATz15FtgGdCc
uzwR5bAQUStpkhd4a/0ACsNnSMCa8P9DiFipxh5R3qEeBTjkys6jop9lw7gSas8e
72vYuCg2GBe/vDSWVlhzCIscUTVddSiwqKaQCru8rwbE4L2MapVxaNp8m2UzKmIm
3aHb3LfKSXCSg7bTnaZhn+0NlWHxIjTO9zV1378DOLhYuvwLDa0TCUwKfZTxgP/z
M71DKknT0LoiU2T8k3LhJbBlAEkx+x7Vh42kyTgwcCJqrwiJn4aSV1ueHTjlzHa6
bg+4c9nA8+PKWt0hibkx2YNMcsEVRfM6wtimX8IkJ3OdL/a2P3ZH+kAaP0/Ha+vZ
y/7yc60XteWuMYzsN51CrIpfACpaVuTiWiBxwgIIgH0h9S39mcZ1M5STRb8p+GEJ
LOoMX4ugqF6avshW8Dno/H/wrZNGthAyO/pbEk6j2nJBwVc6DcV6shjtwLHQJH/n
duxj8P8UDEfV4/+Qm0hAcsiCPHtTtlObpE2oT4tt5ChNhnUhHK8YNG6JhGYhuHvV
jmyo1LX57KU/U8rWMGlZkG+6N88RphFpn20YRAtI9V2IzBhXOcFUnFP312XoKX/L
dwqHCKEINUoVfYPZeTOVUeFHJHDPlTI0IfDeh1CxIHbVZll3Kso=
=eL1u
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of debian-installer-utils_1.127_source.changes

[Debian FTP Masters]

debian-installer-utils_1.127_source.changes uploaded successfully to localhost
along with the files:
  debian-installer-utils_1.127.dsc
  debian-installer-utils_1.127.tar.xz

Greetings,

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

Accepted debian-installer-utils 1.127 (source) into unstable

[Christian Perrier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 12 Feb 2018 18:47:47 +0100
Source: debian-installer-utils
Binary: di-utils-shell di-utils-reboot di-utils-exit-installer di-utils 
di-utils-mapdevfs di-utils-terminfo
Architecture: source
Version: 1.127
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 di-utils   - Miscellaneous utilities for the debian installer (udeb)
 di-utils-exit-installer - Exit installer (udeb)
 di-utils-mapdevfs - mapdevfs utility for the debian installer (udeb)
 di-utils-reboot - Reboot (udeb)
 di-utils-shell - Execute a shell (udeb)
 di-utils-terminfo - Terminfo entries needed by newt/slang in debian installer 
(udeb)
Changes:
 debian-installer-utils (1.127) unstable; urgency=medium
 .
   [ Updated translations ]
   * Hebrew (he.po) by Yaron Shahrabani
   * Serbian (sr.po) by Слободан Симић(Slobodan Simić)
   * Tajik (tg.po) by Victor Ibragimov
Checksums-Sha1:
 3e2b419a5e974ecaf8610513fd4d04c9ce73d0ba 2234 debian-installer-utils_1.127.dsc
 de74aa409b13412bc1287565da09390a9fd328e4 98816 
debian-installer-utils_1.127.tar.xz
Checksums-Sha256:
 aadf993b5ce7a910721038720db7c4b40882b0c7f1c89d7c53bc2086c772a49b 2234 
debian-installer-utils_1.127.dsc
 4b6d6af18c63f9389e2cff4ff7cf82de93ebdc43c1beb34ad06dd0f701a283c3 98816 
debian-installer-utils_1.127.tar.xz
Files:
 6922e90e44ddb1cec514975430de6b42 2234 debian-installer standard 
debian-installer-utils_1.127.dsc
 2d9230cc8d3fe00d48b5febeb6ad6530 98816 debian-installer standard 
debian-installer-utils_1.127.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE1cL5v8oSi7oip3IYhy9wLE1uJagFAlqCdRsACgkQhy9wLE1u
JahtghAAhXYRJTktOfKWRyP/0irxsrfuvWHjmN0eF5kLz9hcW0fdATz15FtgGdCc
uzwR5bAQUStpkhd4a/0ACsNnSMCa8P9DiFipxh5R3qEeBTjkys6jop9lw7gSas8e
72vYuCg2GBe/vDSWVlhzCIscUTVddSiwqKaQCru8rwbE4L2MapVxaNp8m2UzKmIm
3aHb3LfKSXCSg7bTnaZhn+0NlWHxIjTO9zV1378DOLhYuvwLDa0TCUwKfZTxgP/z
M71DKknT0LoiU2T8k3LhJbBlAEkx+x7Vh42kyTgwcCJqrwiJn4aSV1ueHTjlzHa6
bg+4c9nA8+PKWt0hibkx2YNMcsEVRfM6wtimX8IkJ3OdL/a2P3ZH+kAaP0/Ha+vZ
y/7yc60XteWuMYzsN51CrIpfACpaVuTiWiBxwgIIgH0h9S39mcZ1M5STRb8p+GEJ
LOoMX4ugqF6avshW8Dno/H/wrZNGthAyO/pbEk6j2nJBwVc6DcV6shjtwLHQJH/n
duxj8P8UDEfV4/+Qm0hAcsiCPHtTtlObpE2oT4tt5ChNhnUhHK8YNG6JhGYhuHvV
jmyo1LX57KU/U8rWMGlZkG+6N88RphFpn20YRAtI9V2IzBhXOcFUnFP312XoKX/L
dwqHCKEINUoVfYPZeTOVUeFHJHDPlTI0IfDeh1CxIHbVZll3Kso=
=eL1u
-END PGP SIGNATURE-

Processed: Re: Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Debian Bug Tracking System]

Processing control commands:

> tag -1 - moreinfo
Bug #890262 [flash-kernel] flash-kernel: QNAP TS109, Not enough space for 
initrd in MTD
Removed tag(s) moreinfo.

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

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Ben Hutchings]

Control: tag -1 - moreinfo

On Mon, 2018-02-12 at 22:24 +0100, Gunnar Thorburn wrote:
> Hi,
> 
> Creating this file with COMPRESS=xz worked fine
> /etc/initramfs-tools/conf.d/compress
> 
> Obviously, with xz there is plenty of space left. There was a little
> warning though (see below).
> 
> Generating kernel u-boot image... done.
> Flashing kernel (using 2050440/2097152 bytes)... done.
> Flashing initramfs (using 2870792/4194304 bytes)... done.
> W: APT had planned for dpkg to do more than it reported back (0 vs 7).
>Affected packages: flash-kernel:armel initramfs-tools:armel
> 
> 
> Yes, this system has been upgraded several time. I think your web page
> even said that that is the correct/only way to do it.
> 
> I guess installing Stretch does COMPRESS=xz on its own.
> 
> Thank you so much. My problem is now solved. But perhaps xz could be
> part of the upgrade process.

It seems to me that there are two bugs:

1. flash-kernel gave a useless hint to use MODULES=dep, when that was
already the current configuration.

2. It didn't give the useful hint to use COMPRESS=xz, or make that
configuration change itself.

Now that I think about it, initramfs-tools does allow other packages to
override the configuration for mkinitramfs through shell scripts in
/usr/share/initramfs-tools/conf-hooks.d.  This seems like a good reason
to do that.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



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

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Gunnar Thorburn]

Hi,

Creating this file with COMPRESS=xz worked fine
/etc/initramfs-tools/conf.d/compress

Obviously, with xz there is plenty of space left. There was a little
warning though (see below).

Generating kernel u-boot image... done.
Flashing kernel (using 2050440/2097152 bytes)... done.
Flashing initramfs (using 2870792/4194304 bytes)... done.
W: APT had planned for dpkg to do more than it reported back (0 vs 7).
   Affected packages: flash-kernel:armel initramfs-tools:armel


Yes, this system has been upgraded several time. I think your web page
even said that that is the correct/only way to do it.

I guess installing Stretch does COMPRESS=xz on its own.

Thank you so much. My problem is now solved. But perhaps xz could be
part of the upgrade process.

On 12 February 2018 at 22:05, Gunnar Thorburn  wrote:
> Hi Martin,
>
> I sincerely apologize for setting the wrong severity to the wrong
> package in the original report.
> (I thought the system could be in a state where it would not reboot at all)
>
> I am sorry to inform you that changing to MODULES=dep in
> initramfs.conf did not help.
> (driver-policy already had MODULES=dep).
>
> And no, I am not using LVM or RAID (just a standard ext2-partitions
> for /, /boot, /home/ and one for swap on a single SATA drive).
>
> The good thing is that the system reboots properly and seems to work
> fine with the old 3.16 kernel.
>
> There is no
> /etc/initramfs-tools/conf.d/compress
>
> I will try it out and get back.
>
> Thank you very much!
>
>
>
>
>
> On 12 February 2018 at 21:57, Martin Michlmayr  wrote:
>> Unfortunately my memory is quite bad.  I *thought* the current
>> installer configured XZ compression by default but it seems that's not
>> the case.  So the documentation on my web site is correct.
>>
>> * The installer sets MODULES=dep
>> * It has done so for a long time
>> * But you've upgraded from a really old release where this wasn't the case 
>> (I believe)
>>
>> * The installer doesn't configure XZ compression
>> * You don't need it for a normal installation
>> * If you want LVM or RAID, you have to use XZ, as per the hint at 
>> http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
>>
>> At least I *believe* that's the case.  I didn't investigate in detail.
>>
>> --
>> Martin Michlmayr
>> http://www.cyrius.com/

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Gunnar Thorburn]

Hi Martin,

I sincerely apologize for setting the wrong severity to the wrong
package in the original report.
(I thought the system could be in a state where it would not reboot at all)

I am sorry to inform you that changing to MODULES=dep in
initramfs.conf did not help.
(driver-policy already had MODULES=dep).

And no, I am not using LVM or RAID (just a standard ext2-partitions
for /, /boot, /home/ and one for swap on a single SATA drive).

The good thing is that the system reboots properly and seems to work
fine with the old 3.16 kernel.

There is no
/etc/initramfs-tools/conf.d/compress

I will try it out and get back.

Thank you very much!





On 12 February 2018 at 21:57, Martin Michlmayr  wrote:
> Unfortunately my memory is quite bad.  I *thought* the current
> installer configured XZ compression by default but it seems that's not
> the case.  So the documentation on my web site is correct.
>
> * The installer sets MODULES=dep
> * It has done so for a long time
> * But you've upgraded from a really old release where this wasn't the case (I 
> believe)
>
> * The installer doesn't configure XZ compression
> * You don't need it for a normal installation
> * If you want LVM or RAID, you have to use XZ, as per the hint at 
> http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
>
> At least I *believe* that's the case.  I didn't investigate in detail.
>
> --
> Martin Michlmayr
> http://www.cyrius.com/

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Martin Michlmayr]

Unfortunately my memory is quite bad.  I *thought* the current
installer configured XZ compression by default but it seems that's not
the case.  So the documentation on my web site is correct.

* The installer sets MODULES=dep
* It has done so for a long time
* But you've upgraded from a really old release where this wasn't the case (I 
believe)

* The installer doesn't configure XZ compression
* You don't need it for a normal installation
* If you want LVM or RAID, you have to use XZ, as per the hint at 
http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/

At least I *believe* that's the case.  I didn't investigate in detail.

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

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Martin Michlmayr]

The other thing you can do is to enable XZ compression:
http://www.cyrius.com/debian/orion/qnap/ts-109/troubleshooting/#bootable

I thought this was documented in the release notes but I can't find
it.

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

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Martin Michlmayr]

* Gunnar Thorburn  [2018-02-12 17:52]:
> The initial ramdisk is too large. This is often due to the unnecessary 
> inclusion
> of all kernel modules in the image. To fix this set MODULES=dep in one or both
> /etc/initramfs-tools/conf.d/driver-policy (if it exists) and

> Not enough space for initrd in MTD 'RootFS1' (need 4210887 but is
> actually 4194304).

Please check the various initramfs-tools configuration files to see if
you're using MODULES=dep.  Changing to MODULES=dep would be the fix.
However, given the size of your ramdisk, I fear you are already using
MODULES=dep.

Are you using RAID or LVM?  Unfortunately, since the MTD partition for
the ramdisk is very tiny on the TS-x09, you cannot use RAID or LVM.
(And this was possible in the past, which will lead to problems with
upgrades.)

> But given that TS-109 appears supported
>   http://www.cyrius.com/debian/orion/qnap/ts-109/install/
> and with no major issues
>   http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
> I would not expect this problem well into the upgrade.

I have to document the LVM/RAID issue.  In fact, the installation page
currently says "You can use LVM and RAID and a number of filesystems",
which is definitely no longer true to due to the size issue (even with
MODULES=dep).

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

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Mon, 2018-02-12 at 17:52 +0100, Gunnar Thorburn wrote:
[...]
> I have not tried editing
>   /etc/initramfs-tools/initramfs.conf
> 
> I suppose i could try to change MODULES=most to MODULES=dep.
[...]

This is definitely not a critical bug in flash-kernel.  It even told
you how to fix the problem.  (It is not allowed for a package to
directly modify configuration files belonging to another package.)

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.



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

Processed: Re: Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #890262 [flash-kernel] flash-kernel: QNAP TS109, Not enough space for 
initrd in MTD
Severity set to 'important' from 'critical'
> tag -1 moreinfo
Bug #890262 [flash-kernel] flash-kernel: QNAP TS109, Not enough space for 
initrd in MTD
Added tag(s) moreinfo.

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

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Gunnar Thorburn]

Package: flash-kernel
Version: 3.79
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I have been running Debian on a QNAP TS109 for many years.
I successfully upgraded from Squeeze to Wheezy in 2013 and to Jessie in 2015.

As I now upgrade to Stretch (basically following Debian Upgrade Guide, it
is a very simple system) I now get:

== from apt-get dist-upgrade ==
update-initramfs: Generating /boot/initrd.img-4.9.0-5-marvell
flash-kernel: installing version 4.9.0-5-marvell

The initial ramdisk is too large. This is often due to the unnecessary inclusion
of all kernel modules in the image. To fix this set MODULES=dep in one or both
/etc/initramfs-tools/conf.d/driver-policy (if it exists) and
/etc/initramfs-tools/initramfs.conf and then run 'update-initramfs -u
-k 4.9.0-5-marvell'

Not enough space for initrd in MTD 'RootFS1' (need 4210887 but is
actually 4194304).
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
dpkg: error processing package initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
== end of output

That was (obviously) after
 - editing /etc/apt/sources.list (changing jessie to stretch)
 - apt-get update
 - apt-get upgrade

I am completely aware how old and obsolete this QNAP TS109 is.
It would make complete sense to me if it was not supported anymore.
And I would completely understand if you dont want to fix this problem.

But given that TS-109 appears supported
  http://www.cyrius.com/debian/orion/qnap/ts-109/install/
and with no major issues
  http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
I would not expect this problem well into the upgrade.

To other users, it would be helpful to advice them not to upgrade to Stretch.

I guess my system would reboot if I try (but I have not tried)
I guess Debain 9.3 can run with Linux 3.16.0-5-orion5x from Debian 8, but
to me (I have used Debian for 20 years) the system seems to be in a rather
bad state. (if it fails to boot a serial cable for direct UBOOT is necessary)

I have not tried editing
  /etc/initramfs-tools/initramfs.conf

I suppose i could try to change MODULES=most to MODULES=dep.

However, if I break the system completely it will be much harder for me
to give you any more useful information.


  Best Regards
  Gunnar Thorburn


-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-5-orion5x
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  devio  1.2-1.2+b1
ih  initramfs-tools0.130
ii  linux-base 4.5
ii  mtd-utils  1:2.0.0-1
ii  ucf3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2016.11+dfsg1-4

flash-kernel suggests no packages.

-- debconf information:
  flash-kernel/linux_cmdline: quiet

clock-setup_0.138_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 12 Feb 2018 07:11:28 +0100
Source: clock-setup
Binary: clock-setup
Architecture: source
Version: 0.138
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 clock-setup - set up clock (udeb)
Changes:
 clock-setup (0.138) unstable; urgency=medium
 .
   [ Updated translations ]
   * Hebrew (he.po) by Yaron Shahrabani
   * Tajik (tg.po) by Victor Ibragimov
Checksums-Sha1:
 06d6cfbb70dd5c734c5a2a9419063fa218369fc9 1609 clock-setup_0.138.dsc
 6a31421ec9f234aa9bea516271777b017a74a914 75860 clock-setup_0.138.tar.xz
Checksums-Sha256:
 d422d555db03bf2fdd281fdf52344f4892cdefb90386a78250227125d0ca4e27 1609 
clock-setup_0.138.dsc
 543edaf5fa1e832f722aa6cc2ee4fc9398ce2a4f82ef018b61da0cbf6346de75 75860 
clock-setup_0.138.tar.xz
Files:
 db90b866064afcc75552ec0523cac8c1 1609 debian-installer standard 
clock-setup_0.138.dsc
 3838cae51390f94bbc938448522f369b 75860 debian-installer standard 
clock-setup_0.138.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE1cL5v8oSi7oip3IYhy9wLE1uJagFAlqBm6MACgkQhy9wLE1u
JahKmg//S8woOB32V6gV1KDKwBs5CU7JWFEZkM4xza44HF2lDG3banfD121HIeRY
sDKjz8dxh5KyOVKDf2CWvwxnNLHSMfQTqeFOY0d1cci33Uy7RcBWqJnGzESiUCCi
pmxM4PVmgU+E4QiTAotsnJN25ZHFhvlpqsD1CewZaG7UhBHsABdzXbfVeQ/QjNgw
gvoo0otMeSVyhq9K6ryQBVgF3Q4X9jtqYTz8EvCT+/lE7l2qKcT/fAFTFDixW5sz
wpNjOFhGUOO48kUvjb5LB6IpCBNw53J4bCvnyw1Nja+SmkSIYvcsdS8Ni04ZBKuA
B4Ncg63wGToAcSYkbMJw4//iBbtNWWcMnNs1/E2PFj1bCYszvT7WXHtLd28KwM8U
fWNQ64QGWoB561GjuZlfqLd6ID1fFHGji5PZ2oV6SSYMb2QJMQpIS1LqcTy0/JPU
IWUTek9rW7Z6HpoH/UrJWUCJWNJTLbY4YFdQTlKMJiYxcvsVzULAn44pRFHV5IA9
8Mdef0lXWLlTE6a0QTP3AlD3+eQPjf1yxp8PKY1JgUyv3Exe40PAk8U3ahNrFbjb
BddpRpTaVrBD4gyVA+e+CjnEkTsqWMiI1kwC3jNf2qZ1Fks3pnGZBYbih3/uW6uz
fKmUp3t21P5ejdGrgVJV55AX95YdEoF9zF72qYxv4SuMgWYRxF0=
=BLWq
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Accepted clock-setup 0.138 (source) into unstable

[Christian Perrier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 12 Feb 2018 07:11:28 +0100
Source: clock-setup
Binary: clock-setup
Architecture: source
Version: 0.138
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 clock-setup - set up clock (udeb)
Changes:
 clock-setup (0.138) unstable; urgency=medium
 .
   [ Updated translations ]
   * Hebrew (he.po) by Yaron Shahrabani
   * Tajik (tg.po) by Victor Ibragimov
Checksums-Sha1:
 06d6cfbb70dd5c734c5a2a9419063fa218369fc9 1609 clock-setup_0.138.dsc
 6a31421ec9f234aa9bea516271777b017a74a914 75860 clock-setup_0.138.tar.xz
Checksums-Sha256:
 d422d555db03bf2fdd281fdf52344f4892cdefb90386a78250227125d0ca4e27 1609 
clock-setup_0.138.dsc
 543edaf5fa1e832f722aa6cc2ee4fc9398ce2a4f82ef018b61da0cbf6346de75 75860 
clock-setup_0.138.tar.xz
Files:
 db90b866064afcc75552ec0523cac8c1 1609 debian-installer standard 
clock-setup_0.138.dsc
 3838cae51390f94bbc938448522f369b 75860 debian-installer standard 
clock-setup_0.138.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE1cL5v8oSi7oip3IYhy9wLE1uJagFAlqBm6MACgkQhy9wLE1u
JahKmg//S8woOB32V6gV1KDKwBs5CU7JWFEZkM4xza44HF2lDG3banfD121HIeRY
sDKjz8dxh5KyOVKDf2CWvwxnNLHSMfQTqeFOY0d1cci33Uy7RcBWqJnGzESiUCCi
pmxM4PVmgU+E4QiTAotsnJN25ZHFhvlpqsD1CewZaG7UhBHsABdzXbfVeQ/QjNgw
gvoo0otMeSVyhq9K6ryQBVgF3Q4X9jtqYTz8EvCT+/lE7l2qKcT/fAFTFDixW5sz
wpNjOFhGUOO48kUvjb5LB6IpCBNw53J4bCvnyw1Nja+SmkSIYvcsdS8Ni04ZBKuA
B4Ncg63wGToAcSYkbMJw4//iBbtNWWcMnNs1/E2PFj1bCYszvT7WXHtLd28KwM8U
fWNQ64QGWoB561GjuZlfqLd6ID1fFHGji5PZ2oV6SSYMb2QJMQpIS1LqcTy0/JPU
IWUTek9rW7Z6HpoH/UrJWUCJWNJTLbY4YFdQTlKMJiYxcvsVzULAn44pRFHV5IA9
8Mdef0lXWLlTE6a0QTP3AlD3+eQPjf1yxp8PKY1JgUyv3Exe40PAk8U3ahNrFbjb
BddpRpTaVrBD4gyVA+e+CjnEkTsqWMiI1kwC3jNf2qZ1Fks3pnGZBYbih3/uW6uz
fKmUp3t21P5ejdGrgVJV55AX95YdEoF9zF72qYxv4SuMgWYRxF0=
=BLWq
-END PGP SIGNATURE-

Processing of clock-setup_0.138_source.changes

[Debian FTP Masters]

clock-setup_0.138_source.changes uploaded successfully to localhost
along with the files:
  clock-setup_0.138.dsc
  clock-setup_0.138.tar.xz

Greetings,

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

Re: Scheduling 9.4

[Ansgar Burchardt]

On Sat, 2018-02-10 at 12:27 +0100, Julien Cristau wrote:
> we shipped 9.3 a couple of months ago, so we're overdue for 9.4.
> 
> Can you please let us know your availability on the following:
> - March 3
> - March 10

These don't work for me.

> - March 17
> - March 24
> - March 31

These might work.

Given Steve doesn't have time on the later dates, it might be better to
have another ftpmaster handle the point release on March 3 or 10.

Ansgar

Bug#839046: debootstrap: enable --merged-usr by default

[Ansgar Burchardt]

Guillem Jover writes:
> In any case, I looked the other day into implementing the
> --map-pathname option for dpkg-query, and I've got most of the code
> ready. The problem is that this requires adding support for config
> files and config fragments to dpkg-query, which has the additional
> problem of making it possible to mess with the --showformat option
> and breaking the expectations from maintscripts, for example. The
> other problem is with the search behavior changing depending on the
> packages providing those mappings being installed (because dpkg would
> certainly not provide them).

So who should provide them?  debootstrap?  base-files?

The correct long-term fix is probably for packages to eventually install
to the location in /usr anyway.  That doesn't work without some
transition period of 1-2 releases though.

Ansgar

Bug#839046: debootstrap: enable --merged-usr by default

[Ansgar Burchardt]

Ian Jackson writes:
> Also, I fear that unless we provide a straightforward way to retain
> separate /usr, including an appropriate d-i command line option, we
> will get further pushback and anger from traditionalists.  We risk
> reopening old wounds (see some of the less temperate responses earlier
> in the thread Ansgar links to as [1]).

There were 11 mails in the thread I linked as [1] in my initial mail.
None were really negative, just one person wondering if this means /
and /usr on separate filesystems is no longer supported (even though I
explicitly said it is in my initial mail).

Also, switching to merged-/usr, but still supporting non-merged-/usr
beyond a transition period means one uses one of the benefits for
maintainers no longer having to care where to install libraries or
programs (or worse: having to move them between / and /usr because
someone would like to use some additional program in early boot or a new
upstream release has support for some new feature requiring a library in
/usr).

I assume the less temperate responses are ones as [no argument]?  I
don't believe that one shouldn't base any decisions on less temperate
responses someone makes on the internet.  That way no change ever could
be implemented.  (What happens when I write less temperate responses to
the less temperate responses calling a proposal shit without any
argument?  Do I invalidate their less temperate response too or is that
reserved to the initial less temperate response?)

I strongly prefer technical reasons instead, such as the issue with
`dpkg -S` that was mentioned by Guillem.

  [no argument]: https://lists.debian.org/debian-devel/2016/01/msg5.html

[...]
> Finally, I have to say that I think that this summary from Ansgar
> is not really accurate:

I think that your summary is far less accurate than mine ;-)

>> As mentioned earlier, I would like to see --merged-usr enabled by
>> default for Debian Stretch.  The last discussion on -devel@[1] was
>> quite positive; I had some additional positive feedback on IRC.
> ...
>> [1] 
>
> That is a link to a message from Russ which mostly explains why
> mounting /usr early (ie in the initramfs, by default) is a good idea.
> That has now been implemented and has caused very little push-back.

No, that's a link to a message by me.

> But this bug report requests something entirely different: it is about
> actually moving the contents of /bin into /usr/bin, etc.

That is also what the linked mail is about.

> It is also not fair to say that the discussion was "quite positive".
> There was a good deal of opposition of various kinds, much of it
> quite heated.

Why not?  None of the 11 mails was really negative.

Ansgar