From glen at pld-linux.org  Wed Sep  1 05:54:43 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 1 Sep 2021 06:54:43 +0300
Subject: rpm.org does not like absolute ones
In-Reply-To: <9759d1fd9d7285e94e648536e0ac108a6a9004d5_refs_heads_master@pld-linux.org>
References: <40aa0a345dcafaa146ef76b7cee48ddf7ab77f07_refs_heads_master@pld-linux.org>
 <9759d1fd9d7285e94e648536e0ac108a6a9004d5_refs_heads_master@pld-linux.org>
Message-ID: <f7883b68-4611-f6bc-5e6a-5422791e676d@pld-linux.org>


On 01.09.2021 01:24, baggins wrote:
> commit 9759d1fd9d7285e94e648536e0ac108a6a9004d5
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Wed Sep 1 00:23:26 2021 +0200
>
>      - relative symlinks, rpm.org does not like absolute ones

i don't like either :)


already from vserver times, when you walk vserver contents outside 
vserver, the links point to wrong places ...



From glen at pld-linux.org  Tue Sep  7 07:58:51 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 7 Sep 2021 08:58:51 +0300
Subject: go offline builds
Message-ID: <fba9ceaf-032c-5559-53e1-94448633170a@pld-linux.org>

http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=gitlab-runner&id=5c82ef48-a66a-4a3e-aa01-f8a19d9f0ac9&action=tail

so, how to tell go not to try to download and test those .mod files?


+ go build -ldflags '-X 
gitlab.com/gitlab-org/gitlab-runner/common.VERSION=13.12.0 -X 
gitlab.com/gitlab-org/gitlab-runner/common.REVISION=05161b14 -X 
gitlab.com/gitlab-org/gitlab-runner/common.BRANCH=v13.12.0 -X 
gitlab.com/gitlab-org/gitlab-runner/common.BUILT=2021-09-06T14:31:59+00:00 
-B 0xa57b752b73b6887bec85d38cc0f611b460527f0e' -a -v go: cloud.google.com/go/storage at v1.12.0: Get "https://proxy.golang.org/cloud.google.com/go/storage/@v/v1.12.0.mod": dial tcp 142.250.203.209:443: connect: connection refused
error: Bad exit status from /tmp/B.u4171lt3/BUILD/tmp/rpm-tmp.NIo6js 
(%build)


it's not a problem that sources are missing, the go mod vendor did not 
download any new files:


cd src/gitlab.com/gitlab-org/gitlab-runner

cp -a vendor/ vendor.old

go mod vendor

diff -ur vendor.old/ vendor

go version go1.16.6 linux/amd64




From glen at pld-linux.org  Tue Sep  7 08:11:04 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 7 Sep 2021 09:11:04 +0300
Subject: go offline builds
In-Reply-To: <fba9ceaf-032c-5559-53e1-94448633170a@pld-linux.org>
References: <fba9ceaf-032c-5559-53e1-94448633170a@pld-linux.org>
Message-ID: <e114e43f-f339-eb9e-dbbc-7c2469cafc95@pld-linux.org>


On 07.09.2021 08:58, Elan Ruusam?e wrote:
>
> http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=gitlab-runner&id=5c82ef48-a66a-4a3e-aa01-f8a19d9f0ac9&action=tail
>
> so, how to tell go not to try to download and test those .mod files?
>
>
> + go build -ldflags '-X 
> gitlab.com/gitlab-org/gitlab-runner/common.VERSION=13.12.0 -X 
> gitlab.com/gitlab-org/gitlab-runner/common.REVISION=05161b14 -X 
> gitlab.com/gitlab-org/gitlab-runner/common.BRANCH=v13.12.0 -X 
> gitlab.com/gitlab-org/gitlab-runner/common.BUILT=2021-09-06T14:31:59+00:00 
> -B 0xa57b752b73b6887bec85d38cc0f611b460527f0e' -a -v go:cloud.google.com/go/storage at v1.12.0: Get"https://proxy.golang.org/cloud.google.com/go/storage/@v/v1.12.0.mod": dial tcp 142.250.203.209:443: connect: connection refused
> error: Bad exit status from /tmp/B.u4171lt3/BUILD/tmp/rpm-tmp.NIo6js 
> (%build)

seems the fix was to force -mod=vendor:

https://github.com/pld-linux/gitlab-runner/commit/19c2ece1b357713056e21c35eb9c44acffa056df



From atler at pld-linux.org  Thu Sep 16 11:37:05 2021
From: atler at pld-linux.org (Jan Palus)
Date: Thu, 16 Sep 2021 11:37:05 +0200
Subject: [packages/icu/icu-67] - build icu67 packages, qt4 does not build
 correctly with gcc 11, so let's fulfill the icu dependenc
In-Reply-To: <2cee6d28a25b124dbe274691e5c3d5969b3514ec_refs_heads_icu-67@pld-linux.org>
References: <163014041472.31728.12259859885460004355@pld-linux.org>
 <2cee6d28a25b124dbe274691e5c3d5969b3514ec_refs_heads_icu-67@pld-linux.org>
Message-ID: <20210916093705.orsvjcfyait7ug2e@pine>

On 28.08.2021 10:46, baggins wrote:
> commit 2cee6d28a25b124dbe274691e5c3d5969b3514ec
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Sat Aug 28 10:45:38 2021 +0200
> 
>     - build icu67 packages, qt4 does not build correctly with gcc 11, so let's fulfill the icu dependency with this
> 

This package is somewhat problematic due to the way poldek works. On one
of my machines still with icu 67 that's what happened:

harfbuzz-icu-2.8.2-1.x86_64 obsoleted by harfbuzz-icu-2.9.1-1.x86_64                                                                                                                                                                  [256/384]
harfbuzz-icu-2.9.1-1.x86_64 marks libicu-69.1-1.x86_64 (cap libicuuc.so.69()(64bit))
 libicu-67.1-1.x86_64 obsoleted by libicu-69.1-1.x86_64
   orphaned QtCore-4.8.7-28.x86_64 marks libicu67-67.1-4.x86_64 (cap libicu = 67.1)

QtCore pulled libicu67 to satisfy broken dep, but it also left plenty of
other packages depending on libicu in old version since libicu67
satisfied broken dep. In other words upgrade of libicu to 69 does not
pull all packages that should be upgraded. This in turn will likely lead
to multiple libicu versions being loaded for a single application which
in turn means problems.


From baggins at pld-linux.org  Sun Sep 19 20:17:47 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 19 Sep 2021 20:17:47 +0200
Subject: qt4 broken on i686
In-Reply-To: <20210819190932.GA1671@mail>
References: <YR1u6OgNZ0H07bxm@tachikoma>
 <20210819190932.GA1671@mail>
Message-ID: <YUd+y1ujK4JdumEY@starbug>

On Thu, 19 Aug 2021, Jakub Bogusz wrote:

> On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan R?korajski wrote:
> > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> > infinite looping (ex. meinproc4 in kde4-kig).
> > 
> > I'm running out of ideas[1] and time to troubleshoot this and would
> > appreciate if anyone would be willing to try and figure out WTF is
> > broken there.
> > 
> > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> > glibc 2.34 issue, but I don't have resources at hand to validate it.
> 
> I don't know yet if it's related to glibc, gcc or binutils, but simple
> testcase is searching in empty QMap:
> 
> ```
> #include <QtCore/QMap>
> 
> int main()
> {
>     QMap<int, std::string> mm;
>     mm.constFind(999);
> }
> ```
> 
> It hangs even on carme-x86_64.
> 
> Issue is probably related to shared_null static field (SIOF?)

My take is on gcc 11. I downgraded everything but gcc and it still crashed.

To verify that it's indeed gcc I need to rebuild it (gcc) locally due to
intertwined deps preventing simple package downgrade.

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


From baggins at pld-linux.org  Sun Sep 19 20:20:28 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 19 Sep 2021 20:20:28 +0200
Subject: [packages/icu/icu-67] - build icu67 packages, qt4 does not build
 correctly with gcc 11, so let's fulfill the icu dependenc
In-Reply-To: <20210916093705.orsvjcfyait7ug2e@pine>
References: <163014041472.31728.12259859885460004355@pld-linux.org>
 <2cee6d28a25b124dbe274691e5c3d5969b3514ec_refs_heads_icu-67@pld-linux.org>
 <20210916093705.orsvjcfyait7ug2e@pine>
Message-ID: <YUd/bO5++ElSQWWZ@starbug>

On Thu, 16 Sep 2021, Jan Palus wrote:

> On 28.08.2021 10:46, baggins wrote:
> > commit 2cee6d28a25b124dbe274691e5c3d5969b3514ec
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Sat Aug 28 10:45:38 2021 +0200
> > 
> >     - build icu67 packages, qt4 does not build correctly with gcc 11, so let's fulfill the icu dependency with this
> > 
> 
> This package is somewhat problematic due to the way poldek works. On one
> of my machines still with icu 67 that's what happened:
> 
> harfbuzz-icu-2.8.2-1.x86_64 obsoleted by harfbuzz-icu-2.9.1-1.x86_64                                                                                                                                                                  [256/384]
> harfbuzz-icu-2.9.1-1.x86_64 marks libicu-69.1-1.x86_64 (cap libicuuc.so.69()(64bit))
>  libicu-67.1-1.x86_64 obsoleted by libicu-69.1-1.x86_64
>    orphaned QtCore-4.8.7-28.x86_64 marks libicu67-67.1-4.x86_64 (cap libicu = 67.1)
> 
> QtCore pulled libicu67 to satisfy broken dep, but it also left plenty of
> other packages depending on libicu in old version since libicu67
> satisfied broken dep. In other words upgrade of libicu to 69 does not
> pull all packages that should be upgraded. This in turn will likely lead
> to multiple libicu versions being loaded for a single application which
> in turn means problems.

That's unfortunate. I would happily get rid of this, but to do so,
we need to figure a way to reliably rebuild qt using gcc 11

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


From qboosh at pld-linux.org  Sun Sep 19 22:06:03 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 19 Sep 2021 22:06:03 +0200
Subject: qt4 broken on i686
In-Reply-To: <YUd+y1ujK4JdumEY@starbug>
References: <YR1u6OgNZ0H07bxm@tachikoma> <20210819190932.GA1671@mail>
 <YUd+y1ujK4JdumEY@starbug>
Message-ID: <20210919200603.GA14206@mail>

On Sun, Sep 19, 2021 at 08:17:47PM +0200, Jan R?korajski wrote:
> On Thu, 19 Aug 2021, Jakub Bogusz wrote:
> 
> > On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan R?korajski wrote:
> > > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> > > infinite looping (ex. meinproc4 in kde4-kig).
> > > 
> > > I'm running out of ideas[1] and time to troubleshoot this and would
> > > appreciate if anyone would be willing to try and figure out WTF is
> > > broken there.
> > > 
> > > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> > > glibc 2.34 issue, but I don't have resources at hand to validate it.
> > 
> > I don't know yet if it's related to glibc, gcc or binutils, but simple
> > testcase is searching in empty QMap:
> > 
> > ```
> > #include <QtCore/QMap>
> > 
> > int main()
> > {
> >     QMap<int, std::string> mm;
> >     mm.constFind(999);
> > }
> > ```
> > 
> > It hangs even on carme-x86_64.
> > 
> > Issue is probably related to shared_null static field (SIOF?)
> 
> My take is on gcc 11. I downgraded everything but gcc and it still crashed.
> 
> To verify that it's indeed gcc I need to rebuild it (gcc) locally due to
> intertwined deps preventing simple package downgrade.

I tried to investigate the issue deeper - and the last I found was:

The symbol _ZN8QMapData11shared_nullE (demangled: QMapData::shared_null)
resides both in executable (objdump -T from i686):

0804c040 g    DO .bss   00000048  Base        _ZN8QMapData11shared_nullE

and libQtCore.so.4:

002fa460 g    DO .data  00000048  Base        _ZN8QMapData11shared_nullE


When compiled in current Th, the code in executable sees symbol mapped
from executable and the library sees symbol mapped from library.

IIRC when compiled on slightly older system (qt4 built with gcc 7 or 8,
glibc 2.33 etc.) in both cases symbol address was the same.

But in my current system (i686, glibc-2.34, binutils-2.37, gcc-8.4.0, qt4
rebuilt in this environment) the result is the same as in Th: there are
two instances of this symbol and testcase hangs.


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


From atler at pld-linux.org  Wed Sep 22 16:20:42 2021
From: atler at pld-linux.org (Jan Palus)
Date: Wed, 22 Sep 2021 16:20:42 +0200
Subject: qt4 broken on i686
In-Reply-To: <20210919200603.GA14206@mail>
References: <YR1u6OgNZ0H07bxm@tachikoma> <20210819190932.GA1671@mail>
 <YUd+y1ujK4JdumEY@starbug> <20210919200603.GA14206@mail>
Message-ID: <20210922142042.kocshj6263uexvgy@kalarepa>

On 19.09.2021 22:06, Jakub Bogusz wrote:
> On Sun, Sep 19, 2021 at 08:17:47PM +0200, Jan R?korajski wrote:
> > On Thu, 19 Aug 2021, Jakub Bogusz wrote:
> > 
> > > On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan R?korajski wrote:
> > > > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> > > > infinite looping (ex. meinproc4 in kde4-kig).
> > > > 
> > > > I'm running out of ideas[1] and time to troubleshoot this and would
> > > > appreciate if anyone would be willing to try and figure out WTF is
> > > > broken there.
> > > > 
> > > > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> > > > glibc 2.34 issue, but I don't have resources at hand to validate it.
> > > 
> > > I don't know yet if it's related to glibc, gcc or binutils, but simple
> > > testcase is searching in empty QMap:
> > > 
> > > ```
> > > #include <QtCore/QMap>
> > > 
> > > int main()
> > > {
> > >     QMap<int, std::string> mm;
> > >     mm.constFind(999);
> > > }
> > > ```
> > > 
> > > It hangs even on carme-x86_64.
> > > 
> > > Issue is probably related to shared_null static field (SIOF?)
> > 
> > My take is on gcc 11. I downgraded everything but gcc and it still crashed.
> > 
> > To verify that it's indeed gcc I need to rebuild it (gcc) locally due to
> > intertwined deps preventing simple package downgrade.
> 
> I tried to investigate the issue deeper - and the last I found was:
> 
> The symbol _ZN8QMapData11shared_nullE (demangled: QMapData::shared_null)
> resides both in executable (objdump -T from i686):
> 
> 0804c040 g    DO .bss   00000048  Base        _ZN8QMapData11shared_nullE
> 
> and libQtCore.so.4:
> 
> 002fa460 g    DO .data  00000048  Base        _ZN8QMapData11shared_nullE
> 
> 
> When compiled in current Th, the code in executable sees symbol mapped
> from executable and the library sees symbol mapped from library.
> 
> IIRC when compiled on slightly older system (qt4 built with gcc 7 or 8,
> glibc 2.33 etc.) in both cases symbol address was the same.
> 
> But in my current system (i686, glibc-2.34, binutils-2.37, gcc-8.4.0, qt4
> rebuilt in this environment) the result is the same as in Th: there are
> two instances of this symbol and testcase hangs.

Same findings here, workaround committed which makes avogadro compile
successfully. Root cause of this behavior still to be determined though.


From glen at pld-linux.org  Thu Sep 23 13:32:39 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Thu, 23 Sep 2021 14:32:39 +0300
Subject: rpm: --nofsync: unknown option
Message-ID: <d7e234d7-58b1-a6f7-6a6e-2c00491e3113@pld-linux.org>

is there equivalent for rpm 4.16?


in virtualized environments, like docker build, there's no point calling 
fsync after each package installation.



From ngompa13 at gmail.com  Thu Sep 23 13:37:35 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Thu, 23 Sep 2021 07:37:35 -0400
Subject: rpm: --nofsync: unknown option
In-Reply-To: <d7e234d7-58b1-a6f7-6a6e-2c00491e3113@pld-linux.org>
References: <d7e234d7-58b1-a6f7-6a6e-2c00491e3113@pld-linux.org>
Message-ID: <CAEg-Je9wNoE6WoScgii=L54wJt2b-TkEGQhL61PKhRR86hkENA@mail.gmail.com>

On Thu, Sep 23, 2021 at 7:32 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
>
> is there equivalent for rpm 4.16?
>
>
> in virtualized environments, like docker build, there's no point calling
> fsync after each package installation.
>

No, it was explicitly removed a long time ago[1], though there are
knobs to minimize writes:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/macros.in#L750-L762

[1]: https://github.com/rpm-software-management/rpm/issues/1401#issuecomment-760919959

-- 
?????????/ Always, there's only one truth!


From qboosh at pld-linux.org  Mon Sep 27 18:42:38 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 27 Sep 2021 18:42:38 +0200
Subject: systemd vs split /usr
Message-ID: <20210927164238.GA5889@stranger.qboosh.pl>

meson.build from systemd 249 says:
"split-usr mode is going to be removed"
(and sysusers.d location is already broken/inconsistent in this version,
I'm going to patch it)

Any plans related to this?


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


From ngompa13 at gmail.com  Mon Sep 27 18:46:05 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Mon, 27 Sep 2021 12:46:05 -0400
Subject: systemd vs split /usr
In-Reply-To: <20210927164238.GA5889@stranger.qboosh.pl>
References: <20210927164238.GA5889@stranger.qboosh.pl>
Message-ID: <CAEg-Je-f_KDmokXEyUHgOt0dXNDfBPK3mJE9CDgxbGBOLu3HKA@mail.gmail.com>

On Mon, Sep 27, 2021 at 12:37 PM Jakub Bogusz <qboosh at pld-linux.org> wrote:
>
> meson.build from systemd 249 says:
> "split-usr mode is going to be removed"
> (and sysusers.d location is already broken/inconsistent in this version,
> I'm going to patch it)
>
> Any plans related to this?
>

Nobody is maintaining split /usr mode upstream, so I'm not surprised
it's going away. If someone still wants that, they should help
upstream to maintain the option.



-- 
?????????/ Always, there's only one truth!