Re: busybox: CONFIG_FEATURE_DI_ENV_HACK: is it still needed?

[Michael Tokarev]

31.12.2023 19:11, Michael Tokarev wrote:

Hi!

There's a debian-specific patch in busybox since 2017 which adds ability
to lift variable name filtering rules for d-i.  A comment in there says:

     This is not a long term fix for this problem: a different approach is
     needed to parse the values from the kernel command-line, but we don't
     want to be responsible for holding up the debian-installer alpha
     release any longer than it has already.

Is it still needed in 2024?


A friendly ping?

Thanks,

/mjt

Bug#1071227: busybox-udeb: provides binaries that are also provided by kmod-udeb (e.g. modprobe)

[Michael Tokarev]

16.05.2024 20:17, Philip Hands пишет:

Package: busybox-udeb
Severity: normal
User: debian-rele...@lists.debian.org

Hi,

I notice that busybox-udeb provides the following binaries in /sbin:

   depmod insmod lsmod modinfo modprobe rmmod

while kmod-udeb provides the same, except located in /usr/sbin.


https://salsa.debian.org/installer-team/busybox/-/commit/a52da181d4cd0e41c04ab1d5be9130270df0f696
#1060134

fwiw.

/mjt
--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Re: udhcpc search domain

[Michael Tokarev]

26.04.2024 13:24, Frédéric Guyot wrote:

After looking at this a bit more closely , it seems that netcfg is calling 
udhcpc with  limited set options. see here:
https://salsa.debian.org/installer-team/netcfg/-/blob/master/dhcp.c#L38 


We would just need to add "search" to this list of options and update the 
/etc/udhcpc/default.default.script as stated previously.


I just committed this change:
https://salsa.debian.org/installer-team/busybox/-/commit/bd0d90574a4e39b39d38b664ad15ac0c2ca1bbad

It's interesting we had no complaints about this so far..

/mjt

--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Re: Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Michael Tokarev]

Ok,

I'm removing whole modutils from busybox udeb (besides depmod, this is
lsmod, insmod, rmmod, and modprobe).  All these are provided by
kmod-udeb as far as I can see (as symlinks to kod).

--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Michael Tokarev]

09.04.2024 16:48, Cyril Brulebois wrote:

Marco d'Itri  (2024-04-09):

Yes. Nowadays kmod has many more features related to compressed modules
and verification of signatures.
Can we agree that kmod should provide these programs for d-i?
Or can the d-i maintainers just tell us what they want?


I meant to come back to this after experimenting, then things happened…

I picked kmod at the time because it worked, and because busybox didn't
work, which I summed up in:
   
https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145

(plus follow-up commit, woopsie
   
https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07
)

I'm fine with sticking to kmod regarding module support in d-i. I'm not
sure we should keep support in two different modules, so dropping it
from busybox would work for me. Others might have different views on
this, though.


So, should I disable module utils in busybox-udeb now?
Wanted to spare some time on busybox, this bug report come in.

Is kmod udeb ready and used in d-i already, or does it need some
prep first?

Thanks,

/mjt

--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Bug#1065463: debootstrap can deal with native dpkg file replacement feature

[Michael Tokarev]

05.03.2024 03:36, Steven Shiau :

Package: debootstrap
Version: 1.0.134
Severity: wishlist

Dear Maintainer,

As mentioned here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065394#28
For the moment on Mar/5/2024 in the Debian Sid repository, libuuid1 "Provides:
libuuid1t64 (= 2.39.3-9)", and an exact version of libuuid1t64 which
is not in repos. libuuid1 and libuuid1t64 have "Replaces:" on each other 
already.
debootstrap should be able to solve the libuuid1t64 dependency by installing 
libuuid1 only.


I think we should not add complexity to debootstrap just to be able to perform a
transition like this once in 20+ years.

/mjt

Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'

[Michael Tokarev]

09.02.2024 17:57, Thorsten Bonow :

dash << 'EOF'    [15:28:53]
if $( (true) 2>/dev/null); then
  echo "42"
fi
EOF
42

which only works in dash because of the added space between the command 
substitution $(...) and the subshell (...).

Does dash think it has to do arithmetic expansion "$((...))"?


Yes, arithmetic, and that's what bash does too.  dash does not understand
space between two closing parens though, ') )'.  And this is logical - if
the opening is "((", use the same matching "))" for closing.

$(( ... )) is arithmetic expression,
$( ( ... ) ) is a subshell.

Everything else is asking for trouble like this.


But what's POSIX take on this?  I couldn't find anything.  Is this a bug in 
dash or in setupcon?


It's a bug in setupcon.

/mjt

Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'

[Michael Tokarev]

09.02.2024 16:58, ca...@allfreemail.net

Package: console-setup
Followup-For: Bug #1063518

Consider making all scripts provided by console-setup shellcheck-clean, there 
are lots of tiny issues that can turn into big issues under the right 
conditions.


Please do not do this. Shellcheck is a huge problem and we had large amount
of bugs due to people trying to apply its suggestions.  It's very difficult
in many cases to spot why shellcheck is wrong (classic is the suggestion to
put $var into double quotes "$var" which breaks badly if $var is supposed to
contain zero or more separate words - this way, even boot scripts has become
buggy leading to system becoming unbootable).

Shellcheck is a very bad tool.

/mjt

Re: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Michael Tokarev]

06.01.2024 11:40, Helmut Grohne:

On Sat, Jan 06, 2024 at 09:01:12AM +0100, Helmut Grohne wrote:

I also recommend to establish QA for all udebs to automatically detect,
report and address such conflicts as they evidently cause undefined
behaviour otherwise. That can be as simple as collecting file lists of
all udebs and comparing them.


This seems like a more generic problem. I downloaded all amd64 udebs and
the following files (normalized to account for aliasing) pose a
conflict:


From this list, only a few utilities are from busybox, namely wget and module
utilities (depmod/insmod/lsmod/modinfo/modprobe/rmmod).

My initial plan - with regular busybox package and with busybox udeb - is to
provide most things in busybox, so that other packages don't need to ship
udeb packages and the whole thing (be it d-i or initrd) is small.

Yes, some utils in busybox aren't as good as regular implementations. For
example, I just found out busybox's xz does not perform compression, only
decompression (-d option is mandatory).  Or #1003757 - missing functionality
in busybox ip.  Still, overall, it is enough for most things.  BTW, it looks
like with compressed kernel modules, busybox m-i-t needs some (albiet minor)
tweaks (it works but kernel produces warnings when busybox tries to load a
module).

Unfortunately this didn't work out for one reason or another.  One of the
reasons is perhaps #921556, where original util does more than needed but
busybox didn't implement the unnecessary functionality.

This needs to be thought about at a more general level. Including initrd
stuff (if we still need it, instead of relying on mkosi-initrd).  I use
my own initrd for a good reason, and this one does not include 2 or even
3 libc as debian does..

/mjt

busybox: CONFIG_FEATURE_DI_ENV_HACK: is it still needed?

[Michael Tokarev]

Hi!

There's a debian-specific patch in busybox since 2017 which adds ability
to lift variable name filtering rules for d-i.  A comment in there says:

This is not a long term fix for this problem: a different approach is
needed to parse the values from the kernel command-line, but we don't
want to be responsible for holding up the debian-installer alpha
release any longer than it has already.

Is it still needed in 2024?

Thanks,

/mjt

Re: Immediate fallouts from the big linux changes, and actions

[Michael Tokarev]

24.12.2023 11:16, Cyril Brulebois :
...

Searching for information about fuse and virtio, I finally noticed this
entry, which probably explains both fuse's “going away” and ditto for
some (but not all) virtio modules:

 * Set CONFIG_VIRTIO_FS and its dependencies to builtin, to allow building
   images that boot directly to rootfs (skipping the initrd)

as it changes:

 -CONFIG_VIRTIO_PCI=m
 +CONFIG_VIRTIO_PCI=y
 -CONFIG_FUSE_FS=m
 +CONFIG_FUSE_FS=y
 -CONFIG_VIRTIO_FS=m
 +CONFIG_VIRTIO_FS=y


Hm. This same argument can be used to include every storage- and 
filesystem-related
module into the kernel.  Why don't we have ahci and sd_mod built-in?  This does
look quite a bit strange to me to include this stuff..

(This commit is not about big linux changes but about small debian changes ;)

/mjt

Bug#1056628: udhcpc: file loss during upgrade due to Multi-Arch: same interacting with /usr-merge

[Michael Tokarev]

24.11.2023 02:27, Helmut Grohne:

Package: udhcpc
Version: 1:1.36.1-6~exp.1
Severity: normal
User: helm...@debian.org
Usertags: dep17p7

Hi Chris,

thanks for sitting down with me and doing this /usr-move. We aimed to be
careful and upload to experimental. Now dumat doesn't like your upload.
I'm trying to figure out why and whether this is an analyzer bug or a
real problem, so please do not move busybox to unstable for the time
bing.

What follows is details that you may skip entirely, but figured I better
write them down for my future self. So dumat figured that udhcpc is
Multi-Arch: same in bookworm and /sbin/udhcpc is a shared file. Then the
experimental package contains /usr/sbin/udhcpc. In theory, this could
result in a loss scenario, because you can install udhcpc for two
architecture in bookworm, ...


Helmut, udhcp is arch-all package.  You can't install two arch-all
packages at the same time..

I think we've been there before.  [/usr]/sbin/udhcpc is just a symlink
to [/usr]/bin/busybox.

/mjt

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Tokarev]

14.11.2023 14:56, Luca Boccassi wrote:

On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev 
wrote:

..


With just dh_installsystemd --no-enable, it is still started.
With dh_installsystemd --no-enable --no-start, it is started
as well, - apparently because initscript is started.  Also,
with --no-enable --no-start, it is not restarted on upgrades
if enabled locally.

After doing several iterations, I decided to abandon this attempt, -
it just does not work, and I've no time to fight with the tools.

If someone has a working recipe for all this madness, please
share a patch for d/rules.

Tagging with "help" for now.


Could you please share a branch or a patch with your attempt? What you
tried should work, but it's hard to say without looking at the
implementation in details.


Sure thing, it is in current busybox master on salsa, here:

https://salsa.debian.org/installer-team/busybox/-/blob/master/debian/rules#L172

with udhcpd.service & udhcpd.init in the same dir.

Thanks,

/mjt

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Tokarev]

Control: tag -1 + help

On Sun, 25 Jun 2023 23:20:24 +0100 bl...@debian.org wrote:

Package: busybox
Severity: important
User: bl...@debian.org
Usertags: missing-systemd-service

Dear Maintainer(s),

busybox has been flagged by Lintian as shipping a sysv-init script
without a corresponding systemd unit file. The default init system in
Debian is systemd, and so far this worked because a transitional
sysv-init-to-unit generator was shipped by systemd. This is in the
process of being deprecated and will be removed by the time Trixie
ships, so the remaining packages that ship init scripts without
systemd units will stop working.

There are various advantages to using native units, for example the
legacy generator cannot tell the different between a oneshot service
and a long running daemon. Also, sanboxing and security features
become available for services. For more information, consult the
systemd documentation:
https://www.freedesktop.org/software/systemd/man/systemd.unit.html

You can find the Lintian warning here:

https://lintian.debian.org/sources/busybox


This site can't be found.  But it's ok.

So in current state, only udhcpd lacks systemd file.  So I tried to
provide one.  The initscript for udhcpd checks for UDHCPD_ENABLED=yes/no
in /etc/default/udhcpd and does nothing if it is not enabled, which
is the default.  Since there's no way in systemd to check for that
(well, there is, with ExecConditional, but it ugly at best), I thought
to ship udhcpd.service not enabled by default.  Except it doesn't
work.

With just dh_installsystemd --no-enable, it is still started.
With dh_installsystemd --no-enable --no-start, it is started
as well, - apparently because initscript is started.  Also,
with --no-enable --no-start, it is not restarted on upgrades
if enabled locally.

After doing several iterations, I decided to abandon this attempt, -
it just does not work, and I've no time to fight with the tools.

If someone has a working recipe for all this madness, please
share a patch for d/rules.

Tagging with "help" for now.

Thanks,

/mjt

Bug#857763: udhcpd: Please set FEATURE_UDHCPD_WRITE_LEASES_EARLY in build config

[Michael Tokarev]

On Tue, 14 Mar 2017 17:25:50 + Sabahattin Gucukoglu  
wrote:

Source: busybox
Version: 1:1.22.0-19
Severity: wishlist

The dumpleases utility would be made more useful on a system with an SSD if 
FEATURE_UDHCPD_WRITE_LEASES_EARLY were set at build time, because then you 
wouldn't need to set a low auto_time (udhcpd.conf option) to get up-to-date 
lease information from an unprivileged account, without having to first send 
a signal to udhcpd from root. Please set this build option.


I guess it's still too much to write leases file on every DHCP ACK, even 6
years after this bug report has been submitted.

What would be useful though, is for dumpleases to send SIGUSR1 to dhcpd
before reading the leases file.  I guess.  Dunno how it would syncronize
though.

/mjt

Bug#1036446: Bug1036446: Please enable udhcpc6

[Michael Tokarev]

Control: tag -1 + pending

On Sun, 21 May 2023 04:11:09 +0200 Ben Hutchings  wrote:

Package: udhcpc
Version: 1:1.35.0-4+b2
Severity: wishlist
Tags: ipv6

Busybox has a DHCPv6 client (udhcpc6) but this is not included
in the Debian packages.

Please enable CONFIG_UDHCPC6 and the dependent features.


This probably needs udhcpc6 package too, similar to udhcpc package.

/mjt

Bug#925545: udhcpd: support for Runit supervision system

[Michael Tokarev]

On Tue, 26 Mar 2019 17:25:09 + Dmitry Bogatov  wrote:


Package: udhcpd
Version: 1:1.30.1-3
Severity: wishlist
Tags: patch
User: ru...@packages.debian.org
Usertags: runscript


Curious - Why are you filing this against udhcpd only,
why not to do it for other packages too?

Also, how runit handles restarts/reloads/shutdowns,
aren't additional scripts needed for this?

/mjt

Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty

[Michael Tokarev]

Hi everyone!

Somehow I missed this whole issue, - I didn't see it until now.
Will adjust my mail filters.

08.08.2023 00:49, Philip Hands wrote:

Steve McIntyre  writes:


On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote:

Hi Michael,

Cyril Brulebois  (2023-06-28):

Control: reassign -1 busybox-udeb 1:1.36.1-3


[…]


With a local build, confirmed -3 is buggy, and that reverting only
busybox-udeb to -1 is sufficient to restore syslog support in the
installer.

Reassigning there; the GRUB thing can be filed separately once we have
actual information via syslog.


A fix would be appreciated, we've got reports piling up about things we
have no logs for.


After weeks with this breakage, I've just uploaded a minimal NMU to
fix it, reverting the syslog changes since -1. I've buit and tested
successfully locally.


It turned out whole syslog thing in busybox is quite broken, - this is
obvious when you see my initial patch which started whole this issue.
Later on upstream did it in a different way which broke whole thing
entirely, which I tried to fix and it seemed to be working locally, I
notified upstream about the breakage and moved on, thinking it's all
set. But obviously it is not.


Thanks -- and I agree, it works :-)

   https://openqa.debian.net/tests/178534/logfile?filename=DI_syslog.txt

As it happens, over the weekend it occurred to me that I might be able
to pave the way to a fix for this bug by coming up with a test for the
failure.

Awkwardly, syslogd wants to open /dev/log and bails out if it's already
in use, so I resorted to (the somewhat disgusting hack of) using podman:


https://salsa.debian.org/philh/busybox/-/commit/2697f7cce81d1a70de202a30e7062dc9f64a94b1

At least it allows syslogd to run well enough to succeed or fail
similarly to the behaviour seen in the bug.


Gosh..


Here it is going wrong with the -3 code:

   https://salsa.debian.org/philh/busybox/-/jobs/4523822#L3963
   (lines 3969-3975, with the last line showing the entire syslog)

and here is an example of it going right:

   https://salsa.debian.org/philh/busybox/-/jobs/4523808#L3668

   Line 3668 here, saying "PASS: syslogd-works" indicates that we
   succeeded in grepping the test string in /var/log/syslog

The difference between these two is simply disabling
CONFIG_FEATURE_REMOTE_LOG, as seen here:

   
https://salsa.debian.org/philh/busybox/-/commit/89c253f75690dd41487b6fd6f9356a1e890a6ac2

I'm not proposing that as a fix, but it does seem to indicate where the
problem may be located. I'm afraid I've failed to work out what's
actually going wrong here (my C's pretty rusty).

BTW At one point I thought I'd narrowed it down to the while loop here:

   
https://salsa.debian.org/philh/busybox/-/commit/328fdfbe43cd8d9e4425c3ee1c68aadfa44ee434

but if that did work, it does no longer. Either I was mistaken about it
having worked earlier (I'm at least 80% sure that's not the case) or
something non-deterministic is going on ... which makes me wonder if the
underlying cause might be something to do with using uninitialised data
somewhere.

Hopefully this will be of some use to those more familiar with the code.


Oh well. So much work for so minor thing.. :(  I'm sorry for missing whole
thing, I'd act right away and fix whole thing in a minutes.

The whole thing is.. well, quite bad.  We identified a few issues, upstream
syslogd is entirely broken now, remote logging isn't that important and it
has just been enabled, - the fix for now is to just disable remote logging
and to revert to the previous-to-breakage situation as is done in the NMU
(remote logging is a niche thing in this context, while it might be useful
for sure - provided it actually works.)  And ping upstream.

The thing is that upstream will most likely fix it in a different way anyway,
as Denys likes to keep it small even if the code becomes barely readable,
and he has a few common practices which he uses when changing anything.

Thank you all for all this huge work.  Adding podman to the tests is.. oh 
well...

/mjt

Re: Changes to the default rsyslog configuration

[Michael Tokarev]

15.06.2023 15:25, Michael Biebl wrote:


# Log anything besides private authentication messages to a single log file
#
*.*;auth,authpriv.none    -/var/log/syslog

#
# Log commonly used facilities to their own log file
#
auth,authpriv.*        /var/log/auth.log
cron.*    -/var/log/cron.log
kern.*    -/var/log/kern.log
mail.*    -/var/log/mail.log
user.*    -/var/log/user.log


There's no daemon.log. Is it because we already have syslog?

Thanks!

/mjt

Re: Changes to the default rsyslog configuration

[Michael Tokarev]

15.06.2023 15:25, Michael Biebl wrote:

Hi providers of system-log-daemon,

when I started packaging rsyslog for Debian I based /etc/rsyslog.conf on what's been in /etc/syslog.conf at that time (as provided by the no longer 
existing sysklogd).


Unfortunately, this also meant, there was a lot of duplication (say mail messages being logged to 4 different files) and no one could explain to me, 
why we had this duplication / particular setup.


I tried to clean that up for rsyslog during the bookworm release cycle.
My guiding principle was to have a single log file containing everything (minus security sensitive information) and separate log files for commonly 
used facilities that are in use as of today.


I ended up with

#
# Log anything besides private authentication messages to a single log file
#
*.*;auth,authpriv.none    -/var/log/syslog

#
# Log commonly used facilities to their own log file
#
auth,authpriv.*    /var/log/auth.log
cron.*    -/var/log/cron.log
kern.*    -/var/log/kern.log
mail.*    -/var/log/mail.log
user.*    -/var/log/user.log


Hm.  Guess I'll use this for busybox-syslogd too. Thank you for the heads-up,
it come really timely, since just a few days ago I refreshed that package
and was now wondering what files needed to be there.

Another question is whenever to store files as root:adm, mode 0640 by default.
I guess these permissions are set by logrotate, but I'm not sure.

Thank!

/mjt

Bug#907189: busybox-syslogd: Please provide systemd .service files (attached)

[Michael Tokarev]

21.01.2023 19:49, Michael Tokarev wrote:
..

What's the reason to provide these systemd services for busybox-syslogd?

In my view, busybox-syslogd can be used as a minimal syslogging service
on a bare minimal system without much else besides busybox itself.
On a system with systemd, systemd-journald is already running, and provides
far better logging services than busybox-syslogd, including kernel logging
and /dev/log redirection.

I don't really see the point in providing systemd .services for busybox-syslogd.


After some thinking and facing issues with logging on a low-power machine where
systemd-journald is taking just too much time to find journal entries, I think
it is a good idea to provide busybox-syslogd.

In /etc/init.d/busybox-klogd, we have if running_under_systemd; then exit; fi -
added by me, with a comment stating klogd makes no sense under systemd. This
is apparently wrong, - yes, journald does intercept kernel log and logs it to
the journal, but it suffers from the same prob: on a low-power machine these
journal entries takes ages to retrieve. So it makes sense to package klogd
too, and to provide systemd service file for it.

Doing that now.

/mjt

Bug#907189: busybox-syslogd: Please provide systemd .service files (attached)

[Michael Tokarev]

Control: tag -1 + moreinfo

On Fri, 24 Aug 2018 16:39:00 +0200 "W. Martin Borgert"  
wrote:

Package: busybox-syslogd
Version: 1:1.22.0-19
Tags: patch

Please add systemd .service files to busybox-syslogd.
The attached files are taken from OpenEmbedded and
seem to work on my embedded device on Debian 9.
Thanks in advance!


What's the reason to provide these systemd services for busybox-syslogd?

In my view, busybox-syslogd can be used as a minimal syslogging service
on a bare minimal system without much else besides busybox itself.
On a system with systemd, systemd-journald is already running, and provides
far better logging services than busybox-syslogd, including kernel logging
and /dev/log redirection.

I don't really see the point in providing systemd .services for busybox-syslogd.

Thanks,

/mjt

Bug#1023501: busybox-static: version 1:1.35.0-3 breaks boot on hppa

[Michael Tokarev]

Control: tag -1 + confirmed

On Sat, 5 Nov 2022 21:18:58 +0100 Robert Luberda  wrote:

severity 1023501 grave
retitle 1023501 busybox-static: version 1:1.35.0-3 breaks boot on hppa 
and amd64

found 1023501 1:1.35.0-3
notfound 1023501  1:1.35.0-2

On Sat, 05 Nov 2022 13:31:51 + John David Anglin 
 wrote:

> Package: busybox-static
> Version: 1:1.35.0-2
> Severity: normal
> 
> Dear Maintainer,
> 
> With 1:1.35.0-3, boot ends in initramfs:
> 
> Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.

> Begin: Running /scripts/local-premount ... done.
> Begin: Waiting for root file system ... Begin: Running /scripts/local-block 
...
mdadm: No arrays found in config file or automatically
> done.
> Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically

> >
> >  - Missing modules (cat /proc/modules; ls /dev)
> > ALERT!  LABEL=ROOT2 does not exist.  Dropping to a shell!


I had the same issue on amd64.
Removing mdadm package did not help.
Downgrading busybox-static to 1.35.0-2 fixed the issue.


Now this is interesting.  In -3, I included these changes:

commit ac478f88b64d5884d5e81bcd8f8344f0ec72df6a
Author: Michael Tokarev 
Date:   Mon Oct 17 12:52:23 2022 +0300

deb,static: enable blkid applet (useful for rescue purposes)

commit d371992b4a0394f02cd29cb9cb946080414f8afb
Author: Michael Tokarev 
Date:   Mon Oct 17 13:00:16 2022 +0300

deb,static: enable findfs applet (useful for rescue purposes)

Both really are useful for rescue purposes, I've hit this - the lack of
blkid and findfs in busybox - several times, and finally decided to enable
them.. It's a minimal version, it can help in many situations.

But it turns out debian initramfs generator includes its own blkiid, which
is more advanced than busybox's.  For regular (non-static) build, busybox
adds links to itself for applets it have but which aren't provided by other
tools already.  However, for the static build, it has CONFIG_PREFER_APPLETS=y
(in order to be more useful when the filesystem is damaged/incomplete), so
it ignores external implementation of these utilities.  And we end up in
this situation.

And for the static build, it is even more interesting to have these utils
available.

*sigh*

I'll disable one of them for -static build for now, to work around this
issue (have to check which one is to blame, most likely blkid).

But.. *sigh* :)

Thanks,

/mjt

busybox uploads

[Michael Tokarev]

Hi!

I uploaded a new busybox release today (mostly non-linux changes,
it now builds on hurd), but thought maybe I should've asked here
before doing that. But it was too late already.

Should I ask the next time?

Thanks,

/mjt

Re: busybox upload and further maintenance

[Michael Tokarev]

Ok, it's been almost a month since my initial email here.

If there's no objections, I'll upload the new busybox release tomorrow
(from the "mjt" branch). It's enough waiting :)

I want to enable awk applet for d-i (udeb) config before the upload, for
some things it is much easier to use than e.g. sed.

I do have some more thoughts, including some doubts about the way I changed
the build procedure (it looks like there's a simpler way), but that's for
the future.

Thanks,

/mjt

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Michael Tokarev]

19.05.2022 17:23, Philip Hands wrote:

Michael Tokarev  writes:


19.05.2022 15:59, Philip Hands wrote:
...

Actually, I'm unable to resist the urge to remove the redundant use of
cat (that was already there), so how about doing it in a single sed:

LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }' 
/usr/share/localechooser/languagelist)


That smells like awk usage, not sed ;)


Doh!

I started out with awk, as it's cleaner for this, and then noticed that
we don't have awk enabled in d-i's busybox, so changed to sed.


Is there a reason we don't have awk in busybox? Maybe it's time to enable it?
Some stuff, like this one, is really easier to do with awk.

(and I'm still waiting for a reply from Chris Boot about busybox).

Thanks,

/mjt

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Michael Tokarev]

19.05.2022 15:59, Philip Hands wrote:
...

Actually, I'm unable to resist the urge to remove the redundant use of
cat (that was already there), so how about doing it in a single sed:

   LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }' 
/usr/share/localechooser/languagelist)


That smells like awk usage, not sed ;)

/mjt

Bug#980127: busybox-static: Please enable the "hush" applet

[Michael Tokarev]

Control: tag -1 + moreinfo

On Thu, 14 Jan 2021 13:12:58 -0800 Josh Triplett  wrote:

Package: busybox-static
Version: 1:1.30.1-6
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

For busybox-static, I'd love to have the "hush" applet available. It's a
more feature-complete shell, including features such as brace expansion.

Please consider enabling CONFIG_HUSH and CONFIG_HUSH_BASH_COMPAT in
busybox-static.


Hi Josh!

Myself I haven't used hush in busybox but I always used ash. If we're to
enable hush, I think we should remove ash and make hush the only shell.
And do that in regular deb config too, - there's no good reason to keep
them different.

But I wonder what implications we might have there, if we switch from
ash to hush.  How compatible the two shells are? I dunno. I think it
needs to be verified at least..

busybox's ash is very limited indeed.

Thanks,

/mjt

Bug#964579: lsblk not included in busybox version used with installer

[Michael Tokarev]

Control: tag -1 + moreinfo

On Wed, 8 Jul 2020 23:23:51 + Holger Levsen  wrote:

Package: busybox
Version: 1:1.30.1-4
Severity: wishlist
x-debbugs-cc: Russell Weber 
submitter: Russell Weber 

On Wed, Jul 08, 2020 at 02:43:43PM -0600, Russell Weber wrote:
> Package: busybox
> Version: 1:1.30.1-4
> Severity: wishlist
> lsblk is a very useful tool for understanding your current disks and block
> devices. It can be used to
> query lots of information including disk manufacturer, serial number, model
> number, the structure of your disks if the disk is already in use for
> another block device. Given that the installer has mission critical goals
> associated with the disks, it's a bit of a mystery that lsblk isn't
> included into the busy box implementation used in the installer. This is
> especially important when seeding automatic/unattended installs for debian
> since many of the seed files used will query information from disks in
> scripts using the "d-i partman/early_command string" of debconf.  I can see
> that this issue has been raised in multiple places online: stack overflow,
> IRC.  However, scanning older tickets, I was not able to find a ticket
> which raises the issue.  Is there any reason that lsblk as a command is not
> included?  As far as I can tell, the bloat size would only be around 20-40
> KiB in size.  May I suggest that we start including the lsblk binaries in
> the next versions of Debian?


Hi Russel!

Thank you for the detailed bug description.

The only question remain is who will write lsblk for busybox, who
writes the actual code to do all this?  Can you help with that,
to collect all the mentioned information in a useful for the user
form?

This applet is not written.

Thanks,

/mjt

Bug#921556: busybox: Enable more applets to support initramfs-tools

[Michael Tokarev]

Control: tag -1 + upstream

On Wed, 06 Feb 2019 18:58:06 + Ben Hutchings  wrote:

Package: busybox
Version: 1:1.27.2-3
Severity: wishlist

Once we have busybox 1.28.0, we could enable these extra applets on
Linux:

ipconfig  [CONFIG_IPCONFIG]
nuke  [CONFIG_NUKE]
resume[CONFIG_RESUME]
run-init  [CONFIG_RUN_INIT]


So this is almost there, except of ipconfig which is not implemented yet.
There's just a wip version, a first draft, klibc-utils/ipconfig.c.txt,
not touched since initial import in Sep-2017.

It's an interesting goal there, to have everything in busybox to stop
providing two libCs and two shells and two everything in initramfs..

Thanks,

/mjt

Re: busybox upload and further maintenance

[Michael Tokarev]

08.05.2022 23:06, Cyril Brulebois wrote:

Michael Tokarev  (2022-05-08):

The prob is not the burden of maintaining it, I'm okay with that one.
It is just that the whole thing seems wrong :)

Again, I'm definitely not arguing for dropping it right now, but we
either plan to do this some other way, or we don't. If we do, we can
start some discussion/review in this area.


If you want to double check every single place where preseeding can
happen, and prepare a plan to make this patch dispensable, feel free to.
It just seems to me that the cost of doing so is huge compared to the
gain over the current situation it would represent.


yeah, that's a long way forward, I know.


Personally, I'd rather spend my time on finally letting go of gtk2, for
example. (And that's because I have to, not because I want to.)


Yeah.


The argument "it only affects the udeb" is lame :) Udeb does not need
to suffer - neither this one nor any other udeb, and actually it does
not only affect udeb, it affect busybox as a whole, and the upstream
change which we revert is there for a reason :)


For the avoidance of doubt, that patch guards the “new” code with a
macro check, keeping the “old” code when an option is set. That option
is only set in the udeb build:

 debian/config/pkg/deb:# CONFIG_FEATURE_DI_ENV_HACK is not set
 debian/config/pkg/static:# CONFIG_FEATURE_DI_ENV_HACK is not set
 debian/config/pkg/udeb:CONFIG_FEATURE_DI_ENV_HACK=y

so I'm not sure my argument is wrong in addition to being lame?


Cyrill, I was nothing more than joking about the lame part, really.
Please note the smile.

As of the DI_ENV_HACK, I wondered what an interesting name it is,
which is being noticed if I forget to apply patches.  And I stand
corrected, - indeed, you're absolutely right, this is something
specific to udeb due to this new config feature check.  I haven't
noticed it when I initially looked at the patch (briefly).

Thank you for correcting me there!

/mjt

Re: busybox upload and further maintenance

[Michael Tokarev]

08.05.2022 19:39, Cyril Brulebois wrote:

Hi,

Michael Tokarev  (2022-05-08):

I don't understand what is holding an upload right now, -- the salsa
busybox repository is more than 3 months old now.  I think it is ready
for an upload, - I think we should do it and deal with any issues
which may come.


Without knowing about the busybox situation specifically, it happens
that people prepare stuff but don't feel the need or confidence to
upload, so they can stay around for a while.


Yeah, I know this feeling very well, been there myself ;)

I prepared some changes in a separate branch (for now) named "mjt",
it is on top of current master - the changes I'd do in there.
There are many other things in there which needs to be reviewed.

Yet I don't see any reason to hold the upload further.

I'd love to hear opinion by Chris Boot who did most recent work
in there, - if it is okay for him if I merge my branch into
master.  And next, let's upload this thing. I can do that, or
Chris can do that, - provided he is not against me doing some
stuff in there.


In d/patches/ there's a hackish patch temp-deb-installer-hack.patch
which seriously needs addressing I think (not in this upload though),
-- has anything been done in this direction, to get values from the
kernel command line in some more sane place than shell environment?


Oh, what a blast from the past. It's been temporary for 5 years…


Yeah. As usual :)


I'm still not familiar with d-i and its internals, so I need some
help there. At least some discussion should be happening, I think,
because this seems to be a serious change for the d-i.  Yet keeping
this patch does not seem to be a good idea.


Well, I can understand the feeling but unless maintaining the patch
itself is a burden (which I kind of doubt, given it's quite targeted),
in which case I'm happy to help, it only affects the udeb, and makes
sure we don't break preseeding gratuitously…


The prob is not the burden of maintaining it, I'm okay with that one.
It is just that the whole thing seems wrong :)

Again, I'm definitely not arguing for dropping it right now, but we
either plan to do this some other way, or we don't. If we do, we can
start some discussion/review in this area.

The argument "it only affects the udeb" is lame :) Udeb does not need
to suffer - neither this one nor any other udeb, and actually it does
not only affect udeb, it affect busybox as a whole, and the upstream
change which we revert is there for a reason :)

Let's upload the thing and see what happen.

I'm ready to help and to bring it up if it falls into pieces :)

Thanks!

/mjt

Re: ifupdown/dhcp

[Michael Tokarev]

08.05.2022 18:24, Michael Stone wrote:

[apologies to package aliases getting this twice due to autocomplete fail]

I've been trying to make sense of the NEWS item in isc-dhcp-client (that alternatives are needed) in combination with the functionality of ifupdown 
and what the implications are for debian upgrades generally.


isc-dhcp-client as of the last upgrade is telling users to stop using it (the 
default dhcp client for debian).

ifupdown (the traditional tool for managing networking on debian systems) has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a 
virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a 
working configuration managed by ifupdown if installed, as it will try to take over interfaces currently set, e.g., to manual). This seems suboptimal 
at best.


I believe that ifupdown will attempt to use udhcpd if installed, which should be a mostly-transparent change (except for the potential loss of lease 
information and any customization of dhclient scripts) but it isn't even on the ifupdown recommends list.


Yes ifupdown knows about udhcpd. I dunno how seriuos this one is, the udhcpcd 
from busybox.
We use it in many different cases locally, and a few times I used it on a 
regular linux
client in various public networks, it is scriptable (it relies on the script to 
do the
actual work).  It is maintained, - well, hopefully, - and in debian, I 
maintained this
package for quite some years locally before, next stepped up as debian 
maintainer of
busybox package, and continue to maintain it locally for another several years. 
Recently
I thought about giving it another try to make it in good shape in debian, and 
others
are doing their work there too.

busybox is recommended by initramfs-tools, so it is installed on all debian 
systems
where install-recommends is not explicitly set to false, so it is always 
available,
more or less (the udhcpcd package is just a symlink to busybox).

But I never really thought about it as an alternative to "big" dhcp client. I 
dunno
why, maybe because I always treated busybox as a "small brother" not ready for
anything serious.

Overall it just works, especially after some tweaks to its script.  Maybe I 
should
give it another try too, I dunno.

What's up with ISC dhclient?

Thanks,

/mjt

busybox upload and further maintenance

[Michael Tokarev]

Hi!

Quite some years ago I stepped down as a busybox maintainer, in a somewhat
scandalous way even, and the details of that story are now started escaping
my memory.  At any rate, I become older, much less touchy than before, and
that time wasn't my easiest period of my life which might have prompted
something unwanted.  I don't remember who was wrong and who was right, if
I you think I did some wrong, please accept my apologies. It definitely
was not my intention to harm anyone, it was just other issues I had at
that time.

Today I thought I'd give busybox another try, if you please.  Just like I
maintained it locally for many years before I become bb maintainer, I
continue to maintain it locally after stepping down (and after nothing
in it happened for years again).

I looked at the current packaging, - Chris Boot did a good job there,
it seems.  It is not an easiest package wrt the amount of bug reports
in there, one has to be brave enough to do some work with it :)

I don't understand what is holding an upload right now, -- the
salsa busybox repository is more than 3 months old now.  I think it
is ready for an upload, - I think we should do it and deal with any
issues which may come.

I'd only do some minor touches there which I noticed immediately -
like, enabling the tr equivalence classes for the static busybox
build too, just like it is done for the regular deb.

In d/patches/ there's a hackish patch temp-deb-installer-hack.patch
which seriously needs addressing I think (not in this upload though), --
has anything been done in this direction, to get values from the
kernel command line in some more sane place than shell environment?

I'm still not familiar with d-i and its internals, so I need some
help there. At least some discussion should be happening, I think,
because this seems to be a serious change for the d-i.  Yet keeping
this patch does not seem to be a good idea.

So, to sum it up the tl;dr way:

- is it okay for you if I help with bb, with its upload and with
  further maintenance?

- is there anything that is holding the upload now which I'm not
  aware of?

- do we have anything in the d-i kernel command line processing
  front, in moving stuff from $env-vars to some saner place?

Thank you!

/mjt

Bug#1009309: udhcpc: allow usage without busybox

[Michael Tokarev]

13.04.2022 09:31, Helmut Grohne wrote:

Control: tags -1 + moreinfo

On Wed, Apr 13, 2022 at 09:13:58AM +0300, Michael Tokarev wrote:

No, as far as I understand. B/c udhcpc package lacks the main binary
if there's no busybox... ;)

Can you explain please? :)


Head -> table. I now understand why udhcpc is so small. Thank you for
your kind reply. There is nothing to change here. I'll look into the
reverse (and usual) solution to space saving: replace everything else
with busybox.


That was good Helmut!  Thank you!


On a related note, I have been wondering whether we could somehow put
the integration of busybox on more solid footing. A possible route could
be adding tiny symlink packages e.g. iproute2-minimal containing ip,
kmod-minimal containing lsmod and friends or procps-minimal containing
top et al. These would have to conflict with iproute2, kmod and procps
respectively as they're sharing paths. To make that actually useful,
downstream packages could update their depends to foo | foo-minimal when
they are known to work with busybox. If toybox wants to join, -minimal
would refer to the minimal baselines provided by both busybox and
toybox. It's a lot of small packages and metadata though. I'm not
convinced yet and merely sharing thoughts. Properly minimizing Debian
chroots with busybox is not a "it just works" experience yet.


I thought about this back when I stepped on as busybox maintainer a few
years back.  Busybox isn't really suitable as a full-blown implementation
for many system utilities. For one, quite some things on the system will
break when you replace something with busybox, due to maintscripts, or
startup scripts, whatever, usage of options/features/lack-of-bugs of the
busybox's large brothers. Eg, file^Wcoreutils or [mg]awk provides much
more features than busybox counterparts, and these features are being
used in debian.  This isn't difficult to fix in most places but you
know the drill with cross-compile, how slow this process is :)

But busybox is basically not maintained in Debian. I tried to at least
reduce the number of active bug reports (there were many of them),
updated version to current one (previous update was a few versions
behind), tried to sync different configuration with each other and
with reality.. until something happened a few debian releases ago
and I was pissed off and stepped down.  I don't even remember what
happened, just a vague memory of someone uploading busybox backing
up changes I did and refusing my changes to go, or some such..  So
after that, busybox basically froze again.  I still maintain it
locally for our needs just like I did before, but I don't do that
in Debian anymore.  Maybe I should try again...

/mjt

Bug#1009309: udhcpc: allow usage without busybox

[Michael Tokarev]

11.04.2022 15:21, Helmut Grohne wrote:

Source: busybox
Version: 1:1.30.1-7
Severity: wishlist
Tags: patch

Hi Aurelien,

would it be possible to avoid the udhcpc -> busybox dependency? It may
seem strange to remove busybox in a quest to reduce file system usage at
first, but if you need iproute2 for other reasons, it should be fine at
providing what udhcpc needs. I'm attaching a patch so you can judge the
impact.


Helmut, I'm not sure I follow you here. udhcpc itself is provided by
bysybox. There's no udhcpc without busybox. udhcpc package is just a
set of support files for busybox's udhcpc applet. This is exactly why
I implemented it this way in the dhcp script: we're absolutely sure
busybox implementations of awk and ip are always here, since without
these there would be udhcpc.


If that's not a reasonable move forward, how about demoting the
dependency to Recommends? Admittedly, the case of using udhcpc without


No, as far as I understand. B/c udhcpc package lacks the main binary
if there's no busybox... ;)

Can you explain please? :)

/mjt

Re: Bug#983197: debootstrap: autopkgtest regression under autopkgtest-virt-qemu

[Michael Tokarev]

22.02.2021 13:00, Simon McVittie wrote:

Control: reassign -1 src:debootstrap 1.0.123
Control: retitle -1 debootstrap: autopkgtest regression under 
autopkgtest-virt-qemu

[]

not ok 19 - unshare -m 
/tmp/autopkgtest.PYPTQP/build.yxt/src/debian/tests/fake/schroot-1.6.10-3 
chroot.d runuser -u nobody -- script -q -c cat /etc/debian_version /dev/null
not ok 20 - script(1) should work under (fake) schroot


Can it be #983087 ?

Thanks,

/mjt

Bug#689528: please add virtio support for cdrom at install time

[Michael Tokarev]

22.01.2020 09:18, Witold Baryluk wrote:

Package: debian-installer
Followup-For: Bug #689528

Dear Maintainer,

any progress on this, I still have this issue.


Out of curiosity, _why_ this is necessary?
For the install time, isn't it trivial to use regular ide/sata cdrom
drive or an usb flash instead of more exotic ways? Most of the time
cdrom is only needed for the installation, later on you can either
remove it entirely or switch it to virtio if needed.

We did lots of installations of various systems out there in qemu/kvm,
and we always use most common devices during this time.

Thanks,

/mjt

Bug#893843: please enable nbd applet

[Michael Tokarev]

Package: busybox
Version: 1:1.27.2-2
Severity: wishlist

Please enable NBD applet for regular deb configuration. It costs almost
nothing but it is useful for our environment for booting over network.

Thanks!

/mjt

Bug#838031: task-laptop: Add 'ntp' to list of recommended packages.

[Michael Tokarev]

16.09.2016 20:51, Ben Hutchings wrote:

We should install a minimal NTP client by default.  Not ntp, it's far
more complex than needed and (partly as a result of that) has a poor
security record.


Systemd comes with systemd-timesyncd these days, JFYI.

Thanks,

/mjt

Ben.

Re: [PATCH initramfs-tools 0/4] Changes to busybox integration

[Michael Tokarev]

22.01.2016 01:14, Ben Hutchings wrote:
> This series removes the busybox hook script and definition of
> BUSYBOXDIR from initramfs-tools, leaving busybox itself responsible
> for these.

Oh well.  How many times I talked with Max on IRC, sent patches,
created a git tree for initramfs to pull from..  His answer has
always been the same: no need.  So I gave up, creating an ugly
zzz-busybox which undoes the mess done in initramfs script.

Please note that once the d-i team prevented me from maintaining
busybox, this package remains unmaintained.  So maybe it is a
better idea to remove usage of busybox in initramfs (which this
series actually does).

Thank you Ben!

(And yes, I'm still subscribed to busybox package, for unknown
reason).

/mjt

Re: Bug#784070: is it maybe possible to settle dislikings and fix this bug?

[Michael Tokarev]

27.10.2015 18:23, Ben Hutchings wrote:
> On Tue, 2015-10-27 at 10:25 +0300, Michael Tokarev wrote:
>> I'm not maintaining mdadm anymore.
> 
> Then why have you not orphaned it?

It is team-maintained (or was), and orphaning it means uploading
it which means I'll have to ask the d-i team again.  I described
it all in the previous email.

Thanks,

/mjt

Re: Bug#784070: is it maybe possible to settle dislikings and fix this bug?

[Michael Tokarev]

27.10.2015 02:27, Francesco Poli wrote:
> On Tue, 6 Oct 2015 00:01:18 +0200 Francesco Poli wrote:
> 
> [...]
>> Michael, I am not sure I understand what happened: I don't see any
>> recent NMUs for package mdadm, hence I cannot see how d-i developers
>> could "throw your work away".
>>
>> Anyway, the last resort strategy to address your disagreement with the
>> d-i developers could be referring it to the technical committee, as
>> Paul seems to suggest...
>> But, before doing so, I would try hard to talk to the d-i developers
>> and solve the disagreement in the most amicable way.
> 
> Michael, could you please clarify?
> What are going to do in order to solve this unfortunate "conflict"?

I asked the technical commitee during jessie freeze, asked this exact
question, what right has the d-i team to reject my non-d-i-related
changes and why my (hard in this case) work has to be removed.  The
reply come way too late, so my work which I made for jessie has been
lost.  And it actually didn't answer my question, instead addressing
me back to the d-i team where I come from.  This was about busybox.
I asked to at least remove my name from the released version in jessie,
because I can't be blamed for not doing something, -- even that small
wish weren't fullfilled (maybe because this might break something?).

>From that time, and I mentioned that multiple times, I can't work on
any package which produces d-i component, because d-i team throws my
work away without any good reason.  They're producing next alpha release
of stretch installer these days, which means udebs (d-i components)
are frozen again (or so I understand), and mdadm is one of them (which
provides a piece of d-i to deal with software raid during install time).

I'm not maintaining mdadm anymore.  I'm not maintaining any piece which
produces udebs.  Because I can't.  I'm not the only one person in this
world who can do this.  Debian is made entirely by volunteers. Someone
should step in and try their own luck here, maybe they'll more productive.

I'm sorry for making this bug.  But now I can't and wont do anything
with it, because this involves another process of communicating things
with the d-i team, which I definitely wont do.  And I expressed this
multiple times already.

>> Otherwise, if you are absolutely unwilling to continue maintaining the
>> mdadm Debian package (as I said, I hope you reconsider!), then I think
>> you should officially search for someone willing to adopt the package...

Yes, that's what I'm saying.  Maybe someone else will have more luck
working with the d-i team.  Or the technical committee.

> I really hope you change your mind and begin to maintain the mdadm
> Debian package again. But, if you don't and you are absolutely
> unwilling to touch mdadm again, then you should formally state your
> decision and search for someone to adopt the package.

I don't know how to "formally" state my descision.  Debian knows about
it, d-i team knows about it, technical committee knows about it.  I
wont _upload_ any new mdadm release (so that my name wont be listed
in the control file) because of the reasons already stated above.  I
can't change the maintainer, because I'm not listed as maintainer,
it is a team-maintained package (where I'm just one of the members,
tho only one active member in 2 recent years).  I asked, honestly,
to at least remove my name from the busybox package for jessie (where
I'm also the only one active maintainer for a some years), even that
weren't made.

No, I don't know how to "state" this.  Someone can make an nmu with
my name removed and maybe the bug fixed, I dunno.  Maybe the d-i
team can do that after all (Cc'ing them).  I wont, and again, I stated
this multiple times.

Thanks,

/mjt

Bug#783637: Installation fails because starting colord fails on missing libudev.so.0

[Michael Tokarev]

05.05.2015 21:13, Michael Lager wrote:
> I can't remove libusb-1.0-0 package which provides libusb-1.0.so.0 because 93 
> packages depend on it including gdm3, gnome, cups and many others and that 
> would render jessie practically useless.  The version required by jessie is 
> given as 2:1.0.19-1:amd64 and this is what is installed.  So the symlink 
> works.

I told you the solution is to remove the library you installed
manually in /usr/local/lib which is named libusb-1.0.so.0.
No package in debian provides any library in /usr/local, all
libs are installed to /usr/lib or /lib.  The library you have
in /usr/local/lib is not from debian, it is something you
installed most likely from source.  You shouldn't remove
the debian-supplied library but the one you installed outside
of debian.

[]
> Anyway, the whole point was to say that the upgrade failed when trying to 
> start the display manager and to suggest a cure.  I don't think it was 
> anything I installed that caused this. Have you a better one?

The whole point is that what you did is WRONG.  So if you
don't listen to advise several people offered to you, at
least others hopefully wont repeat your mistake after finding
your "fix" in this bugreport.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55492812.2080...@msgid.tls.msk.ru

Bug#783637: Installation fails because starting colord fails on missing libudev.so.0

[Michael Tokarev]

05.05.2015 14:55, Michael Lager wrote:
> This was an upgrade from debian wheezy to jessie and a report (as requested) 
> on how it went.  I just hope this can be put right for others wishing to  
> upgrade and finding it doesn't work.  My work-around was to create a symbolic 
> link (result as below) for the missing file based on the pattern for symbolic 
> links elsewhere: jessie now works OK.
> 
> $ ll|grep udev
> lrwxrwxrwx   1 root root   21 Apr 16 16:53 libgudev-1.0.so.0 -> 
> libgudev-1.0.so.0.2.0
> -rw-r--r--   1 root root42920 Apr 16 16:53 libgudev-1.0.so.0.2.0
> lrwxrwxrwx   1 root root   38 Apr 16 16:53 libudev.so -> 
> /lib/x86_64-linux-gnu/libudev.so.1.5.0
> lrwxrwxrwx   1 root root   10 Apr 28 11:10 libudev.so.0 -> libudev.so
> lrwxrwxrwx   1 root root   12 Apr 29 10:34 libudev.so.1 -> libudev.so.0

So for someone who finds this, don't do this, this is WRONG.  The libs are
named the way they are for a purpose, because symbols in libudev.so.0 are
not compatible with these in libudev.so.1 and so on.  Sometimes such symlinking
makes some executable to start so seemingly this smells like a solution, but
it is quite possible that this executable will just crash when asked to do
something real.  Sometimes this doesn't work at all.

This has nothing to do with upgrade from wheezy to jessie really.  You have
locally installed alternative libusb-1.0.so.0.  This library is not recorded
in the dpkg database so apt/dpkg doesn't know about it and doesn't know
that it needs libudev.so.0.  This is a library you installed manually.

The solution is to either install libudev0 package to make your libusb-1.0 to
work (and maybe record that libudev0 is needed so it wont be removed by a
chance), or, better yet, just remove your libusb-1.0, because jessie comes
with its own, most likely never version, and together with support.

Your situation is rare, because it is uncommon to install 3rd party libraries
like this, and even less common to come across such an issue.

But the "solution" you offered is _wrong_.

Thanks,

/mjt

> On Mon, 4 May 2015 18:04:02 +0200 Samuel Thibault  
> wrote:
>> Michael Lager, le Mon 04 May 2015 12:54:14 +0100, a écrit :
>> > /usr/local/lib/libusb-1.0.so.0
>> > NEEDED libudev.so.0
>> > NEEDED librt.so.1
>> > NEEDED libpthread.so.0
>> > NEEDED libc.so.6
>> > dpkg-query: no path found matching pattern /usr/local/lib/libusb-1.0.so.0
>>
>> We can not support the dependencies of locally-installed software.
>> Either remove that software, or install the required dependencies (here,
>> fetch the libudev0 package from wheezy)
>>
>> Samuel
>>
>>
> 
> 


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5548baa0.5080...@msgid.tls.msk.ru

Re: bastardizing packages or stepping down

[Michael Tokarev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

06.03.2015 15:02, Sam Hartman wrote:
[]
> So, you're involving the TC because you're hoping to better understand why 
> your unblock was not approved?
> 
> How are you hoping the TC can help?  Here are some options I see:
> 
> * Some folks on the TC are fairly good at release engineering and have been 
> involved in this either in Debian, for other projects or for other 
> distributions. We could look over the situation and try to help you 
> understand why someone might decide not to approve those unblocks.  Since we 
> weren't the one acting on the request we can give you an understanding of why 
> someone might think that way, but not why they did.
> 
> * Alternatively you could be asking for help engaging with the release team 
> and Cyril to explain the actual reasoning involved.
> 
> Or perhaps you're asking for something else.

I asked for understanding mostly.  But as I wrote at the very
beginning of my first email, I don't have much hope.

This email has been sent to 3 places: d-i team who rejected busybox,
d-release team and TC, so maybe at least one party can find something
to say or do.


What I see here are 3 possible solutions to this problem.  I guess I
ordered them right, starting with most unlikely but best, and ending
in most likely but worst.


a) allow current busybox to migrate from unstable to testing.
This is what I asked when filing an unblock-udeb request initially
in #771208, which was filed before jessie freeze.  This is what
will make everyone happy, I think, including current people involved
with the package because there wont be any reason anymore to do the
same work twice (including making another crippled release for
jessie with unneeded-for-debian security bugfix but without needed-
for-jessie other fixes), there wont be any need anymore to bastardize
the package.

Disadvantages are none, to my view anyway, except that in this case,
people who rejected the unblock request will have to agree it was
a mistake.  That, I think, is one of important points here, because
Cyril is one of them (if not the only one), and he's an important
person for the project, and no one want to make him unhappy.

But since this hasn't happened so far, and even my main questions went
unanswered this far in the release cycle, I've no hope for this.


b) someone -- be it TC, or D-I team, or the Release team, explain to
me why the changes hasn't been accepted.  I asked this several times,
but always got the same answer: the changes are fixing jessie-ignore
bug and introduce uneeded-for-jessie changes for things which are now
history already (glibc bug).  To which I answered initially in the
very first unblock request: the jessie-ignore thing was only because
that bug was _difficult_ to fix in time for jessie (but I did that
and I was in time), so not to introduce an RC bug which is unlikely
to be fixed, and that these changes are _needed_ for jessie, not
anything past jessie, exactly because it isn't yet history for jessie,
as buildd story demonstrates, and because fixed glibc hasn't even
been released upstream at the time -- if not for jessie users,
this helps derived distributions and in other situations, like
backporting and whatnot.

But even more: all this, which I voluntary explained, is hardly
relevant for the unblock-UDEB request, because none of the changes
in question EVER affect D-I in any way whatsoever.  So I don't
really understand why an unblock-UDEB request has been denied in
a background that the changes aren't needed for jessie, BEFORE
jessie has been frozen?

And another question which I asked several times is, even if the
changes aren't exactly necessary, does it HURT any?  Does the
new stuff break anything?  If not, again, why to work more when
it's that simple to do less and make everyone happy?

So, basically, it'd be good to understand why.  Maybe TC can help,
maybe the release team can, or maybe d-i team, I dunno.

c) lacking a) and b), I don't have any choice but to step down.
The reason is plain and simple.

I don't understand why, see b), why even such small, easy to review,
carefully selected, tested and needed changes can't be accepted,
and why my questions goes on unanswered while freeze progresses,
and why it is better to do more work _instead_ of the same work
which I already did.

Since I don't understand why my work isn't needed for debian,
and instead, debian prefers to do MORE work, I see this as I'm
not helping debian but instead disturbing its work.  So I can't
continue, I don't want to make life for others harder.  So I
_have_ to go.  I can't even change the way I do things to make
it easier for debian, because I don't understand what is
going on so don't know the direction to change myself.


So, if c) is the only choice I have, I request that my name
be removed from all packages which, at leaat, produces udebs
(these are busybox and mdadm so far) on the next upload, and
I'm stopping maintaining these packages, bec

Bug#779890: udhcpd: Support for multiple interfaces/udhcpd processes

[Michael Tokarev]

06.03.2015 02:57, Elliott Mitchell wrote:
> Package: udhcpd
> Version: 1:1.20.0-7
> Severity: wishlist
> 
> The documentation seems to suggest udhcpd can only handle binding to one
> interface and using one IP address range per udhcpd process.  Due to
> this, it would be handy if Debian's init scripts had support for
> starting/stopping multiple udhcpd processes (this would mean require
> multiple .conf and .pid files).

I suggest using some more advanced dhcp servers for this, for
example there's an excellent piece of software named dnsmasq
which is small and has other useful functionality.  Udhcpd
scripts can be extended to support multiple interfaces, but
I think at this time, it is better to use, say, systemd
service files for that, which should be trivial to write
and drop to the right location (and no, I don't know off
my head how to do that ;).

> When reading the man page I was wondering, could multiple configuration
> files be specified on udhcpd's command-line and would this have the
> effect of starting multiple udhcpd processes?  (I rather doubt it, but
> the man page could be read that way)

One invocation handles one interface, I think.  But you can try :)

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f942ff.40...@msgid.tls.msk.ru

Re: bastardizing packages or stepping down

[Michael Tokarev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

05.03.2015 15:08, Sam Hartman wrote:
>>>>>> "Adam" == Adam D Barratt  writes:
> 
> Adam> Hi, Making no comment on the remainder of the mail:
> 
> Adam> On 2015-03-05 10:38, Michael Tokarev wrote:
>>> And since I can't do my work, I'm stepping down from being busybox 
>>> maintainer, and am kindly asking the release team to remove my name from 
>>> debian/control file in busybox, so that people don't blame me for things I 
>>> can't do.
> 
> Adam> I don't believe it would be appropriate for us to do so. We Adam> have 
> no control or say in who maintains packages (beyond that Adam> available to 
> any other DD or interested contributor).
> 
> michael, I'd like to ask if I'm hearing you correctly.  So, what I'm hearing 
> is very strong frustration.  You had hoped that you would have the power to 
> produce a package that you'd be happy being responsible for.  However you 
> don't believe  that you have that power; you're saying that changes you 
> consider essential  to creating a busybox you're comfortable being 
> responsible for are rejected.  Am I hearing you correctly?

Well.  It is not about being happy or being powerful.  It is about at least
understanding the reasons why we should take bad and have more work instead
of taking good and have peace.  This is the main source of frustration, and
this is the main question which went unanswered so far.

The main changes I've made (this build-using thing plus a build-time glibc
check) are _only_ needed for jessie, since after jessie this whole single
issue will really be history, while for jessie it isn't history yet, like
a story with buildds demonstrating.

Another source of frustration is the fact that all the changes in question
does not break things, it does not hurt anyone, and especially does not affect
the D-I in any way whatsoever, but are being rejected on the D-I side.

Another frustration comes because much more intrusive but much less needed
changes are being happily accepted after the deadlines, even if here, I
missed the deadlines because of factors not under my control, but trying
my best.

So, the main point is that apparently it is better to do more work and make
everyone frustrated than to just accept already (hopefully well-) done work
and continue peacfully.  I don't see the reason WHY (hence I Cc'd ctte).
It is not about power.

> Adam, let's assume for the moment I've got that right.  I'm trying to connect 
> with the frustration I'd feel if I were told that I didn't even have the 
> power to distance myself from something I couldn't in good conscious claim to 
> support. I hope that there's some way that michael can approach stepping away 
> from the package in jessie if he wants to. If what you're saying is that his 
> proposed mechanism for doing that is the wrong one, would you be willing to 
> help him out and suggest a mechanism you believe to be more appropriate?  
> (Perhaps you'd approve an ublock for an upload that simply changed maintainer 
> to debian-qa?)

There's no need to change maintainer, it is debian-boot (d-i team) and
it remains like that, at least in busybox.  In busybox my name is in
Uploaders: field only.  For mdadm, on the other hand, even if it is set
as team-maintained, the sole maintainer is me, so that'd be appropriate
to change maintainer to debian-qa.

Both packages affects d-i, and for the reasons I already described, I
can't do that myself, since I'll face the same unblock request process
from the D-I team.  More, I don't really want to keep my name as the
author of last changelog entry in this case.

> If what you're saying is that you see no mechanism for him to step away from 
> a package he no longer feels he can maintain because he and the release team 
> disagree with the desired contents of that package in Jessie, then I 
> respectfully ask you to reconsider that position.  That sort of thing would 
> likely drive me away from the entire project, not just one package.

Actually this was my first reaction, but I thought I'd wait for a bit
and just point out a possible defect in debian, possible request for
discussion.

> Micahel, one final question to you. Are you firmly committed to the path of 
> stepping away from busybox maintenance, or would you be willing to 
> re-evaluate that decision after we see what comes of your request for 
> understanding?

I don't believe there's any other alternative actually.  I dunno, it is
difficult to think.  I wanted to understand the WHY first, because clearly,
as I tried to describe, I don't see, at all, why this is done.  I don't
really feel "powerle

bastardizing packages or stepping down

[Michael Tokarev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I didn't really want to write this email, but it looks I now have to,
even if, for reasons which whill be shown below, don't expect any
good news from this.

Trying to make the story short.

For quite some time we had a bug in glibc in jessie which resulted
in statically-linked applications malfunctioning when using any of
nsswitch-related functionality (eg gethostbyname() etc), #757941.

This glibc bug resulted in bugreport about busybox package -- #769190
(#757941 has been filed against busybox too, initially).  The problem
was that many busybox applets didn't work in static build.

That bug was rather fun, because even if it is fixed in glibc, your
package depends on the fixed version to be present on all buildds,
or else the resulting binary will be buggy again.  This is exactly
what happened with #769190 -- to work around initial #757941 in bb,
it has been bin-NMUed and rebuilt with a fixed glibc.  But once I
uploaded a next release of busybox to the archive, it was rebuilt
using older, unfixed glibc, and the original problem reappeared.

For added fun, since glibc package names are architecture-dependent,
it is rather difficult to express all necessary build-depends correctly.

Having all this, and having in mind that at least initially you don't
know if this particular build of your package is affected or not,
another bug has been filed against busybox -- #768876, requesting
that busybox-static have a Built-Using field to allow seeing which
glibc version it was built against, at least.

This bugreport (#768876, built-using) is of serious severity and is
tagged with jessie-ignore, not because it is irrelevant for jessie but
because it is _difficult_ to fix and the package already received
manual treatment to be rebuilt against a fixed glibc version.

Understanding the actual severity of this problem, I tried to fix this
before jessie, because I know it is important to do so (see below).
I had fever at that time, and fixing it turned out rather difficult
and required several iterations to finally get it right.  I especially
tried to fix that as fast as possible despite the fever, because it
was near jessie freeze so, even if I was absolutely sure it wont be a
problem to accept these changes to jessie, I didn't want to add more
work for already busy enough release team to review and accept the changes.

But at that time things didn't go right, because it turned out many
buildds are still having old version of glibc and the resulting binary
is buggy again.  So I tried to add a versioned build-dependency on
glibc, which too took several iterations because glibc package names
are arch-specific and because I wanted to keep ability of busybox to
be compiled against old version of glibc (eg for backports), both of
which finally worked.  Also I added a built-time test which builds a
tiny static program which does getpwnam("root"), to verify before build
that the build environment is able to produce static executables at all.
At least this should ensure we wont have known-broken binary after a
successful build.

All 3 changes -- the generation of Built-Using field, the build-time test
to ensure static linking works, and addition of extra build-depends field --
are small and self-contained in d/rules (or d/control) file, easy to review
or remove when it all really becomes history.

Meanwhile I fixed another, unrelated, buglet in the package which annoyed
me enough during these multiple uploads -- I changed d/rules so it does
not produce arch-all package (busybox-syslogd) when asked only to produce
arch-specific packages.  This was a bit larger change in d/rules but is a
well tested in other packages.

Neither of these changes, and this is important point, -- neither of these
changes affects the resulting binary packages on a system where glibc is
fixed.  The changes adds one extra field (Built-Using) to busybox-static
package, ensures the build environment is able to produce a static binary
and introduces a versioned build-depends on libc which allows us to build
the package either with fixed glibc version or with glibc which does not
have that bug yet.

After all this it turned out that several buildds were still having issues
with the new build-depends, so the package were attempted to build multiple
times - some buildds had unfixed glibc so build-depends were impossible to
satisfy.  More, it turned out hurd-i386 build env is not able to produce
a working statically-linked getpwnam("root") binary at all.  So I pinged
buildd maintainers asking to update glibc, I also contacted hurd people
asking what to do (hurd is not a release arch but it is in buildd and if
I can fix hurd before freeze so I wont need to add more work for the release
team that'd be nice).  But time was, ofcourse, ticking. (Btw, I received no
replies to my inquires about release-goal buildds, however after numerous
attempts buildd network finally was able to produce working busybox
binari

Bug#776186: busybox: CVE-2014-9645

[Michael Tokarev]

04.03.2015 19:10, Cyril Brulebois wrote:

> Looking at the just uploaded -15, I don't understand what you tried to
> do there.

I didn't upload -15, I just tried to clean up what's left
before I retire, and - unintentionally - pushed things to
git.d.o.  It was my mistake.  More, we have 2 branches, one
master and one debian-unstable, I now don't remember anymore
which is which, my local debian-unstable was set to track
master, yet the d-unstable changes were in debian-unstable
branch, not in master branch.

Now, since you apparently pulled the changes already, should
I keep it this (unreleased but committed) way, or should I
push -f without my last changes?

> In the meanwhile I had been included Michael's proposed fix for
> CVE-2014-9645 aka. #776186, as opposed to CVE-2014-4607 aka. #768945,
> and successfully testing it in a d-i context.
> 
> Since you updated the master branch with what got uploaded, I've pushed

I updated debian-unstable branch long time ago.  I don't remember
why I didn't use master, -- probably because previous maintainer
left it that way, when all development happens in debian-unstable
branch not in master branch.  It was my mistake.  I just wanted
to ensure nothing's left in my local repo before I officially step
out of busybox maintainership.

> my local branch as pu/776186. I have the same changes for the jessie
> branch, and initially planned on first getting stuff into unstable, let
> it be tested for a while there, then consider tpu-ing.
> 
> Feel free to incorporate bits of the said branch and upload again to
> unstable; I can then deal with the jessie part later.

I don't understand what you're saying.  I created a mess in git repo
today which I didn't want to create, I apologize for that and am asking
for advise about what to do with it.  It is not a new upload, I didn't
plan to make uploads really.  But I completely lost understanding of
your intentions, -- it was already completely unclear for me why do
you do all this complex things (branching off some earlier revision
rewriting history, etc) when the solution is much much simpler.  Now
I don't understand anything at all.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f730cd.7000...@msgid.tls.msk.ru

Bug#776186: busybox: CVE-2014-9645

[Michael Tokarev]

02.03.2015 19:53, Cyril Brulebois wrote:
> Moritz Muehlenhoff  (2015-03-02):
[]
>> I'm slightly confused here. Is 1:1.22.0-9+deb8u1 different from
>> the upload you mentioned above? 
> 
> It's basically the same thing as I proposed initially, but with
> different changes in the git history because 1. the maintainer was
> calling me a liar; and 2. the uploader didn't want to touch git, so the
> end result is a single commit stating that the NMU was imported, with
> the bug closure.

I was calling you that because of a single word you used - intrusive -
for changes which are a) very localized to d/rules (touching a little
place of it) and b) not affecting anything you care, and especially
not affecting the resulting binaries in any way. And the changes which
were made way before freeze, the package hasn't been unblocked because
of old/buggy glibc installed on some buildds.  And ofcourse I stand
by my words.  Note that much bigger and more intrusive changes were
accepted after the freeze.

>> jessie has CVE-2014-4607 fixed, but not CVE-2014-9645 (which isn't
>> terribly severe and which could be tagged no-dsa if no further
>> busybox upload is planned for jessie).
> 
> I guess someone with enough time could stack this extra change on top of
> the jessie branch, and either let it stay there, or upload the package
> at the same time.
> 
> Sorry, I lost track of that extra fix and didn't think of it when Mehdi
> proposed NMUing it for the first CVE fix.

And now someone please tell me why to do all this.  From a package with
a willing maintainer who cared about the package, from a package which
was in good shape and with all the changes carefully selected for jessie,
to basically an unmaintained package with no one having time to maintain
and no one who cares, exactly the way it was over the years, and which
required a lot of work to get it in some more or less good shape.

Oh well.

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f6cc0d.2090...@msgid.tls.msk.ru

Bug#777140: Using mdadm to install Debian on Intel RST RAID array stopped working between Wheezy 7.8 and Jessie RC1

[Michael Tokarev]

Control: retitle -1 Using mdadm to install Debian on Intel IMSM RAID array 
stopped working between Wheezy 7.8 and Jessie RC1
Control: reassign -1 mdadm
Control: tag -1 + help

05.02.2015 17:43, Benjamin Black wrote:
> Package: debian-installer
> Version: used in Debian GNU/Linux Jessie-DI-rc1 "Jessie" - Official RC amd64 
> CD Binary-1 20150109-01:06 image
> 
> My UEFI motherboard has an Intel RST chip on it, which I use to set up a pair 
> of SSD drives in a RAID-0 array.  I have successfully installed Debian Wheezy 
> on this array in the past, using an expert set up and some manual 
> configuration during the install.  I tried repeating that process using the 
> Jessie RC1 installer, and it failed.
> 
> For Wheezy, I used the image Debian GNU/Linux 7.8.0 "Wheezy" - Official amd64 
> CD Binary-1 20150110-14:43
> 
> For Jessie, I used the image Debian GNU/Linux Jessie-DI-rc1 "Jessie" - 
> Official RC amd64 CD Binary-1 20150109-01:06
> 
> Both images were written to a USB stick, and both installers were booted in 
> UEFI mode.
> 
> To do the installation, I run through the first few steps of the expert 
> install, up to and including detecting disks.  At that point, I switch to the 
> console (Alt-F2), to assemble and start the software arrays.  First I load 
> the kernel modules for RAID, which also loads the md_mod module, and then I 
> execute mdadm to assemble and start the arrays.
> 
> When I do this in Wheezy, it successfully builds the arrays and starts them:
> 
> ~ # modprobe raid0
> ~ # mdadm --assemble --scan --verbose
> mdadm: looking for devices for further assembly
> mdadm: /dev/sdb is identified as a member of /dev/md/imsm0, slot -1.
> mdadm: /dev/sda is identified as a member of /dev/md/imsm0, slot -1.
> mdadm: added /dev/sda to /dev/md/imsm0 as -1
> mdadm: added /dev/sdb to /dev/md/imsm0 as -1
> mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
> mdadm: looking in container /dev/md127
> mdadm: found match on member /md127/0 in /dev/md127
> mdadm: Started /dev/md/Boot_0 with 2 devices
> 
> However, following the same steps in Jessie, mdadm fails to start the array 
> because of some file permission problem:
> 
> ~ # modprobe raid0
> ~ # mdadm --assemble --scan --verbose
> mdadm: looking for devices for further assembly
> mdadm: /dev/sdb is identified as a member of /dev/md/imsm0, slot -1.
> mdadm: /dev/sda is identified as a member of /dev/md/imsm0, slot -1.
> mdadm: added /dev/sda to /dev/md/imsm0 as -1
> mdadm: added /dev/sdb to /dev/md/imsm0 as -1
> mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
> mdadm: cannot open device /dev/md/imsm0: No such file or directory

I don't see any permission problems in here, but indeed, mdadm is
unable to complete the process.

Since this has nothing to do with the installer really, -- you're
trying to assemble the array manually using mdadm and it fails,
I'm reassigning this bugreport to mdadm package.

However, since I don't have hardware where I can test this, I'm
tagging this as "help", -- because I can't debug it myself.  Maybe
someone with the hardware will be able to understand what's going
on.

BTW, does /dev/md/ directory exists?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54d46d00.7080...@msgid.tls.msk.ru

Bug#776566: Please cater to serial consoles

[Michael Tokarev]

29.01.2015 15:12, Samuel Thibault wrote:
> martin f krafft, le Thu 29 Jan 2015 11:52:36 +0100, a écrit :
>>   2. the boot: prompt appears on both, console and serial console,
> 
> Nack with my brltty maintainer hat: you don't want to send things on the
> serial port without the user saying to do this. In the case of braille
> devices, we have already seen some device being bricked by such behavior
> because it unfortunately made the device enter a ROM-flash mode...

Some serial-connected models of Powercom UPSes will turn off power after
seeing this sequence... ;)  I don't remember which code it is exactly,
but it is a single char from lowercase latin letters.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca3029.7010...@msgid.tls.msk.ru

Re: Problem with ACPI on reboot

[Michael Tokarev]

27.01.2015 10:48, Pierre GINDRAUD wrote:
> Hello evryone,
> 
> I'm not sure that is the best mailing list to expose my problem, but I try 
> anyway
> 
> I've bought recently, an motherboard in order to make a simple server in my 
> home, the model is a ASROCK Q2900 ITX (see documentation below)
> http://www.asrock.com/mb/Intel/Q2900-ITX/
> 
> My problem occur when I reboot the MB.
> If I turn off (shutdown -h now) and push physically the power button it 
> successfully restart
> But if I type `reboot` the MB turn off but doesn't power on, the boot freeze 
> just after showing POST screen of the bios.
> 
> During my test, I've try to put "acpi=off" option to kernel and the reboot 
> problem disappear, but this time it's the shutdown process which is impacted. 
> When I type shutdown the system succesfully halt but the MB doesn't 
> physically poweroff
> 
> Can anyone already had a similar problem ?

I had very similar problem with my intel D2500CC board (also mini-itx), and 
before
with similar (also intel) boards with prev-gen Atom CPUs.  In all these cases 
the
prob was a bug in bios and were fixed by updating the bios.  Intel had a fix for
prev-gen atom and the same bug on D2500CC which they fixed later, so I had to 
live
with reboot probs for a while.

In my case the bug was possible to work around by creating an ms-dos bootable
partition on the hdd.

That all to say: the chances are very high that this is a prob in bios.  There's
still a small chance that it is in linux (in kernel in this case), but if that's
the case, debugging it will be quite difficult.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c74ed1.1000...@msgid.tls.msk.ru

Re: Last hints for d-i, upload tomorrow

[Michael Tokarev]

27.01.2015 08:59, Christian PERRIER пишет:
> (CC'ed in case you guys subscribed to -release. I am subscribed
> so please no CC)
> 
> Quoting Michael Tokarev (m...@tls.msk.ru):
> 
>> So you're continuing to ruin my (hard in this case) work, spreading lies
>> (invasive) and confirming you're against others working on debian.
> 
> Given that Cyril is THE person that currently makes Debian Installer
> to happen, I would kindly ask you to refrain on such claims, please.

Yes, I understand full well Cyril's role in the D-I, and I apprecate
it and I'm grateful for that.  Really.  However in this very case, I
told exactly what I think and feel.  And I stand on my words, because
I think it is true and I'm not quite ready to lie yet.  Maybe the same
can be expressed differently and worded better.

Also, the changes in question has nothing to do with the D-I itself,
these are minor changes in packaging and build process which result
in the same binary as used by d-i previously.  So judjing here with
D-I hat on is not exactly wise, because the changes don't affect
D-I.

> You may have disagreements (which I don't share) but please keep the
> tone low and polite.

> We have a good release manager for D-I and, believe me, this is hard
> to find and you probably don't imagine the hard work he has for every
> release. For people who follow Debian closely, they probably noticed
> that Cyril obviously went through hard times recently and I felt some
> kind of demotivation in his mails, sometimes. I would prefer that
> nobody pushes harder in that direction.

Agreed 100%.

> So, well, your work on busybox is very highly appreciated and
> valued. Yes, it was in a bad state and you definitely revived
> it. We're all deeply thankful for that.
> 
>> That's fine with me too.  I can continue maintain local copy of busybox
>> the same way as I did before I took over its maintenance, because in
>> debian it was in *awful* state and mostly unusable.
>>
>> (For the record: all the recent changes I made in busybox is needed for 
>> jessie,
>> I especially and carefully selected the minimal set.  We had it in broken 
>> state
>> for too long.)
> 
> If these changes are needed for jessie, please follow the Debian
> release managers guidelines : point which release critical bugs are
> fixed by these fixes, and aruge with the Release Team about unblocks
> by providing patches (or just copy/pasting them from git) so that one
> release manager can  make his|her own decision, with the help of
> Cyril.

That's the exact procedure I followed, after missing the deadline by a
few days because I was ill myself, and after a long delay dealing with
the static link issue in glibc (#769190).  The RC bug has been filed
exactly due to that issue with static linking (#768876), so, being ill
myself, I rushed to fix it to ensure we wont have the same problem
again somewhere else during jessie lifecycle, thinking it is really
essential to fix it for jessie.  Yes, #768876 is tagged jessie-ignore,
but that was just because Aurelien didn't want to add a "hard" (as it
turned out) bug before freeze.  And yes it took me several iterations
to finally fix it for real.

Now, the only questionable difference between testing and what I think
must be in testing is this adding of Built-Using field for busybox-static
(which does not affect d-i in any way as I mentioned before), and minor
changes to the build procedure to stop building arch-all package when
only arch-specific build is requested - again, does not affect d-i.

While the build changes (arch-all vs arch-specific) aren't exactly
essential (it was trivial to fix, I was just tired stumbling upon
dpkg warning when rebuilding the package while trying to fix #768876),
#768876 itself is essential, well-tested finally, and simple.  Yet
these (packaging-only) changes are being rejected, and I yet to see
a reason for that.

And while doing that, maintainer (me) is being pissed off and discoraged
from even thinking to work on this package again, *and* much more work
is being done to cherry-pick the "really-really-necessary" changes to
fix stupid bugs which are unimportant (because busybox isn't used in
debian in environments where these bugs can be triggered).

This is unfair and even stupid thing to do, because it is a way to
have more work to undo the _necessary_ things and to redo them again
in favour of things which actually aren't important.  Why do more
when we already have enough and the work is already done??

> If that doesn't happen, then you can't hardly complain. Yes that may
> be a PITA work to do because this is indeed really a mandatory
> step. This indeed explains why important changes are better done
> *before* freezes than during

Bug#775164: unblock: mdadm/3.3.2-5

[Michael Tokarev]

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

Please unblock package mdadm

It contains a single noticeable change which fixes a bug which is important
for upgrades from wheezy -- #770883 (https://bugs.debian.org/770883).
The original problem is that udev in wheezy does not understand $devnode
variable in its .rules file, so new mdadm will not work with old udev,
and mdadm does not declare versioned dependency on udev.  Instead of
introducing a versioned dependency (with larger breakage potential), I
decided to fix this by using a variant of .rules file which will work
equally well with both old and new versions of udev.

There are 2 other changes in the package - adding forgotten bug numbers
into debian/changelog to the points/versions when these bugs has been
fixed.

The package has been in testing in this form for a long time already.

When unblocking mdadm, it should be unblocked for the debian installer
too since it produces udeb too.

Thanks,

/mjt

unblock mdadm/3.3.2-5
unblock-udev mdadm/3.3.2-5


diff -Nru mdadm-3.3.2/debian/changelog mdadm-3.3.2/debian/changelog
--- mdadm-3.3.2/debian/changelog2014-12-05 17:29:22.0 +0300
+++ mdadm-3.3.2/debian/changelog2014-12-20 11:48:54.0 +0300
@@ -1,8 +1,20 @@
+mdadm (3.3.2-5) unstable; urgency=medium
+
+  * use-tempnode-not-devnode.patch: change udev rules file to use
+$tempnode which works both on wheezy and jessie udev, instead
+of $devnode which only works in jessie.  At this stage it is
+better to make rules file compatible with old version instead
+of adding versioned dependency.  Should be removed for jessie+1.
+(Closes: #770883)
+  * fix Closes: list in previous entry (Closes: #771852)
+
+ -- Michael Tokarev   Sat, 20 Dec 2014 11:48:44 +0300
+
 mdadm (3.3.2-4) unstable; urgency=medium
 
   * really remove /var/lib/mdadm in postinst, fixing a brown-paper bag
 bug in previous upload (I fixed it earlier but forgot to commit it
-before 3.3.2-3 release).  (Closes: #764036 #771852)
+before 3.3.2-3 release).  (Closes: #764036, #771852)
   * mention closing of #588965 #599352 #694513 by 3.3-1
 
  -- Michael Tokarev   Fri, 05 Dec 2014 17:29:22 +0300
@@ -84,7 +96,7 @@
 mdadm (3.3-1) unstable; urgency=low
 
   [ Michael Tokarev ]
-  * new upstream 3.3 release (Closes: #718896 #588965 #599352 #694513)
+  * new upstream 3.3 release (Closes: #718896, #588965, #599352, #694513)
 See ANNOUNCE-3.3 for details.
 Patches:
 - refreshed debian-conffile-location.diff
diff -Nru mdadm-3.3.2/debian/patches/series mdadm-3.3.2/debian/patches/series
--- mdadm-3.3.2/debian/patches/series   2014-11-14 19:16:41.0 +0300
+++ mdadm-3.3.2/debian/patches/series   2014-12-05 18:59:42.0 +0300
@@ -2,6 +2,7 @@
 debian-no-Werror.diff
 sha1-includes.diff
 use-external-blkid.diff
+use-tempnode-not-devnode.patch
 build-sys-no-check_rundir.patch
 rebuildmap-strip-local-host-name-from-device-name.patch
 readlink-path.patch
diff -Nru mdadm-3.3.2/debian/patches/use-tempnode-not-devnode.patch 
mdadm-3.3.2/debian/patches/use-tempnode-not-devnode.patch
--- mdadm-3.3.2/debian/patches/use-tempnode-not-devnode.patch   1970-01-01 
03:00:00.0 +0300
+++ mdadm-3.3.2/debian/patches/use-tempnode-not-devnode.patch   2014-12-05 
19:10:18.0 +0300
@@ -0,0 +1,31 @@
+From: Michael Tokarev 
+Subject: use tempnode not devnode in udev rules
+Bug-Debian: http://bugs.debian.org/770883
+Forwarded: no
+
+udev in wheezy does not understand $devnode construct
+in rules file, while upstream uses it in mdadm rules
+files.  udev in jessie has $devnode and it also supports
+old $tempnode which is the way it worked in wheezy and
+before, even if $tempnode in jessie's udev is not documented.
+So on jessie, both $tempnode and $devnode works fine, while
+in wheezy, only $tempnode works.
+
+Use $tempnode instead of $devnode.  Since mdadm is important
+enough for system functionality and easily can break system
+by making it unbootable, and this is the only incompatibility
+between wheezy's and jessie's udev wrt mdadm, it is better than
+having a versioned dependency on udev.
+
+This patch is debian-specific and should be dropped for jessie+1.
+
+--- a/udev-md-raid-arrays.rules
 b/udev-md-raid-arrays.rules
+@@ -20 +20 @@
+-IMPORT{program}="BINDIR/mdadm --detail --export $devnode"
++IMPORT{program}="BINDIR/mdadm --detail --export $tempnode"
+--- a/udev-md-raid-assembly.rules
 b/udev-md-raid-assembly.rules
+@@ -30 +30 @@
+-ACTION=="add|change", IMPORT{program}="BINDIR/mdadm --incremental --export 
$devnode --offroot ${DEVLINKS}"
++ACTION=="add|change", IMPORT{program}="BINDIR/mdadm --incremental --export 
$tempnode --offroot ${DEVLINKS}"


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lis

Re: Bug#771208: unblock: busybox/1:1.22.0-14

[Michael Tokarev]

11.12.2014 13:02, Cyril Brulebois wrote:
> Hi,

Hello

> can you please still push your master branch and tags to the git
> repository? Last commit there points to debian/1.22.0-9 which is
> 5 revisions old, at least if I'm reading cgit and gitk properly.

Oh yeah.  I'm sorry about that.  Pushed now.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54896d0a.70...@msgid.tls.msk.ru

Re: Bug#771208: unblock: busybox/1:1.22.0-14

[Michael Tokarev]

11.12.2014 10:52, Ivo De Decker wrote:
[]
> As the libc issue with the static binary seems to be fixed in the libc version
> in both jessie and sid, the only remaining issue is the missing build-using,
> which can wait till after jessie.
> 
> Could you do a new upload with only the security fix?

I'll leave this and other maintenance of busybox to others.

I especially selected only the changes which I think are necessary for jessie.
But since we obviously have different criteria for this, and for some other
things too, I'd rather not mess up with the package further.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548967db.4050...@msgid.tls.msk.ru

Bug#768876: unblock: busybox/1:1.22.0-14

[Michael Tokarev]

So, can someone please tell me what's wrong with
this unblock request?

I can try to fix built-using generation adding gcc
to the mix but I'm afraid to do that this late in
the release cycle, especially after it required so
many iterations to get the most important in this
context part of built-using.  Note that this most
important part - which prompted the original bug
report wrt built-using - is here with proper
value (it is glibc which had bug in several
versions, producing buggy static binaries).

Thanks,

/mjt

28.11.2014 18:33, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Michael Tokarev wrote:
> 
>> Um.  Maybe we should assume exact versions of software running in
>> buildds too?
> 
> No, only things that end up in the binaries.
> 
>> BTW, how about somethig like gcc -v (I'm not sure it is the right
>> option actually) which shows all libs it actually used for linking -
> 
> Yes, except that is not parsable, and varies by compiler.
> 
>> run it once, find out all actual libs and go from there, translating
>> the list to debian package names.  I think _that_ will be the only
>> real thing.
> 
> I agree. Maybe -Wl,-v or -Wl,-t instead. We always use binutils…
> but these options also have their shortcomings.
> 
>> Besides, this process should be automated with some helper, something
>> like dh_built-using, I dunno.  Or else, due to the fact that it is
> 
> No, this requires intimate knowledge of the build system in use;
> autoconf will break during the configure phase if you use some
> compiler flags (like -Werror) for example, so you have to inject
> that flag somewhere.
> 
> Also, not everything is always static, and if you build multiple
> binary packages, you need to track what is what anyway.
> 
> I think that, for B-U, we can’t find a generic solution.
> 
>> Oh well.  Do you think I should reopen this bugreport?
> 
> I think you probably only should add the libgcc.a provider
> and cross fingers for now. B-U are not unimportant, but a
> real PITA anyway right now.
> 
> bye,
> //mirabilos
> 


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547c8f31.4040...@msgid.tls.msk.ru

Bug#768876: unblock: busybox/1:1.22.0-14

[Michael Tokarev]

28.11.2014 18:06, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Michael Tokarev wrote:
> 
>>> ‣ intimate knowledge of the build system required, so you know
>>>   what precidely is pulled in (reading shlibs:Depends from the
>>>   build of the shared version is almost certainly wrong)
>>
>> Why it is wrong?  To be this looks like the most accurate approach

it supposed to be "To me".

> The builds probably differ, especially when using autoconf.

Probably?  If they differ it is a bug which should be fixed.

In this case it is irrelevant because busybox only uses libc
and probably libm which both comes form the same package anyway
(plus whatever libgcc it is pulling in too).  Even if some other
lib will be used, the same lib will be used for both static and
non-static versions.

>>> In *all* cases, you also need
>>>
>>> • x=$(dpkg -S "$(readlink -f "$($CC -print-file-name=libgcc.a)")")
>>>   libgcc_pkgname=${x%%: *}
>>
>> Why?
> 
> Because some of these functions do end up in the resulting executable.
> 
>> This assumes it is gcc an it uses libgcc, so it wont work with,
>> say, clang.
> 
> True. But either “clang -print-file-name=libgcc.a” will be empty,
> or it will report libgcc.a which may or may not be pulled in. But
> archive builds are not done using clang _yet_. I’ll revisit this
> when that option exists, or so. It’s too fast moving a target at
> the moment, anyway.

Um.  Maybe we should assume exact versions of software running in
buildds too?  I don't think this approach scales, to me it is wrong,
and we should use some more generic way.

BTW, how about somethig like gcc -v (I'm not sure it is the right
option actually) which shows all libs it actually used for linking -
run it once, find out all actual libs and go from there, translating
the list to debian package names.  I think _that_ will be the only
real thing.

But for now, current way to construct built-using from shlibdeps,
maybe adding libgcc/gcc too on the way should be enough, for this
very package anyway.  And more, I'm not sure at all I want to
perform another series of experiments while asking for an unblock...

Besides, this process should be automated with some helper, something
like dh_built-using, I dunno.  Or else, due to the fact that it is
very difficult to get the value right, we'll have it all wrong, and
differently wrong in every place too.

>> Note also that if libgcc is used by shared build, it will
>> also be listed in shilbdeps.
> 
> Fallacy. I know GCC interna better than I wish to. Most of
> libgcc.a is always put into binaries; the shared libgcc is
> mostly the libgcc_eh.a equivalent, and -static-libgcc is,
> normally, the default for C language builds. (Also, it’s a
> good way to keep the GCC version used to build it in the
> archive.)

Oh well.  Do you think I should reopen this bugreport?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54789336.3040...@msgid.tls.msk.ru

Bug#768876: unblock: busybox/1:1.22.0-14

[Michael Tokarev]

28.11.2014 15:11, Thorsten Glaser wrote:
> On Thu, 27 Nov 2014, Michael Tokarev wrote:
> 
>> (The Built-Using field generation is a bit fun here: I asked on IRC
>> how people identify which libc is in use, and got various somewhat-
>> incpmplete replies (the prob is that on different arches, libc package
>> is named differently).  So I invented my own way for busybox, because
> 
> You didn’t ask in the #!/bin/mksh channel on IRC (= Freenode) ;-)

I asked in several debian-related places, since this is a debian-specific
thing.

> So let me add mine:
> 
> ‣ intimate knowledge of the build system required, so you know
>   what precidely is pulled in (reading shlibs:Depends from the
>   build of the shared version is almost certainly wrong)

Why it is wrong?  To be this looks like the most accurate approach
really.

> In the mksh case, I have a switch between different libcs to use.
> For dietlibc and klibc, the cases are clear:

Wug.

[]
> In *all* cases, you also need
> 
> • x=$(dpkg -S "$(readlink -f "$($CC -print-file-name=libgcc.a)")")
>   libgcc_pkgname=${x%%: *}

Why?  This assumes it is gcc an it uses libgcc, so it wont work with,
say, clang.  Note also that if libgcc is used by shared build, it will
also be listed in shilbdeps.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54788e02.7010...@msgid.tls.msk.ru

Re: Bug#771208: unblock: busybox/1:1.22.0-14

[Michael Tokarev]

27.11.2014 19:00, Cyril Brulebois wrote:
> (Putting on my d-i RM fedora.)

Thank you for your review.

> Michael Tokarev  (2014-11-27):
>> Please unblock package busybox.  Last upload has one security bugfix
>> (CVE-2014-4607, #768945), the fix is from upstream stable branch,
>> fixing an integer overflow in lzo decompressor; it adds a Built-Using
>> control field for busybox-static variant (#768926), and also arranges
>> build system to only produce binary or indep .debs (or both), depending
>> on the d/rules target (binary-all vs binary-indep vs binary) -- this
>> is a long-standing lintian bug which I overlooked previously.
> 
> #768926 is still not #768876:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768926#28

Yes you're right.  I fixed it in the changelog but not in this unblock
request.  Actual bug fixed here is #768876.

[]
> #768876 is tagged jessie-ignore so I'm really unconvinced by the
> debian/rules changes.

It is jessie-ignore just to be non-RC.  The fun with static linking
and bugs it discovered shows that proper Built-Using field is really
necessary (it is what #768876 is about).

However, bulk of d/rules changes are due to another build fix, to
stop building arch-all package (busybox-syslogd) when building
binary-arch.  Plus one block of added lines to check whenever
libc is able to produce working statically-linked executables.

> At this stage, I'd rather see the security fix only.
> 
> Release team people, what's your take on this?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54774c91.9080...@msgid.tls.msk.ru

unblock: busybox/1:1.22.0-14

[Michael Tokarev]

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

Please unblock package busybox.  Last upload has one security bugfix
(CVE-2014-4607, #768945), the fix is from upstream stable branch,
fixing an integer overflow in lzo decompressor; it adds a Built-Using
control field for busybox-static variant (#768926), and also arranges
build system to only produce binary or indep .debs (or both), depending
on the d/rules target (binary-all vs binary-indep vs binary) -- this
is a long-standing lintian bug which I overlooked previously.

The busybox-static fix turned out to be a fun case, because I needed
a way to build-conflict on a non-broken libc (because the original
prob is in libc due to #754813), and that turned out to be a not-so-
trivial task, which resulted in several iterations.  Meanwhile I
discovered that current glibc is not able to produce working stati-
cally linked executables on hurd which uses nss functions --
statically linked executable on hurd just segfaults.  So now,
after a fix for #768926, busybox package does not build on hurd,
while previously it silently produced failing busybox-static.
Hurd people are working on the fix.

(The Built-Using field generation is a bit fun here: I asked on IRC
how people identify which libc is in use, and got various somewhat-
incpmplete replies (the prob is that on different arches, libc package
is named differently).  So I invented my own way for busybox, because
this package allows me to do that -- I took the contents of $shlibs:Depends
variable for the dynamically-linked version, and transformed it into
a list of sources required for Built-Using using dpkg-query.)

There's no code changes except the lzo decompression bugfix, only
packaging changes.

Since busybox is used in d-i too, I kindly request for a
udeb-unblock too.

Previously I submitted an unblock request for busybox 1.22.0-10,
as #769129, but that turned out to be a bit preliminary because
of the fun with libc versioned build dependency iterations.

Thank you!

/mjt

unblock busybox/1:1.22.0-14

diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2014-09-30 08:50:20.0 +0400
+++ busybox-1.22.0/debian/changelog 2014-11-14 12:53:24.0 +0300
@@ -1,3 +1,46 @@
+busybox (1:1.22.0-14) medium; urgency=low
+
+  * one more attempt to fix the glibc build-depend for #769190, now
+using versioned build-dependency on libc-dev-bin which is named
+this way on all architectures (unlike libc6|libc6.1|libc0.1|libc0.3)
+
+ -- Michael Tokarev   Fri, 14 Nov 2014 12:52:18 +0300
+
+busybox (1:1.22.0-13) unstable; urgency=medium
+
+  * really fix #769190 the hard way, by build-conflicting with all
+arch-specific names of libc with version <2.19-12 (Closes: #769190)
+  * check if glibc can produce working statically linked binaries
+by performing a getpwnam("root") call before building (#754813)
+
+ -- Michael Tokarev   Wed, 12 Nov 2014 23:59:30 +0300
+
+busybox (1:1.22.0-12) unstable; urgency=medium
+
+  * fix the previous changelog entry (wrong bug# was "fixed" and typos)
+  * ensure we build against non-broken glibc (>=2.19-12) (Closes: #769190)
+
+ -- Michael Tokarev   Wed, 12 Nov 2014 12:37:11 +0300
+
+busybox (1:1.22.0-11) unstable; urgency=medium
+
+  * fix the built-using generation in the previous upload -- did not
+work correctly for != 1 dependency and #588505 in dpkg
+
+ -- Michael Tokarev   Tue, 11 Nov 2014 19:24:21 +0300
+
+busybox (1:1.22.0-10) unstable; urgency=high
+
+  * lzop-add-overflow-check-CVE-2014-4607.patch (Closes: #768945)
+  * add Built-Using control field for -static, deriving it from
+regular build (this will be glibc) (Closes: #768876)
+  * install only arch/indep deb as requested by binary-arch or binary-indep
+target.  This fixes a long-standing lintian error, when package build
+always produces busybox-syslogd package which is arch:all and should not
+    be built on a buildd.
+
+ -- Michael Tokarev   Tue, 11 Nov 2014 17:07:34 +0300
+
 busybox (1:1.22.0-9) unstable; urgency=medium

   * cherry-pick find /BITS patch from upstream (Closes: #760637)
diff -Nru busybox-1.22.0/debian/control busybox-1.22.0/debian/control
--- busybox-1.22.0/debian/control   2014-09-30 08:35:20.0 +0400
+++ busybox-1.22.0/debian/control   2014-11-14 12:52:17.0 +0300
@@ -5,7 +5,10 @@
 Uploaders: Bastian Blank , Michael Tokarev 
 Build-Depends: debhelper (>= 9),
 # needs for testsuite to run
-  zip
+  zip,
+# glibc static-nss #754813, 2.19..2.19-11, -12 is ok. Depend on libc-dev-bin
+# as it is the package which is named the same on all architectures
+ libc-dev-bin (>> 2.19-12~) | libc-dev-bin (<< 2.19),
 Standards-Version: 3.9.5
 Vcs-Git: git://anonscm.debian.org/d-i/busybox.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/busybox.git
@@ -33,6 +36,7 @@

 Package: 

Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload

[Michael Tokarev]

13.11.2014 00:03, Michael Tokarev пишет:
> 12.11.2014 22:45, Aurelien Jarno wrote:
>> On Wed, Nov 12, 2014 at 09:17:20PM +0400, Michael Tokarev wrote:
>>> Should I list them all in the build-deps?  If yes, what's the complete list?
> 
>> It should be libc6-dev[linux-any !alpha !ia64] | libc6.1-dev [alpha ia64] | 
>> libc0.1-dev (>> 2.19-12~) [kfreebsd-any] | libc0.3 (2.19-12~) [hurd-any]
> 
> Please double-check:
> 
> Build-Depends:
> # glibc static-nss #754813, 2.19..2.19-11, -12 is ok
>  libc6-dev (>> 2.19-12~) [linux-any !alpha !ia64] |
>  libc6-dev (<< 2.19) [linux-any !alpha !ia64] |

This does not work.

  conflicting-negation-in-source-relation build-depends: libc6-dev (>> 
2.19-12~) [linux-any !alpha !ia64]

It looks like the arch strings in []s must either be
all positive or all negative, but not a mix.

So this becomes insane.  I'll just add a build-time check for it.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5463d95c.4000...@msgid.tls.msk.ru

Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload

[Michael Tokarev]

12.11.2014 22:45, Aurelien Jarno wrote:
> On Wed, Nov 12, 2014 at 09:17:20PM +0400, Michael Tokarev wrote:
>> Should I list them all in the build-deps?  If yes, what's the complete list?

> It should be libc6-dev[linux-any !alpha !ia64] | libc6.1-dev [alpha ia64] | 
> libc0.1-dev (>> 2.19-12~) [kfreebsd-any] | libc0.3 (2.19-12~) [hurd-any]

Please double-check:

Build-Depends:
# glibc static-nss #754813, 2.19..2.19-11, -12 is ok
 libc6-dev (>> 2.19-12~) [linux-any !alpha !ia64] |
 libc6-dev (<< 2.19) [linux-any !alpha !ia64] |
 libc6.1-dev (>> 2.19-12~) [alpha ia64] |
 libc6.1-dev (<< 2.19) [alpha ia64] |
 libc0.1-dev (>> 2.19-12~) [kfreebsd-any] |
 libc0.1-dev (<< 2.19) [kfreebsd-any] |
 libc0.3-dev (>> 2.19-12~) [hurd-any] |
 libc0.3-dev (<< 2.19) [hurd-any],

Since this is all alternatives, is it really necessary to list the [arch]
names?  I mean, just list of pkgs with versions should be enough I think,
each arch will pick the right name, no?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5463cb2b.9050...@msgid.tls.msk.ru

Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload

[Michael Tokarev]

12.11.2014 21:05, Aurelien Jarno wrote:
[]
>> And there's nothing I can do about this on busybox side -- except,
>> again, adding a versioned build-dep.
> 
> I'll schedule binNMUs for now, but it might be a good idea to add a
> versioned build-dep so that it doesn't happen again.

Please don't.  I want to fix it for real today, one way or another.

And this brings an interesting question:  how to add this build-dep?

I tried adding build-depends: libc-bin (>>2.19-12~) | libc-bin (<<2.19)

but this one just pulls the libc-bin package not libc6 and libc6-dev.

Ofcourse I thouht about using libc6[-dev] in this context, but immediately
come across the fact that on different arches, libc is named differently
(libc6.1, libc0.3 etc).

Should I list them all in the build-deps?  If yes, what's the complete list?

(I tried to keep it buildable on older glibc too; but it's ofcourse possible
to add a build-conflicts: libc6 (<<2.19-12), libc6.1 (<<2.19-12) etc --
this is easier than listing two versions for each)

Another thought is to add a build-time test that the thing actually work
(eg, busybox-static ping localhost or something, or a small separate
program to be run before real build) -- with this in mind, it might not
be even required to add a build-dep, -- build will just fail with a
friendly message telling to fix glibc...

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54639620.5000...@msgid.tls.msk.ru

Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload

[Michael Tokarev]

BTW, the bug is _not_ fixed by -12 upload where I added a build-dep on libc-bin.

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546396a3.1000...@msgid.tls.msk.ru

Bug#769190: busybox-static: DNS resolver is broken again with the last upload

[Michael Tokarev]

12.11.2014 04:27, Diederik de Haas wrote:
> Package: busybox-static
> Version: 1:1.22.0-11
> Severity: important
> 
> This is basically the same error as with bug #757941, but it was
> reassigned to glibc and fixed there. As Aurelien Jarno correctly stated
> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757941#120
> it was indeed fixed with version 1.22.0-9+b1, which I have verified.
> 
> However, I just received version 1.22.0-11 of busybox-static and now it
> fails again:

Now this is funny.  Should I add a versioned build-dependency against
libc6-dev perhaps?

Because, according to the build log of amd64 (that's your arch), the
package has been built against glibc (= 2.19-11) -- grep for Built-Using
in the build log:

 
https://buildd.debian.org/status/fetch.php?pkg=busybox&arch=amd64&ver=1%3A1.22.0-11&stamp=1415729242

now I wonder how the -9+b1 version has been built against fixed
glibc-2.19-12 while at least one of amd64 buildds have -11 ?

And there's nothing I can do about this on busybox side -- except,
again, adding a versioned build-dep.

Aurelien?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5463120f.6030...@msgid.tls.msk.ru

Bug#768876: Bug#768926: Wrong bug number fixed?

[Michael Tokarev]

12.11.2014 04:35, Diederik de Haas wrote:
> Bug nr 768926 is filed against qemu-user-static, and was supposedly fixed 
> with 
> busybox version 1.22.0-10
> My guess is that that upload was supposed to fix bug nr 768876 and not 768926

Yes, you're exactly right.  This is what happens when I do things in a hurry.
I'll fix the mess, thank you for noticing this.

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54630ab3.8010...@msgid.tls.msk.ru

Re: Bug#769129: unblock: busybox/1:1.22.0-10

[Michael Tokarev]

11.11.2014 18:08, Michael Tokarev wrote:
> Please unblock package busybox.  Last upload has one security bugfix
> (CVE-2014-4607, #768945), the fix is from upstream stable branch,
> fixing an integer overflow in lzo decompressor; it adds a Built-Using
> control field for busybox-static variant (#768926), and also arranges
> build system to only produce binary or indep .debs (or both), depending
> on the d/rules target (binary-all vs binary-indep vs binary) -- this
> is a long-standing lintian bug which I overlooked previously.
> 
> (The Built-Using field generation is a bit fun here: I asked on IRC
> how people identify which libc is in use, and got various somewhat-
> incpmplete replies (the prob is that on different arches, libc package
> is named differently).  So I invented my own way for busybox, because
> this package allows me to do that -- I took the contents of $shlibs:Depends
> variable for the dynamically-linked version, and transformed it into
> a list of sources required for Built-Using using dpkg-query.

So this was a bit preliminary (following the "notify the release team
early" rule too aggressively) -- this very Built-Using generation was
broken due to an error on my part (trivial) and due to bug in dpkg,
#588505.  I just uploaded new release fixing this, 1:1.22.0-11, will
see how it goes first, and will ping this bug if everything is okay.
(Yes, I verified the fixed release builds on kfreebsd-amd64 where
the problematic release failed).

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5462412b.7060...@msgid.tls.msk.ru

unblock: busybox/1:1.22.0-10

[Michael Tokarev]

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

Please unblock package busybox.  Last upload has one security bugfix
(CVE-2014-4607, #768945), the fix is from upstream stable branch,
fixing an integer overflow in lzo decompressor; it adds a Built-Using
control field for busybox-static variant (#768926), and also arranges
build system to only produce binary or indep .debs (or both), depending
on the d/rules target (binary-all vs binary-indep vs binary) -- this
is a long-standing lintian bug which I overlooked previously.

(The Built-Using field generation is a bit fun here: I asked on IRC
how people identify which libc is in use, and got various somewhat-
incpmplete replies (the prob is that on different arches, libc package
is named differently).  So I invented my own way for busybox, because
this package allows me to do that -- I took the contents of $shlibs:Depends
variable for the dynamically-linked version, and transformed it into
a list of sources required for Built-Using using dpkg-query.

There's no code changes except the lzo decompression bugfix, only
packaging changes.

Thank you!

/mjt

unblock busybox/1:1.22.0-10

diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2014-09-30 08:50:20.0 +0400
+++ busybox-1.22.0/debian/changelog 2014-11-11 17:07:46.0 +0300
@@ -1,3 +1,15 @@
+busybox (1:1.22.0-10) unstable; urgency=high
+
+  * lzop-add-overflow-check-CVE-2014-4607.patch (Closes: #768945)
+  * add Built-Using control field for -static, deriving it from
+regular build (this will be glibc) (Closes: #768926)
+  * install only arch/indep deb as requested by binary-arch or binary-indep
+target.  This fixes a long-standing lintian error, when package build
+alway produces busybox-syslogd package which is arch:all and should not
+be built on a buildd.
+
+ -- Michael Tokarev   Tue, 11 Nov 2014 17:07:34 +0300
+
 busybox (1:1.22.0-9) unstable; urgency=medium
 
   * cherry-pick find /BITS patch from upstream (Closes: #760637)
diff -Nru busybox-1.22.0/debian/control busybox-1.22.0/debian/control
--- busybox-1.22.0/debian/control   2014-09-30 08:35:20.0 +0400
+++ busybox-1.22.0/debian/control   2014-11-10 15:06:53.0 +0300
@@ -33,6 +33,7 @@
 
 Package: busybox-static
 Architecture: any
+Built-Using: ${built-using}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Conflicts: busybox
 Replaces: busybox
diff -Nru 
busybox-1.22.0/debian/patches/lzop-add-overflow-check-CVE-2014-4607.patch 
busybox-1.22.0/debian/patches/lzop-add-overflow-check-CVE-2014-4607.patch
--- busybox-1.22.0/debian/patches/lzop-add-overflow-check-CVE-2014-4607.patch   
1970-01-01 03:00:00.0 +0300
+++ busybox-1.22.0/debian/patches/lzop-add-overflow-check-CVE-2014-4607.patch   
2014-11-10 15:06:53.0 +0300
@@ -0,0 +1,67 @@
+From a9dc7c2f59dc5e92870d2d46316ea5c1f14740e3 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Mon, 30 Jun 2014 10:14:34 +0200
+Subject: lzop: add overflow check
+Bug-Debian: http://bugs.debian.org/768945
+
+See CVE-2014-4607
+http://www.openwall.com/lists/oss-security/2014/06/26/20
+
+function old new   delta
+lzo1x_decompress_safe   10101031 +21
+
+Signed-off-by: Denys Vlasenko 
+---
+ archival/libarchive/liblzo.h  |2 ++
+ archival/libarchive/lzo1x_d.c |3 +++
+ 2 files changed, 5 insertions(+)
+
+diff --git a/archival/libarchive/liblzo.h b/archival/libarchive/liblzo.h
+index 843997c..4596620 100644
+--- a/archival/libarchive/liblzo.h
 b/archival/libarchive/liblzo.h
+@@ -76,11 +76,13 @@
+ #define TEST_IP (ip < ip_end)
+ #define NEED_IP(x) \
+ if ((unsigned)(ip_end - ip) < (unsigned)(x))  goto input_overrun
++#define TEST_IV(x)  if ((x) > (unsigned)0 - (511)) goto 
input_overrun
+ 
+ #undef TEST_OP  /* don't need both of the tests here */
+ #define TEST_OP 1
+ #define NEED_OP(x) \
+ if ((unsigned)(op_end - op) < (unsigned)(x))  goto output_overrun
++#define TEST_OV(x)  if ((x) > (unsigned)0 - (511)) goto 
output_overrun
+ 
+ #define HAVE_ANY_OP 1
+ 
+diff --git a/archival/libarchive/lzo1x_d.c b/archival/libarchive/lzo1x_d.c
+index 9bc1270..40b167e 100644
+--- a/archival/libarchive/lzo1x_d.c
 b/archival/libarchive/lzo1x_d.c
+@@ -92,6 +92,7 @@ int lzo1x_decompress_safe(const uint8_t* in, unsigned in_len,
+   ip++;
+   NEED_IP(1);
+   }
++  TEST_IV(t);
+   t += 15 + *ip++;
+   }
+   /* copy literals */
+@@ -224,6 +225,7 @@ int lzo1x_decompress_safe(const uint8_t* in, unsigned 
in_len,
+   ip++;
+   

Bug#768945: busybox lzo implementation suffers from CVE-2014-4607 flaw

[Michael Tokarev]

Source: busybox
Version: 1:1.22.0-5
Severity: serious
Tags: security patch upstream fixed-upstream

Busybox embeds mini-lzo library implementation which suffers
from CVE-2014-4607 -- integer overflow with memory corruption
potential and a risk of (remote) code execution, see
http://www.openwall.com/lists/oss-security/2014/06/26/20 for
details.

This flaw has been fixed in busybox upstream in commit
a9dc7c2f59dc5e92870d2d46316ea5c1f14740e3.

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141110105759.26128.19795.reportbug@gandalf.local

Bug#611250: please support network bonding

[Michael Tokarev]

Maybe it is really better to postprone bonding configuration until
past installation?  As far as I understand, bonding is entirely
optional and is intended to make network faster and more reliable.
It is not exactly necessary during install, and can be made later.
But more feature makes d-i complex for both developers and users...

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545dfbdd.8060...@msgid.tls.msk.ru

Re: Bug#762762: Updating isc-dhcp udeb to dynamically link bind

[Michael Tokarev]

31.10.2014 13:42, Herbert Kaminski wrote:
> On Thu, 30 Oct 2014 22:37:24 +
> Steven Chamberlain  wrote:
> 
>> On 20/10/14 01:09, Michael Gilbert wrote:
>>> The new isc-dhcp is now uploaded.  Please let me know how your testing goes.
>>
>> After the upload of bind9/1:9.9.5.dfsg-5, this does seem to be working
>> well now in sid d-i.  Thanks.
> 
> Just tested the netinst daily image as of 2014-10-31: 
> dhcp now works again in the installer.

Is it on kfreebsd, or on linux kernel too?  I wonder maybe we should
switch to isc-dhcp on all variants/arches, and ditch udhcpc...

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54536809.2020...@msgid.tls.msk.ru

Re: Are there packages for which NO upload is wished right now?

[Michael Tokarev]

03.10.2014 08:47, Christian PERRIER wrpte:
> Hello,
> 
> 3 packages currentrly have pendign changes in git:
> 
> ./busybox/debian/changelog

I uploaded busybox a few days ago, with the mentioned plus a few
other unreliated to d-i changes a few days ago, but forgot to
sync a git repository.  Did so now, here's the complete changelog
from busybox:

busybox (1:1.22.0-9) unstable; urgency=medium

  * cherry-pick find /BITS patch from upstream (Closes: #760637)
  * clean-up provides/replaces/conflicts of busybox-syslogd from referencs
to klogd/sysklogd/inetutils-syslogd, only keep virtual packages
{linux-kernel,system}-log-daemon in there (Closes: #730059)
  * test for /run/systemd/system in busybox-klogd initscript and exit
if present, to not conflict with systemd klogd functions
  * do not pass extra params to dh_installinit (using dep-based ordering)

 -- Michael Tokarev   Tue, 30 Sep 2014 08:50:20 +0400

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542e2db2.4040...@msgid.tls.msk.ru

Bug#730059: busybox-syslogd conflicts with systemd

[Michael Tokarev]

Control: tag -1 - wontfix

29.09.2014 13:56, Trent W. Buck wrote:
> Michael Tokarev wrote:
> 
>> It is not the init script, it is the busybox syslog implementation.
>> For simplicity, it is one applet that does both syslog function and
>> klogd function, and klogd function is not optional.
> 
> Er, are you sure?

Errr not.  That was a definitive -ENOCOFFEE.

I stand corrected.  Yes you're absolutely right, that's 2 separate applets,
with 2 separate initscripts for them included in busybox-syslogd package.

I just cleaned up Provides/Replaces/Conflicts lines of busybox-syslogd
package, so this conflict should be fixed.

I also added a line to busybox-klogd to stop starting it when systemd is
running.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542a6100.1030...@msgid.tls.msk.ru

Bug#730059: busybox-syslogd conflicts with systemd

[Michael Tokarev]

Control: tag -1 - moreinfo + wontfix
11.09.2014 09:49, Trent W. Buck wrote:
> In fact busybox-syslogd is the *only* package with
>   Provides: klogd
> the others seem to
>  Provides: linux-kernel-log-daemon
> 
> I don't understand why this is the case.
> Does the difference signify a different interface,
> or is it just an oversight?
> 
> The point is probably moot since journalctl replaces it, but couldn't
> the busybox-syslogd init script say "if pid1 is systemd, start syslogd
> but not klogd" ?

It is not the init script, it is the busybox syslog implementation.
For simplicity, it is one applet that does both syslog function and
klogd function, and klogd function is not optional.  In order to
stop providing klogd, someone should write a patch for busybox
(upstream, because I for one don't want to make debian-specific
changes to busybox) to make klogd function optional, after which
it will be possible to adjust initscript to run syslogd without
klogd if systemd is running.

Tagging as wontfix for now.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5428fd4c.7010...@msgid.tls.msk.ru

Bug#756593: busybox's switch_root makes read-only NFS root read/write

[Michael Tokarev]

[Rehashing a somewhat old thread...]
08.08.2014 14:55, Zimmermann, Alexander wrote:

> So here is the full output. Vanilla Linux 3.16. No patches. There is 
> definitely something
> broken in the userland. I will set up a new image via debootstrap next week.

So, Alexander, did you succeed in finding what turns your root
read-write?  Since you confirm the bug is not in busybox, I'm
about to close this bugreport, or maybe we should reassign it
to some other package instead, because it contains quite some
useful debugging information and it'd be sad if this info will
be lost...

I still can't reproduce the problem you describe.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5428fe0d.80...@msgid.tls.msk.ru

Bug#763073: partman-md places first line of mdadm.conf to wrong file

[Michael Tokarev]

Package: partman-md
Version: 70
Severity: normal
Tags: patch

finish-install.d/65partman-md reads:

 CF=/target/etc/mdadm/mdadm.conf
 if ... then
mkdir -p /target/etc/mdadm
echo "# Autogenerated by partman-md. See mdadm.conf(5) for more details 
on this file." > /etc/mdadm.conf
echo "DEVICE partitions" >> $CF
...

and all subsequent lines adds information to $CF.
But the very first line, the "Autogenerated.." header
line, is put into d-i filesystem, where it is not used.
The intention was, obviously, to put it to target
mdadm.conf, ie, to $CF.

Appended patch does just that.  While at it, it also
replaces argument of mkdir to be ${CF%/*}, to keep
path info in only one place, in CF variable assignment
( ${var%pattern} construct works with dash too).

Thanks,

/mjt
--- partman-md/finish-install.d/65partman-md.orig
+++ partman-md/finish-install.d/65partman-md
@@ -2,8 +2,8 @@
 CF=/target/etc/mdadm/mdadm.conf
 if [ ! -s "$CF" ] && [ -e /proc/mdstat ] && \
grep ^md /proc/mdstat >/dev/null; then
-	mkdir -p /target/etc/mdadm
-	echo "# Autogenerated by partman-md. See mdadm.conf(5) for more details on this file." > /etc/mdadm.conf
+	mkdir -p ${CF%/*}
+	echo "# Autogenerated by partman-md. See mdadm.conf(5) for more details on this file." > $CF
 	echo "DEVICE partitions" >> $CF
 	if [ "$(udpkg --print-os)" = "kfreebsd" ]; then
 		mount -t linprocfs proc /target/proc

Bug#757941: busybox-static: DNS resolver stopped working in busybox-static version 1.22.0-7

[Michael Tokarev]

21.09.2014 17:19, Diederik de Haas wrote:
> On Tuesday 12 August 2014 21:46:43 Michael Tokarev wrote:
>> Nope.  This is getaddrinfo() function.  So it is glibc, not gcc or
>> optimization.
>>
>> getaddrinfo() does not work in jessie glibc when linked statically.
>> It immediately returns "Name or service not known" (rc=-2) without
>> trying to read /etc/hosts or send dns queries.
> 
> Any news on this bug?
> 
> When I look at the diff from 1.22.0-6 to 1.22.0-7 it indeed doesn't seem 
> likely 
> that the issue is in busybox itself.
> But when you look at the changelog of (e)glibc since 1.22.0-6 was released 
> there has been a new upstream release (2.19) and various patches relating to 
> dns resolving (as far as I can understand it).
> 
> Maybe this should be reassigned to (e)glibc?

This _is_ a glibc problem, and it can be trivially demonstrated by writing
a tiny program that calls, say, getaddrinfo() on its argument.  When built
statically it always returns NOTFOUND, without any attempt to load any
nss modules or make dns queries or even do a /etc/hosts lookup.

More, I don't think reassigning it to glibc will do any good either, because
static linking has been discoraged there for ages.

I'm thinking about building busybox-static against uclibc.  This means
compiling uclibc from uclibc-source during build time, but it is not much
more work than, say, compiling qemu (which also needs to link statically,
but has additional prob because it links with glib which can't be mixed
with uclibc).  But anyway it will be a much bigger change than I'd like
to implement here.

If anyone has better idea please share.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/541ed3e0.9080...@msgid.tls.msk.ru

Bug#757941: busybox-static: DNS resolver stopped working in busybox-static version 1.22.0-7

[Michael Tokarev]

12.08.2014 21:34, Cyril Brulebois wrote:

> Smells like a possible compiler optimization bug? (The relevant code
> might be buggy and falling into undefined behaviour; meaning not a
> compiler bug.) Should be easy to check by building at -O0.

Nope.  This is getaddrinfo() function.  So it is glibc, not gcc or
optimization.

getaddrinfo() does not work in jessie glibc when linked statically.
It immediately returns "Name or service not known" (rc=-2) without
trying to read /etc/hosts or send dns queries.

At link time, there's a warning issued, --

 warning: Using 'getaddrinfo' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking

but even if the same library is installed it doesn't work still.

This makes it.. interesting...

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ea5303.2080...@msgid.tls.msk.ru

Bug#757941: busybox-static: DNS resolver stopped working in busybox-static version 1.22.0-7

[Michael Tokarev]

12.08.2014 21:16, Michael Tokarev wrote:

> jessie does not work.  Also, it is specific to amd64 arch, it does not
> happen on i386 (from 2 variants of x86 arches).

No, i386 jessie does not work too.  It was a very old jessie32 chroot here
where I tried to build it and it worked.  So it looks like the issue is
specific to gcc-4.9.

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ea4ec3.9050...@msgid.tls.msk.ru

Bug#757941: busybox-static: DNS resolver stopped working in busybox-static version 1.22.0-7

[Michael Tokarev]

Control: tag -1 + confirmed

12.08.2014 19:30, Diederik de Haas wrote:
> Package: busybox-static
> Version: 1:1.22.0-8
> Severity: important
> 
> When trying to ping an address, like debian.org, with busybox-static you
> get a "ping: bad address 'debian.org'" error.

Yes, this is what we have.  Current busybox-static in wheezy+ does not
work.

What's interesting - I compiled busybox-static on curent wheezy host,
the resulting binary works fine.  But the same busybox compiled on
jessie does not work.  Also, it is specific to amd64 arch, it does not
happen on i386 (from 2 variants of x86 arches).

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ea4bd6.4050...@msgid.tls.msk.ru

Bug#757316: whole disk one big partition is a bad default

[Michael Tokarev]

07.08.2014 10:35, 積丹尼 Dan Jacobson wrote:
> Package: debian-installer
> 
> Please do not make the default for beginners making the whole disk one
> big partition anymore.
> 
> Just leave a little free space just in case...

How much is "a little" ?

> You never know when they might need to tune their unmounted file system
> etc...

So once we do this, people will start filing bugreports saying that
debian does not use all their HDD space even if told to do so.

I don't think it is right.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e31f89.1090...@msgid.tls.msk.ru

Bug#756593: busybox's switch_root makes read-only NFS root read/write

[Michael Tokarev]

05.08.2014 17:36, Zimmermann, Alexander wrote:

> Despite the fact that I was unable to write a proper wrapper :-) - the kernel 
> crashes - 
> I know now that neither busybox nor AUFS is the culprit. See below:

Um.  The wrapper should be something like:

#! /bin/sh
echo mounts before-init:
mount
exec /sbin/init "$@"

The key point is, I think, the `exec' keyword.  Init should be started as pid=1.

> (initramfs) mount
> rootfs on / type rootfs (rw)
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> udev on /root/dev type devtmpfs 
> (rw,relatime,size=10240k,nr_inodes=2051439,mode=755)
> devpts on /root/dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
> tmpfs on /root/run type tmpfs (rw,nosuid,relatime,size=3282972k,mode=755)
> 192.168.0.10:/muclab/image/debian-sid on /root type nfs 
> (ro,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=7,retrans=10,sec=sys,local_lock=all,addr=192.168.0.10)
> (initramfs) exit
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> udev on /dev type devtmpfs 
> (rw,relatime,size=10240k,nr_inodes=2051439,mode=755)
> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
> tmpfs on /run type tmpfs (rw,nosuid,relatime,size=3282972k,mode=755)
> 192.168.0.10:/muclab/image/debian-sid on / type nfs 
> (ro,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=7,retrans=10,sec=sys,local_lock=all,addr=192.168.0.10)
> Usage: init {-e VAR[=VAL] | [-t SECONDS] 
> {0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0100

But I see.  Busybox switch_root worked, ran your myinit, and the mount
in question - nfs mount - is still readonly like it should be...

Now this is really interrresting.

Do you have /etc/fstab entry for this mount?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e1c029.8040...@msgid.tls.msk.ru

Bug#756593: busybox's switch_root makes read-only NFS root read/write

[Michael Tokarev]

01.08.2014 15:37, Zimmermann, Alexander wrote:

> As you can see, we use a vanilla 3.14 Kernel, patched w/ official AUFS patch 
> (see
> http://aufs.sourceforge.net)

I too use aufs here, for a very long time.  But I never tried
nfs-root together with aufs, I used if in slightly different
scenarios.

> To enable/disable AUFS we use a patched version of the root-ro script (see
> https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash) in our 
> initramfs.
> The script is located under /etc/initramfs-tools/scripts/init-bottom/. 
> 
>> Where do you set breakpoints?
> 
> To ensure that the root-to script isn’t the culprit, I disabled it (and 
> therefore
> AUFS too) via cmdline parameter root-ro=false and put a breakpoint right after
> (break=init). At the breakpoint, the NFS mount was still ro.
> 
> I put another „breakpoint“ in /etc/rc3.d/S01* start script to verify the mount
> right after switch_root. Here, the mount was already rw.

You can also write a small script - a wrapper for /sbin/init which will
show you the mount info and exec /sbin/init, and run it with init=yourscript.

> Let me double check that AUFS is not broken. I try to boot a vanilla kernel.
> I will come back to you w/ the results.
> 
> Alex
> 
> —-
> As a side note, if we boot w/ AUFS, the mount points are right.

That's even more interesting :)

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53db7e10.30...@msgid.tls.msk.ru

Bug#756593: busybox's switch_root makes read-only NFS root read/write

[Michael Tokarev]

Control: tag -1 + moreinfo

31.07.2014 11:56, Zimmermann, Alexander wrote:
> Package: busybox
> Version: 1:1.22.0-6
> Severity: important
> 
> Dear Maintainer,
> 
> we have a PXE environments in our lab, where we boot both physical boxes
> and XEN machines via NFS from one centralized Debian SID image. While
> the kernel/initramfs mounts the image correctly read only (I set a
> breakpoint just before switch_root get invoked) (see [1]), makes
> switch_root the NFS root read/write (see [2]).

Very interesting.

I can't reproduce this behavor here.  I use remote root a lot,
also with PXE booting, and never saw a read-write root after
switch_root run.

Looking at the source, it only does one mount(2) syscall:

// Overmount / with newdir and chroot into it
if (mount(".", "/", NULL, MS_MOVE, NULL)) {
// For example, fails when newroot is not a mountpoint
bb_perror_msg_and_die("error moving root");

and that's about it.  So unless the kernel is broken, it
should not result in changing the mount flags in any way.

And it definitely doesn't change flags when switch_root'ing to
a regular ext4 or other local filesystem (in a regular initramfs
which is used by almost all debian systems).

Maybe you can describe your environment a bit more?
Where do you set breakpoints?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53da90ac.5060...@msgid.tls.msk.ru

Bug#690889: udhcpc always returns a domain of "bad" when receiving a valid dhcp ack packet

[Michael Tokarev]

18.04.2014 00:21, Иван Сусанин wrote:
[]
> I've already reopened original udchpc bug at busybox bugtracker 
> (https://bugs.busybox.net/show_bug.cgi?id=3979), but it looks like I'm asking 
> for a miracle...

I've seen that discussion.  And frankly, I strongly support Denis here.
We've a well-documented dhcp options used for various things - namely,
for setting domain name and for setting domain search path.  However,
for some reason, those options has been abused (or, rather, used
incorrectly) for years.  Now, when software actually refuses to let
this abuse happen, we complain that the software is bad.  But it just
follows the standard.

> What can be done on this matter?

I think the best is to fix the  setup.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5350cefb.3060...@msgid.tls.msk.ru

Bug#740397: busybox: please add support for parallel building

[Michael Tokarev]

Control: tag -1 + pending

01.03.2014 12:01, Michael Tokarev wrote:
> 01.03.2014 06:17, Cyril Brulebois wrote:
>> Package: busybox
>> Version: 1:1.20.0-7
>> Severity: normal
>> Tags: patch
>>
>> Hi,
>>
>> the title and the attached patch say it all.
> 
> Oh well.
> 
> This come several times in the past for various packages, and it always
> ends up in some strange place.
> 
> I always build my packages in parallel mode locally and ofcourse
> ensure they build fine that way.  Because, well, I dislike waiting
> for too long when my machine have many cores doing nothing.
> 
> The way I alway do this is by passing -jX flag to dpkg-buildpackage,
> sbuild, or just ./d/rules -jX, and so on.  This ends up being a flag
> for the top-level make (which calls d/rules) so the job server becomes
> global. It is the easiest and most strightforward way.
> 
> Now, when adding support for DEB_BUILD_OPTIONS's parallel=X suboption,
> I always end up in either my packages building in just one thread
> (because I still haven't figured how to pass environment variables to
> sbuild for example), or I have to use a non-easy, much more verbose
> way to run dpkg-buildpackage (setting DEB_BUILD_OPTIONS= instead of
> just passing -j).  Because DEB_BUILD_OPTIONS handling, at the end,
> overrides -j somehow.
> 
> The way how you proposed to fix your initial proposal -- add
> "else\nNUMJOBS = 1" -- makes this obvious, -- no matter what -jX
> is passed to the top-level, the build will be done according to
> DEB_BUILD_OPTS (whenever it is set or unset).
> 
> I asked about this several times on #irc but got no good answer.
> And after some tries I ended up in what we have now, -- I just ignore
> DEB_BUILD_OPTIONS, because I try to build the package much more
> often than it is built on buildds, and I want the process to be
> easiest for me not for machines, and I value my own time much more
> than CPU time of debian buildd network (even of the slowest machines
> in there).

Ok.  After looking around I found a recipe which I used in other
packages to satisfy both those requiriments:

# support parallel build using DEB_BUILD_OPTIONS=parallel=N
ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
  MAKEFLAGS += \
-j$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
endif

(which is quite similar to what the debian policy says), and it
appears to work.  So I've added the same to busybox d/rules and
it at least continues to work with -jN, so I know that my way
of doing things hasn't broke, which is good.

Other related topics (how to pass DEB_BUILD_OPTIONS or anything
else to sbuild, or how to make simple -j work together with this
DEB_BUILD_OPTIONS in dh-style d/rules etc), while related, are
not holding this bug in any way.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53119839.1060...@msgid.tls.msk.ru

Bug#740397: busybox: please add support for parallel building

[Michael Tokarev]

01.03.2014 06:17, Cyril Brulebois wrote:
> Package: busybox
> Version: 1:1.20.0-7
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> the title and the attached patch say it all.

Oh well.

This come several times in the past for various packages, and it always
ends up in some strange place.

I always build my packages in parallel mode locally and ofcourse
ensure they build fine that way.  Because, well, I dislike waiting
for too long when my machine have many cores doing nothing.

The way I alway do this is by passing -jX flag to dpkg-buildpackage,
sbuild, or just ./d/rules -jX, and so on.  This ends up being a flag
for the top-level make (which calls d/rules) so the job server becomes
global. It is the easiest and most strightforward way.

Now, when adding support for DEB_BUILD_OPTIONS's parallel=X suboption,
I always end up in either my packages building in just one thread
(because I still haven't figured how to pass environment variables to
sbuild for example), or I have to use a non-easy, much more verbose
way to run dpkg-buildpackage (setting DEB_BUILD_OPTIONS= instead of
just passing -j).  Because DEB_BUILD_OPTIONS handling, at the end,
overrides -j somehow.

The way how you proposed to fix your initial proposal -- add
"else\nNUMJOBS = 1" -- makes this obvious, -- no matter what -jX
is passed to the top-level, the build will be done according to
DEB_BUILD_OPTS (whenever it is set or unset).

I asked about this several times on #irc but got no good answer.
And after some tries I ended up in what we have now, -- I just ignore
DEB_BUILD_OPTIONS, because I try to build the package much more
often than it is built on buildds, and I want the process to be
easiest for me not for machines, and I value my own time much more
than CPU time of debian buildd network (even of the slowest machines
in there).

When you look at debhelper in this context, things becomes even more
interesting.  I wasn't able to make it work with -j _and_ with its
--parallel flag.

Also, when you set -j just for submakes, quite often make complains
about various issues with the job server.  When -j is set for the
top-level d/rules, this doesn't happen (unless there's a bug in the
submake invocation or in upstream build system).

> (On a slightly, but not totally unrelated note: supporting nocheck as
> well would be nice.)

Yeah, nocheck is something I wanted to implement but forgot.
Will do.

> Reference:
>   https://www.debian.org/doc/debian-policy/ch-source.html

Yes, I know parallel= in there.  And I tried numerous times to obey the
rules and to make it work. Every time had issues and finally gave up.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531193c8.1000...@msgid.tls.msk.ru

Bug#738864: Remove copy operation for parted3 transition

[Michael Tokarev]

13.02.2014 20:45, Phillip Susi wrote:
> Package: partman-partitioning
> Tags: patch
> 
> This patch removes the copy operation from the partman menu in
> preparation for the parted3 transition, which no longer supports this.
> 

Out of curiocity, why libparted is needed to copy a partition
into some other place?  How about

  dd if=/dev/source-partition of=/dev/dest-partition

?

(Well, with proper options, maybe with iflag=direct etc, but that's
details).

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fcfc10.1040...@msgid.tls.msk.ru

Bug#736872: busybox: zcat does not decompress file which do not have a .gz suffix

[Michael Tokarev]

28.01.2014 00:51, Ian Campbell wrote:
> Package: busybox
> Version: 1:1.22.0-2
> Severity: critical
> Justification: breaks the whole system
> 
> The zcat applet seems to behave like cat unless the input file has a .gz
> suffix:
> 
> Given two identical files (compressed string "Hello World"), one with a .gz
> suffix and one without:

Thank you for a very nice bugreport, and for further analysis.  Much apprecated.
(Initially I started bisecting and found the commit which inroduced the issue,
and immediately found two more emails from you, pointing to the fixes).

[]
> I've given this severity critical since it break the installer by breaking at
> least net-retriever.

Well, I disagree about the severity, but indeed, it breaks unrelated software.

So I prepared a new release (will upload in a few minutes) fixing this issue.

Uncortunately, this whole mess around compression introduces another issue.
After the 2 fixes for this bug, busybox zcat happily accepts uncompressed
input and behaves like regular cat, while original zcat refuses to accept
uncpmpressed input.  I reported this upstream.  But I think it is better
to accept and use uncompressed data than to fail to decompress compressed
data, and the current bug is indeed serious enough to have a quick fix.

Thank you!

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e77338.2090...@msgid.tls.msk.ru

Bug#736521: busybox-static: 1:1.22.0-1 makes initrd.img unbootable

[Michael Tokarev]

24.01.2014 18:41, HIGUCHI Daisuke (VDR dai) пишет:
> Package: busybox-static
> Version: 1:1.22.0-1
> Severity: important
> 
> busybox-static 1:1.22.0-1 makes initrd.img unbootable.
> boot stopped with below message.
> 
> -
> /init: exec: line 331: switch_root: not found
> -

This is because in order to use busybox applets, you have to call it either
`busybox $applet_name', or to have a link with $applet_name to busybox
binary.

I deliberately removed the behind-the-scenes calling of busybox applets
internally, when busybox executes itself without searching in $PATH as
usual.  Because this way, you can't control which implementation to
invoke (busybox or external), and there are many alternatives.

It is more, -- quite often when you use busybox together with another
util, you may see surprizes.  For example:

 busybox nc   -e dd of=filename oflag=direct

-- this fails, because busybox runs its own dd, which does not have
`oflag' option at all.  Ditto for tar and other utils.

In order to fix the initrd issue with busybox.static, we need to
use initramfs hook similar to what non-static version provides.

Actually I'm not sure what to do here.  I didn't think about using
_static_ version of busybox in initramfs, it is not really intended
for that purpose, but rather for some system repair work.

So while I provided necessary setup for regular build to ensure
initramfs works, I never thought about busubox-static in this
context.

But busybox and busybox-static conflicts and replaces one another,
and initramfs-tools uses busybox by default if it is installed.
So this breaks every system where busybox-static is installed,
which is not good...

So I think I'll just copy the same initramfs hook script to
static package, at least for now, to fix this issue.

Thank you!

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e27f50.9070...@msgid.tls.msk.ru

Bug#720002: busybox: FTBFS with make 3.82

[Michael Tokarev]

Control: tag -1 + moreinfo unreproducible

17.08.2013 19:31, Daniel Schepler wrote:
> Source: busybox
> Version: 1:1.20.0-8.1
> Severity: important
> 
>>From my pbuilder build log, using a chroot with make 3.82-1 from experimental 
> installed:
> 
> ...
>   GEN libbb/Kbuild
>   GEN libbb/Config.in
> make[1]: Leaving directory `/tmp/buildd/busybox-1.20.0/debian/build/udeb'
> cat debian/config/pkg/udeb >> debian/build/udeb/.config
> /usr/bin/make -C debian/build/udeb oldconfig
> make[1]: Entering directory `/tmp/buildd/busybox-1.20.0/debian/build/udeb'
> .config:417: *** missing separator.  Stop.
> make[1]: *** [scripts_basic] Error 2
> make[1]: Leaving directory `/tmp/buildd/busybox-1.20.0/debian/build/udeb'
> make: *** [debian/build/udeb/.setup] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2

Hmm.  I tried to reproduce this, but can not, neither with 1.20 version
from wheezy nor with 1.21 version from sid, with parallel make or not.

When this happens, can you show the affected line from .config?
As far as I can see, .config is generated to be a valid makefile
fragment.

Thank you!

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a6445d.9030...@msgid.tls.msk.ru

Bug#726298: debian-installer: graphical install as KVM guest crashes when switching to text console

[Michael Tokarev]

Control: tag -1 + wontfix moreinfo - patch

14.10.2013 14:45, Thiemo Nagel wrote:
> severity 726298 wishlist
> retitle 726298 Give guidance to console-switching installer users
> reassign 726298 busybox
> tags 726298 + patch
> thanks
> 
> It's all my fault. I just realized that X is fine, I just didn't
> expect it to live on console #5. Maybe the attached patch could help
> prevent others falling into the same trap?

First of all, somehow I haven't noticed this bugreport until now.

Here's your patch:

 From d2e289c95d454ec752af14b18b417ce30fca741d Mon Sep 17 00:00:00 2001
 From: Thiemo Nagel 
 Date: Mon, 14 Oct 2013 12:34:41 +0200
 Subject: [PATCH] Add help message to inactive consoles

 --- a/init/init.c
 +++ b/init/init.c
 @@ -485,7 +485,10 @@ static pid_t run(const struct init_action *a)
  #ifdef CUSTOMIZED_BANNER
  #include CUSTOMIZED_BANNER
  #endif
 -  "\nPlease press Enter to activate this console. ";
 +  "\nPlease press Enter to activate this console. "
 +  "(Hit Ctrl-Alt-F5 to return to the graphical "
 +  "installer or Ctrl-Alt-F1 for the text-mode "
 +  "installer, respectively.) ";


This is completely wrong.  There's no reason X installer should be running
on tty5 or text-mode installer on tty1.  This patch breaks regular use
of busybox, because outside of the d-i environment, there's no reason to
expect the installer to be running at all.

As far as I remember, things are actually documented in the installation
manual, isn't that not enough?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a34b7f.8080...@msgid.tls.msk.ru

Re: sid netinst broken due to pool depends

[Michael Tokarev]

[Replying to oldish email]

28.08.2013 20:30, Samuel Thibault wrote:

Joseph M. Deming, le Wed 28 Aug 2013 12:06:06 -0400, a écrit :

busybox fails to install due to dependency on libperl packages which then
depend on perlapi-5.14.2.


We're at the beginning of a perl transition.  Packages need to be
rebuilt, simply. Perhaps we can ask for rebuilding busybox to fix this
precise bug, but there are most probably quite a few others behind.


Hm.  Busybox does not use or depend on perl, at runtime it only depends
on libc.  Which dependency we're talking about here?

Thanks,

/mjt


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52283a3a.8040...@msgid.tls.msk.ru

Bug#716808: Busybox is outdated

[Michael Tokarev]

14.07.2013 18:22, Holger Levsen wrote:
> On Samstag, 13. Juli 2013, Michael Tokarev wrote:
>> Heh.  And this is exactly why I closed it: users don't need the
>> new version.  I especially asked Jackson which features or bugfixes
>> he needs.  He replied with a link to a changelog, which makes me
>> think that he simple does not care, so does not actually need a
>> new version.
> 
> WTF?! He gave you a long list of reasons (all those changes) and from that 
> you 
> conclude "this cannot be true, the user must not know what he wants, I'll 
> close his request" without any further questions asked.
> 
> Wow, "way to go" :-(


Yes indeed.  I'm not a robot or a machine, and feeding me URLs without
any description of without actually answering my question is the way
to go.  I will never tolerate this complete lack of respect.

Fell free to close this bugreport when a new version will be packaged.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e2d073.6010...@msgid.tls.msk.ru

Bug#716808: Busybox is outdated

[Michael Tokarev]

13.07.2013 17:41, Holger Levsen wrote:
> Hi Michael,
> 
> On Samstag, 13. Juli 2013, Michael Tokarev wrote:
>> Because it serves no (additional) purpose (we have a watch file
>> for that already) except of cluttering buglist (which is already
> 
> it does serve  a purpose: to express+document users needs for the new version 
> (which then is useful to priorize work etc).

Heh.  And this is exactly why I closed it: users don't need the
new version.  I especially asked Jackson which features or bugfixes
he needs.  He replied with a link to a changelog, which makes me
think that he simple does not care, so does not actually need a
new version.  And this was exactly the reason why I closed it --
because there's actually no indication that users need it.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e15adf.4080...@msgid.tls.msk.ru

Bug#716808: Busybox is outdated

[Michael Tokarev]

I forgot to address another comment.

13.07.2013 13:41, Holger Levsen wrote:

> And, did you even read the list of changes?

Oh yes I did.
But I'm *still* waiting for the wheezy update, which
went unanswered for half a year now.

> Let me quote it for you:

Thank you very much, much apprecated - I forgot how to
click an URL.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e156d5.2070...@msgid.tls.msk.ru

Bug#716808: Busybox is outdated

[Michael Tokarev]

13.07.2013 13:41, Holger Levsen wrote:
> Hi Michael,
> 
> exactly why did you close the bug?

Because it serves no (additional) purpose (we have a watch file
for that already) except of cluttering buglist (which is already
quite long) even more, making it more unreadable.  I will most
likely forget to close it when the new version will be packaged,
so I closed it when I do remember it.

But actually, the more I think about this all, the less I care.
I wanted to fix real bugs in busybox, but no one else did so.
Instead, a bin-nmu has been uploaded (with the changes which
I already did locally, waiting for busybox to enter wheezy).
If fixing bugs in wheezy isn't needed, why new version is
desirable?  I don't understand.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e15633.9080...@msgid.tls.msk.ru