From qboosh at pld-linux.org  Fri Oct  1 20:27:21 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 1 Oct 2021 20:27:21 +0200
Subject: [packages/ca-certificates] Rel 6;
 make sure we don't include expired certs
In-Reply-To: <0818a4328225cca2d41e43f0fa816f38bb3cbe69_refs_heads_master@pld-linux.org>
References: <4e16aaa8f73d270583a031434344bf57b43e56d7_refs_heads_master@pld-linux.org>
 <0818a4328225cca2d41e43f0fa816f38bb3cbe69_refs_heads_master@pld-linux.org>
Message-ID: <20211001182721.GA1085@mail>

On Fri, Oct 01, 2021 at 12:36:20PM +0200, arekm wrote:
> commit 0818a4328225cca2d41e43f0fa816f38bb3cbe69
> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> Date:   Fri Oct 1 12:36:07 2021 +0200
> 
>     Rel 6; make sure we don't include expired certs

Unfortunately ix86 `date` doesn't know y2038+...

| date: invalid date 'Oct 25 08:25:55 2043 GMT'


-- 
Jakub Bogusz    http://qboosh.pl/


From arekm at maven.pl  Sun Oct  3 08:49:38 2021
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Sun, 3 Oct 2021 08:49:38 +0200
Subject: [packages/ca-certificates] Rel 6; make sure we don't include
 expired certs
In-Reply-To: <20211001182721.GA1085@mail>
References: <4e16aaa8f73d270583a031434344bf57b43e56d7_refs_heads_master@pld-linux.org>
 <0818a4328225cca2d41e43f0fa816f38bb3cbe69_refs_heads_master@pld-linux.org>
 <20211001182721.GA1085@mail>
Message-ID: <d78469c8-fa2d-c7a6-f088-bce1d7d97d82@maven.pl>

W dniu 01.10.2021 o?20:27, Jakub Bogusz pisze:
> On Fri, Oct 01, 2021 at 12:36:20PM +0200, arekm wrote:
>> commit 0818a4328225cca2d41e43f0fa816f38bb3cbe69
>> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
>> Date:   Fri Oct 1 12:36:07 2021 +0200
>>
>>     Rel 6; make sure we don't include expired certs
> 
> Unfortunately ix86 `date` doesn't know y2038+...
> 
> | date: invalid date 'Oct 25 08:25:55 2043 GMT'
> 
> 

Jan, what was the reason behind  --disable-year2038 in coreutils?

Enabling that and date on ix86 parses such date correctly (with
coreutils 9.0).

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From atler at pld-linux.org  Sun Oct  3 10:47:25 2021
From: atler at pld-linux.org (Jan Palus)
Date: Sun, 3 Oct 2021 10:47:25 +0200
Subject: [packages/ca-certificates] Rel 6; make sure we don't include
 expired certs
In-Reply-To: <d78469c8-fa2d-c7a6-f088-bce1d7d97d82@maven.pl>
References: <4e16aaa8f73d270583a031434344bf57b43e56d7_refs_heads_master@pld-linux.org>
 <0818a4328225cca2d41e43f0fa816f38bb3cbe69_refs_heads_master@pld-linux.org>
 <20211001182721.GA1085@mail>
 <d78469c8-fa2d-c7a6-f088-bce1d7d97d82@maven.pl>
Message-ID: <20211003084725.qekgrnsk7ofnmpel@pine>

On 03.10.2021 08:49, Arkadiusz Mi?kiewicz via pld-devel-en wrote:
> W dniu 01.10.2021 o?20:27, Jakub Bogusz pisze:
> > On Fri, Oct 01, 2021 at 12:36:20PM +0200, arekm wrote:
> >> commit 0818a4328225cca2d41e43f0fa816f38bb3cbe69
> >> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> >> Date:   Fri Oct 1 12:36:07 2021 +0200
> >>
> >>     Rel 6; make sure we don't include expired certs
> > 
> > Unfortunately ix86 `date` doesn't know y2038+...
> > 
> > | date: invalid date 'Oct 25 08:25:55 2043 GMT'
> > 
> > 
> 
> Jan, what was the reason behind  --disable-year2038 in coreutils?
> 
> Enabling that and date on ix86 parses such date correctly (with
> coreutils 9.0).

The primary effect of y2038 handling is change of time_t from 32bit to
64bit which breaks abi compatibility with external libraries that were
not compiled with y2038. If there's any library call that involves
time_t either directly (argument/return value) or indirectly (member of
publicly defined struct) then it will cause incorrect results if caller
and callee use different time_t size. That's exactly what happened in
wget interacting with libmetalink:

https://savannah.gnu.org/bugs/index.php?61140

whether any such situation is possible in coreutils -- don't know, but
to be on the safe side I prefer to disable it for the time being.
Especially that y2038 handling is still a moving target. ie even if you
don't use y2038 glibc requires you to be aware of internal mechanisms to
handle it in order to use api correctly:

https://github.com/systemd/systemd/issues/20564

I would say y2038 is either all or nothing. At some point we'd need
rebuild everything with 64bit time_t (and keep our fingers crossed that
abi breakages do not happen too often on builders during the process of
transition).


From glen at pld-linux.org  Tue Oct  5 10:29:31 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 5 Oct 2021 11:29:31 +0300
Subject: stbr broken
Message-ID: <6943a491-898d-c18b-ea3b-36ac01c6308a@pld-linux.org>


Problem while sending request via HTTP: 
https://srcbuilder.pld-linux.org:1235/: HTTP Error 500: None: 'utf-8' 
codec can't decode byte 0xe4 in position 205: invalid continuation byte



From glen at pld-linux.org  Tue Oct  5 15:56:42 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 5 Oct 2021 16:56:42 +0300
Subject: stbr broken
In-Reply-To: <6943a491-898d-c18b-ea3b-36ac01c6308a@pld-linux.org>
References: <6943a491-898d-c18b-ea3b-36ac01c6308a@pld-linux.org>
Message-ID: <4eadc7cf-0d90-4964-50a9-66e411bf893f@pld-linux.org>

On 05.10.2021 11:29, Elan Ruusam?e wrote:

>
> Problem while sending request via HTTP: 
> https://srcbuilder.pld-linux.org:1235/: HTTP Error 500: None: 'utf-8' 
> codec can't decode byte 0xe4 in position 205: invalid continuation byte
>

I suspect this has something to do my gecos field containing ? (U+00C4), 
probably in iso8858-1 not in utf-8 encoding.


but until someone fixes it, please stbr:

- python3-markupsafe.spec

- python3-jinja2.spec

- nagios-notify.spec



From baggins at pld-linux.org  Tue Oct  5 23:42:11 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 5 Oct 2021 23:42:11 +0200
Subject: firefox extensions
Message-ID: <YVzGs8hgz3atCLaS@tachikoma.lan>

I can't figure out what the trigger was, but since recently (92+?,
September?) firefox extensions started misbehaving. ex. ublock is
not really blocking adds, and if I try to click its icon all I get
is a single vertical line instead of the menu.

So, does firefox extensions work for you? Any hints what's going on?

I did try launching firefox on a clean profile, problem persists, and
the same thing happens on both mozilla-firefox-bin and PLD compiled
package.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From baggins at pld-linux.org  Tue Oct  5 23:50:36 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 5 Oct 2021 23:50:36 +0200
Subject: firefox extensions
In-Reply-To: <YVzGs8hgz3atCLaS@tachikoma.lan>
References: <YVzGs8hgz3atCLaS@tachikoma.lan>
Message-ID: <YVzIrAZ4YsSACFMW@tachikoma.lan>

On Tue, 05 Oct 2021, Jan R?korajski wrote:

> I can't figure out what the trigger was, but since recently (92+?,
> September?) firefox extensions started misbehaving. ex. ublock is
> not really blocking adds, and if I try to click its icon all I get
> is a single vertical line instead of the menu.
> 
> So, does firefox extensions work for you? Any hints what's going on?
> 
> I did try launching firefox on a clean profile, problem persists, and
> the same thing happens on both mozilla-firefox-bin and PLD compiled
> package.

I also did try downgrading to 91.0 and it looks the same, so, what could
have changed recently that broke JavaScript(?) in forefox?

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From krzysztof at mrozowicz.eu  Tue Oct  5 23:55:02 2021
From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz)
Date: Tue, 5 Oct 2021 22:55:02 +0100
Subject: firefox extensions
In-Reply-To: <YVzIrAZ4YsSACFMW@tachikoma.lan>
References: <YVzGs8hgz3atCLaS@tachikoma.lan> <YVzIrAZ4YsSACFMW@tachikoma.lan>
Message-ID: <20211005225502.773fc7b6@oko>

Dnia 2021-10-05, o godz. 23:50:36
Jan R?korajski <baggins at pld-linux.org> napisa?(a):

> On Tue, 05 Oct 2021, Jan R?korajski wrote:
> 
> > I can't figure out what the trigger was, but since recently (92+?,
> > September?) firefox extensions started misbehaving. ex. ublock is
> > not really blocking adds, and if I try to click its icon all I get
> > is a single vertical line instead of the menu.
> > 
> > So, does firefox extensions work for you? Any hints what's going on?
> > 
> > I did try launching firefox on a clean profile, problem persists,
> > and the same thing happens on both mozilla-firefox-bin and PLD
> > compiled package.  
> 
> I also did try downgrading to 91.0 and it looks the same, so, what
> could have changed recently that broke JavaScript(?) in forefox?
> 

I only can confirm the problem. I noticed that with the NextCloud
Password manager extension, but checked ublock right now and also its
interface doesn't show up.

-- 
Krzysiek


From atler at pld-linux.org  Wed Oct  6 01:18:50 2021
From: atler at pld-linux.org (Jan Palus)
Date: Wed, 6 Oct 2021 01:18:50 +0200
Subject: firefox extensions
In-Reply-To: <YVzIrAZ4YsSACFMW@tachikoma.lan>
References: <YVzGs8hgz3atCLaS@tachikoma.lan> <YVzIrAZ4YsSACFMW@tachikoma.lan>
Message-ID: <20211005231850.ksvggb62pj4gpyxk@pine>

On 05.10.2021 23:50, Jan R?korajski wrote:
> On Tue, 05 Oct 2021, Jan R?korajski wrote:
> 
> > I can't figure out what the trigger was, but since recently (92+?,
> > September?) firefox extensions started misbehaving. ex. ublock is
> > not really blocking adds, and if I try to click its icon all I get
> > is a single vertical line instead of the menu.
> > 
> > So, does firefox extensions work for you? Any hints what's going on?
> > 
> > I did try launching firefox on a clean profile, problem persists, and
> > the same thing happens on both mozilla-firefox-bin and PLD compiled
> > package.
> 
> I also did try downgrading to 91.0 and it looks the same, so, what could
> have changed recently that broke JavaScript(?) in forefox?

It appears to be sandbox/seccomp related so perhaps glibc just like
chrome? Workaround:

- install ublock
- modify "security.sandbox.content.level" from "4" to "2"
- restart firefox and bring back "security.sandbox.content.level" to "4"
- restart firefox and enjoy ublock

No idea what's wrong exactly though.


From baggins at pld-linux.org  Wed Oct  6 09:03:38 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 6 Oct 2021 09:03:38 +0200
Subject: firefox extensions
In-Reply-To: <20211005231850.ksvggb62pj4gpyxk@pine>
References: <YVzGs8hgz3atCLaS@tachikoma.lan> <YVzIrAZ4YsSACFMW@tachikoma.lan>
 <20211005231850.ksvggb62pj4gpyxk@pine>
Message-ID: <YV1KSnXsmXeUa0Q5@starbug.lan>

On Wed, 06 Oct 2021, Jan Palus wrote:

> On 05.10.2021 23:50, Jan R?korajski wrote:
> > On Tue, 05 Oct 2021, Jan R?korajski wrote:
> > 
> > > I can't figure out what the trigger was, but since recently (92+?,
> > > September?) firefox extensions started misbehaving. ex. ublock is
> > > not really blocking adds, and if I try to click its icon all I get
> > > is a single vertical line instead of the menu.
> > > 
> > > So, does firefox extensions work for you? Any hints what's going on?
> > > 
> > > I did try launching firefox on a clean profile, problem persists, and
> > > the same thing happens on both mozilla-firefox-bin and PLD compiled
> > > package.
> > 
> > I also did try downgrading to 91.0 and it looks the same, so, what could
> > have changed recently that broke JavaScript(?) in forefox?
> 
> It appears to be sandbox/seccomp related so perhaps glibc just like
> chrome? Workaround:
> 
> - install ublock
> - modify "security.sandbox.content.level" from "4" to "2"

Works up to here ;)

> - restart firefox and bring back "security.sandbox.content.level" to "4"
> - restart firefox and enjoy ublock

Bringing back to "4" breaks extensions again.

> No idea what's wrong exactly though.

According to https://wiki.mozilla.org/Security/Sandbox#Content_Levels
it's "Read access to most of the filesystem" that's problematic (yes,
"3" already breaks stuff).

Oh, well, at least there is a workaround.

Thanks a lot.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From glen at pld-linux.org  Fri Oct  8 10:40:59 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Fri, 8 Oct 2021 11:40:59 +0300
Subject: carme and expired certs
Message-ID: <9f50acc8-f9a1-dc69-00b0-f629272bc86a@pld-linux.org>

please fix ca-certificates problem on carme


```
ca-certificates-20210119-6.noarch: equal version installed, skipped

[~/rpm/packages/apache(2.4.50) (master)?] ? pldnotify.py *.spec
Checking 1 packages
[1/1] checking apache.spec
apache: 2.4.50
ERROR: HTTPSConnectionPool(host='release-monitoring.org', port=443): Max 
retries exceeded with url: /api/project/pld-linux/apache (Caused by 
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] 
certificate verify failed: certificate has expired (_ssl.c:1129)')))


[~/rpm/packages/apache(2.4.50) (master)?] ? curl 
https://release-monitoring.org/
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

```



From glen at pld-linux.org  Fri Oct  8 12:44:58 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Fri, 8 Oct 2021 13:44:58 +0300
Subject: stbr broken
In-Reply-To: <4eadc7cf-0d90-4964-50a9-66e411bf893f@pld-linux.org>
References: <6943a491-898d-c18b-ea3b-36ac01c6308a@pld-linux.org>
 <4eadc7cf-0d90-4964-50a9-66e411bf893f@pld-linux.org>
Message-ID: <e7d04012-1ce3-f500-229e-92e7246d6cb5@pld-linux.org>


On 05.10.2021 16:56, Elan Ruusam?e wrote:
>
> On 05.10.2021 11:29, Elan Ruusam?e wrote:
>
>>
>> Problem while sending request via HTTP: 
>> https://srcbuilder.pld-linux.org:1235/: HTTP Error 500: None: 'utf-8' 
>> codec can't decode byte 0xe4 in position 205: invalid continuation byte
>>
>
> I suspect this has something to do my gecos field containing ? 
> (U+00C4), probably in iso8858-1 not in utf-8 encoding.
>
>
> but until someone fixes it, please stbr:
>
> - python3-markupsafe.spec
>
> - python3-jinja2.spec
>
> - nagios-notify.spec
>

also stbr apache(2.4.51) (CVE fixes)



From glen at pld-linux.org  Fri Oct  8 23:33:33 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Sat, 9 Oct 2021 00:33:33 +0300
Subject: [packages/clamav] - package docs - updated cmake and macros
 version, BR: bzip2-devel
In-Reply-To: <c3e2478bbcd6bf57b2bae057b3dc0e4539ff9ee9_refs_heads_master@pld-linux.org>
References: <1ac1f471d4a487c7debb205eb8769f1097f4613e_refs_heads_master@pld-linux.org>
 <c3e2478bbcd6bf57b2bae057b3dc0e4539ff9ee9_refs_heads_master@pld-linux.org>
Message-ID: <830c32b1-417e-5eb5-6967-da44b011f9c8@pld-linux.org>


On 08.10.2021 22:04, qboosh wrote:
> commit c3e2478bbcd6bf57b2bae057b3dc0e4539ff9ee9
> Author: Jakub Bogusz <qboosh at pld-linux.org>
> Date:   Fri Oct 8 21:08:59 2021 +0200
>
>      - package docs
[...]
> +%package doc
> +Summary:	ClamAV documentation
> +Summary(pl.UTF-8):	Dokumentacja do ClamAVa
> +Group:		Documentation


missing noarch





From baggins at pld-linux.org  Sat Oct  9 23:50:53 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 9 Oct 2021 23:50:53 +0200
Subject: stbr broken
In-Reply-To: <e7d04012-1ce3-f500-229e-92e7246d6cb5@pld-linux.org>
References: <6943a491-898d-c18b-ea3b-36ac01c6308a@pld-linux.org>
 <4eadc7cf-0d90-4964-50a9-66e411bf893f@pld-linux.org>
 <e7d04012-1ce3-f500-229e-92e7246d6cb5@pld-linux.org>
Message-ID: <YWIOvZBp4bglzPZF@tachikoma.lan>

On Fri, 08 Oct 2021, Elan Ruusam?e wrote:

> 
> On 05.10.2021 16:56, Elan Ruusam?e wrote:
> >
> > On 05.10.2021 11:29, Elan Ruusam?e wrote:
> >
> >>
> >> Problem while sending request via HTTP: 
> >> https://srcbuilder.pld-linux.org:1235/: HTTP Error 500: None: 'utf-8' 
> >> codec can't decode byte 0xe4 in position 205: invalid continuation byte
> >>
> >
> > I suspect this has something to do my gecos field containing ? 
> > (U+00C4), probably in iso8858-1 not in utf-8 encoding.
> >
> >
> > but until someone fixes it, please stbr:
> >
> > - python3-markupsafe.spec

broken deps

http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=python3-markupsafe&id=d4c07d06-86e6-4579-9249-c1e30c2e7525&action=tail

> > - python3-jinja2.spec

broken

http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=python3-jinja2&id=490ce6df-8790-42c4-86e7-4929a27ab91d&action=tail

> > - nagios-notify.spec

done

> also stbr apache(2.4.51) (CVE fixes)

done

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From glen at pld-linux.org  Wed Oct 13 17:26:45 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 13 Oct 2021 18:26:45 +0300
Subject: stbr broken
In-Reply-To: <4eadc7cf-0d90-4964-50a9-66e411bf893f@pld-linux.org>
References: <6943a491-898d-c18b-ea3b-36ac01c6308a@pld-linux.org>
 <4eadc7cf-0d90-4964-50a9-66e411bf893f@pld-linux.org>
Message-ID: <a73123e5-7254-5fca-fccb-37121fbc780f@pld-linux.org>


On 05.10.2021 16:56, Elan Ruusam?e wrote:
>
> On 05.10.2021 11:29, Elan Ruusam?e wrote:
>
>>
>> Problem while sending request via HTTP: 
>> https://srcbuilder.pld-linux.org:1235/: HTTP Error 500: None: 'utf-8' 
>> codec can't decode byte 0xe4 in position 205: invalid continuation byte
>>
>
> I suspect this has something to do my gecos field containing ? 
> (U+00C4), probably in iso8858-1 not in utf-8 encoding.or gec
>
my local gecos nor gecos on cvs host contain that character, but it 
still fails.


here's verbose output


glen at glen pld-builder/client$ ./make-request.sh -r 
php-composer-xdebug-handler?? -v
* Sending using HTTP mode to https://srcbuilder.pld-linux.org:1235/
* Using priority 2
* Using URL https://srcbuilder.pld-linux.org:1235/
* Build mode: ready
* Queue-ID: 2ed4c69c-aeaf-45b1-8d09-0c8aef819c97
* Builder: th-*
* Upgrade mode: yes
* Adding #1 php-composer-xdebug-handler.spec:HEAD
<group id='2ed4c69c-aeaf-45b1-8d09-0c8aef819c97' no='0' flags=' upgrade'>
 ??????? <time>1634138701</time>
 ??????? <priority>2</priority>

 ??????? <batch id='81854869-05e7-4c5f-b439-0c8ddb910673' depends-on=''>
<spec>php-composer-xdebug-handler.spec</spec>
 ???????????????? <branch>HEAD</branch>


 ???????????????? <info></info>


 ?<builder>th-*</builder>
 ??????? </batch>
</group>
gpg: using "glen at delfi.ee" as default secret key for signing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<group id='2ed4c69c-aeaf-45b1-8d09-0c8aef819c97' no='0' flags=' upgrade'>
 ??????? <time>1634138701</time>
 ??????? <priority>2</priority>

 ??????? <batch id='81854869-05e7-4c5f-b439-0c8ddb910673' depends-on=''>
<spec>php-composer-xdebug-handler.spec</spec>
 ???????????????? <branch>HEAD</branch>


 ???????????????? <info></info>


 ?<builder>th-*</builder>
 ??????? </batch>
</group>
-----BEGIN PGP SIGNATURE-----

iGwEARECACwWIQRwBb1dPvMIXMyGzFtvJKN3dvGQdwUCYWb6TQ4cZ2xlbkBkZWxm
aS5lZQAKCRBvJKN3dvGQdznEAKCRm4/IZk14YFRfBXIR/ltY1iiVeQCfTA7KKDvk
gwMiQNXcCDN1H5Ih3cA=
=+2a+
-----END PGP SIGNATURE-----
Problem while sending request via HTTP: 
https://srcbuilder.pld-linux.org:1235/: HTTP Error 500: None: 'utf-8' 
codec can't decode byte 0xe4 in position 205: invalid continuation byte



From arekm at maven.pl  Sun Oct 17 18:28:34 2021
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Sun, 17 Oct 2021 18:28:34 +0200
Subject: PLD New Rescue Th-20211017
Message-ID: <55c973bc-5321-8f5b-a324-554245ddfdb8@maven.pl>


PLD New Rescue Th-20211017 is there. Based on PLD Th main tree as of
20211017.


https://github.com/pld-linux-org/pld-new-rescue/releases/tag/th-current-2021017


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From atler at pld-linux.org  Fri Oct 22 10:12:06 2021
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 22 Oct 2021 10:12:06 +0200
Subject: TEST build OK: openjdk8.spec
In-Reply-To: <f9c3d01f-da60-4c33-827c-d580eb0026fb@pld.src.builder>
References: <f9c3d01f-da60-4c33-827c-d580eb0026fb@pld.src.builder>
Message-ID: <20211022081206.sxkzfnajgyncxtcq@pine>

On 21.10.2021 10:08, PLD th-src builder wrote:
> openjdk8.spec (HEAD): OK
> 
> --- openjdk8.spec:HEAD:
> Build-Time: user:12.04s sys:6.78s real:23.38s (faults io:18 non-io:365577)
> 
> Files queued for ftp:
>   77449097 openjdk8-1.8.0.312-1.src.rpm
> 

Any clues why the build hanged on th-x86_64 and th-i686?


From j.rekorajski at gmail.com  Fri Oct 22 10:38:11 2021
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Fri, 22 Oct 2021 10:38:11 +0200
Subject: TEST build OK: openjdk8.spec
In-Reply-To: <20211022081206.sxkzfnajgyncxtcq@pine>
References: <f9c3d01f-da60-4c33-827c-d580eb0026fb@pld.src.builder>
 <20211022081206.sxkzfnajgyncxtcq@pine>
Message-ID: <CAKY5yHwNWoV30Aq44HsqJ=EuY4J0f5L9M1h9VcHXqJ+Vnf74uQ@mail.gmail.com>

17461 ?        Ss     0:00  |                           \_ rpmbuild
-bb --define _smp_mflags -j9 --define _make_opts -Otarget --define
_pld_builder 1 --define _topdir /tmp/B.0338pl28 --defin
17597 ?        S      0:00  |                               \_ /bin/sh
-e /tmp/B.0338pl28/BUILD/tmp/rpm-tmp.xcCtoN
17640 ?        S      0:00  |                                   \_
/bin/bash ./configure LDFLAGS=-Wl,--as-needed
-Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc
CFLAGS=-O2 -fw
17643 ?        S      0:00  |                                       \_
bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
/tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/con
17826 ?        S      0:00  |
 \_ bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
/tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga
17828 ?        S      0:00  |
 |   \_ bash -c .
/tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
/tmp/B.0338pl28/BUILD/jdk8u-jdk8u31
18249 ?        S      0:00  |
 |   |   \_ bash -c .
/tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
/tmp/B.0338pl28/BUILD/jdk8u-jdk
18250 ?        Sl     0:02  |
 |   |       \_ /usr/lib/jvm/openjdk8/bin/java -version
17829 ?        S      0:00  |
 |   \_ tee -a ./configure.log
17827 ?        S      0:00  |
 \_ tee -a ./configure.log

strace: Process 18250 attached
futex(0xf7ee3b28, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 18251, NULL,
FUTEX_BITSET_MATCH_ANY^C
strace: Process 18250 detached
 <detached ...>

icedtea8 nie lubi si? z glibc 2.34?

Ut?uk?em oba.

On Fri, Oct 22, 2021 at 10:12 AM Jan Palus <atler at pld-linux.org> wrote:
>
> On 21.10.2021 10:08, PLD th-src builder wrote:
> > openjdk8.spec (HEAD): OK
> >
> > --- openjdk8.spec:HEAD:
> > Build-Time: user:12.04s sys:6.78s real:23.38s (faults io:18 non-io:365577)
> >
> > Files queued for ftp:
> >   77449097 openjdk8-1.8.0.312-1.src.rpm
> >
>
> Any clues why the build hanged on th-x86_64 and th-i686?
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



-- 
Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
baggins<at>pld-linux.org


From j.rekorajski at gmail.com  Fri Oct 22 10:44:15 2021
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Fri, 22 Oct 2021 10:44:15 +0200
Subject: TEST build OK: openjdk8.spec
In-Reply-To: <CAKY5yHwNWoV30Aq44HsqJ=EuY4J0f5L9M1h9VcHXqJ+Vnf74uQ@mail.gmail.com>
References: <f9c3d01f-da60-4c33-827c-d580eb0026fb@pld.src.builder>
 <20211022081206.sxkzfnajgyncxtcq@pine>
 <CAKY5yHwNWoV30Aq44HsqJ=EuY4J0f5L9M1h9VcHXqJ+Vnf74uQ@mail.gmail.com>
Message-ID: <CAKY5yHw7x7jOJZWxVEOX2uJWiMe8nnrsHOq005C7XxDY2W+m+A@mail.gmail.com>

Ah, it wasn't icedtea but openjdk8 that was installed on i686 and x86_64.
I'm uninstalling it and blocking in poldek on builders so that we have
only openjdk11 installable there.

On Fri, Oct 22, 2021 at 10:38 AM Jan R?korajski <j.rekorajski at gmail.com> wrote:
>
> 17461 ?        Ss     0:00  |                           \_ rpmbuild
> -bb --define _smp_mflags -j9 --define _make_opts -Otarget --define
> _pld_builder 1 --define _topdir /tmp/B.0338pl28 --defin
> 17597 ?        S      0:00  |                               \_ /bin/sh
> -e /tmp/B.0338pl28/BUILD/tmp/rpm-tmp.xcCtoN
> 17640 ?        S      0:00  |                                   \_
> /bin/bash ./configure LDFLAGS=-Wl,--as-needed
> -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc
> CFLAGS=-O2 -fw
> 17643 ?        S      0:00  |                                       \_
> bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
> /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/con
> 17826 ?        S      0:00  |
>  \_ bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
> /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga
> 17828 ?        S      0:00  |
>  |   \_ bash -c .
> /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
> /tmp/B.0338pl28/BUILD/jdk8u-jdk8u31
> 18249 ?        S      0:00  |
>  |   |   \_ bash -c .
> /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
> /tmp/B.0338pl28/BUILD/jdk8u-jdk
> 18250 ?        Sl     0:02  |
>  |   |       \_ /usr/lib/jvm/openjdk8/bin/java -version
> 17829 ?        S      0:00  |
>  |   \_ tee -a ./configure.log
> 17827 ?        S      0:00  |
>  \_ tee -a ./configure.log
>
> strace: Process 18250 attached
> futex(0xf7ee3b28, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 18251, NULL,
> FUTEX_BITSET_MATCH_ANY^C
> strace: Process 18250 detached
>  <detached ...>
>
> icedtea8 nie lubi si? z glibc 2.34?
>
> Ut?uk?em oba.
>
> On Fri, Oct 22, 2021 at 10:12 AM Jan Palus <atler at pld-linux.org> wrote:
> >
> > On 21.10.2021 10:08, PLD th-src builder wrote:
> > > openjdk8.spec (HEAD): OK
> > >
> > > --- openjdk8.spec:HEAD:
> > > Build-Time: user:12.04s sys:6.78s real:23.38s (faults io:18 non-io:365577)
> > >
> > > Files queued for ftp:
> > >   77449097 openjdk8-1.8.0.312-1.src.rpm
> > >
> >
> > Any clues why the build hanged on th-x86_64 and th-i686?
> > _______________________________________________
> > pld-devel-en mailing list
> > pld-devel-en at lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>
>
>
> --
> Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> baggins<at>pld-linux.org



-- 
Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
baggins<at>pld-linux.org


From atler at pld-linux.org  Fri Oct 22 11:37:10 2021
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 22 Oct 2021 11:37:10 +0200
Subject: TEST build OK: openjdk8.spec
In-Reply-To: <CAKY5yHw7x7jOJZWxVEOX2uJWiMe8nnrsHOq005C7XxDY2W+m+A@mail.gmail.com>
References: <f9c3d01f-da60-4c33-827c-d580eb0026fb@pld.src.builder>
 <20211022081206.sxkzfnajgyncxtcq@pine>
 <CAKY5yHwNWoV30Aq44HsqJ=EuY4J0f5L9M1h9VcHXqJ+Vnf74uQ@mail.gmail.com>
 <CAKY5yHw7x7jOJZWxVEOX2uJWiMe8nnrsHOq005C7XxDY2W+m+A@mail.gmail.com>
Message-ID: <20211022093710.v25jx4erszaje2gk@pine>

On 22.10.2021 10:44, Jan R?korajski wrote:
> Ah, it wasn't icedtea but openjdk8 that was installed on i686 and x86_64.
> I'm uninstalling it and blocking in poldek on builders so that we have
> only openjdk11 installable there.

Currently openjdk8 requires either JDK 1.7 or 1.8 for build, I guess we
can patch it and try to build with openjdk11, no guarantees it would
work though. Not sure what is the difference but I had no issues
building openjdk8 1.8.0.312 with openjdk8 1.8.0.302 and glibc 2.34 on
x86_64, aarch64 and armv7hnl. I'll try to reproduce in fresh VM.

> On Fri, Oct 22, 2021 at 10:38 AM Jan R?korajski <j.rekorajski at gmail.com> wrote:
> >
> > 17461 ?        Ss     0:00  |                           \_ rpmbuild
> > -bb --define _smp_mflags -j9 --define _make_opts -Otarget --define
> > _pld_builder 1 --define _topdir /tmp/B.0338pl28 --defin
> > 17597 ?        S      0:00  |                               \_ /bin/sh
> > -e /tmp/B.0338pl28/BUILD/tmp/rpm-tmp.xcCtoN
> > 17640 ?        S      0:00  |                                   \_
> > /bin/bash ./configure LDFLAGS=-Wl,--as-needed
> > -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc
> > CFLAGS=-O2 -fw
> > 17643 ?        S      0:00  |                                       \_
> > bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
> > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/con
> > 17826 ?        S      0:00  |
> >  \_ bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
> > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga
> > 17828 ?        S      0:00  |
> >  |   \_ bash -c .
> > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
> > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u31
> > 18249 ?        S      0:00  |
> >  |   |   \_ bash -c .
> > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure
> > /tmp/B.0338pl28/BUILD/jdk8u-jdk
> > 18250 ?        Sl     0:02  |
> >  |   |       \_ /usr/lib/jvm/openjdk8/bin/java -version
> > 17829 ?        S      0:00  |
> >  |   \_ tee -a ./configure.log
> > 17827 ?        S      0:00  |
> >  \_ tee -a ./configure.log
> >
> > strace: Process 18250 attached
> > futex(0xf7ee3b28, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 18251, NULL,
> > FUTEX_BITSET_MATCH_ANY^C
> > strace: Process 18250 detached
> >  <detached ...>
> >
> > icedtea8 nie lubi si? z glibc 2.34?
> >
> > Ut?uk?em oba.
> >
> > On Fri, Oct 22, 2021 at 10:12 AM Jan Palus <atler at pld-linux.org> wrote:
> > >
> > > On 21.10.2021 10:08, PLD th-src builder wrote:
> > > > openjdk8.spec (HEAD): OK
> > > >
> > > > --- openjdk8.spec:HEAD:
> > > > Build-Time: user:12.04s sys:6.78s real:23.38s (faults io:18 non-io:365577)
> > > >
> > > > Files queued for ftp:
> > > >   77449097 openjdk8-1.8.0.312-1.src.rpm
> > > >
> > >
> > > Any clues why the build hanged on th-x86_64 and th-i686?
> > > _______________________________________________
> > > pld-devel-en mailing list
> > > pld-devel-en at lists.pld-linux.org
> > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> >
> >
> >
> > --
> > Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> > baggins<at>pld-linux.org
> 
> 
> 
> -- 
> Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> baggins<at>pld-linux.org
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


From baggins at pld-linux.org  Thu Oct 28 23:04:46 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Thu, 28 Oct 2021 23:04:46 +0200
Subject: How to update rust vendored crates contents?
Message-ID: <YXsQbqAHe9bsjUz9@tachikoma.lan>

Does anyone know how to update vendored crates in a rust package?

The problem is that only the latest and greates rust openssl crate
supports openssl 3.0.0, but libetebase and sccache list an old version.

I tried to change the versions in Cargo.lock but it gets confused about
checksums and dependencies. Removing checksum entries seem to move
things forward but does not pull other, intermediate deps.

Is there way to make that pull all the right crates automagically?

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From glen at pld-linux.org  Fri Oct 29 09:56:01 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Fri, 29 Oct 2021 10:56:01 +0300
Subject: How to update rust vendored crates contents?
In-Reply-To: <YXsQbqAHe9bsjUz9@tachikoma.lan>
References: <YXsQbqAHe9bsjUz9@tachikoma.lan>
Message-ID: <44b3db3c-a622-bb07-4c67-f60e0ac2bacd@pld-linux.org>

On 29.10.2021 00:04, Jan R?korajski wrote:

> Does anyone know how to update vendored crates in a rust package?
>
> The problem is that only the latest and greates rust openssl crate
> supports openssl 3.0.0, but libetebase and sccache list an old version.
>
> I tried to change the versions in Cargo.lock but it gets confused about
> checksums and dependencies. Removing checksum entries seem to move
> things forward but does not pull other, intermediate deps.
>
> Is there way to make that pull all the right crates automagically?

can you point to specific package, and/or your previous attempts (push 
as branch perhaps)




From baggins at pld-linux.org  Fri Oct 29 10:10:25 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 29 Oct 2021 10:10:25 +0200
Subject: How to update rust vendored crates contents?
In-Reply-To: <44b3db3c-a622-bb07-4c67-f60e0ac2bacd@pld-linux.org>
References: <YXsQbqAHe9bsjUz9@tachikoma.lan>
 <44b3db3c-a622-bb07-4c67-f60e0ac2bacd@pld-linux.org>
Message-ID: <YXuscUVGNHJDewdl@starbug.lan>

On Fri, 29 Oct 2021, Elan Ruusam?e wrote:

> On 29.10.2021 00:04, Jan R?korajski wrote:
> 
> > Does anyone know how to update vendored crates in a rust package?
> >
> > The problem is that only the latest and greates rust openssl crate
> > supports openssl 3.0.0, but libetebase and sccache list an old version.
> >
> > I tried to change the versions in Cargo.lock but it gets confused about
> > checksums and dependencies. Removing checksum entries seem to move
> > things forward but does not pull other, intermediate deps.
> >
> > Is there way to make that pull all the right crates automagically?
> 
> can you point to specific package, and/or your previous attempts (push 
> as branch perhaps)

See above, libetebase and sccache

And pushing to branch is not going to work because it breaks at
vendoring crates.

Edit Cargo.lock and update openssl and openssl-sys versions, try
`cargo vandor` and watch it fail.

I'll try to solve it a different way, let's see if making rust-openssl
as a separate package will work.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From atler at pld-linux.org  Sun Oct 31 02:06:03 2021
From: atler at pld-linux.org (Jan Palus)
Date: Sun, 31 Oct 2021 02:06:03 +0200
Subject: [packages/dracut] - bash is *required* for dracut initramfs to
 work correctly, rel 3
In-Reply-To: <63a4b90ecfdd4ac023ab8542fd6af60f4c80516e_refs_heads_master@pld-linux.org>
References: <272c7dd7eb5dfbcd6be88d0c4a584fd9f36163c4_refs_heads_master@pld-linux.org>
 <63a4b90ecfdd4ac023ab8542fd6af60f4c80516e_refs_heads_master@pld-linux.org>
Message-ID: <20211031000603.siaiyvmu3mifoyv5@kalarepa>

On 30.10.2021 23:23, baggins wrote:
> commit 63a4b90ecfdd4ac023ab8542fd6af60f4c80516e
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Sat Oct 30 23:21:06 2021 +0200
> 
>     - bash is *required* for dracut initramfs to work correctly, rel 3

At some point dracut started to pretend mksh is supported as /bin/sh
inside initramfs but that's simply not true. Default fallback is
whatever system /bin/sh is linked which in our case is mksh hence broken
initramfs in some cases. Going back to previous default "dash" helped in
my case (lvm) -- are you sure it really needs bash? And perhaps maybe
let's leave a possibility to customize shell and instead of hardcoding
bash use:

add_dracutmodules+=" bash "

which effectively changes default shell.

(At some point I was going to add `add_dracutmodules+=" dash "` but must
have forgotten).

>     
>     If /bin/sh is not bash then dracut initramfs is unable to grok encrypted partitions.
> 
>  bash.patch  | 10 ++++++++++
>  dracut.spec |  4 +++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> ---
> diff --git a/dracut.spec b/dracut.spec
> index c9484a0..4384e98 100644
> --- a/dracut.spec
> +++ b/dracut.spec
> @@ -2,7 +2,7 @@ Summary:	Initramfs generator using udev
>  Summary(pl.UTF-8):	Generator initramfs wykorzystuj?cy udev
>  Name:		dracut
>  Version:	055
> -Release:	2
> +Release:	3
>  License:	GPL v2+
>  Group:		Base
>  Source0:	https://www.kernel.org/pub/linux/utils/boot/dracut/%{name}-%{version}.tar.xz
> @@ -13,6 +13,7 @@ Patch1:		os-release.patch
>  Patch2:		arch-libdir.patch
>  Patch3:		systemd-paths.patch
>  Patch4:		cryptsetup.patch
> +Patch5:		bash.patch
>  URL:		https://dracut.wiki.kernel.org/
>  BuildRequires:	asciidoc
>  BuildRequires:	dash
> @@ -185,6 +186,7 @@ Bashowe dope?nianie sk?adni dla polecenia dracut.
>  %patch2 -p1
>  %patch3 -p1
>  %patch4 -p1
> +%patch5 -p1
>  
>  %{__sed} -i -e 's, at libexecdir@,%{_libexecdir},g' modules.d/50plymouth/module-setup.sh
>  %{__sed} -i -e 's, at lib@,%{_lib},g' modules.d/95resume/module-setup.sh
> diff --git a/bash.patch b/bash.patch
> new file mode 100644
> index 0000000..e51aae7
> --- /dev/null
> +++ b/bash.patch
> @@ -0,0 +1,10 @@
> +--- dracut-055/modules.d/00bash/module-setup.sh~	2021-05-27 14:34:19.000000000 +0200
> ++++ dracut-055/modules.d/00bash/module-setup.sh	2021-10-30 23:03:00.931687353 +0200
> +@@ -27,6 +27,6 @@
> +     inst /bin/bash
> + 
> +     # Prefer bash as default shell if no other shell is preferred.
> +-    [[ -L $initdir/bin/sh ]] || ln -sf bash "${initdir}/bin/sh"
> ++    ln -sf bash "${initdir}/bin/sh"
> + 
> + }
> ================================================================
> 
> ---- gitweb:
> 
> http://git.pld-linux.org/gitweb.cgi/packages/dracut.git/commitdiff/63a4b90ecfdd4ac023ab8542fd6af60f4c80516e
> 
> _______________________________________________
> pld-cvs-commit mailing list
> pld-cvs-commit at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit


From baggins at pld-linux.org  Sun Oct 31 09:21:53 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 31 Oct 2021 09:21:53 +0100
Subject: [packages/dracut] - bash is *required* for dracut initramfs to
 work correctly, rel 3
In-Reply-To: <20211031000603.siaiyvmu3mifoyv5@kalarepa>
References: <272c7dd7eb5dfbcd6be88d0c4a584fd9f36163c4_refs_heads_master@pld-linux.org>
 <63a4b90ecfdd4ac023ab8542fd6af60f4c80516e_refs_heads_master@pld-linux.org>
 <20211031000603.siaiyvmu3mifoyv5@kalarepa>
Message-ID: <YX5SIaZkH7PsXJG1@starbug.lan>

On Sun, 31 Oct 2021, Jan Palus wrote:

> On 30.10.2021 23:23, baggins wrote:
> > commit 63a4b90ecfdd4ac023ab8542fd6af60f4c80516e
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Sat Oct 30 23:21:06 2021 +0200
> > 
> >     - bash is *required* for dracut initramfs to work correctly, rel 3
> 
> At some point dracut started to pretend mksh is supported as /bin/sh
> inside initramfs but that's simply not true. Default fallback is
> whatever system /bin/sh is linked which in our case is mksh hence broken
> initramfs in some cases. Going back to previous default "dash" helped in
> my case (lvm) -- are you sure it really needs bash? And perhaps maybe

I know for certain that mksh does not. And very silently at that. Initramfs
just doesn't detect encrypted partitions.

> let's leave a possibility to customize shell and instead of hardcoding
> bash use:
> 
> add_dracutmodules+=" bash "
> 
> which effectively changes default shell.

I'm not so sure. What I found in the code is that dracut first installs
/bin/sh and then shell modules (00bash, 00dash, 00mksh) as needed.
But, those modules do not create /bin/sh if it already exists, and since
that symlink is installed first it will not be re-created.

> 
> (At some point I was going to add `add_dracutmodules+=" dash "` but must
> have forgotten).

Dracut already requires and installs bash into the initramfs for its own
needs. I'd rather stick to my "fix" to make absolutely sure it's there
and as /bin/sh to avoid new surprises.

Besides /etc/dracut.conf.d/01-dist.conf is marked in package as
config(noreplace) and you may end up with .rpmnew and effectively a
noop.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From atler at pld-linux.org  Sun Oct 31 11:56:00 2021
From: atler at pld-linux.org (Jan Palus)
Date: Sun, 31 Oct 2021 11:56:00 +0100
Subject: [packages/dracut] - bash is *required* for dracut initramfs to
 work correctly, rel 3
In-Reply-To: <YX5SIaZkH7PsXJG1@starbug.lan>
References: <272c7dd7eb5dfbcd6be88d0c4a584fd9f36163c4_refs_heads_master@pld-linux.org>
 <63a4b90ecfdd4ac023ab8542fd6af60f4c80516e_refs_heads_master@pld-linux.org>
 <20211031000603.siaiyvmu3mifoyv5@kalarepa>
 <YX5SIaZkH7PsXJG1@starbug.lan>
Message-ID: <20211031105600.7jais6u4utwplvsa@kalarepa>

On 31.10.2021 09:21, Jan R?korajski wrote:
> On Sun, 31 Oct 2021, Jan Palus wrote:
> 
> > On 30.10.2021 23:23, baggins wrote:
> > > commit 63a4b90ecfdd4ac023ab8542fd6af60f4c80516e
> > > Author: Jan R?korajski <baggins at pld-linux.org>
> > > Date:   Sat Oct 30 23:21:06 2021 +0200
> > > 
> > >     - bash is *required* for dracut initramfs to work correctly, rel 3
> > 
> > At some point dracut started to pretend mksh is supported as /bin/sh
> > inside initramfs but that's simply not true. Default fallback is
> > whatever system /bin/sh is linked which in our case is mksh hence broken
> > initramfs in some cases. Going back to previous default "dash" helped in
> > my case (lvm) -- are you sure it really needs bash? And perhaps maybe
> 
> I know for certain that mksh does not. And very silently at that. Initramfs
> just doesn't detect encrypted partitions.
> 
> > let's leave a possibility to customize shell and instead of hardcoding
> > bash use:
> > 
> > add_dracutmodules+=" bash "
> > 
> > which effectively changes default shell.
> 
> I'm not so sure. What I found in the code is that dracut first installs
> /bin/sh and then shell modules (00bash, 00dash, 00mksh) as needed.
> But, those modules do not create /bin/sh if it already exists, and since
> that symlink is installed first it will not be re-created.

Works for me. The place where dracut installs /bin/sh -> mksh is at first
script with /bin/sh shebang:

https://github.com/dracutdevs/dracut/blob/15398458685d376fef56b1bf6fe09ae7c68324c1/src/install/dracut-install.c#L531

Hence shell modules (bash/dash/mksh) are ordered with 00 before any such
script could be installed.

> > 
> > (At some point I was going to add `add_dracutmodules+=" dash "` but must
> > have forgotten).
> 
> Dracut already requires and installs bash into the initramfs for its own
> needs. I'd rather stick to my "fix" to make absolutely sure it's there
> and as /bin/sh to avoid new surprises.
> 
> Besides /etc/dracut.conf.d/01-dist.conf is marked in package as
> config(noreplace) and you may end up with .rpmnew and effectively a
> noop.

True. We could add a new file like 00-default-shell.conf though.


From baggins at pld-linux.org  Sun Oct 31 18:01:39 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 31 Oct 2021 18:01:39 +0100
Subject: Some packages to be removed post openssl 3.0.0 update
Message-ID: <YX7L844Yf80Meq5V@starbug.lan>

There are a few packages that do not build either because of OpenSSL
incompatibilities or/and because they are FUBAR.

Unless someone fixes the packages below, I will remove them in ~two
weeks.

php 5.2
ekg
ipsec-tools (abandoned by upstream, do not use)
libetebase
megacmd
mosh

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/