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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Michael Tokarev <mjt@tls.msk.ru> (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.

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?

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

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…

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?

Absolutely, thanks for stepping up.

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

No idea about that one. I'm fine with a temporary breakage in unstable
anyway, in case things don't work out immediately.

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

I don't recall whatever happened after we introduced this patch, I'm not
sure we did much work there.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmJ38i0ACgkQ/5FK8MKz VSBaUw//QAoScs1vDFSjU3CcA1HvXpN7DGT1n67xwmxWjAnIhHVCkCvVH1tvPXEN tOwRzk5dLA+J+6P8h0pO1uOITYDV/gSNtx8Zmwdex7IloFMOFd/khAkKM8/kTFCb /GJzkHQB3k2BE5Q/72+QpyBs1KE8osvVZKtGZfAXZ7E37OQkex3kiqVtDcBI/ghG AOYJq68eTEkRqHycMvS6+5O13ysnvRbvccPPjRtl89m3s5ZkjcENXWx98cxfEbC4 bwTlu94Jhg/qJOQZg4YhbuHMJpWCVE8hofkW65yWoye0hXAOyxV6gTVxtrs2D9N5 8htlChllOQ43ms2qLaKSgpJitu/39nklNTY0prH12O/WUSn99miH6x4TDjFz6U4x 2GnRtFRfDi6NWZtipft3ujiX6sItwZrwMYpuodRe396bBPIV7l2DWGZ+pcnFDMwR Q7jqJAjD8+gg5l+4AAyIiR6hF850asSCD3krGrYEEnxjaUNY0FFfExwcR4grYKmt yETg4r/HXpp4Lwa3b7TkghJ9e1COiL8hKqewA7DWJc9Ljc9H3ETdqq3EooUI9lVQ NJMvs6UDLdxptXYEYXhLLfDxe+tJ2dmI4xeATpERAGEY4Giw6vQkxQxvVo9FxSRb 48skW61uFRZm7++YeV4RCu+F7mj5JwmjB6s4JsFd0mJ79N+mYa4=
=Tx8/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

08.05.2022 19:39, Cyril Brulebois wrote:

Hi,

Michael Tokarev <mjt@tls.msk.ru> (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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael Tokarev <mjt@tls.msk.ru> (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.

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.)

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?


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmJ4ItAACgkQ/5FK8MKz VSB5WBAAqYhw9lJYThLzFuvynuFwT+sXvdP3tm4Vg8CXRZLGW8JFsWgMOs2WT1yc k/1/5Ykvyh+X6rIZCdTQ+zl6T6adnNUEHDPIhP9H9IJAzoFzRhU3Y16YIQig+kIb 9DTr7DLPw0jAq13zrvxxub4m9fl2+dQ1V8qTwricegEaIZQ/hF18mUCJubHJVEHN OkfFvwfgProNW2z4ka1KBm/+DdL1/9Vro2LrY+KXA9vjjCWxesfiYO3QwzmeI0qW IyXyjY6K+ydXW49HvhL8mfB/CeEjCbEOibuOIGwSt6iSQq1mtHGptuPdiYEcnRiQ LqQaUB3CaZ79DuhvuKHHROiCPkhuKNQuBPGt6/8xLviZ36fx3Fp18PzB9gHs/utE 9JzjrCKy24EIsZNfyuJOhPtAMFVjxVufoLOfvpG9D5Dm3GeesCaeRZz2E3cR3EnC 95hUy2KDFJYbM3f5ntY05R8hHsXBIwF8tcBxxeLRB5X/i2TPIpLAA8okduElLmDD zkyU6fWy8CIAhULqjfMXsHUJqFBfn5Dp+f9orkNuz/J9/UKGghnK60W0IXcyC5p6 m6bFfVSjuqg8nYKuGG5WfcbSALEKnoCEV18PqP1AxoWz/1xTh6O9sH5eYa2dCdyp oY2FKo35tqwa2iMDMGiiXv67Mrne0Q/nO3laORSj6rOYcyOYb68=
=VqmX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

08.05.2022 23:06, Cyril Brulebois wrote:

Michael Tokarev <mjt@tls.msk.ru> (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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: debian-boot@lists.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------QPgzwrDAFulIhcEXBf1avWgf
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgTWljaGFlbCwNCg0KT24gMDQvMDYvMjAyMiAxMDoyMCwgTWljaGFlbCBUb2thcmV2IHdy b3RlOg0KPiBPaywgaXQncyBiZWVuIGFsbW9zdCBhIG1vbnRoIHNpbmNlIG15IGluaXRpYWwg ZW1haWwgaGVyZS4NCj4gDQo+IElmIHRoZXJlJ3Mgbm8gb2JqZWN0aW9ucywgSSdsbCB1cGxv YWQgdGhlIG5ldyBidXN5Ym94IHJlbGVhc2UgdG9tb3Jyb3cNCj4gKGZyb20gdGhlICJtanQi IGJyYW5jaCkuIEl0J3MgZW5vdWdoIHdhaXRpbmcgOikNCg0KU29ycnksIGxpZmUgaGFzIGp1 c3QgYmVlbiB3YXkgdG9vIGJ1c3kgdG8gZ2V0IHRvIGJ1c3lib3ggbWFpbnRlbmFuY2Ugb24g DQpteSBwYXJ0IC0gb3IsIGl0IHNlZW1zLCBldmVuIHJlcGx5aW5nIHRvIGxpc3QgbWFpbCBs aWtlIHRoaXMuIEknbSB2ZXJ5IA0KZ2xhZCB0byBzZWUgeW91IHdvcmtpbmcgb24gaXQgaW4g RGViaWFuIGFnYWluLCBhbmQgdGhhbmtzIGZvciBkb2luZyB0aGUgDQp1cGxvYWQgYSBjb3Vw bGUgb2Ygd2Vla3MgYWdvIHRvIGJyaW5nIGl0IHVwIHRvIGRhdGUuDQoNCj4gSSB3YW50IHRv IGVuYWJsZSBhd2sgYXBwbGV0IGZvciBkLWkgKHVkZWIpIGNvbmZpZyBiZWZvcmUgdGhlIHVw bG9hZCwgZm9yDQo+IHNvbWUgdGhpbmdzIGl0IGlzIG11Y2ggZWFzaWVyIHRvIHVzZSB0aGFu IGUuZy4gc2VkLg0KDQpUaGF0IG1ha2VzIHNlbnNlIHRvIG1lLiBJIGRvbid0IHRoaW5rIHdl J3JlIG5lYXJseSBhcyBhbmFsIGFzIHdlIHVzZWQgdG8gDQpiZSBhYm91dCBrZWVwaW5nIHRo ZSBpbnN0YWxsZXIgc21hbGwgKGUuZy4gd2UgZHVtcGVkIHRoZSBidXNpbmVzc2NhcmQgQ0Qg DQppbWFnZXMgaW4gMjAxMikgc28gaXQgbWFrZXMgc2Vuc2UgdG8gZW5hYmxlIGdlbnVpbmVs eSB1c2VmdWwgDQpmdW5jdGlvbmFsaXR5IGluIGJ1c3lib3guDQoNCj4gSSBkbyBoYXZlIHNv bWUgbW9yZSB0aG91Z2h0cywgaW5jbHVkaW5nIHNvbWUgZG91YnRzIGFib3V0IHRoZSB3YXkg SSBjaGFuZ2VkDQo+IHRoZSBidWlsZCBwcm9jZWR1cmUgKGl0IGxvb2tzIGxpa2UgdGhlcmUn cyBhIHNpbXBsZXIgd2F5KSwgYnV0IHRoYXQncyBmb3INCj4gdGhlIGZ1dHVyZS4NCg0KSSdk IGJlIGludGVyZXN0ZWQgdG8gc2VlIHRoYXQuIEkgZm91Z2h0IHdpdGggdGhlIGJ1aWxkIHBy b2Nlc3MgZm9yIHF1aXRlIA0KYSB3aGlsZSB0byBnZXQgaXQgd2hlcmUgaXQgc2VlbWVkIHRv IHdvcmsgbmljZWx5LCBzbyBpZiB5b3UgY2FuIGltcHJvdmUgDQppdCB0aGVuIHRoYXQncyBn cmVhdCENCg0KSWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBkbyBmZWVsIGZyZWUgdG8gbWFp bCBtZSBkaXJlY3RseSwgSSdtIG11Y2ggDQptb3JlIGxpa2VseSB0byBzZWUgeW91ciBtYWls IHRoYXQgd2F5Lg0KDQpDaGVlcnMsDQpDaHJpcw0KDQotLSANCkNocmlzIEJvb3QNCmJvb3Rj QGRlYmlhbi5vcmcNCg==

--------------QPgzwrDAFulIhcEXBf1avWgf--

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEakxNgo23DDPFqbsY1o29Dt2gqWQFAmKw4RtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZB NEM0RDgyOERCNzBDMzNDNUE5QkIxOEQ2OERCRDBFRERBMEE5NjQACgkQ1o29Dt2g qWTeVw//fVJqR4tBb1JonGRPF9lbynUjtrIdTjf34VKqO5t+ZlCw0vd6ZNGOK4KY ZxjQ9MF/7jiKjbCRPzZkptd6gpopOdo2FRgRRyeXKi5IUWamduknjB29tUpv6iTM KSccFJiTEf1KX/RPVs9/L9AH3/ixZJBq7dDoc/JlQKXLkj+rALbc/fkGGmtOw7hX 5e7KjRKegrIIIfwZCzz+2A5fAdI2yXSJsgyNPJCOLahmmGVJc8rvaP0OWBgZZfNb Db3kjlAax5Efv+irr/Ow/n67xjbS021wbqNoYu4dgTt4sb2pmyCLovR6tLnJeSJj lBEPgnA0DlXgMTSTPflJl+K2nSYNEK5t3Ag+rsEt0wTF9J2LHJgyO/LhyepKYwp/ pDXpIWDkbNEkzarWMQHcWPTOwNvPN0nYHJoPMFHDPhdwdyyOKvrdOPgntISc6XlM N0s9Z1YSKdO7mnbFmey+3fjwVVEyfmjmOSwzxBzo4xL8O6rYlzTLX0vTQYl+Zb5P MxmGHwiArCZ/CxxMaLjwh55hf8RyDIV16j3ZUL2wTUzBx7t2B2drUyja/C3OdS5d V+OvGxact2mYsoxKMkIo2dR7G1iDSoGMoROj52Z/mvr/+PMxWYsFC4XmeJayKnDT jOHbe7uu+OdEEizhbqDiWqQJF5TMOGHIyO7v2FJwmuCneOAZ1f4=
=JRjM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)