From atler at pld-linux.org  Mon Mar  1 00:50:56 2021
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 1 Mar 2021 00:50:56 +0100
Subject: OK: python-traceback2.spec
In-Reply-To: <pld-builder.1614554949.988538.15257@ymir>
References: <9f3694ac-3dc9-4009-a026-3da7ee950e41@pld.src.builder>
 <pld-builder.1614554949.988538.15257@ymir>
Message-ID: <20210228235056.tbv3qpyubtwcyu24@pine>

On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> python-traceback2.spec (HEAD): OK
> 
> --- python-traceback2.spec:HEAD:
> upgrading packages
> Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751)
> 
> Files queued for ftp:
>      22657 python3-traceback2-1.4.0-4.noarch.rpm
>      19641 python-traceback2-1.4.0-4.noarch.rpm
>        144 python-traceback2-1.4.0-4.src.rpm.uploadinfo
> 

Any idea why builders did not upgrade to this release (still on
1.4.0-2)?


From baggins at pld-linux.org  Mon Mar  1 01:08:24 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 1 Mar 2021 01:08:24 +0100
Subject: OK: python-traceback2.spec
In-Reply-To: <20210228235056.tbv3qpyubtwcyu24@pine>
References: <9f3694ac-3dc9-4009-a026-3da7ee950e41@pld.src.builder>
 <pld-builder.1614554949.988538.15257@ymir>
 <20210228235056.tbv3qpyubtwcyu24@pine>
Message-ID: <20210301000824.GL1869@starbug>

On Mon, 01 Mar 2021, Jan Palus wrote:

> On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > python-traceback2.spec (HEAD): OK
> > 
> > --- python-traceback2.spec:HEAD:
> > upgrading packages
> > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751)
> > 
> > Files queued for ftp:
> >      22657 python3-traceback2-1.4.0-4.noarch.rpm
> >      19641 python-traceback2-1.4.0-4.noarch.rpm
> >        144 python-traceback2-1.4.0-4.src.rpm.uploadinfo
> > 
> 
> Any idea why builders did not upgrade to this release (still on
> 1.4.0-2)?

Does not seem installed at all

https://srcbuilder.pld-linux.org/th/queue.html#215039


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


From atler at pld-linux.org  Mon Mar  1 01:14:22 2021
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 1 Mar 2021 01:14:22 +0100
Subject: OK: python-traceback2.spec
In-Reply-To: <20210301000824.GL1869@starbug>
References: <9f3694ac-3dc9-4009-a026-3da7ee950e41@pld.src.builder>
 <pld-builder.1614554949.988538.15257@ymir>
 <20210228235056.tbv3qpyubtwcyu24@pine>
 <20210301000824.GL1869@starbug>
Message-ID: <20210301001422.drtvlz2ib6dzacqb@pine>

On 01.03.2021 01:08, Jan R?korajski wrote:
> On Mon, 01 Mar 2021, Jan Palus wrote:
> 
> > On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > > python-traceback2.spec (HEAD): OK
> > > 
> > > --- python-traceback2.spec:HEAD:
> > > upgrading packages
> > > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751)
> > > 
> > > Files queued for ftp:
> > >      22657 python3-traceback2-1.4.0-4.noarch.rpm
> > >      19641 python-traceback2-1.4.0-4.noarch.rpm
> > >        144 python-traceback2-1.4.0-4.src.rpm.uploadinfo
> > > 
> > 
> > Any idea why builders did not upgrade to this release (still on
> > 1.4.0-2)?
> 
> Does not seem installed at all
> 
> https://srcbuilder.pld-linux.org/th/queue.html#215039

Little confused then, what's the meaning of "rpm -qa of builder:" in
build details? ie:

http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&action=qatxt


From baggins at pld-linux.org  Mon Mar  1 01:18:59 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 1 Mar 2021 01:18:59 +0100
Subject: OK: python-traceback2.spec
In-Reply-To: <20210301001422.drtvlz2ib6dzacqb@pine>
References: <9f3694ac-3dc9-4009-a026-3da7ee950e41@pld.src.builder>
 <pld-builder.1614554949.988538.15257@ymir>
 <20210228235056.tbv3qpyubtwcyu24@pine>
 <20210301000824.GL1869@starbug>
 <20210301001422.drtvlz2ib6dzacqb@pine>
Message-ID: <20210301001859.GM1869@starbug>

On Mon, 01 Mar 2021, Jan Palus wrote:

> On 01.03.2021 01:08, Jan R?korajski wrote:
> > On Mon, 01 Mar 2021, Jan Palus wrote:
> > 
> > > On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > > > python-traceback2.spec (HEAD): OK
> > > > 
> > > > --- python-traceback2.spec:HEAD:
> > > > upgrading packages
> > > > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751)
> > > > 
> > > > Files queued for ftp:
> > > >      22657 python3-traceback2-1.4.0-4.noarch.rpm
> > > >      19641 python-traceback2-1.4.0-4.noarch.rpm
> > > >        144 python-traceback2-1.4.0-4.src.rpm.uploadinfo
> > > > 
> > > 
> > > Any idea why builders did not upgrade to this release (still on
> > > 1.4.0-2)?
> > 
> > Does not seem installed at all
> > 
> > https://srcbuilder.pld-linux.org/th/queue.html#215039
> 
> Little confused then, what's the meaning of "rpm -qa of builder:" in
> build details? ie:
> 
> http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&action=qatxt

Query done at: 2021-02-28 03:00:01.083405

Out of date? I can take a look at this tomorrow if no one beats me to it.

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


From atler at pld-linux.org  Mon Mar  1 10:48:08 2021
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 1 Mar 2021 10:48:08 +0100
Subject: OK: python-traceback2.spec
In-Reply-To: <20210301001859.GM1869@starbug>
References: <9f3694ac-3dc9-4009-a026-3da7ee950e41@pld.src.builder>
 <pld-builder.1614554949.988538.15257@ymir>
 <20210228235056.tbv3qpyubtwcyu24@pine>
 <20210301000824.GL1869@starbug>
 <20210301001422.drtvlz2ib6dzacqb@pine>
 <20210301001859.GM1869@starbug>
Message-ID: <20210301094808.dhb32mmd6y2lruqr@pine>

On 01.03.2021 01:18, Jan R?korajski wrote:
> On Mon, 01 Mar 2021, Jan Palus wrote:
> 
> > On 01.03.2021 01:08, Jan R?korajski wrote:
> > > On Mon, 01 Mar 2021, Jan Palus wrote:
> > > 
> > > > On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > > > > python-traceback2.spec (HEAD): OK
> > > > > 
> > > > > --- python-traceback2.spec:HEAD:
> > > > > upgrading packages
> > > > > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751)
> > > > > 
> > > > > Files queued for ftp:
> > > > >      22657 python3-traceback2-1.4.0-4.noarch.rpm
> > > > >      19641 python-traceback2-1.4.0-4.noarch.rpm
> > > > >        144 python-traceback2-1.4.0-4.src.rpm.uploadinfo
> > > > > 
> > > > 
> > > > Any idea why builders did not upgrade to this release (still on
> > > > 1.4.0-2)?
> > > 
> > > Does not seem installed at all
> > > 
> > > https://srcbuilder.pld-linux.org/th/queue.html#215039
> > 
> > Little confused then, what's the meaning of "rpm -qa of builder:" in
> > build details? ie:
> > 
> > http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&action=qatxt
> 
> Query done at: 2021-02-28 03:00:01.083405
> 
> Out of date? I can take a look at this tomorrow if no one beats me to it.

Thanks that explains. Actually it made me realize that `rpm -qa` for
every build is the same global link. So far I was under impression that
`rpm -qa` would be done for each request before build or at least that
would make more sense to me. Can it be changed this way?


From atler at pld-linux.org  Mon Mar  1 13:19:10 2021
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 1 Mar 2021 13:19:10 +0100
Subject: TEST build ERRORS: vtk.spec
In-Reply-To: <b76b65f4-6808-41c9-aba0-8df70db54cd6@pld.src.builder>
References: <b76b65f4-6808-41c9-aba0-8df70db54cd6@pld.src.builder>
Message-ID: <20210301121910.cqbogn2o4v6h3qnv@pine>

On 01.03.2021 11:59, PLD th-src builder wrote:
> vtk.spec (HEAD): FAILED
> 
> --- vtk.spec:HEAD:
> Build-Time: user:1.17s sys:0.84s real:7.29s (faults io:435 non-io:44415)
> 
> 
> 
> *** buildlog for vtk.spec
> request from: atler
> started at: Mon Mar  1 12:59:52 2021
> building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps --http --define '_pld_builder 1' -bs  -r HEAD    vtk.spec 2>&1
> 
> Cloning into 'vtk'...
> Already on 'master'
> Your branch is up to date with 'origin/master'.
> Already up to date.
> sh: /usr/bin/tclsh: inaccessible or not found
> error: /home/users/builder/rpm/packages/vtk/vtk.spec: line 399: Macro %tcl_version has empty body
> Name (NVR) query failed
> internal error: cache_rpm_dump not called! (missing %prep?)
> internal error: cache_rpm_dump not called! (missing %prep?)
> internal error: cache_rpm_dump not called! (missing %prep?)
> internal error: cache_rpm_dump not called! (missing %prep?)
> internal error: cache_rpm_dump not called! (missing %prep?)
> internal error: cache_rpm_dump not called! (missing %prep?)
> WARNING! Spec name (vtk) does not agree with package name ()

I suppose tcl should be installed on src builder.

> No conditional flags passed
> 
> from available:
> --with   :	 OSMesa system_gl2ps
> --without:	 doc ffmpeg java
> 
> Available branches: VTK-6.0 master
> ./builder[2720]: ulimit: unlimited exceeds allowable coredump(blocks) limit
> error: Bad source: /home/users/builder/rpm/packages/vtk/VTKData-8.2.0.tar.gz: No such file or directory
> Building target platforms: i686-linux
> Building for target i686-linux
> real 0.09
> user 0.06
> sys 0.01
> Error: package build failed. (no more info)
> exit status 1280
> error: No files produced.
> error: Macro %_builddir has empty body
> Begin-PLD-Builder-Info
> Build-Time: user:1.17s sys:0.84s real:7.29s (faults io:435 non-io:44415)
> 
> End-PLD-Builder-Info
> 
> 


From baggins at pld-linux.org  Mon Mar  1 20:44:38 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 1 Mar 2021 20:44:38 +0100
Subject: TEST build ERRORS: vtk.spec
In-Reply-To: <20210301121910.cqbogn2o4v6h3qnv@pine>
References: <b76b65f4-6808-41c9-aba0-8df70db54cd6@pld.src.builder>
 <20210301121910.cqbogn2o4v6h3qnv@pine>
Message-ID: <20210301193308.GA17422@tachikoma>

On Mon, 01 Mar 2021, Jan Palus wrote:

> On 01.03.2021 11:59, PLD th-src builder wrote:
> > vtk.spec (HEAD): FAILED
> > 
> > --- vtk.spec:HEAD:
> > Build-Time: user:1.17s sys:0.84s real:7.29s (faults io:435 non-io:44415)
> > 
> > 
> > 
> > *** buildlog for vtk.spec
> > request from: atler
> > started at: Mon Mar  1 12:59:52 2021
> > building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps --http --define '_pld_builder 1' -bs  -r HEAD    vtk.spec 2>&1
> > 
> > Cloning into 'vtk'...
> > Already on 'master'
> > Your branch is up to date with 'origin/master'.
> > Already up to date.
> > sh: /usr/bin/tclsh: inaccessible or not found
> > error: /home/users/builder/rpm/packages/vtk/vtk.spec: line 399: Macro %tcl_version has empty body
> > Name (NVR) query failed
> > internal error: cache_rpm_dump not called! (missing %prep?)
> > internal error: cache_rpm_dump not called! (missing %prep?)
> > internal error: cache_rpm_dump not called! (missing %prep?)
> > internal error: cache_rpm_dump not called! (missing %prep?)
> > internal error: cache_rpm_dump not called! (missing %prep?)
> > internal error: cache_rpm_dump not called! (missing %prep?)
> > WARNING! Spec name (vtk) does not agree with package name ()
> 
> I suppose tcl should be installed on src builder.

That's half of the solution. The other half is to fix the macro to not
expand to nothing. I'll take care of both.

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


From baggins at pld-linux.org  Mon Mar  1 20:48:13 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 1 Mar 2021 20:48:13 +0100
Subject: OK: python-traceback2.spec
In-Reply-To: <20210301094808.dhb32mmd6y2lruqr@pine>
References: <9f3694ac-3dc9-4009-a026-3da7ee950e41@pld.src.builder>
 <pld-builder.1614554949.988538.15257@ymir>
 <20210228235056.tbv3qpyubtwcyu24@pine>
 <20210301000824.GL1869@starbug>
 <20210301001422.drtvlz2ib6dzacqb@pine>
 <20210301001859.GM1869@starbug>
 <20210301094808.dhb32mmd6y2lruqr@pine>
Message-ID: <20210301194813.GB17422@tachikoma>

On Mon, 01 Mar 2021, Jan Palus wrote:

> On 01.03.2021 01:18, Jan R?korajski wrote:
> > On Mon, 01 Mar 2021, Jan Palus wrote:
> > 
> > > On 01.03.2021 01:08, Jan R?korajski wrote:
> > > > On Mon, 01 Mar 2021, Jan Palus wrote:
> > > > 
> > > > > On 28.02.2021 23:29, PLD th-x86_64 builder wrote:
> > > > > > python-traceback2.spec (HEAD): OK
> > > > > > 
> > > > > > --- python-traceback2.spec:HEAD:
> > > > > > upgrading packages
> > > > > > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751)
> > > > > > 
> > > > > > Files queued for ftp:
> > > > > >      22657 python3-traceback2-1.4.0-4.noarch.rpm
> > > > > >      19641 python-traceback2-1.4.0-4.noarch.rpm
> > > > > >        144 python-traceback2-1.4.0-4.src.rpm.uploadinfo
> > > > > > 
> > > > > 
> > > > > Any idea why builders did not upgrade to this release (still on
> > > > > 1.4.0-2)?
> > > > 
> > > > Does not seem installed at all
> > > > 
> > > > https://srcbuilder.pld-linux.org/th/queue.html#215039
> > > 
> > > Little confused then, what's the meaning of "rpm -qa of builder:" in
> > > build details? ie:
> > > 
> > > http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&action=qatxt
> > 
> > Query done at: 2021-02-28 03:00:01.083405
> > 
> > Out of date? I can take a look at this tomorrow if no one beats me to it.
> 
> Thanks that explains. Actually it made me realize that `rpm -qa` for
> every build is the same global link. So far I was under impression that
> `rpm -qa` would be done for each request before build or at least that
> would make more sense to me. Can it be changed this way?

That would require some reengineering. This is currently run on builders
as a cronjob.

http://git.pld-linux.org/?p=projects/pld-builder.new.git;a=blob;f=PLD_Builder/maintainer.py

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


From glen at pld-linux.org  Tue Mar  2 10:34:55 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 2 Mar 2021 11:34:55 +0200
Subject: OK: python-traceback2.spec
In-Reply-To: <20210301194813.GB17422@tachikoma>
References: <9f3694ac-3dc9-4009-a026-3da7ee950e41@pld.src.builder>
 <pld-builder.1614554949.988538.15257@ymir>
 <20210228235056.tbv3qpyubtwcyu24@pine> <20210301000824.GL1869@starbug>
 <20210301001422.drtvlz2ib6dzacqb@pine> <20210301001859.GM1869@starbug>
 <20210301094808.dhb32mmd6y2lruqr@pine> <20210301194813.GB17422@tachikoma>
Message-ID: <30cba548-0f03-c128-0239-260d8eec48a1@pld-linux.org>

On 01.03.2021 21:48, Jan R?korajski wrote:

>
>> Thanks that explains. Actually it made me realize that `rpm -qa` for
>> every build is the same global link. So far I was under impression that
>> `rpm -qa` would be done for each request before build or at least that
>> would make more sense to me. Can it be changed this way?
> That would require some reengineering. This is currently run on builders
> as a cronjob.
simplest would be modify rpm_builder to run the command before and after 
each build

ideally it could be formatted as html details block:

<details>

<summary>Output of <tt>rpm -qa</tt></summary>

<pre>

here be rpm -qa output

</pre>

</details>


stupid-simple-but-wrong is to format exactly like that in rpm_builder

correct, but more difficult would be to apply formatting on buildlogs code.


that's another topic i guess, but consider that when making the changes.


From glen at pld-linux.org  Tue Mar  2 10:38:11 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 2 Mar 2021 11:38:11 +0200
Subject: [packages/flake8] explicit runtime deps on
 python-{entrypoints,mccabe,pycodestyle,pyflakes}; rel 3
In-Reply-To: <9c7664000af796dea8cd3794ae3ac37ff08274bb_refs_heads_master@pld-linux.org>
References: <a712f07c9735ac47fe0c6fdd5c51b7bf6eaf7253_refs_heads_master@pld-linux.org>
 <9c7664000af796dea8cd3794ae3ac37ff08274bb_refs_heads_master@pld-linux.org>
Message-ID: <183501e7-e09b-b8dc-bf0c-ee425c499b89@pld-linux.org>

On 01.03.2021 18:53, atler wrote:

> commit 9c7664000af796dea8cd3794ae3ac37ff08274bb
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Mon Mar 1 17:52:20 2021 +0100
>
>      explicit runtime deps on python-{entrypoints,mccabe,pycodestyle,pyflakes}; rel 3
>      
>      ...because poldek cannot handle boolean dep
>
>   flake8.spec | 18 +++++++++++++++++-
>   1 file changed, 17 insertions(+), 1 deletion(-)
> ---
> diff --git a/flake8.spec b/flake8.spec
> index 5dbcb6f..5ddc216 100644
> --- a/flake8.spec
> +++ b/flake8.spec
> @@ -9,7 +9,7 @@ Summary:	The modular source code checker: pycodestyle, pyflakes and co
>   Summary(pl.UTF-8):	Modularne narz?dzie do sprawdzania kodu ?r?d?owego: pycodestyle, pyflakes itp.
>   Name:		flake8
>   Version:	3.7.9
> -Release:	2
> +Release:	3
>   License:	MIT
>   Group:		Development/Tools
>   #Source0Download: https://pypi.org/simple/flake8/
> @@ -85,7 +85,15 @@ dla narz?dzi:
>   Summary:	The modular source code checker: pycodestyle, pyflakes and co
>   Summary(pl.UTF-8):	Modularne narz?dzie do sprawdzania kodu ?r?d?owego: pycodestyle, pyflakes itp.
>   Group:		Libraries/Python
> +Requires:	python-entrypoints >= 0.3
> +Requires:	python-entrypoints < 0.4
> +Requires:	python-mccabe >= 0.6.0
> +Requires:	python-mccabe < 0.7.0
>   Requires:	python-modules >= 1:2.7
> +Requires:	python-pycodestyle >= 2.5.0
> +Requires:	python-pycodestyle < 2.6.0
> +Requires:	python-pyflakes >= 2.1.0
> +Requires:	python-pyflakes < 2.2.0
>   

what is boolean dep? can't see any match from here:

- https://www.pld-linux.org/packages/rpm


from what you solving, seems a dependency generator issue to me

i? think it's still better to fix dependency generator than again start 
to manually fill dependencies,

and then those get outdated very soon.



From atler at pld-linux.org  Tue Mar  2 11:49:24 2021
From: atler at pld-linux.org (Jan Palus)
Date: Tue, 2 Mar 2021 11:49:24 +0100
Subject: [packages/flake8] explicit runtime deps on
 python-{entrypoints,mccabe,pycodestyle,pyflakes}; rel 3
In-Reply-To: <183501e7-e09b-b8dc-bf0c-ee425c499b89@pld-linux.org>
References: <a712f07c9735ac47fe0c6fdd5c51b7bf6eaf7253_refs_heads_master@pld-linux.org>
 <9c7664000af796dea8cd3794ae3ac37ff08274bb_refs_heads_master@pld-linux.org>
 <183501e7-e09b-b8dc-bf0c-ee425c499b89@pld-linux.org>
Message-ID: <20210302104924.awnqr6yjx73nti7t@pine>

On 02.03.2021 11:38, Elan Ruusam?e wrote:
> On 01.03.2021 18:53, atler wrote:
> 
> > commit 9c7664000af796dea8cd3794ae3ac37ff08274bb
> > Author: Jan Palus <atler at pld-linux.org>
> > Date:   Mon Mar 1 17:52:20 2021 +0100
> > 
> >      explicit runtime deps on python-{entrypoints,mccabe,pycodestyle,pyflakes}; rel 3
> >      ...because poldek cannot handle boolean dep
> > 
> >   flake8.spec | 18 +++++++++++++++++-
> >   1 file changed, 17 insertions(+), 1 deletion(-)
> > ---
> > diff --git a/flake8.spec b/flake8.spec
> > index 5dbcb6f..5ddc216 100644
> > --- a/flake8.spec
> > +++ b/flake8.spec
> > @@ -9,7 +9,7 @@ Summary:	The modular source code checker: pycodestyle, pyflakes and co
> >   Summary(pl.UTF-8):	Modularne narz?dzie do sprawdzania kodu ?r?d?owego: pycodestyle, pyflakes itp.
> >   Name:		flake8
> >   Version:	3.7.9
> > -Release:	2
> > +Release:	3
> >   License:	MIT
> >   Group:		Development/Tools
> >   #Source0Download: https://pypi.org/simple/flake8/
> > @@ -85,7 +85,15 @@ dla narz?dzi:
> >   Summary:	The modular source code checker: pycodestyle, pyflakes and co
> >   Summary(pl.UTF-8):	Modularne narz?dzie do sprawdzania kodu ?r?d?owego: pycodestyle, pyflakes itp.
> >   Group:		Libraries/Python
> > +Requires:	python-entrypoints >= 0.3
> > +Requires:	python-entrypoints < 0.4
> > +Requires:	python-mccabe >= 0.6.0
> > +Requires:	python-mccabe < 0.7.0
> >   Requires:	python-modules >= 1:2.7
> > +Requires:	python-pycodestyle >= 2.5.0
> > +Requires:	python-pycodestyle < 2.6.0
> > +Requires:	python-pyflakes >= 2.1.0
> > +Requires:	python-pyflakes < 2.2.0
> 
> what is boolean dep? can't see any match from here:

https://rpm.org/user_doc/boolean_dependencies.html

in this case it's a dependency that tells ie required python-pyflakes
version should be both '>=' and '<'.

Sample from failing rpmlint build:
http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&ns=&cnt=50&off=0&name=rpmlint&id=e978a528-13c2-428f-88f7-22ba68295283&action=text

poldek: warn: (python3.9dist(entrypoints) < 0.4 with python3.9dist(entrypoints) >= 0.3): skipping boolean dependency (not supported yet)
poldek: warn: (python3.9dist(mccabe) < 0.7 with python3.9dist(mccabe) >= 0.6): skipping boolean dependency (not supported yet)
poldek: warn: (python3.9dist(pycodestyle) < 2.6 with python3.9dist(pycodestyle) >= 2.5): skipping boolean dependency (not supported yet)
poldek: warn: (python3.9dist(pyflakes) < 2.2 with python3.9dist(pyflakes) >= 2.1): skipping boolean dependency (not supported yet)
poldek: There are 2 packages to install:
poldek: A python3-flake8-3.7.9-2.noarch  python3-rpm-4.16.1.2-7.x86_64
...
poldek: Executing pm-command.sh --upgrade -vh --test --root / --define _check_dirname_deps 0...
poldek: error: Failed dependencies:
poldek: 	(python3.9dist(entrypoints) < 0.4 with python3.9dist(entrypoints) >= 0.3) is needed by python3-flake8-3.7.9-2.noarch
poldek: 	(python3.9dist(mccabe) < 0.7 with python3.9dist(mccabe) >= 0.6) is needed by python3-flake8-3.7.9-2.noarch
poldek: 	(python3.9dist(pyflakes) < 2.2 with python3.9dist(pyflakes) >= 2.1) is needed by python3-flake8-3.7.9-2.noarch

> - https://www.pld-linux.org/packages/rpm
> 
> 
> from what you solving, seems a dependency generator issue to me
> 
> i? think it's still better to fix dependency generator than again start to
> manually fill dependencies,
> 
> and then those get outdated very soon.

The solution is to add boolean dependency support to poldek.


From glen at pld-linux.org  Fri Mar  5 22:21:18 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Fri, 5 Mar 2021 23:21:18 +0200
Subject: PLD-doc: BuildRequires.txt - updated noarch subpackage dependency
In-Reply-To: <PLD_doc_BuildRequires.txt.1.203@pld-linux.org>
References: <PLD_doc_BuildRequires.txt.1.202@pld-linux.org>
 <PLD_doc_BuildRequires.txt.1.203@pld-linux.org>
Message-ID: <b2e0e501-11d7-9732-dd14-81b9c1ac297d@pld-linux.org>

On 05.03.2021 21:59, qboosh wrote:

> +# subpackage with BuildArch: noarch
> +BuildRequires:	rpm-build >= 4.6
> +# (with epoch 0 covers both rpm.org 4.6+ (>= 1:4.6) / rpm5 (>= 5.0);
> +# it's mostly informational, rpm 4.5 will bail with syntax error,
> +# before noticing unfulfilled dependency)
> +
Epoch: 1 was introduced in 4.16, not before


From glen at pld-linux.org  Tue Mar  9 13:36:10 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 9 Mar 2021 14:36:10 +0200
Subject: warning: tag 273 type(0x6) != implicit type(0x0)
Message-ID: <1ed70eb4-3804-2ded-a1c7-4d565602a222@pld-linux.org>

|Upgrading... 1:ImageMagick-libs 
########################################### [ 20%] 2:ImageMagick 
########################################### [ 40%] ==> warning: tag 273 
type(0x6) != implicit type(0x0) 3:php53-pecl-imagick 
########################################### [ 60%] what can you say 
about those messages? 1. what does it mean? 2. what's the impact (what's 
missing, what's broken) package itself seems okay, `php -m` shows the 
module. |



From glen at pld-linux.org  Tue Mar  9 16:45:14 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 9 Mar 2021 17:45:14 +0200
Subject: hrmib compat
Message-ID: <e9565a8f-eb04-6084-05b8-00d02e3733ce@pld-linux.org>

could we please remove (rename to .rpmold or something) the directory 
that is no longer supported:


[~/rpm/packages/BUILD.x86_64-linux/opencv-4.5.1] ? du /var/cache/hrmib/
384K??? /var/cache/hrmib/
[~/rpm/packages/BUILD.x86_64-linux/opencv-4.5.1] ?


so, instead of giving outdated info, it would give ENOENT error.



From qboosh at pld-linux.org  Tue Mar  9 16:50:17 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 9 Mar 2021 16:50:17 +0100
Subject: warning: tag 273 type(0x6) != implicit type(0x0)
In-Reply-To: <1ed70eb4-3804-2ded-a1c7-4d565602a222@pld-linux.org>
References: <1ed70eb4-3804-2ded-a1c7-4d565602a222@pld-linux.org>
Message-ID: <20210309155017.GA23235@mail>

On Tue, Mar 09, 2021 at 02:36:10PM +0200, Elan Ruusam?e wrote:
> |Upgrading... 1:ImageMagick-libs 
> ########################################### [ 20%] 2:ImageMagick 
> ########################################### [ 40%] ==> warning: tag 273 
> type(0x6) != implicit type(0x0) 3:php53-pecl-imagick 
> ########################################### [ 60%] what can you say 
> about those messages? 1. what does it mean? 2. what's the impact (what's 
> missing, what's broken) package itself seems okay, `php -m` shows the 
> module. |

Looks like some rpm format incompatibilities.
Which rpm is used to install, which was used to built this package?


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


From arekm at maven.pl  Tue Mar  9 16:58:30 2021
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Tue, 9 Mar 2021 16:58:30 +0100
Subject: warning: tag 273 type(0x6) != implicit type(0x0)
In-Reply-To: <20210309155017.GA23235@mail>
References: <1ed70eb4-3804-2ded-a1c7-4d565602a222@pld-linux.org>
 <20210309155017.GA23235@mail>
Message-ID: <23e5ce22-8185-d474-5b06-0be6fde7de31@maven.pl>

W dniu 09.03.2021 o?16:50, Jakub Bogusz pisze:
> On Tue, Mar 09, 2021 at 02:36:10PM +0200, Elan Ruusam?e wrote:
>> |Upgrading... 1:ImageMagick-libs 
>> ########################################### [ 20%] 2:ImageMagick 
>> ########################################### [ 40%] ==> warning: tag 273 
>> type(0x6) != implicit type(0x0) 3:php53-pecl-imagick 
>> ########################################### [ 60%] what can you say 
>> about those messages? 1. what does it mean? 2. what's the impact (what's 
>> missing, what's broken) package itself seems okay, `php -m` shows the 
>> module. |
> 
> Looks like some rpm format incompatibilities.
> Which rpm is used to install, which was used to built this package?
> 
> 

Packages built with rpm4 that are installed on rpm5 systems often (not
sure if always) trigger this.

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


From krzysztof at mrozowicz.eu  Tue Mar  9 17:19:51 2021
From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz)
Date: Tue, 9 Mar 2021 16:19:51 +0000
Subject: =?utf-8?q?Re=3A?==?utf-8?q?_warning=3A?= tag 273 type(0x6)
 =?utf-8?q?!=3D?= implicit type(0x0)
In-Reply-To: <23e5ce22-8185-d474-5b06-0be6fde7de31@maven.pl>
Message-ID: <0102017817c999be-1ae3aaee-6d43-436a-8f93-553e3c7ba8d4-000000@eu-west-1.amazonses.com>

On Tuesday, March 09, 2021 15:58 GMT, Arkadiusz Mi?kiewicz <arekm at maven.pl> wrote: 
> 
> Packages built with rpm4 that are installed on rpm5 systems often (not
> sure if always) trigger this.

In my case it was opposite, as far as I remember. On one of the machines I installed rpm4, before it was announced as available on th-test and for few weeks I was seeing similar warnings. Once I installed rpm, poldek, etc... from th-test the warning disappeared.

--
Krzysiek


From baggins at pld-linux.org  Wed Mar 10 08:57:53 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 10 Mar 2021 08:57:53 +0100
Subject: warning: tag 273 type(0x6) != implicit type(0x0)
In-Reply-To: <1ed70eb4-3804-2ded-a1c7-4d565602a222@pld-linux.org>
References: <1ed70eb4-3804-2ded-a1c7-4d565602a222@pld-linux.org>
Message-ID: <20210310075753.GA2262@starbug>

On Tue, 09 Mar 2021, Elan Ruusam?e wrote:

> |Upgrading... 1:ImageMagick-libs 
> ########################################### [ 20%] 2:ImageMagick 
> ########################################### [ 40%] ==> warning: tag 273 
> type(0x6) != implicit type(0x0) 3:php53-pecl-imagick 
> ########################################### [ 60%] what can you say 
> about those messages? 1. what does it mean? 2. what's the impact (what's 
> missing, what's broken) package itself seems okay, `php -m` shows the 
> module. |

Harmless. This is

RPMTAG_SHA256HEADER         = RPMTAG_SIG_BASE+17,

that does not exist in rpm5. So when rpm5 sees an unknown tag it assumes
it should have no type and then emits the warning.

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


From glen at pld-linux.org  Wed Mar 10 15:16:25 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 10 Mar 2021 16:16:25 +0200
Subject: doc: rediff-patches.py
Message-ID: <9b6b773b-c4bb-7f3c-5bb5-837ad9881234@pld-linux.org>

(arekm): document, or at least menton rediff-patches.py in wiki

https://www.pld-linux.org/packages/rpm



From glen at pld-linux.org  Wed Mar 10 15:17:49 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 10 Mar 2021 16:17:49 +0200
Subject: doc: rediff-patches.py
In-Reply-To: <9b6b773b-c4bb-7f3c-5bb5-837ad9881234@pld-linux.org>
References: <9b6b773b-c4bb-7f3c-5bb5-837ad9881234@pld-linux.org>
Message-ID: <a3ec2da7-fca5-6aad-4fce-6fe818be0cab@pld-linux.org>

On 10.03.2021 16:16, Elan Ruusam?e wrote:

> (arekm): document, or at least menton rediff-patches.py in wiki
>
> https://www.pld-linux.org/packages/rpm
>
also, make it universally usable elsewhere than "works for me":


[~/rpm/packages/eventum(3.9.11) (master)?] ? 
../rpm-build-tools/rediff-patches.py -v *.spec
Traceback (most recent call last):
 ? File 
"/home/users/glen/rpm/packages/eventum/../rpm-build-tools/rediff-patches.py", 
line 188, in <module>
 ??? main()
 ? File 
"/home/users/glen/rpm/packages/eventum/../rpm-build-tools/rediff-patches.py", 
line 131, in main
 ??? tempdir = tempfile.TemporaryDirectory(dir="/dev/shm")
 ? File "/usr/lib64/python3.9/tempfile.py", line 779, in __init__
 ??? self.name = mkdtemp(suffix, prefix, dir)
 ? File "/usr/lib64/python3.9/tempfile.py", line 359, in mkdtemp
 ??? _os.mkdir(file, 0o700)
FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/shm/tmpwazv0l62'
[~/rpm/packages/eventum(3.9.11) (master)?] ?



From glen at pld-linux.org  Wed Mar 10 15:46:27 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 10 Mar 2021 16:46:27 +0200
Subject: rpm -blink
Message-ID: <86db8b60-8f0c-f5a7-1858-38a45ab806d7@pld-linux.org>

$ rpm -q glibc --blink

rpm: --blink: unknown option


the "backwards link" is not available for rpm 4.16, any alternatives?



From glen at pld-linux.org  Fri Mar 12 09:40:14 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Fri, 12 Mar 2021 10:40:14 +0200
Subject: ca-certs for https://git.php.net
Message-ID: <23f513f3-3a8f-c2f0-2e5e-fce1a16cd0aa@pld-linux.org>

$ curl https://git.php.net/repository/pecl/encryption/mcrypt.git
curl: (60) SSL certificate problem: unable to get local issuer certificate
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.


$ rpm -q ca-certificates curl-7.75.0
ca-certificates-20210119-1.noarch
curl-7.75.0-1.x86_64


something off in our systems. this works fine on curl on macos brew



From atler at pld-linux.org  Fri Mar 12 09:49:50 2021
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 12 Mar 2021 09:49:50 +0100
Subject: ca-certs for https://git.php.net
In-Reply-To: <23f513f3-3a8f-c2f0-2e5e-fce1a16cd0aa@pld-linux.org>
References: <23f513f3-3a8f-c2f0-2e5e-fce1a16cd0aa@pld-linux.org>
Message-ID: <20210312084950.ga47s6xx5kkj4mg7@pine>

On 12.03.2021 10:40, Elan Ruusam?e wrote:
> $ curl https://git.php.net/repository/pecl/encryption/mcrypt.git
> curl: (60) SSL certificate problem: unable to get local issuer certificate
> 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.
> 
> 
> $ rpm -q ca-certificates curl-7.75.0
> ca-certificates-20210119-1.noarch
> curl-7.75.0-1.x86_64
> 
> 
> something off in our systems. this works fine on curl on macos brew

Works for me with same set of packages. Outdated ca-certificates.crt due
to ca-certificates-update + noreplace perhaps? Try with
ca-certificates-20210119-2.


From glen at pld-linux.org  Fri Mar 12 09:55:36 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Fri, 12 Mar 2021 10:55:36 +0200
Subject: [packages/python-sympy] - up to 1.7.1, python 2 no longer
 supported
In-Reply-To: <a7afb2642f193eb728569b130fd57bdc8acadd02_refs_heads_master@pld-linux.org>
References: <a7715bb72d0b9b22270d78f9f9c7f8ea280cd570_refs_heads_master@pld-linux.org>
 <a7afb2642f193eb728569b130fd57bdc8acadd02_refs_heads_master@pld-linux.org>
Message-ID: <3b26fa0f-fac3-84a1-7042-ef287b8d0331@pld-linux.org>


On 12.03.2021 00:32, baggins wrote:
> commit a7afb2642f193eb728569b130fd57bdc8acadd02
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Thu Mar 11 23:32:30 2021 +0100
>
>      - up to 1.7.1, python 2 no longer supported
>
>   python-sympy-nodisplay.patch | 25 -------------------------
>   python-sympy.spec            |  8 +++-----
>   2 files changed, 3 insertions(+), 30 deletions(-)
> ---
> diff --git a/python-sympy.spec b/python-sympy.spec
> index cb6d2e4..6c9214c 100644
> --- a/python-sympy.spec
> +++ b/python-sympy.spec
> @@ -2,20 +2,19 @@
>   # Conditional build:
>   %bcond_without	doc	# HTML and PDF documentation
>   %bcond_without	tests	# unit tests
> -%bcond_without	python2 # CPython 2.x module
> +%bcond_with	python2 # CPython 2.x module
>   %bcond_without	python3 # CPython 3.x module
>   

i agree with what qboosh has been doing in this cases:

1. git ssh copy python-foo to python3-foo

2. update python3-foo to be python3 only

3. update python3-foo to new version, stb

4. disable python3 from python-foo, relup, stb


it takes extra steps to do that, but i think it's worth the effort in 
long term.

it's weird to have python-foo to build python3-foo,
and the python3-foo will be cleaner without having to support two python 
versions.


ps;

git ssh seems to be my alias in git config:


```

[alias]
 ??? ssh = !ssh git at git.pld-linux.org

```




From j.rekorajski at gmail.com  Fri Mar 12 10:25:36 2021
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Fri, 12 Mar 2021 10:25:36 +0100
Subject: [packages/python-sympy] - up to 1.7.1,
 python 2 no longer supported
In-Reply-To: <3b26fa0f-fac3-84a1-7042-ef287b8d0331@pld-linux.org>
References: <a7715bb72d0b9b22270d78f9f9c7f8ea280cd570_refs_heads_master@pld-linux.org>
 <a7afb2642f193eb728569b130fd57bdc8acadd02_refs_heads_master@pld-linux.org>
 <3b26fa0f-fac3-84a1-7042-ef287b8d0331@pld-linux.org>
Message-ID: <CAKY5yHw4EbfKZsn545fASiBK7dM6puXK5mEfMhDojAWZyqw3_Q@mail.gmail.com>

On Fri, Mar 12, 2021 at 9:55 AM Elan Ruusam?e <glen at pld-linux.org> wrote:

>
> On 12.03.2021 00:32, baggins wrote:
> > commit a7afb2642f193eb728569b130fd57bdc8acadd02
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Thu Mar 11 23:32:30 2021 +0100
> >
> >      - up to 1.7.1, python 2 no longer supported
> >
> >   python-sympy-nodisplay.patch | 25 -------------------------
> >   python-sympy.spec            |  8 +++-----
> >   2 files changed, 3 insertions(+), 30 deletions(-)
> > ---
> > diff --git a/python-sympy.spec b/python-sympy.spec
> > index cb6d2e4..6c9214c 100644
> > --- a/python-sympy.spec
> > +++ b/python-sympy.spec
> > @@ -2,20 +2,19 @@
> >   # Conditional build:
> >   %bcond_without      doc     # HTML and PDF documentation
> >   %bcond_without      tests   # unit tests
> > -%bcond_without       python2 # CPython 2.x module
> > +%bcond_with  python2 # CPython 2.x module
> >   %bcond_without      python3 # CPython 3.x module
> >
>
> i agree with what qboosh has been doing in this cases:
>
> 1. git ssh copy python-foo to python3-foo
>
> 2. update python3-foo to be python3 only
>
> 3. update python3-foo to new version, stb
>
> 4. disable python3 from python-foo, relup, stb
>

And I very much do not agree with that.
Python 2 must die. If upstream decides to drop python2 support, we should
too,
we should not keep old odd versions indefinitely[1].  This creates chaos
because
we end up with inconsistent mess.

[1] We may, but only for a very strong reasons, ex. a ton of packages would
break.

it takes extra steps to do that, but i think it's worth the effort in
> long term.
>
> it's weird to have python-foo to build python3-foo,
> and the python3-foo will be cleaner without having to support two python
> versions.
>

What we should do here is to just drop python2 from python-foo, what I'll
do once
the dust after current 3.9 / rpm deps rebuild settles.

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


From glen at pld-linux.org  Fri Mar 12 20:36:09 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Fri, 12 Mar 2021 21:36:09 +0200
Subject: ca-certs for https://git.php.net
In-Reply-To: <20210312084950.ga47s6xx5kkj4mg7@pine>
References: <23f513f3-3a8f-c2f0-2e5e-fce1a16cd0aa@pld-linux.org>
 <20210312084950.ga47s6xx5kkj4mg7@pine>
Message-ID: <aabdd977-ac98-7be5-b057-09748ab306b8@pld-linux.org>


On 12.03.2021 10:49, Jan Palus wrote:
> On 12.03.2021 10:40, Elan Ruusam?e wrote:
>> $ curl https://git.php.net/repository/pecl/encryption/mcrypt.git
>> curl: (60) SSL certificate problem: unable to get local issuer certificate
>> 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.
>>
>>
>> $ rpm -q ca-certificates curl-7.75.0
>> ca-certificates-20210119-1.noarch
>> curl-7.75.0-1.x86_64
>>
>>
>> something off in our systems. this works fine on curl on macos brew
> Works for me with same set of packages. Outdated ca-certificates.crt due
> to ca-certificates-update + noreplace perhaps? Try with
> ca-certificates-20210119-2.


updated, still doesn't work on carme:


$ curl https://git.php.net/repository/pecl/encryption/mcrypt.git
curl: (60) SSL certificate problem: unable to get local issuer certificate
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.

$ q ca-certificates
ca-certificates-20210119-3.noarch


here's probably the problem source, the host has ca-certificates 
installed, and very old config:

$ l /etc/ca-certificates.conf*
-rw-r--r-- 1 root root 6.3K Feb? 1? 2010 /etc/ca-certificates.conf
-rw-r--r-- 1 root root 5.5K Mar 12 12:51 /etc/ca-certificates.conf.rpmnew

perhaps the package provided certs should be moved to 
/usr/share/ca-certificates/ca-certificates.conf and 
/etc/ca-certificates.conf be only local customizations?



From glen at pld-linux.org  Sat Mar 13 12:56:55 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Sat, 13 Mar 2021 13:56:55 +0200
Subject: ac updates stop
Message-ID: <cd8401d9-0093-4da8-2c2d-fae29ff98001@pld-linux.org>

https://www.pld-linux.org/ac#updates_stopped

there haven't been any updates for a while for pld-ac,

and as the builders infrastructure no longer works due drop of python2 
and introduction of rpm 4.16 on src builder,

i've decided to just stop the infrastructure, rather repairing it.



From qboosh at pld-linux.org  Sat Mar 13 22:17:30 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 13 Mar 2021 22:17:30 +0100
Subject: [packages/python-sympy] - up to 1.7.1,
 python 2 no longer supported
In-Reply-To: <CAKY5yHw4EbfKZsn545fASiBK7dM6puXK5mEfMhDojAWZyqw3_Q@mail.gmail.com>
References: <a7715bb72d0b9b22270d78f9f9c7f8ea280cd570_refs_heads_master@pld-linux.org>
 <a7afb2642f193eb728569b130fd57bdc8acadd02_refs_heads_master@pld-linux.org>
 <3b26fa0f-fac3-84a1-7042-ef287b8d0331@pld-linux.org>
 <CAKY5yHw4EbfKZsn545fASiBK7dM6puXK5mEfMhDojAWZyqw3_Q@mail.gmail.com>
Message-ID: <20210313211730.GA20612@mail>

On Fri, Mar 12, 2021 at 10:25:36AM +0100, Jan R?korajski wrote:
> On Fri, Mar 12, 2021 at 9:55 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
> 
> >
> > On 12.03.2021 00:32, baggins wrote:
> > > commit a7afb2642f193eb728569b130fd57bdc8acadd02
> > > Author: Jan R?korajski <baggins at pld-linux.org>
> > > Date:   Thu Mar 11 23:32:30 2021 +0100
> > >
> > >      - up to 1.7.1, python 2 no longer supported
> > >
> > >   python-sympy-nodisplay.patch | 25 -------------------------
> > >   python-sympy.spec            |  8 +++-----
> > >   2 files changed, 3 insertions(+), 30 deletions(-)
> > > ---
> > > diff --git a/python-sympy.spec b/python-sympy.spec
> > > index cb6d2e4..6c9214c 100644
> > > --- a/python-sympy.spec
> > > +++ b/python-sympy.spec
> > > @@ -2,20 +2,19 @@
> > >   # Conditional build:
> > >   %bcond_without      doc     # HTML and PDF documentation
> > >   %bcond_without      tests   # unit tests
> > > -%bcond_without       python2 # CPython 2.x module
> > > +%bcond_with  python2 # CPython 2.x module
> > >   %bcond_without      python3 # CPython 3.x module
> > >
> >
> > i agree with what qboosh has been doing in this cases:
> >
> > 1. git ssh copy python-foo to python3-foo
> >
> > 2. update python3-foo to be python3 only
> >
> > 3. update python3-foo to new version, stb
> >
> > 4. disable python3 from python-foo, relup, stb
> >
> 
> And I very much do not agree with that.
> Python 2 must die. If upstream decides to drop python2 support, we should
> too,
> we should not keep old odd versions indefinitely[1].  This creates chaos
> because
> we end up with inconsistent mess.
> 
> [1] We may, but only for a very strong reasons, ex. a ton of packages would
> break.

Python 2 is dying, more and more (mostly very common) packages are dropping support,
but there are still/will be "long tails" of not ported single packages.

Mainstream is slowly porting from gtk+ 3 to gtk 4 and we still have gtk+ 1.

Ofc, there is no sense to keep all active forever, python2 packages can
fade out from the "loose" (non-required) ends.

For the active cases - as we didn't go Fedora way with renaming all
python 2.x packages to python2-*, I see two possibilities:

a) python-foo.spec with python2-only module/version of module or python2/3 modules
  and python3-foo.spec with python3-only module/version of module

b) python-foo.spec:master branch with python3-only module/version of module or python2/3 modules
  and python-foo.spec:PYTHON2 branch with last supported python2 version

I personally prefer a) because:
- we can build all active packages from repo heads (I am aware of just two
  exceptions from this "rule": kernel.spec and php.spec)

- in case of python3-only spec, we need only one package preamble
  (b) case requires dummy base package and "-n python3-foo" subpackage)

In case of b), in python3-only cases apidocs should be packaged as
"%package -n python3-*-apidocs", not "%package apidocs".

> it takes extra steps to do that, but i think it's worth the effort in
> > long term.
> >
> > it's weird to have python-foo to build python3-foo,
> > and the python3-foo will be cleaner without having to support two python
> > versions.
> >
> 
> What we should do here is to just drop python2 from python-foo, what I'll
> do once
> the dust after current 3.9 / rpm deps rebuild settles.

Keeping dead python2 boilerplate in spec (just with bcond off) after updating
to python3-only version makes no sense...


As for establishing some python2/3 packaging/migration policy - where to
Obsolete python-* packages after dropping python2 variants?


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


From gotar at polanet.pl  Sun Mar 14 04:06:36 2021
From: gotar at polanet.pl (Tomasz Pala)
Date: Sun, 14 Mar 2021 04:06:36 +0100
Subject: ca-certs for https://git.php.net
In-Reply-To: <aabdd977-ac98-7be5-b057-09748ab306b8@pld-linux.org>
References: <23f513f3-3a8f-c2f0-2e5e-fce1a16cd0aa@pld-linux.org>
 <20210312084950.ga47s6xx5kkj4mg7@pine>
 <aabdd977-ac98-7be5-b057-09748ab306b8@pld-linux.org>
Message-ID: <20210314030635.GA20358@polanet.pl>

On Fri, Mar 12, 2021 at 21:36:09 +0200, Elan Ruusam?e wrote:

> $ q ca-certificates
> ca-certificates-20210119-3.noarch
> 
> 
> here's probably the problem source, the host has ca-certificates 
> installed, and very old config:
> 
> $ l /etc/ca-certificates.conf*
> -rw-r--r-- 1 root root 6.3K Feb? 1? 2010 /etc/ca-certificates.conf
> -rw-r--r-- 1 root root 5.5K Mar 12 12:51 /etc/ca-certificates.conf.rpmnew
> 
> perhaps the package provided certs should be moved to 
> /usr/share/ca-certificates/ca-certificates.conf and 
> /etc/ca-certificates.conf be only local customizations?


Do not reinvent the wheel, introduce distro-agnostic and widly adopdet update-ca-trust:

https://stackoverflow.com/questions/37043442/how-to-add-certificate-authority-file-in-centos-7
https://gist.github.com/kekru/deabd57f0605ed95d5c8246d18483687
https://docs.fedoraproject.org/en-US/quick-docs/using-shared-system-certificates/
https://wiki.archlinux.org/index.php/User:Grawity/Adding_a_trusted_CA_certificate
https://fedora.pkgs.org/32/fedora-x86_64/ca-certificates-2020.2.40-3.fc32.noarch.rpm.html
https://fedoraproject.org/wiki/CA-Certificates


Second thing - please move away all the additional/local (national) CAs from global
package; I don't trust ESTEID, you shouldn't trust Certum (or should you? [1]).

I have no idea, if Terena should be trusted by default:
https://www.geant.org/Services/Trust_identity_and_security/Pages/TCS.aspx
https://wiki.geant.org/display/TCSNT/TCS+wiki+%282020%29+Sectigo

but I definitely do not need them:

https://wiki.geant.org/display/TCSNT/TCS+Participants+Sectigo


OTOH I use NCCert-signed EuroCert certificates for ePUAP validation. Here comes the quest:
find the valid ones.

https://www.nccert.pl/ root CA:
	-> https://www.nccert.pl/files/nccert2016.crt

https://www.nccert.pl/zaswiadczenia.htm EuroCert_QCA3_2017.crt doesn't work
	-> https://www.nccert.pl/files/EuroCert_QCA3_2017.crt
        Serial Number:
            47:00:3d:10:9e:95:cc:29:5e:b6:3a:b7:82:43:0c:55:e7:e4:b7:63
        Issuer: C=PL, O=Narodowy Bank Polski, CN=Narodowe Centrum Certyfikacji/2.5.4.97=VATPL-5250008198
        Validity
            Not Before: Mar 14 11:39:23 2017 GMT
            Not After : Mar 14 23:59:59 2028 GMT
        Subject: 2.5.4.97=VATPL-9512352379, C=PL, O=EuroCert Sp. z o.o., CN=Centrum Kwalifikowane EuroCert

https://eurocert.pl/pub/Prawo/		QCA03_Eurocert_2017.der works fine
	-> https://eurocert.pl/pub/Prawo/QCA03_Eurocert_2017.der
        Serial Number:
            1a:57:34:b0:d4:72:d2:51:e1:d3:7c:fe:3d:79:6a:c1:17:10:24:90
        Issuer: C=PL, O=Narodowy Bank Polski, CN=Narodowe Centrum Certyfikacji/2.5.4.97=VATPL-5250008198
        Validity
            Not Before: Feb 14 12:26:19 2017 GMT
            Not After : Feb 14 23:59:59 2028 GMT
        Subject: 2.5.4.97=VATPL-9512352379, C=PL, O=EuroCert Sp. z o.o., CN=Centrum Kwalifikowane EuroCert



However - and this might also be the case of ESTEID - I do use the
NCCert CA to validate the documents, but I don't need them to be in the
main CA bundle and trusted by default by all the system apps.

These certificates are used for private resources and might simply
reside in separate directory (I use /etc/pki/nccert) to be pointed when needed.


[1] back in 2003 I've also added Unizeto (Certum):
http://git.pld-linux.org/packages/certificates

It's been 18 years and if they didn't make it into some global widely
adopted bundle, they should go into separate subpackage.


In general, we shouldn't mix CAs from different resources (unless we're
going to start and really manage our own list).


Even more, I'd be pleased if the main bundle was split into parts of
globally respected ones and the rest. I don't need to trust any CA from
Brasil, China, Turkey (Kamu!) or Hungary.

https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
https://wiki.mozilla.org/CA/Additional_Trust_Changes


We should be able to select alternate lists, e.g.:
https://support.google.com/a/answer/7448393
https://www.chromium.org/Home/chromium-security/root-ca-policy


Thus:
ca-certificates -> virtual package falling back to R: ca-root-bundle-mozilla
ca-root-bundle-mozilla - mozilla root program
ca-root-bundle-chrome - chrome root program (https://g.co/chrome/root-store)
ca-root-bundle-microsoft - https://aka.ms/RootCert
ca-root-individual-pl-{asseco,kir} - Asseco/Unizeto/Certum, KIR (polish ones)
ca-root-individual-letsencrypt - single CA if I don't want any bundle
ca-root-individual-{google,apple,microsoft...} - ...and compose my own list
ca-root-private-* - installed in a way, that doesn't merge them into global CA
		(NCCert, possibly ESTEID)


-- 
Tomasz Pala <gotar at pld-linux.org>


From glen at pld-linux.org  Sun Mar 14 08:44:22 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Sun, 14 Mar 2021 09:44:22 +0200
Subject: [packages/libmodulemd] - finished packaging - rel 1
In-Reply-To: <7e23c54ef08faf4f8e8c57688903d25d7b5aa6d4_refs_heads_master@pld-linux.org>
References: <ac8ca4ca0c6db3e64db322c442d5194e578f720c_refs_heads_master@pld-linux.org>
 <7e23c54ef08faf4f8e8c57688903d25d7b5aa6d4_refs_heads_master@pld-linux.org>
Message-ID: <3af53def-c00b-399d-e18a-cbbd6bd58477@pld-linux.org>


On 13.03.2021 23:08, baggins wrote:
> commit 7e23c54ef08faf4f8e8c57688903d25d7b5aa6d4
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Sat Mar 13 22:07:34 2021 +0100
...
> +%package -n python2-%{name}
> +Summary:	Python 2 bindings for %{name}

this is new, we have been consistent and packaging python 2 packages as 
python-, not python2-


has this policy have been changed? are we massively migrating to that 
scheme?

in some earlier email to pld-devel-en you wrote you target dropping 
python2 from th,

so it does not make sense to start changing python 2 packaging scheme now.


if there is packaging change, it should include clear announcement, and 
preferrably prior discussion.



From baggins at pld-linux.org  Sun Mar 14 09:33:26 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 14 Mar 2021 09:33:26 +0100
Subject: [packages/libmodulemd] - finished packaging - rel 1
In-Reply-To: <3af53def-c00b-399d-e18a-cbbd6bd58477@pld-linux.org>
References: <ac8ca4ca0c6db3e64db322c442d5194e578f720c_refs_heads_master@pld-linux.org>
 <7e23c54ef08faf4f8e8c57688903d25d7b5aa6d4_refs_heads_master@pld-linux.org>
 <3af53def-c00b-399d-e18a-cbbd6bd58477@pld-linux.org>
Message-ID: <20210314083326.GB2262@starbug>

On Sun, 14 Mar 2021, Elan Ruusam?e wrote:

> 
> On 13.03.2021 23:08, baggins wrote:
> > commit 7e23c54ef08faf4f8e8c57688903d25d7b5aa6d4
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Sat Mar 13 22:07:34 2021 +0100
> ...
> > +%package -n python2-%{name}
> > +Summary:	Python 2 bindings for %{name}
> 
> this is new, we have been consistent and packaging python 2 packages as 
> python-, not python2-
> 
> 
> has this policy have been changed? are we massively migrating to that 
> scheme?
> 
> in some earlier email to pld-devel-en you wrote you target dropping 
> python2 from th,
> 
> so it does not make sense to start changing python 2 packaging scheme now.
> 
> 
> if there is packaging change, it should include clear announcement, and 
> preferrably prior discussion.

It would cost you less energy to fix that copy-pasto than write a wall
of text of nitpicking.

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


From glen at pld-linux.org  Sun Mar 14 11:00:35 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Sun, 14 Mar 2021 12:00:35 +0200
Subject: [packages/libmodulemd] - finished packaging - rel 1
In-Reply-To: <20210314083326.GB2262@starbug>
References: <ac8ca4ca0c6db3e64db322c442d5194e578f720c_refs_heads_master@pld-linux.org>
 <7e23c54ef08faf4f8e8c57688903d25d7b5aa6d4_refs_heads_master@pld-linux.org>
 <3af53def-c00b-399d-e18a-cbbd6bd58477@pld-linux.org>
 <20210314083326.GB2262@starbug>
Message-ID: <127c7a41-cc81-09fa-669f-e6db8f3ca4ac@pld-linux.org>

On 14.03.2021 10:33, Jan R?korajski wrote:

>
> It would cost you less energy to fix that copy-pasto than write a wall
> of text of nitpicking.

how would i know it's a copy-pasto error? you are making changes without 
prior discussion.





From atler at pld-linux.org  Tue Mar 16 13:39:17 2021
From: atler at pld-linux.org (Jan Palus)
Date: Tue, 16 Mar 2021 13:39:17 +0100
Subject: [packages/poldek] skip /usr/lib/.build-id when processing
 obsoletes
In-Reply-To: <aba59b953581b330457d7e6f0ea3e1ab648f80a7_refs_heads_master@pld-linux.org>
References: <f6764fbdf7354a79d6ba0cb53d5e1dd7a5f57d92_refs_heads_master@pld-linux.org>
 <aba59b953581b330457d7e6f0ea3e1ab648f80a7_refs_heads_master@pld-linux.org>
Message-ID: <20210316123917.usyzzgg72mjomlrj@pine>

On 16.03.2021 13:31, atler wrote:
> commit aba59b953581b330457d7e6f0ea3e1ab648f80a7
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Tue Mar 16 13:28:50 2021 +0100
> 
>     skip /usr/lib/.build-id when processing obsoletes
>     
>     fixes major performance regression when changing (downgrade, obsolete)
>     package with build-id to one that doesn't
> 
>  poldek.spec                  |  2 ++
>  skip-buildid-obsoletes.patch | 11 +++++++++++
>  2 files changed, 13 insertions(+)
...
> diff --git a/skip-buildid-obsoletes.patch b/skip-buildid-obsoletes.patch
> new file mode 100644
> index 0000000..1b2e7c1
> --- /dev/null
> +++ b/skip-buildid-obsoletes.patch
> @@ -0,0 +1,11 @@
> +--- poldek-0.42.2/install3/obsoletes.c.orig	2020-01-25 22:59:59.000000000 +0100
> ++++ poldek-0.42.2/install3/obsoletes.c	2021-03-16 13:14:05.667576984 +0100
> +@@ -188,6 +188,8 @@
> +         "/usr/share/doc/*",
> +         "/usr/share/man/*.[0-9]",
> +         "/usr/src/examples/*",
> ++        "/usr/lib/.build-id",
> ++        "/usr/lib/.build-id/*",
> +         "*.desktop",
> +         "*.mo",
> +         "*.gz",

Note that it's just half of the solution, the other one is to fix
find-debuginfo.sh to exclude any dir ownership. Currently every binary
package built with rpm4 owns /usr/lib/.build-id and its subdirectories
while only symlinks should be owned. If someone is up for this please be
my guest.


From glen at pld-linux.org  Tue Mar 16 13:54:11 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 16 Mar 2021 14:54:11 +0200
Subject: rpm 4.16 landed?
Message-ID: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>

i see rpm 4.16 is in th main.

please add a news entry to frontpage!



From glen at pld-linux.org  Tue Mar 16 15:45:27 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 16 Mar 2021 16:45:27 +0200
Subject: rpm 4.16 landed -> errors!
In-Reply-To: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
References: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
Message-ID: <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>

On 16.03.2021 14:54, Elan Ruusam?e wrote:

> i see rpm 4.16 is in th main.
>
> please add a news entry to frontpage!
>
the automatic upgrade is failing:

- https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214

to reproduce run poldek upgrade dist:


```

docker run 
registry.gitlab.com/pld-linux/pld:latest at sha256:3bf9e65ba27f6d2e254d37e5219d5ff38b8e6f86c214ae0d8c730b2868775931 
poldek --up --upgrade-dist

```

Backup of the rpm database has been created in 
/var/lib/rpm.rpmbackup-4.16.1.2-6 If poldek aborts after migration with 
rpmdb error, this is expected behaviour, you should ignore it and 
restart poldek warning: Converting database from bdb to sqlite backend 
error: failed to replace old database with new database! error: replace 
files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.40 to 
recover rpm database conversion failed! You have to run '/usr/bin/rpmdb 
--rebuilddb' manually error: %posttrans(rpm-4.16.1.2-6.x86_64) scriptlet 
failed, exit status 1




From glen at pld-linux.org  Tue Mar 16 15:47:35 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 16 Mar 2021 16:47:35 +0200
Subject: rpm 4.16 landed -> errors!
In-Reply-To: <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>
References: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
 <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>
Message-ID: <425b47d7-886c-3dc2-0a74-ab19dd26f756@pld-linux.org>


On 16.03.2021 16:45, Elan Ruusam?e wrote:
>
> the automatic upgrade is failing:
>
> - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214
>
oh, and user is left without rpmdb:


[@46a17bd0ade9 /]# rpm -q rpm poldek
warning: Found bdb Packages database while attempting sqlite backend: 
using bdb backend.
warning: Generating 6 missing index(es), please wait...
package rpm is not installed
package poldek is not installed

[@46a17bd0ade9 /]# rpm -q rpm poldek
warning: Found bdb Packages database while attempting sqlite backend: 
using bdb backend.
package rpm is not installed
package poldek is not installed
[@46a17bd0ade9 /]#




From baggins at pld-linux.org  Tue Mar 16 18:38:42 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 16 Mar 2021 18:38:42 +0100
Subject: rpm 4.16 landed -> errors!
In-Reply-To: <425b47d7-886c-3dc2-0a74-ab19dd26f756@pld-linux.org>
References: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
 <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>
 <425b47d7-886c-3dc2-0a74-ab19dd26f756@pld-linux.org>
Message-ID: <20210316173842.GC2262@starbug>

On Tue, 16 Mar 2021, Elan Ruusam?e wrote:

> 
> On 16.03.2021 16:45, Elan Ruusam?e wrote:
> >
> > the automatic upgrade is failing:
> >
> > - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214
> >
> oh, and user is left without rpmdb:
> 
> 
> [@46a17bd0ade9 /]# rpm -q rpm poldek
> warning: Found bdb Packages database while attempting sqlite backend: 
> using bdb backend.
> warning: Generating 6 missing index(es), please wait...
> package rpm is not installed
> package poldek is not installed
> 
> [@46a17bd0ade9 /]# rpm -q rpm poldek
> warning: Found bdb Packages database while attempting sqlite backend: 
> using bdb backend.
> package rpm is not installed
> package poldek is not installed
> [@46a17bd0ade9 /]#

First, regarding lost database.
You do have a backup of the database from before the update:

Backup of the rpm database has been created in /var/lib/rpm.rpmbackup-4.16.1.2-6

There is also the new database, that rpm was unable to move:

error: replace files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.42 to recover

Is /var/lib/rpm a mountpoint? That would be the explanation that comes
to mind. There must be something that prevented rpm from renaming temporary
directory in /var/lib to rpm.

I've been (live) testing upgrade path and I assumed it does work.
Never encountered problems after squashing rpm5 oddities.

I've been also asking over and over for testing and no one came with any
issues like this.

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


From ngompa13 at gmail.com  Tue Mar 16 18:57:10 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Tue, 16 Mar 2021 13:57:10 -0400
Subject: rpm 4.16 landed -> errors!
In-Reply-To: <20210316173842.GC2262@starbug>
References: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
 <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>
 <425b47d7-886c-3dc2-0a74-ab19dd26f756@pld-linux.org>
 <20210316173842.GC2262@starbug>
Message-ID: <CAEg-Je-1eC7SuHX=LcTZhnFXOUyGzg3R9QOtYNTk+CXNtSn8mg@mail.gmail.com>

On Tue, Mar 16, 2021 at 1:39 PM Jan R?korajski <baggins at pld-linux.org> wrote:
>
> On Tue, 16 Mar 2021, Elan Ruusam?e wrote:
>
> >
> > On 16.03.2021 16:45, Elan Ruusam?e wrote:
> > >
> > > the automatic upgrade is failing:
> > >
> > > - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214
> > >
> > oh, and user is left without rpmdb:
> >
> >
> > [@46a17bd0ade9 /]# rpm -q rpm poldek
> > warning: Found bdb Packages database while attempting sqlite backend:
> > using bdb backend.
> > warning: Generating 6 missing index(es), please wait...
> > package rpm is not installed
> > package poldek is not installed
> >
> > [@46a17bd0ade9 /]# rpm -q rpm poldek
> > warning: Found bdb Packages database while attempting sqlite backend:
> > using bdb backend.
> > package rpm is not installed
> > package poldek is not installed
> > [@46a17bd0ade9 /]#
>
> First, regarding lost database.
> You do have a backup of the database from before the update:
>
> Backup of the rpm database has been created in /var/lib/rpm.rpmbackup-4.16.1.2-6
>
> There is also the new database, that rpm was unable to move:
>
> error: replace files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.42 to recover
>
> Is /var/lib/rpm a mountpoint? That would be the explanation that comes
> to mind. There must be something that prevented rpm from renaming temporary
> directory in /var/lib to rpm.
>
> I've been (live) testing upgrade path and I assumed it does work.
> Never encountered problems after squashing rpm5 oddities.
>
> I've been also asking over and over for testing and no one came with any
> issues like this.
>

This is probably an overlayfs specific issue, I've seen various
problems with renames (which is what rpm does for rebuilding
databases) in containers.



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


From qboosh at pld-linux.org  Tue Mar 16 21:12:45 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 16 Mar 2021 21:12:45 +0100
Subject: [packages/crossmingw32-pango] - rpm.org+meson combo require to
 redefine all dirs
In-Reply-To: <f5e59fe05417d0d72ef5e99cb896e81fdb32885a_refs_heads_master@pld-linux.org>
References: <377adf3bd2b738e6a47e2c00fb3020fb5ce38cfd_refs_heads_master@pld-linux.org>
 <f5e59fe05417d0d72ef5e99cb896e81fdb32885a_refs_heads_master@pld-linux.org>
Message-ID: <20210316201245.GA17542@mail>

On Sun, Mar 14, 2021 at 10:31:25PM +0100, qboosh wrote:
> commit f5e59fe05417d0d72ef5e99cb896e81fdb32885a
> Author: Jakub Bogusz <qboosh at pld-linux.org>
> Date:   Sun Mar 14 22:32:30 2021 +0100
> 
>     - rpm.org+meson combo require to redefine all dirs; disable debug packages
> 
>  crossmingw32-pango.spec | 9 +++++++++
>  1 file changed, 9 insertions(+)
> ---
> diff --git a/crossmingw32-pango.spec b/crossmingw32-pango.spec
> index b0b1e43..5d32499 100644
> --- a/crossmingw32-pango.spec
> +++ b/crossmingw32-pango.spec
> @@ -45,6 +45,14 @@ BuildRoot:	%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
>  %define		_libdir			%{_prefix}/lib
>  %define		_pkgconfigdir		%{_prefix}/lib/pkgconfig
>  %define		_dlldir			/usr/share/wine/windows/system
> +# rpm.org needs redefining these (redefining _prefix don't change them)
> +%define		_bindir			%{_prefix}/bin
> +%define		_sbindir		%{_prefix}/sbin
> +%define		_includedir		%{_prefix}/include
> +%define		_libexecdir		%{_prefix}/libexec
> +%define		_datadir		%{_prefix}/share
> +%define		_infodir		%{_datadir}/info
> +%define		_mandir			%{_datadir}/man
>  %define		__pkgconfig_provides	%{nil}
>  %define		__pkgconfig_requires	%{nil}
>  # for meson 0.50+, keep __cc/__cxx as host compiler and pass %{target}-* in meson-cross.txt

In rpm5 packaging _*dir macros were defined relative to _prefix.
In rpm.org rpm/platform/*-linux/macros files define absolute _*dir macros
(instead of relative to %{_prefix}):

| # ---- configure macros.
| #
| %_prefix                /usr
| %_exec_prefix           /usr
| %_bindir                /usr/bin
| %_sbindir               /usr/sbin
| %_libexecdir            /usr/libexec
| %_datarootdir           %{_prefix}/share
| %_datadir               /usr/share
| %_sysconfdir            /etc
| %_sharedstatedir        /var/lib
| %_localstatedir         /var
| %_lib                   lib
| %_libdir                /usr/lib
| %_includedir            /usr/include
| %_oldincludedir         /usr/include
| %_infodir               /usr/share/info
| %_mandir                /usr/share/man

Is it intentional change?

meson doesn't allow --{bin,sbin,include,libexec,data,info,man}dir outside --prefix,
so in case of cross* packages I needed to additionally redefine more macros, even
though some dirs are not actually used (just %meson macro passes them).


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


From baggins at pld-linux.org  Tue Mar 16 22:02:18 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 16 Mar 2021 22:02:18 +0100
Subject: [packages/crossmingw32-pango] - rpm.org+meson combo require to
 redefine all dirs
In-Reply-To: <20210316201245.GA17542@mail>
References: <377adf3bd2b738e6a47e2c00fb3020fb5ce38cfd_refs_heads_master@pld-linux.org>
 <f5e59fe05417d0d72ef5e99cb896e81fdb32885a_refs_heads_master@pld-linux.org>
 <20210316201245.GA17542@mail>
Message-ID: <20210316210218.GD17422@tachikoma>

On Tue, 16 Mar 2021, Jakub Bogusz wrote:

> On Sun, Mar 14, 2021 at 10:31:25PM +0100, qboosh wrote:
> > commit f5e59fe05417d0d72ef5e99cb896e81fdb32885a
> > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > Date:   Sun Mar 14 22:32:30 2021 +0100
> > 
> >     - rpm.org+meson combo require to redefine all dirs; disable debug packages
> > 
> >  crossmingw32-pango.spec | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > ---
> > diff --git a/crossmingw32-pango.spec b/crossmingw32-pango.spec
> > index b0b1e43..5d32499 100644
> > --- a/crossmingw32-pango.spec
> > +++ b/crossmingw32-pango.spec
> > @@ -45,6 +45,14 @@ BuildRoot:	%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
> >  %define		_libdir			%{_prefix}/lib
> >  %define		_pkgconfigdir		%{_prefix}/lib/pkgconfig
> >  %define		_dlldir			/usr/share/wine/windows/system
> > +# rpm.org needs redefining these (redefining _prefix don't change them)
> > +%define		_bindir			%{_prefix}/bin
> > +%define		_sbindir		%{_prefix}/sbin
> > +%define		_includedir		%{_prefix}/include
> > +%define		_libexecdir		%{_prefix}/libexec
> > +%define		_datadir		%{_prefix}/share
> > +%define		_infodir		%{_datadir}/info
> > +%define		_mandir			%{_datadir}/man
> >  %define		__pkgconfig_provides	%{nil}
> >  %define		__pkgconfig_requires	%{nil}
> >  # for meson 0.50+, keep __cc/__cxx as host compiler and pass %{target}-* in meson-cross.txt
> 
> In rpm5 packaging _*dir macros were defined relative to _prefix.
> In rpm.org rpm/platform/*-linux/macros files define absolute _*dir macros
> (instead of relative to %{_prefix}):
> 
> | # ---- configure macros.
> | #
> | %_prefix                /usr
> | %_exec_prefix           /usr
> | %_bindir                /usr/bin
> | %_sbindir               /usr/sbin
> | %_libexecdir            /usr/libexec
> | %_datarootdir           %{_prefix}/share
> | %_datadir               /usr/share
> | %_sysconfdir            /etc
> | %_sharedstatedir        /var/lib
> | %_localstatedir         /var
> | %_lib                   lib
> | %_libdir                /usr/lib
> | %_includedir            /usr/include
> | %_oldincludedir         /usr/include
> | %_infodir               /usr/share/info
> | %_mandir                /usr/share/man
> 
> Is it intentional change?
> 
> meson doesn't allow --{bin,sbin,include,libexec,data,info,man}dir outside --prefix,
> so in case of cross* packages I needed to additionally redefine more macros, even
> though some dirs are not actually used (just %meson macro passes them).

Side effect. We had this defined in our macros.pld.in, in rpm.org it's
in the per-platform definitions created by the rpm.

I believe it should be pretty straighforward to patch platform.in to use
relative defs. Just add a patch.

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


From baggins at pld-linux.org  Wed Mar 17 19:48:11 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 17 Mar 2021 19:48:11 +0100
Subject: rpm 4.16 landed -> errors!
In-Reply-To: <CAEg-Je-1eC7SuHX=LcTZhnFXOUyGzg3R9QOtYNTk+CXNtSn8mg@mail.gmail.com>
References: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
 <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>
 <425b47d7-886c-3dc2-0a74-ab19dd26f756@pld-linux.org>
 <20210316173842.GC2262@starbug>
 <CAEg-Je-1eC7SuHX=LcTZhnFXOUyGzg3R9QOtYNTk+CXNtSn8mg@mail.gmail.com>
Message-ID: <20210317184811.GD2262@starbug>

On Tue, 16 Mar 2021, Neal Gompa wrote:

> On Tue, Mar 16, 2021 at 1:39 PM Jan R?korajski <baggins at pld-linux.org> wrote:
> >
> > On Tue, 16 Mar 2021, Elan Ruusam?e wrote:
> >
> > >
> > > On 16.03.2021 16:45, Elan Ruusam?e wrote:
> > > >
> > > > the automatic upgrade is failing:
> > > >
> > > > - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214
> > > >
> > > oh, and user is left without rpmdb:
> > >
> > >
> > > [@46a17bd0ade9 /]# rpm -q rpm poldek
> > > warning: Found bdb Packages database while attempting sqlite backend:
> > > using bdb backend.
> > > warning: Generating 6 missing index(es), please wait...
> > > package rpm is not installed
> > > package poldek is not installed
> > >
> > > [@46a17bd0ade9 /]# rpm -q rpm poldek
> > > warning: Found bdb Packages database while attempting sqlite backend:
> > > using bdb backend.
> > > package rpm is not installed
> > > package poldek is not installed
> > > [@46a17bd0ade9 /]#
> >
> > First, regarding lost database.
> > You do have a backup of the database from before the update:
> >
> > Backup of the rpm database has been created in /var/lib/rpm.rpmbackup-4.16.1.2-6
> >
> > There is also the new database, that rpm was unable to move:
> >
> > error: replace files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.42 to recover
> >
> > Is /var/lib/rpm a mountpoint? That would be the explanation that comes
> > to mind. There must be something that prevented rpm from renaming temporary
> > directory in /var/lib to rpm.
> >
> > I've been (live) testing upgrade path and I assumed it does work.
> > Never encountered problems after squashing rpm5 oddities.
> >
> > I've been also asking over and over for testing and no one came with any
> > issues like this.
> >
> 
> This is probably an overlayfs specific issue, I've seen various
> problems with renames (which is what rpm does for rebuilding
> databases) in containers.

Neal,

Do you have any references to such issues? Like bug reports, or docs?
I'd like to link them to the rpm migration page on our wiki.

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


From ngompa13 at gmail.com  Wed Mar 17 20:06:11 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Wed, 17 Mar 2021 15:06:11 -0400
Subject: rpm 4.16 landed -> errors!
In-Reply-To: <20210317184811.GD2262@starbug>
References: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
 <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>
 <425b47d7-886c-3dc2-0a74-ab19dd26f756@pld-linux.org>
 <20210316173842.GC2262@starbug>
 <CAEg-Je-1eC7SuHX=LcTZhnFXOUyGzg3R9QOtYNTk+CXNtSn8mg@mail.gmail.com>
 <20210317184811.GD2262@starbug>
Message-ID: <CAEg-Je_+UVncxuOUvtypReNURPU93sv-4kSgFsy__S-Y55RgUw@mail.gmail.com>

On Wed, Mar 17, 2021 at 2:48 PM Jan R?korajski <baggins at pld-linux.org> wrote:
>
> On Tue, 16 Mar 2021, Neal Gompa wrote:
>
> > On Tue, Mar 16, 2021 at 1:39 PM Jan R?korajski <baggins at pld-linux.org> wrote:
> > >
> > > On Tue, 16 Mar 2021, Elan Ruusam?e wrote:
> > >
> > > >
> > > > On 16.03.2021 16:45, Elan Ruusam?e wrote:
> > > > >
> > > > > the automatic upgrade is failing:
> > > > >
> > > > > - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214
> > > > >
> > > > oh, and user is left without rpmdb:
> > > >
> > > >
> > > > [@46a17bd0ade9 /]# rpm -q rpm poldek
> > > > warning: Found bdb Packages database while attempting sqlite backend:
> > > > using bdb backend.
> > > > warning: Generating 6 missing index(es), please wait...
> > > > package rpm is not installed
> > > > package poldek is not installed
> > > >
> > > > [@46a17bd0ade9 /]# rpm -q rpm poldek
> > > > warning: Found bdb Packages database while attempting sqlite backend:
> > > > using bdb backend.
> > > > package rpm is not installed
> > > > package poldek is not installed
> > > > [@46a17bd0ade9 /]#
> > >
> > > First, regarding lost database.
> > > You do have a backup of the database from before the update:
> > >
> > > Backup of the rpm database has been created in /var/lib/rpm.rpmbackup-4.16.1.2-6
> > >
> > > There is also the new database, that rpm was unable to move:
> > >
> > > error: replace files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.42 to recover
> > >
> > > Is /var/lib/rpm a mountpoint? That would be the explanation that comes
> > > to mind. There must be something that prevented rpm from renaming temporary
> > > directory in /var/lib to rpm.
> > >
> > > I've been (live) testing upgrade path and I assumed it does work.
> > > Never encountered problems after squashing rpm5 oddities.
> > >
> > > I've been also asking over and over for testing and no one came with any
> > > issues like this.
> > >
> >
> > This is probably an overlayfs specific issue, I've seen various
> > problems with renames (which is what rpm does for rebuilding
> > databases) in containers.
>
> Neal,
>
> Do you have any references to such issues? Like bug reports, or docs?
> I'd like to link them to the rpm migration page on our wiki.
>

Not offhand, but I know that this change to RPM[1] (and a few other
fun quirks of bdb) is what started causing things to trip up in
containers with rpmdb rebuilds. It should basically go away once the
conversion to sqlite rpmdb is done. There is information about how
OverlayFS handles directory renames in the Linux kernel
documentation[2]. This affected YUM too[3], though DNF has workarounds
built into it now[4]. For this specific issue, you can avoid this by
regenerating the container entirely from scratch instead of using an
upgrade to fix it.

More generally, I advise being careful with OverlayFS and being
mindful of the pitfalls[2]. I personally use Btrfs instead, which
neatly avoids this and is a lot more performant.

(As an aside, can someone rebase the DNF package manager stack in PLD?
It's pretty old and broken...)

[1]: https://github.com/rpm-software-management/rpm/commit/fffd652c56eaef8fc41d23190e39513639f2092d
[2]: https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html#renaming-directories
[3]: https://bugzilla.redhat.com/1213602
[4]: https://bugzilla.redhat.com/1658565





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


From baggins at pld-linux.org  Wed Mar 17 22:44:29 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 17 Mar 2021 22:44:29 +0100
Subject: rpm 4.16 landed -> errors!
In-Reply-To: <CAEg-Je_+UVncxuOUvtypReNURPU93sv-4kSgFsy__S-Y55RgUw@mail.gmail.com>
References: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
 <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>
 <425b47d7-886c-3dc2-0a74-ab19dd26f756@pld-linux.org>
 <20210316173842.GC2262@starbug>
 <CAEg-Je-1eC7SuHX=LcTZhnFXOUyGzg3R9QOtYNTk+CXNtSn8mg@mail.gmail.com>
 <20210317184811.GD2262@starbug>
 <CAEg-Je_+UVncxuOUvtypReNURPU93sv-4kSgFsy__S-Y55RgUw@mail.gmail.com>
Message-ID: <20210317214429.GE17422@tachikoma>

On Wed, 17 Mar 2021, Neal Gompa wrote:

> On Wed, Mar 17, 2021 at 2:48 PM Jan R?korajski <baggins at pld-linux.org> wrote:
> >
> > Neal,
> >
> > Do you have any references to such issues? Like bug reports, or docs?
> > I'd like to link them to the rpm migration page on our wiki.
> >
> 
> Not offhand, but I know that this change to RPM[1] (and a few other
> fun quirks of bdb) is what started causing things to trip up in
> containers with rpmdb rebuilds. It should basically go away once the
> conversion to sqlite rpmdb is done. There is information about how
> OverlayFS handles directory renames in the Linux kernel
> documentation[2]. This affected YUM too[3], though DNF has workarounds
> built into it now[4]. For this specific issue, you can avoid this by
> regenerating the container entirely from scratch instead of using an
> upgrade to fix it.
> 
> More generally, I advise being careful with OverlayFS and being
> mindful of the pitfalls[2]. I personally use Btrfs instead, which
> neatly avoids this and is a lot more performant.

Thanks.

> (As an aside, can someone rebase the DNF package manager stack in PLD?
> It's pretty old and broken...)

You mean this? I did an update of dnf packages recently. There are a few
things left to do but most should be up to date.

poldek:/all-avail> ls dnf*
dnf-4.6.1-5.noarch
dnf-automatic-4.6.1-5.noarch
dnf-plugin-cow-0.0.2-1.noarch
dnf-plugin-diff-1.1-1.noarch
dnf-plugin-kickstart-4.0.13-2.noarch
dnf-plugin-leaves-4.0.19-1.noarch
dnf-plugin-local-4.0.19-1.noarch
dnf-plugin-migrate-4.0.19-1.noarch
dnf-plugin-ovl-0.0.3-1.noarch
dnf-plugin-post-transaction-actions-4.0.19-1.noarch
dnf-plugin-rpmconf-4.0.13-2.noarch
dnf-plugin-show-leaves-4.0.19-1.noarch
dnf-plugin-showvars-4.0.13-2.noarch
dnf-plugin-snapper-4.0.13-2.noarch
dnf-plugin-system-upgrade-4.0.13-2.noarch
dnf-plugin-torproxy-4.0.13-2.noarch
dnf-plugin-tracer-4.0.13-2.noarch
dnf-plugin-versionlock-4.0.19-1.noarch
dnf-plugins-core-4.0.19-1.noarch
dnf-plugins-extras-common-4.0.13-2.noarch
dnf-utils-4.0.19-1.noarch
dnfdaemon-0.3.20-2.noarch


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


From ngompa13 at gmail.com  Wed Mar 17 22:45:51 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Wed, 17 Mar 2021 17:45:51 -0400
Subject: rpm 4.16 landed -> errors!
In-Reply-To: <20210317214429.GE17422@tachikoma>
References: <d1c965ea-02a8-3a57-8854-69e5d89f4430@pld-linux.org>
 <79100ffd-d85b-b029-348a-2b3fe4236e2c@pld-linux.org>
 <425b47d7-886c-3dc2-0a74-ab19dd26f756@pld-linux.org>
 <20210316173842.GC2262@starbug>
 <CAEg-Je-1eC7SuHX=LcTZhnFXOUyGzg3R9QOtYNTk+CXNtSn8mg@mail.gmail.com>
 <20210317184811.GD2262@starbug>
 <CAEg-Je_+UVncxuOUvtypReNURPU93sv-4kSgFsy__S-Y55RgUw@mail.gmail.com>
 <20210317214429.GE17422@tachikoma>
Message-ID: <CAEg-Je_Td_E736LA7mwUNKC5PGMzuqUaUhmq23kbx=9SD_sS=Q@mail.gmail.com>

On Wed, Mar 17, 2021 at 5:44 PM Jan R?korajski <baggins at pld-linux.org> wrote:
>
> On Wed, 17 Mar 2021, Neal Gompa wrote:
>
> > On Wed, Mar 17, 2021 at 2:48 PM Jan R?korajski <baggins at pld-linux.org> wrote:
> > >
> > > Neal,
> > >
> > > Do you have any references to such issues? Like bug reports, or docs?
> > > I'd like to link them to the rpm migration page on our wiki.
> > >
> >
> > Not offhand, but I know that this change to RPM[1] (and a few other
> > fun quirks of bdb) is what started causing things to trip up in
> > containers with rpmdb rebuilds. It should basically go away once the
> > conversion to sqlite rpmdb is done. There is information about how
> > OverlayFS handles directory renames in the Linux kernel
> > documentation[2]. This affected YUM too[3], though DNF has workarounds
> > built into it now[4]. For this specific issue, you can avoid this by
> > regenerating the container entirely from scratch instead of using an
> > upgrade to fix it.
> >
> > More generally, I advise being careful with OverlayFS and being
> > mindful of the pitfalls[2]. I personally use Btrfs instead, which
> > neatly avoids this and is a lot more performant.
>
> Thanks.
>
> > (As an aside, can someone rebase the DNF package manager stack in PLD?
> > It's pretty old and broken...)
>
> You mean this? I did an update of dnf packages recently. There are a few
> things left to do but most should be up to date.
>
> poldek:/all-avail> ls dnf*
> dnf-4.6.1-5.noarch
> dnf-automatic-4.6.1-5.noarch
> dnf-plugin-cow-0.0.2-1.noarch
> dnf-plugin-diff-1.1-1.noarch
> dnf-plugin-kickstart-4.0.13-2.noarch
> dnf-plugin-leaves-4.0.19-1.noarch
> dnf-plugin-local-4.0.19-1.noarch
> dnf-plugin-migrate-4.0.19-1.noarch
> dnf-plugin-ovl-0.0.3-1.noarch
> dnf-plugin-post-transaction-actions-4.0.19-1.noarch
> dnf-plugin-rpmconf-4.0.13-2.noarch
> dnf-plugin-show-leaves-4.0.19-1.noarch
> dnf-plugin-showvars-4.0.13-2.noarch
> dnf-plugin-snapper-4.0.13-2.noarch
> dnf-plugin-system-upgrade-4.0.13-2.noarch
> dnf-plugin-torproxy-4.0.13-2.noarch
> dnf-plugin-tracer-4.0.13-2.noarch
> dnf-plugin-versionlock-4.0.19-1.noarch
> dnf-plugins-core-4.0.19-1.noarch
> dnf-plugins-extras-common-4.0.13-2.noarch
> dnf-utils-4.0.19-1.noarch
> dnfdaemon-0.3.20-2.noarch
>

Ah cool, I guess I just missed it. I checked last week. :P



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


From glen at pld-linux.org  Sun Mar 21 22:16:48 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Sun, 21 Mar 2021 23:16:48 +0200
Subject: [packages/coreutils] Updated advancedcopy url.
In-Reply-To: <92b825cf7041cb17b471813efc807d7c16595aac_refs_heads_master@pld-linux.org>
References: <ee6a228faa0271aac380e7b216a66b0a9258788a_refs_heads_master@pld-linux.org>
 <92b825cf7041cb17b471813efc807d7c16595aac_refs_heads_master@pld-linux.org>
Message-ID: <15ace685-13ba-7c27-e33f-f27cefa6e759@pld-linux.org>

On 21.03.2021 22:06, arekm wrote:

> commit 92b825cf7041cb17b471813efc807d7c16595aac
> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> Date:   Sun Mar 21 21:06:24 2021 +0100
>
>      Updated advancedcopy url.
>
>   coreutils.spec | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> ---
> diff --git a/coreutils.spec b/coreutils.spec
> index 2085474..0cab6cd 100644
> --- a/coreutils.spec
> +++ b/coreutils.spec
> @@ -31,7 +31,7 @@ Patch6:		%{name}-fmt-wchars.patch
>   Patch7:		%{name}-sparc64.patch
>   # http://translationproject.org/latest/coreutils/pl.po (pass through msgcat to generate shorter diff)
>   Patch8:		%{name}-pl.po-update.patch
> -# from http://www.beatex.org/web/advancedcopy.html, edited by shadzik
> +# https://github.com/jarun/advcpmv

perhaps just use pv(1)

if coreutils doesn't accept it, we shouldn't maintain the patch around 
forever either.




From arekm at maven.pl  Mon Mar 22 08:17:42 2021
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Mon, 22 Mar 2021 08:17:42 +0100
Subject: rpm 4.16.1.2 from rpm.org has landed in Th
In-Reply-To: <20210222185915.GF1869@starbug>
References: <20210222185915.GF1869@starbug>
Message-ID: <20125245-dd96-2ed2-2308-e68366f1416a@maven.pl>

W dniu 22.02.2021 o?19:59, Jan R?korajski pisze:
> rpm 4.16.1.2 and all dependant packages are now available in th-test.
> 
> More details about the update can be found on
> 
> https://www.pld-linux.org/packages/rpm
> 
> Th builders has been upgraded and all builds will now use rpm.org rpm.
> 

rm /etc/mkshrc
in poldek: install --reinstall mksh

Doesn't put in /etc/mkshrc back in with 4.16.

Is there a workaround? (I used this method to get configs from package
back on the fs)

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


From baggins at pld-linux.org  Mon Mar 22 09:09:00 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 22 Mar 2021 09:09:00 +0100
Subject: rpm 4.16.1.2 from rpm.org has landed in Th
In-Reply-To: <20125245-dd96-2ed2-2308-e68366f1416a@maven.pl>
References: <20210222185915.GF1869@starbug>
 <20125245-dd96-2ed2-2308-e68366f1416a@maven.pl>
Message-ID: <20210322080900.GF2262@starbug>

On Mon, 22 Mar 2021, Arkadiusz Mi?kiewicz wrote:

> W dniu 22.02.2021 o?19:59, Jan R?korajski pisze:
> > rpm 4.16.1.2 and all dependant packages are now available in th-test.
> > 
> > More details about the update can be found on
> > 
> > https://www.pld-linux.org/packages/rpm
> > 
> > Th builders has been upgraded and all builds will now use rpm.org rpm.
> > 
> 
> rm /etc/mkshrc
> in poldek: install --reinstall mksh
> 
> Doesn't put in /etc/mkshrc back in with 4.16.
> 
> Is there a workaround? (I used this method to get configs from package
> back on the fs)

Looks WAI to me. Don't use 'missingok' for config files?

%config(noreplace,missingok) %verify(not md5 mtime size) %{_sysconfdir}/mkshrc

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


From glen at pld-linux.org  Mon Mar 22 16:06:54 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Mon, 22 Mar 2021 17:06:54 +0200
Subject: rpm 4.16.1.2 from rpm.org has landed in Th
In-Reply-To: <20125245-dd96-2ed2-2308-e68366f1416a@maven.pl>
References: <20210222185915.GF1869@starbug>
 <20125245-dd96-2ed2-2308-e68366f1416a@maven.pl>
Message-ID: <e032c299-977f-c511-7c68-7db3816cb5c1@pld-linux.org>

On 22.03.2021 09:17, Arkadiusz Mi?kiewicz wrote:

>
> rm /etc/mkshrc
> in poldek: install --reinstall mksh
>
> Doesn't put in /etc/mkshrc back in with 4.16.
>
> Is there a workaround? (I used this method to get configs from package
> back on the fs)
>
use etckeeper to commit your /etc!


From glen at pld-linux.org  Tue Mar 23 10:04:01 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Mar 2021 11:04:01 +0200
Subject: package names in dependencies
Message-ID: <4f66e077-1e06-2506-ae52-af9e25938e0e@pld-linux.org>

i found some odd inconsistency:


error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon)
error: line 319: Only package names are allowed in Obsoletes: 
Obsoletes:??????? virtual(init-daemon)


So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some 
other tags;


Requires:?? webserver(indexfile)
Requires:?? webserver(php) >= 4.2.0
Suggests:?? php(openssl)
Suggests:?? webserver(setenv)
Provides:?? group(eventum)
Provides:?? user(eventum)




From ngompa13 at gmail.com  Tue Mar 23 11:59:54 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Tue, 23 Mar 2021 06:59:54 -0400
Subject: package names in dependencies
In-Reply-To: <4f66e077-1e06-2506-ae52-af9e25938e0e@pld-linux.org>
References: <4f66e077-1e06-2506-ae52-af9e25938e0e@pld-linux.org>
Message-ID: <CAEg-Je-yHbo-UhdA2Q8AFUAs-j-CD7hSiDacy9ROa4uTP7b_XQ@mail.gmail.com>

On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
>
> i found some odd inconsistency:
>
>
> error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon)
> error: line 319: Only package names are allowed in Obsoletes:
> Obsoletes:        virtual(init-daemon)
>
>
> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some
> other tags;
>
>
> Requires:   webserver(indexfile)
> Requires:   webserver(php) >= 4.2.0
> Suggests:   php(openssl)
> Suggests:   webserver(setenv)
> Provides:   group(eventum)
> Provides:   user(eventum)
>

Obsoletes has to be a real package name, but virtual names are allowed
for other tags.

This was always the case in RPM, but it started enforcing it in RPM 4.13.



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


From atler at pld-linux.org  Tue Mar 23 13:59:25 2021
From: atler at pld-linux.org (Jan Palus)
Date: Tue, 23 Mar 2021 13:59:25 +0100
Subject: [packages/rpm] - x32 patch fixes
In-Reply-To: <b10d9d9e984edbf3157c9fee959c0868486a2f93_refs_heads_master@pld-linux.org>
References: <06dd2f752e640ec4d7cfb4a10fc30b998f5a311b_refs_heads_master@pld-linux.org>
 <b10d9d9e984edbf3157c9fee959c0868486a2f93_refs_heads_master@pld-linux.org>
Message-ID: <20210323125925.ci3pd4b3klmhqeko@pine>

On 23.03.2021 08:53, baggins wrote:
> commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Tue Mar 23 08:52:27 2021 +0100
> 
>     - x32 patch fixes
> 
>  x32.patch | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> ---
> diff --git a/x32.patch b/x32.patch
> index 38aa140..f7ab616 100644
> --- a/x32.patch
> +++ b/x32.patch
> -@@ -190,10 +201,14 @@
> -   # skip architectures for which we dont have full config parameters
> -   [ -z "$CANONARCH" ] && continue
> - 
> --  if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> -+  if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> +@@ -190,6 +201,10 @@
>         LIB=${LIB}64
>     fi

This hunk should either be brought back or CANONCOLOR for x86_64 should
be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.


From j.rekorajski at gmail.com  Tue Mar 23 14:44:34 2021
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Tue, 23 Mar 2021 14:44:34 +0100
Subject: [packages/rpm] - x32 patch fixes
In-Reply-To: <20210323125925.ci3pd4b3klmhqeko@pine>
References: <06dd2f752e640ec4d7cfb4a10fc30b998f5a311b_refs_heads_master@pld-linux.org>
 <b10d9d9e984edbf3157c9fee959c0868486a2f93_refs_heads_master@pld-linux.org>
 <20210323125925.ci3pd4b3klmhqeko@pine>
Message-ID: <CAKY5yHzMPT_ymfX=_suzX6TZvUFkb58hskRpdcB48waq-vio-Q@mail.gmail.com>

On Tue, Mar 23, 2021 at 1:59 PM Jan Palus <atler at pld-linux.org> wrote:

> On 23.03.2021 08:53, baggins wrote:
> > commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Tue Mar 23 08:52:27 2021 +0100
> >
> >     - x32 patch fixes
> >
> >  x32.patch | 10 +++-------
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> > ---
> > diff --git a/x32.patch b/x32.patch
> > index 38aa140..f7ab616 100644
> > --- a/x32.patch
> > +++ b/x32.patch
> > -@@ -190,10 +201,14 @@
> > -   # skip architectures for which we dont have full config parameters
> > -   [ -z "$CANONARCH" ] && continue
> > -
> > --  if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> > -+  if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> > +@@ -190,6 +201,10 @@
> >         LIB=${LIB}64
> >     fi
>
> This hunk should either be brought back or CANONCOLOR for x86_64 should
> be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.
>

Can you restore this hunk and rebuild rpm? I can't do it till evening :(

It should probably even be 'if [ "$OS" = "linux" ] && [ "$CANONARCH" =
"x86_64"] || [ "$CANONCOLOR" = 3 ]; then'

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


From atler at pld-linux.org  Tue Mar 23 15:53:06 2021
From: atler at pld-linux.org (Jan Palus)
Date: Tue, 23 Mar 2021 15:53:06 +0100
Subject: [packages/rpm] - x32 patch fixes
In-Reply-To: <CAKY5yHzMPT_ymfX=_suzX6TZvUFkb58hskRpdcB48waq-vio-Q@mail.gmail.com>
References: <06dd2f752e640ec4d7cfb4a10fc30b998f5a311b_refs_heads_master@pld-linux.org>
 <b10d9d9e984edbf3157c9fee959c0868486a2f93_refs_heads_master@pld-linux.org>
 <20210323125925.ci3pd4b3klmhqeko@pine>
 <CAKY5yHzMPT_ymfX=_suzX6TZvUFkb58hskRpdcB48waq-vio-Q@mail.gmail.com>
Message-ID: <20210323145306.qstjafhgzh23stlj@pine>

On 23.03.2021 14:44, Jan R?korajski wrote:
> On Tue, Mar 23, 2021 at 1:59 PM Jan Palus <atler at pld-linux.org> wrote:
> 
> > On 23.03.2021 08:53, baggins wrote:
> > > commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> > > Author: Jan R?korajski <baggins at pld-linux.org>
> > > Date:   Tue Mar 23 08:52:27 2021 +0100
> > >
> > >     - x32 patch fixes
> > >
> > >  x32.patch | 10 +++-------
> > >  1 file changed, 3 insertions(+), 7 deletions(-)
> > > ---
> > > diff --git a/x32.patch b/x32.patch
> > > index 38aa140..f7ab616 100644
> > > --- a/x32.patch
> > > +++ b/x32.patch
> > > -@@ -190,10 +201,14 @@
> > > -   # skip architectures for which we dont have full config parameters
> > > -   [ -z "$CANONARCH" ] && continue
> > > -
> > > --  if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> > > -+  if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> > > +@@ -190,6 +201,10 @@
> > >         LIB=${LIB}64
> > >     fi
> >
> > This hunk should either be brought back or CANONCOLOR for x86_64 should
> > be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.
> >
> 
> Can you restore this hunk and rebuild rpm? I can't do it till evening :(
> 
> It should probably even be 'if [ "$OS" = "linux" ] && [ "$CANONARCH" =
> "x86_64"] || [ "$CANONCOLOR" = 3 ]; then'

Done. Looks like everything is back to normal.


From glen at pld-linux.org  Tue Mar 23 16:39:40 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Mar 2021 17:39:40 +0200
Subject: package names in dependencies
In-Reply-To: <CAEg-Je-yHbo-UhdA2Q8AFUAs-j-CD7hSiDacy9ROa4uTP7b_XQ@mail.gmail.com>
References: <4f66e077-1e06-2506-ae52-af9e25938e0e@pld-linux.org>
 <CAEg-Je-yHbo-UhdA2Q8AFUAs-j-CD7hSiDacy9ROa4uTP7b_XQ@mail.gmail.com>
Message-ID: <9d1196ef-d12d-c41b-3c1f-1a4dcc1c78b2@pld-linux.org>


On 23.03.2021 12:59, Neal Gompa wrote:
> On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
>> i found some odd inconsistency:
>>
>>
>> error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon)
>> error: line 319: Only package names are allowed in Obsoletes:
>> Obsoletes:        virtual(init-daemon)
>>
>>
>> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some
>> other tags;
>>
>>
>> Requires:   webserver(indexfile)
>> Requires:   webserver(php) >= 4.2.0
>> Suggests:   php(openssl)
>> Suggests:   webserver(setenv)
>> Provides:   group(eventum)
>> Provides:   user(eventum)
>>
> Obsoletes has to be a real package name, but virtual names are allowed
> for other tags.
Why?
> This was always the case in RPM, but it started enforcing it in RPM 4.13.

PLD has used virtual obsoletes for the time i've used it (since 2004).

and we are using it when multiple packages provide something common, say:

'init-daemon"

they are mutually exclusive, so installing one, must uninstall the other.

and if adding new "virtual(init-daemon)" virtual, without need to update 
other packages, they all can have O/P: virtual(init-daemon)


now rpm enforces that each of those packages must cross reference all 
'the other' virtuals... duh!




From ngompa13 at gmail.com  Tue Mar 23 17:18:36 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Tue, 23 Mar 2021 12:18:36 -0400
Subject: package names in dependencies
In-Reply-To: <9d1196ef-d12d-c41b-3c1f-1a4dcc1c78b2@pld-linux.org>
References: <4f66e077-1e06-2506-ae52-af9e25938e0e@pld-linux.org>
 <CAEg-Je-yHbo-UhdA2Q8AFUAs-j-CD7hSiDacy9ROa4uTP7b_XQ@mail.gmail.com>
 <9d1196ef-d12d-c41b-3c1f-1a4dcc1c78b2@pld-linux.org>
Message-ID: <CAEg-Je_a6tGKWQHhTVXzSxcbrdK8aGZrEXEcS7VQpbWM98MOwg@mail.gmail.com>

On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
>
>
> On 23.03.2021 12:59, Neal Gompa wrote:
> > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
> >> i found some odd inconsistency:
> >>
> >>
> >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon)
> >> error: line 319: Only package names are allowed in Obsoletes:
> >> Obsoletes:        virtual(init-daemon)
> >>
> >>
> >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some
> >> other tags;
> >>
> >>
> >> Requires:   webserver(indexfile)
> >> Requires:   webserver(php) >= 4.2.0
> >> Suggests:   php(openssl)
> >> Suggests:   webserver(setenv)
> >> Provides:   group(eventum)
> >> Provides:   user(eventum)
> >>
> > Obsoletes has to be a real package name, but virtual names are allowed
> > for other tags.
> Why?
> > This was always the case in RPM, but it started enforcing it in RPM 4.13.
>
> PLD has used virtual obsoletes for the time i've used it (since 2004).
>
> and we are using it when multiple packages provide something common, say:
>
> 'init-daemon"
>
> they are mutually exclusive, so installing one, must uninstall the other.
>
> and if adding new "virtual(init-daemon)" virtual, without need to update
> other packages, they all can have O/P: virtual(init-daemon)
>
>
> now rpm enforces that each of those packages must cross reference all
> 'the other' virtuals... duh!
>

RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts.

For example, the following is enough to get the behavior you want:

Provides: init-daemon
Conflicts: init-daemon



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


From qboosh at pld-linux.org  Tue Mar 23 17:27:57 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 23 Mar 2021 17:27:57 +0100
Subject: package names in dependencies
In-Reply-To: <CAEg-Je_a6tGKWQHhTVXzSxcbrdK8aGZrEXEcS7VQpbWM98MOwg@mail.gmail.com>
References: <4f66e077-1e06-2506-ae52-af9e25938e0e@pld-linux.org>
 <CAEg-Je-yHbo-UhdA2Q8AFUAs-j-CD7hSiDacy9ROa4uTP7b_XQ@mail.gmail.com>
 <9d1196ef-d12d-c41b-3c1f-1a4dcc1c78b2@pld-linux.org>
 <CAEg-Je_a6tGKWQHhTVXzSxcbrdK8aGZrEXEcS7VQpbWM98MOwg@mail.gmail.com>
Message-ID: <20210323162757.GA26629@mail>

On Tue, Mar 23, 2021 at 12:18:36PM -0400, Neal Gompa wrote:
> On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
> >
> >
> > On 23.03.2021 12:59, Neal Gompa wrote:
> > > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
> > >> i found some odd inconsistency:
> > >>
> > >>
> > >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon)
> > >> error: line 319: Only package names are allowed in Obsoletes:
> > >> Obsoletes:        virtual(init-daemon)
> > >>
> > >>
> > >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some
> > >> other tags;
> > >>
> > >>
> > >> Requires:   webserver(indexfile)
> > >> Requires:   webserver(php) >= 4.2.0
> > >> Suggests:   php(openssl)
> > >> Suggests:   webserver(setenv)
> > >> Provides:   group(eventum)
> > >> Provides:   user(eventum)
> > >>
> > > Obsoletes has to be a real package name, but virtual names are allowed
> > > for other tags.
> > Why?
> > > This was always the case in RPM, but it started enforcing it in RPM 4.13.
> >
> > PLD has used virtual obsoletes for the time i've used it (since 2004).
> >
> > and we are using it when multiple packages provide something common, say:
> >
> > 'init-daemon"
> >
> > they are mutually exclusive, so installing one, must uninstall the other.
> >
> > and if adding new "virtual(init-daemon)" virtual, without need to update
> > other packages, they all can have O/P: virtual(init-daemon)
> >
> >
> > now rpm enforces that each of those packages must cross reference all
> > 'the other' virtuals... duh!
> >
> 
> RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts.
> 
> For example, the following is enough to get the behavior you want:
> 
> Provides: init-daemon
> Conflicts: init-daemon

Uhm, AFAIR such combo was treated as self-conflict by some RPM-based package
management software, thus making package non-installable...

Does it have well defined semantics now?


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


From ngompa13 at gmail.com  Tue Mar 23 18:29:47 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Tue, 23 Mar 2021 13:29:47 -0400
Subject: package names in dependencies
In-Reply-To: <20210323162757.GA26629@mail>
References: <4f66e077-1e06-2506-ae52-af9e25938e0e@pld-linux.org>
 <CAEg-Je-yHbo-UhdA2Q8AFUAs-j-CD7hSiDacy9ROa4uTP7b_XQ@mail.gmail.com>
 <9d1196ef-d12d-c41b-3c1f-1a4dcc1c78b2@pld-linux.org>
 <CAEg-Je_a6tGKWQHhTVXzSxcbrdK8aGZrEXEcS7VQpbWM98MOwg@mail.gmail.com>
 <20210323162757.GA26629@mail>
Message-ID: <CAEg-Je--3PzwWzf9DoMHbXoTzTgk5TpLdYq52mGOEea9UsQ6Pw@mail.gmail.com>

On Tue, Mar 23, 2021 at 12:27 PM Jakub Bogusz <qboosh at pld-linux.org> wrote:
>
> On Tue, Mar 23, 2021 at 12:18:36PM -0400, Neal Gompa wrote:
> > On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
> > >
> > >
> > > On 23.03.2021 12:59, Neal Gompa wrote:
> > > > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
> > > >> i found some odd inconsistency:
> > > >>
> > > >>
> > > >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon)
> > > >> error: line 319: Only package names are allowed in Obsoletes:
> > > >> Obsoletes:        virtual(init-daemon)
> > > >>
> > > >>
> > > >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some
> > > >> other tags;
> > > >>
> > > >>
> > > >> Requires:   webserver(indexfile)
> > > >> Requires:   webserver(php) >= 4.2.0
> > > >> Suggests:   php(openssl)
> > > >> Suggests:   webserver(setenv)
> > > >> Provides:   group(eventum)
> > > >> Provides:   user(eventum)
> > > >>
> > > > Obsoletes has to be a real package name, but virtual names are allowed
> > > > for other tags.
> > > Why?
> > > > This was always the case in RPM, but it started enforcing it in RPM 4.13.
> > >
> > > PLD has used virtual obsoletes for the time i've used it (since 2004).
> > >
> > > and we are using it when multiple packages provide something common, say:
> > >
> > > 'init-daemon"
> > >
> > > they are mutually exclusive, so installing one, must uninstall the other.
> > >
> > > and if adding new "virtual(init-daemon)" virtual, without need to update
> > > other packages, they all can have O/P: virtual(init-daemon)
> > >
> > >
> > > now rpm enforces that each of those packages must cross reference all
> > > 'the other' virtuals... duh!
> > >
> >
> > RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts.
> >
> > For example, the following is enough to get the behavior you want:
> >
> > Provides: init-daemon
> > Conflicts: init-daemon
>
> Uhm, AFAIR such combo was treated as self-conflict by some RPM-based package
> management software, thus making package non-installable...
>
> Does it have well defined semantics now?
>

Hmm, actually I was wrong, it was done in RPM 4.9.0:
https://rpm.org/wiki/Releases/4.9.0

As for "well-defined semantics", it's basically this mailing list
post: http://lists.rpm.org/pipermail/rpm-maint/2010-April/002719.html

It generally works for me, though admittedly, I've only tested YUM,
DNF, and Zypper.


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


From wojciech at blaszkowski.com  Tue Mar 23 19:45:28 2021
From: wojciech at blaszkowski.com (=?UTF-8?Q?Wojciech_B=c5=82aszkowski?=)
Date: Tue, 23 Mar 2021 19:45:28 +0100
Subject: ImageMagick & php53-pecl-imagick
Message-ID: <33d25f02-c734-c818-82c6-ec55472f43de@blaszkowski.com>

Hello,

some unresolved dependencies with ImageMagick & php53 had occured. Any 
chance to fix that?

# poldek --upa && poldek -ug ImageMagick

th is up to date
th is up to date
Loading [pndir]th...
Loading [pndir]th...
30218 packages read
Processing dependencies...
ImageMagick-7.0.10.35-1.x86_64 obsoleted by ImageMagick-7.0.10.60-1.x86_64
   greedy upgrade ImageMagick-coder-jpeg-7.0.10.35-1.x86_64 to 
7.0.10.60-1.x86_64 (unresolved ImageMagick = 1:7.0.10.35-1)
    ImageMagick-coder-jpeg-7.0.10.35-1.x86_64 obsoleted by 
ImageMagick-coder-jpeg-7.0.10.60-1.x86_64
    ImageMagick-coder-jpeg-7.0.10.60-1.x86_64 marks 
ImageMagick-libs-7.0.10.60-1.x86_64 (cap libMagickCore-7.Q16.so.8()(64bit))
     ImageMagick-libs-7.0.10.35-1.x86_64 obsoleted by 
ImageMagick-libs-7.0.10.60-1.x86_64
error: libMagickCore-7.Q16.so.7()(64bit) is required by installed 
php53-pecl-imagick-3.4.4-3.x86_64
error: libMagickWand-7.Q16.so.7()(64bit) is required by installed 
php53-pecl-imagick-3.4.4-3.x86_64
error: libMagickWand-7.Q16.so.7(VERS_7.0)(64bit) is required by 
installed php53-pecl-imagick-3.4.4-3.x86_64
       greedy upgrade ImageMagick-coder-png-7.0.10.35-1.x86_64 to 
7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit))
        ImageMagick-coder-png-7.0.10.35-1.x86_64 obsoleted by 
ImageMagick-coder-png-7.0.10.60-1.x86_64
       greedy upgrade ImageMagick-coder-tiff-7.0.10.35-1.x86_64 to 
7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit))
        ImageMagick-coder-tiff-7.0.10.35-1.x86_64 obsoleted by 
ImageMagick-coder-tiff-7.0.10.60-1.x86_64
       greedy upgrade ImageMagick-coder-pdf-7.0.10.35-1.x86_64 to 
7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit))
        ImageMagick-coder-pdf-7.0.10.35-1.x86_64 obsoleted by 
ImageMagick-coder-pdf-7.0.10.60-1.x86_64
       greedy upgrade ImageMagick-coder-jbig-7.0.10.35-1.x86_64 to 
7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit))
        ImageMagick-coder-jbig-7.0.10.35-1.x86_64 obsoleted by 
ImageMagick-coder-jbig-7.0.10.60-1.x86_64
       greedy upgrade ImageMagick-coder-jpeg2-7.0.10.35-1.x86_64 to 
7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit))
        ImageMagick-coder-jpeg2-7.0.10.35-1.x86_64 obsoleted by 
ImageMagick-coder-jpeg2-7.0.10.60-1.x86_64
       greedy upgrade ImageMagick-coder-heic-7.0.10.35-1.x86_64 to 
7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit))
        ImageMagick-coder-heic-7.0.10.35-1.x86_64 obsoleted by 
ImageMagick-coder-heic-7.0.10.60-1.x86_64
There are 9 packages to install (8 marked by dependencies), 9 to remove:
U ImageMagick-(7.0.10.35 => 7.0.10.60)-1.x86_64 
ImageMagick-coder-heic-(7.0.10.35 => 7.0.10.60)-1.x86_64 
ImageMagick-coder-jbig-(7.0.10.35 => 7.0.10.60)-1.x86_64
U ImageMagick-coder-jpeg-(7.0.10.35 => 7.0.10.60)-1.x86_64 
ImageMagick-coder-jpeg2-(7.0.10.35 => 7.0.10.60)-1.x86_64 
ImageMagick-coder-pdf-(7.0.10.35 => 7.0.10.60)-1.x86_64
U ImageMagick-coder-png-(7.0.10.35 => 7.0.10.60)-1.x86_64 
ImageMagick-coder-tiff-(7.0.10.35 => 7.0.10.60)-1.x86_64 
ImageMagick-libs-(7.0.10.35 => 7.0.10.60)-1.x86_64
This operation will use 122.1KB of disk space.
Need to get 2.1MB of archives (2.1MB to download).

error: 3 unresolved dependencies

-- 
Pozdrawiam,
Wojciech B?aszkowski
www.blaszkowski.com, +48.600197207


From glen at pld-linux.org  Tue Mar 23 21:47:33 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Mar 2021 22:47:33 +0200
Subject: ImageMagick & php53-pecl-imagick
In-Reply-To: <33d25f02-c734-c818-82c6-ec55472f43de@blaszkowski.com>
References: <33d25f02-c734-c818-82c6-ec55472f43de@blaszkowski.com>
Message-ID: <a329265a-cb79-21ea-df7a-95eaa69bbf09@pld-linux.org>


On 23.03.2021 20:45, Wojciech B?aszkowski wrote:
> Hello,
>
> some unresolved dependencies with ImageMagick & php53 had occured. Any 
> chance to fix that?
>
> # poldek --upa && poldek -ug ImageMagick
>
> th is up to date
> th is up to date
> Loading [pndir]th...
> Loading [pndir]th...
> 30218 packages read
> Processing dependencies...
> ImageMagick-7.0.10.35-1.x86_64 obsoleted by 
> ImageMagick-7.0.10.60-1.x86_64
> ? greedy upgrade ImageMagick-coder-jpeg-7.0.10.35-1.x86_64 to 
> 7.0.10.60-1.x86_64 (unresolved ImageMagick = 1:7.0.10.35-1)
> ?? ImageMagick-coder-jpeg-7.0.10.35-1.x86_64 obsoleted by 
> ImageMagick-coder-jpeg-7.0.10.60-1.x86_64
> ?? ImageMagick-coder-jpeg-7.0.10.60-1.x86_64 marks 
> ImageMagick-libs-7.0.10.60-1.x86_64 (cap 
> libMagickCore-7.Q16.so.8()(64bit))
> ??? ImageMagick-libs-7.0.10.35-1.x86_64 obsoleted by 
> ImageMagick-libs-7.0.10.60-1.x86_64
> error: libMagickCore-7.Q16.so.7()(64bit) is required by installed 
> php53-pecl-imagick-3.4.4-3.x86_64


this just means the package was removed:

- 
http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2021-February/026147.html

and the rebuild is not yet moved to main

$ docker-run registry.gitlab.com/pld-linux/pld

Unable to find image 'registry.gitlab.com/pld-linux/pld:latest' locally
latest: Pulling from pld-linux/pld
8b782821df9b: Pull complete
Digest: 
sha256:3bf9e65ba27f6d2e254d37e5219d5ff38b8e6f86c214ae0d8c730b2868775931
Status: Downloaded newer image for registry.gitlab.com/pld-linux/pld:latest

[@3cbca0a58712 /]# poldek -u php53-pecl-imagick
th::packages.ndir.gz [17.8M (6.7M/s)]
th::packages.ndir.dscr.gz [1.2M (1.2M/s)]
th::packages.ndir.gz [17.8M (13.4M/s)]
th::packages.ndir.dscr.gz [2.3M (1.0M/s)]
Loading [pndir]th...
Creating directory index of th...
Loading [pndir]th...
Creating directory index of th...
30218 packages read
error: php53-pecl-imagick: no such package
[@3cbca0a58712 /]#


[@3cbca0a58712 /]# poldek -u php53-pecl-imagick -n th-ready -n th
th-ready::packages.ndir.gz [5.4M (5.4M/s)]
th-ready::packages.ndir.dscr.gz [241.1K (241.1K/s)]
th-ready::packages.ndir.gz [4.1M (4.1M/s)]
th-ready::packages.ndir.dscr.gz [251.0K (251.0K/s)]
Loading [pndir]th-ready...
Creating directory index of th-ready...
Loading [pndir]th-ready...
Creating directory index of th-ready...
Loading [pndir]th...
Loading [pndir]th...
34486 packages read
Processing dependencies...
php53-pecl-imagick-3.4.4-6.x86_64 marks php53-common-5.3.29-52.x86_64 
(cap /etc/php53/conf.d)
 ?php53-common-5.3.29-52.x86_64 marks php-dirs-1.10-1.noarch (cap 
php-dirs >= 1.4)

...



From glen at pld-linux.org  Tue Mar 23 21:51:46 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Mar 2021 22:51:46 +0200
Subject: directory deps
Message-ID: <e2e70adb-f113-8d03-c123-48d69394a541@pld-linux.org>

looks like the directory deps in rpm5 pull superfluous packages when 
installing:


 ????? libmount-2.36.2-2.x86_64 marks VirtualBox-6.1.18-4.x86_64 (cap 
/usr/lib/.build-id/be)


libmount-2.36.2-2.x86_64: required "/usr/lib/.build-id/be" is provided 
by the following packages:
a) OpenImageIO-plugin-dds-2.0.13-3.x86_64
b) abrt-libs-2.14.4-5.x86_64
c) dovecot-2.3.14-1.x86_64
d) frei0r-plugins-1.7.0-2.x86_64
e) gnumeric-1.12.48-4.x86_64
f) gstreamer-plugins-bad-1.16.2-5.x86_64
g) hfst-3.15.1-3.x86_64
h) libblockdev-2.25-2.x86_64
i) libproxy-0.4.17-2.x86_64
j) libreoffice-core-6.4.7.2-4.x86_64
k) libsolv-tools-0.7.17-2.x86_64
l) opencv-4.5.1-3.x86_64
m) python-cheetah-2.4.4-2.x86_64
n) python-dulwich-0.19.14-2.x86_64
o) python-pynifalcon-1.1-3.x86_64
p) python3-Crypto-2.6.1-12.x86_64
q) python3-LibAppArmor-3.0.1-2.x86_64
r) python3-bitarray-1.0.1-2.x86_64
t) python3-scipy-1.5.4-2.x86_64
s) samba-libs-4.13.3-4.x86_64
u) talloc-2.3.1-2.x86_64
v) util-linux-2.36.2-2.x86_64
w) util-vserver-0.30.216-1.pre3126.5.x86_64
x) vlc-3.0.12-2.x86_64
y) vtk-python3-8.2.0-5.x86_64
Which one do you want to install ('Q' to abort)?


so, what could be done is fix that rpm4.16 buold will not generate deps 
for things unde:

/usr/lib/.build-id/


reproducer;

1 use this docker image: 
registry.gitlab.com/pld-linux/pld at sha256:3bf9e65ba27f6d2e254d37e5219d5ff38b8e6f86c214ae0d8c730b2868775931

2. poldek -u php53-pecl-imagick -n th-ready -n th



From hawk at pld-linux.org  Tue Mar 23 22:18:44 2021
From: hawk at pld-linux.org (Marcin Krol)
Date: Tue, 23 Mar 2021 22:18:44 +0100
Subject: directory deps
In-Reply-To: <e2e70adb-f113-8d03-c123-48d69394a541@pld-linux.org>
References: <e2e70adb-f113-8d03-c123-48d69394a541@pld-linux.org>
Message-ID: <6f286554-07da-a2ea-9b4e-d7852a5b3dc9@pld-linux.org>

On 23-Mar-21 21:51, Elan Ruusam?e wrote:
> so, what could be done is fix that rpm4.16 buold will not generate deps 
> for things unde:
> 
> /usr/lib/.build-id/

In TLD I've simply set default of %_build_id_links macro to alldebug so 
regular packages are not cluttered with build-id stuff (it all goes to 
debuginfo packages). IMO easy and more flexible than hacking rpm to not 
generate deps.

M.


From glen at pld-linux.org  Wed Mar 24 09:06:19 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 24 Mar 2021 10:06:19 +0200
Subject: directory deps
In-Reply-To: <6f286554-07da-a2ea-9b4e-d7852a5b3dc9@pld-linux.org>
References: <e2e70adb-f113-8d03-c123-48d69394a541@pld-linux.org>
 <6f286554-07da-a2ea-9b4e-d7852a5b3dc9@pld-linux.org>
Message-ID: <dfd1637b-256e-3ab5-291a-f219c76ee0b8@pld-linux.org>


On 23.03.2021 23:18, Marcin Krol wrote:
> On 23-Mar-21 21:51, Elan Ruusam?e wrote:
>> so, what could be done is fix that rpm4.16 buold will not generate 
>> deps for things under:
>>
>> /usr/lib/.build-id/
>
> In TLD I've simply set default of %_build_id_links macro to alldebug 
> so regular packages are not cluttered with build-id stuff (it all goes 
> to debuginfo packages). IMO easy and more flexible than hacking rpm to 
> not generate deps.
>
you conveniently cut out the context, this happens when rpm5 installs 
the package built by rpm4.16


From hawk at pld-linux.org  Wed Mar 24 11:12:05 2021
From: hawk at pld-linux.org (Marcin Krol)
Date: Wed, 24 Mar 2021 11:12:05 +0100
Subject: directory deps
In-Reply-To: <dfd1637b-256e-3ab5-291a-f219c76ee0b8@pld-linux.org>
References: <e2e70adb-f113-8d03-c123-48d69394a541@pld-linux.org>
 <6f286554-07da-a2ea-9b4e-d7852a5b3dc9@pld-linux.org>
 <dfd1637b-256e-3ab5-291a-f219c76ee0b8@pld-linux.org>
Message-ID: <4b1bb0d0-8291-7a48-6311-b6054e6d1015@pld-linux.org>

> you conveniently cut out the context, this happens when rpm5 installs 
> the package built by rpm4.16

And it would not happen if packages built by rpm 4.16 will not provide 
build-id dirs.

M.


From glen at pld-linux.org  Wed Mar 24 19:29:03 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 24 Mar 2021 20:29:03 +0200
Subject: directory deps
In-Reply-To: <4b1bb0d0-8291-7a48-6311-b6054e6d1015@pld-linux.org>
References: <e2e70adb-f113-8d03-c123-48d69394a541@pld-linux.org>
 <6f286554-07da-a2ea-9b4e-d7852a5b3dc9@pld-linux.org>
 <dfd1637b-256e-3ab5-291a-f219c76ee0b8@pld-linux.org>
 <4b1bb0d0-8291-7a48-6311-b6054e6d1015@pld-linux.org>
Message-ID: <90e8825f-670e-4351-1dbb-36ac86922d9c@pld-linux.org>

On 24.03.2021 12:12, Marcin Krol wrote:

>> you conveniently cut out the context, this happens when rpm5 installs 
>> the package built by rpm4.16
>
> And it would not happen if packages built by rpm 4.16 will not provide 
> build-id dirs.

Oh, I see, i assumed (apparently wrongly) that the %_build_id_links is 
run-time configuration.

current values:

? rpm -q rpm
rpm-4.16.1.2-7.x86_64

? rpm -E %_build_id_links
compat



From glen at pld-linux.org  Tue Mar 30 17:44:29 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 30 Mar 2021 18:44:29 +0300
Subject: [packages/rpm-pld-macros] initial basic rust/cargo macros (2.003)
In-Reply-To: <593b448d587953c0aa5cfb8484485fda26499d3c_refs_heads_master@pld-linux.org>
References: <9cb7bd11d8b428c6d15adb756599b25c5c7f7353_refs_heads_master@pld-linux.org>
 <593b448d587953c0aa5cfb8484485fda26499d3c_refs_heads_master@pld-linux.org>
Message-ID: <85a57f6d-0c2b-64b0-b3d6-9d0544e070fe@pld-linux.org>

On 30.03.2021 14:06, atler wrote:

> commit 593b448d587953c0aa5cfb8484485fda26499d3c
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Tue Mar 30 12:59:03 2021 +0200
>
>      initial basic rust/cargo macros (2.003)
>
>   macros.pld          | 17 +++++++++++++++++

perhaps place the rust/cargo macros to a separate file?




From glen at pld-linux.org  Tue Mar 30 17:46:46 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 30 Mar 2021 18:46:46 +0300
Subject: [projects/template-specs] use %cargo_* macros
In-Reply-To: <f329c346f35622a09475262bb712ae52aed03f4a_refs_heads_master@pld-linux.org>
References: <7043b3a2614aaf1bd5a5f4c5315981953427741d_refs_heads_master@pld-linux.org>
 <f329c346f35622a09475262bb712ae52aed03f4a_refs_heads_master@pld-linux.org>
Message-ID: <8069e411-ed72-fcb7-1c26-414165ee648c@pld-linux.org>


On 30.03.2021 14:26, atler wrote:
> commit f329c346f35622a09475262bb712ae52aed03f4a
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Tue Mar 30 13:25:20 2021 +0200
>
>      use %cargo_* macros
>
>   rust.spec | 7 +++----
>   1 file changed, 3 insertions(+), 4 deletions(-)
> ---
> diff --git a/rust.spec b/rust.spec
> index 3e3e272..d792e2c 100644
> --- a/rust.spec
> +++ b/rust.spec
> @@ -14,6 +14,7 @@ Source1:	%{name}-crates-%{version}.tar.xz
>   # Source1-md5:	-
>   URL:		-
>   BuildRequires:	cargo
> +BuildRequires:	rpmbuild(macros) >= 2.003
>   BuildRequires:	rust
>   BuildRequires:	tar >= 1:1.22
>   BuildRequires:	xz
> @@ -40,19 +41,17 @@ EOF
>   %build
>   export CARGO_HOME="$(pwd)/.cargo"
>   
> -cargo -v build \
> +%cargo_build \
>   %ifarch x32
>   	--target x86_64-unknown-linux-gnux32 \
>   %endif
> -	--release \
>   	--frozen
>   
>   %install
>   rm -rf $RPM_BUILD_ROOT
>   export CARGO_HOME="$(pwd)/.cargo"
>   
> -cargo -vv \
> -	install \
> +%cargo_install \
>   	--frozen \
>   	--path . \
>   	--root $RPM_BUILD_ROOT%{_prefix}


why not include the crate based build options also into common macros?


also, in template-specs/rust.spec, there's comment for source0, creating 
crate, maybe an universal script could be provided by macros package?





From qboosh at pld-linux.org  Tue Mar 30 20:57:03 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 30 Mar 2021 20:57:03 +0200
Subject: [projects/template-specs] use %cargo_* macros
In-Reply-To: <8069e411-ed72-fcb7-1c26-414165ee648c@pld-linux.org>
References: <7043b3a2614aaf1bd5a5f4c5315981953427741d_refs_heads_master@pld-linux.org>
 <f329c346f35622a09475262bb712ae52aed03f4a_refs_heads_master@pld-linux.org>
 <8069e411-ed72-fcb7-1c26-414165ee648c@pld-linux.org>
Message-ID: <20210330185703.GA31305@mail>

On Tue, Mar 30, 2021 at 06:46:46PM +0300, Elan Ruusam?e wrote:
[...]
> >@@ -40,19 +41,17 @@ EOF
> >  %build
> >  export CARGO_HOME="$(pwd)/.cargo"
> >  
> >-cargo -v build \
> >+%cargo_build \
> >  %ifarch x32
> >  	--target x86_64-unknown-linux-gnux32 \
> >  %endif
> >-	--release \
> >  	--frozen
> >  
> >  %install
> >  rm -rf $RPM_BUILD_ROOT
> >  export CARGO_HOME="$(pwd)/.cargo"
> >  
> >-cargo -vv \
> >-	install \
> >+%cargo_install \
> >  	--frozen \
> >  	--path . \
> >  	--root $RPM_BUILD_ROOT%{_prefix}
> 
> 
> why not include the crate based build options also into common macros?
> 
> 
> also, in template-specs/rust.spec, there's comment for source0, creating 
> crate, maybe an universal script could be provided by macros package?

I'd enhance %cargo_build at least by adding x32 --target option.

When it comes to crates, It'd better to find some generic solution for
packaging creates system-wide instead of vendoring everything
everywhere. I'm aware Fedora has some, but I didn't have enough time to
do a research.


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


From glen at pld-linux.org  Wed Mar 31 10:34:03 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 31 Mar 2021 11:34:03 +0300
Subject: [projects/template-specs] use %cargo_* macros
In-Reply-To: <20210330185703.GA31305@mail>
References: <7043b3a2614aaf1bd5a5f4c5315981953427741d_refs_heads_master@pld-linux.org>
 <f329c346f35622a09475262bb712ae52aed03f4a_refs_heads_master@pld-linux.org>
 <8069e411-ed72-fcb7-1c26-414165ee648c@pld-linux.org>
 <20210330185703.GA31305@mail>
Message-ID: <35e5e7fe-8f82-7180-655a-021fcd8f08f9@pld-linux.org>

On 30.03.2021 21:57, Jakub Bogusz wrote:

> On Tue, Mar 30, 2021 at 06:46:46PM +0300, Elan Ruusam?e wrote:
> [...]
> When it comes to crates, It'd better to find some generic solution for
> packaging creates system-wide instead of vendoring everything
> everywhere. I'm aware Fedora has some, but I didn't have enough time to
> do a research.

their solution to create 120 packages for each of them.

the same goes for npm and go packages.

besides, if you diverge from versions present in vendor lock,

you are bringing package support on your own shoulders. we do not have 
such resources!

as for the original topic:

the other place where to integrate crates fetch, could be aside 
`builder` script, maybe builder --update-create option.



From atler at pld-linux.org  Wed Mar 31 11:30:07 2021
From: atler at pld-linux.org (Jan Palus)
Date: Wed, 31 Mar 2021 11:30:07 +0200
Subject: [projects/template-specs] use %cargo_* macros
In-Reply-To: <20210330185703.GA31305@mail>
References: <7043b3a2614aaf1bd5a5f4c5315981953427741d_refs_heads_master@pld-linux.org>
 <f329c346f35622a09475262bb712ae52aed03f4a_refs_heads_master@pld-linux.org>
 <8069e411-ed72-fcb7-1c26-414165ee648c@pld-linux.org>
 <20210330185703.GA31305@mail>
Message-ID: <20210331093007.r4f7x4pxijxpu3s2@pine>

On 30.03.2021 20:57, Jakub Bogusz wrote:
> On Tue, Mar 30, 2021 at 06:46:46PM +0300, Elan Ruusam?e wrote:
> [...]
> > >@@ -40,19 +41,17 @@ EOF
> > >  %build
> > >  export CARGO_HOME="$(pwd)/.cargo"
> > >  
> > >-cargo -v build \
> > >+%cargo_build \
> > >  %ifarch x32
> > >  	--target x86_64-unknown-linux-gnux32 \
> > >  %endif
> > >-	--release \
> > >  	--frozen
> > >  
> > >  %install
> > >  rm -rf $RPM_BUILD_ROOT
> > >  export CARGO_HOME="$(pwd)/.cargo"
> > >  
> > >-cargo -vv \
> > >-	install \
> > >+%cargo_install \
> > >  	--frozen \
> > >  	--path . \
> > >  	--root $RPM_BUILD_ROOT%{_prefix}
> > 
> > 
> > why not include the crate based build options also into common macros?
> > 
> > 
> > also, in template-specs/rust.spec, there's comment for source0, creating 
> > crate, maybe an universal script could be provided by macros package?
> 
> I'd enhance %cargo_build at least by adding x32 --target option.

Good point, thanks. I didn't realize rustc on x32 does not compile to
x32 by default. Added in 2.004.


From atler at pld-linux.org  Wed Mar 31 11:30:45 2021
From: atler at pld-linux.org (Jan Palus)
Date: Wed, 31 Mar 2021 11:30:45 +0200
Subject: [packages/rpm-pld-macros] initial basic rust/cargo macros (2.003)
In-Reply-To: <85a57f6d-0c2b-64b0-b3d6-9d0544e070fe@pld-linux.org>
References: <9cb7bd11d8b428c6d15adb756599b25c5c7f7353_refs_heads_master@pld-linux.org>
 <593b448d587953c0aa5cfb8484485fda26499d3c_refs_heads_master@pld-linux.org>
 <85a57f6d-0c2b-64b0-b3d6-9d0544e070fe@pld-linux.org>
Message-ID: <20210331093045.fwqvdeyw5afslqrx@pine>

On 30.03.2021 18:44, Elan Ruusam?e wrote:
> On 30.03.2021 14:06, atler wrote:
> 
> > commit 593b448d587953c0aa5cfb8484485fda26499d3c
> > Author: Jan Palus <atler at pld-linux.org>
> > Date:   Tue Mar 30 12:59:03 2021 +0200
> > 
> >      initial basic rust/cargo macros (2.003)
> > 
> >   macros.pld          | 17 +++++++++++++++++
> 
> perhaps place the rust/cargo macros to a separate file?

Moved to its own file in 2.004.


From ngompa13 at gmail.com  Wed Mar 31 13:34:23 2021
From: ngompa13 at gmail.com (Neal Gompa)
Date: Wed, 31 Mar 2021 07:34:23 -0400
Subject: [projects/template-specs] use %cargo_* macros
In-Reply-To: <35e5e7fe-8f82-7180-655a-021fcd8f08f9@pld-linux.org>
References: <7043b3a2614aaf1bd5a5f4c5315981953427741d_refs_heads_master@pld-linux.org>
 <f329c346f35622a09475262bb712ae52aed03f4a_refs_heads_master@pld-linux.org>
 <8069e411-ed72-fcb7-1c26-414165ee648c@pld-linux.org>
 <20210330185703.GA31305@mail>
 <35e5e7fe-8f82-7180-655a-021fcd8f08f9@pld-linux.org>
Message-ID: <CAEg-Je_FFekf7FiBSdDZdOx4HU=c+9=Ajt64tAvKmyjJBmEHKg@mail.gmail.com>

On Wed, Mar 31, 2021 at 4:34 AM Elan Ruusam?e <glen at pld-linux.org> wrote:
>
> On 30.03.2021 21:57, Jakub Bogusz wrote:
>
> > On Tue, Mar 30, 2021 at 06:46:46PM +0300, Elan Ruusam?e wrote:
> > [...]
> > When it comes to crates, It'd better to find some generic solution for
> > packaging creates system-wide instead of vendoring everything
> > everywhere. I'm aware Fedora has some, but I didn't have enough time to
> > do a research.
>
> their solution to create 120 packages for each of them.
>
> the same goes for npm and go packages.
>

As one of the developers of those macros, I can confidently say both
ways (per component packaging and vendored packages) are supported.
For Rust and Go, we're doing per-component packaging because having to
patch and fix the same thing hundreds of times is terrible for
security stuff. Fixing the code once and kicking off rebuilds of
reverse dependency chains is way easier. For Nodejs, we do vendored by
default now: https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault

> besides, if you diverge from versions present in vendor lock,
>
> you are bringing package support on your own shoulders. we do not have
> such resources!
>

While it's true you're diverging, this is no different than what you
do with C, C++, Ruby, Perl, and Python. In practice, this is where
distros sharing resources comes in handy because you can collaborate
on it.



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


From glen at pld-linux.org  Wed Mar 31 13:48:53 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 31 Mar 2021 14:48:53 +0300
Subject: [packages/conntrack-tools] borrow systemd unit from fedora; rel 2
In-Reply-To: <9aa04cde77a1d15594bb488c10e9deab63551e1b_refs_heads_master@pld-linux.org>
References: <9898dc973a12058c962299af09c2b379f85d5844_refs_heads_master@pld-linux.org>
 <9aa04cde77a1d15594bb488c10e9deab63551e1b_refs_heads_master@pld-linux.org>
Message-ID: <15ac0d75-d3d2-55c3-407c-e1a113190a83@pld-linux.org>

On 31.03.2021 13:18, atler wrote:

> commit 9aa04cde77a1d15594bb488c10e9deab63551e1b
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Wed Mar 31 12:16:37 2021 +0200
>
>      borrow systemd unit from fedora; rel 2

borrow? you giving it back to them then? :)



From pawelz at pld-linux.org  Wed Mar 31 17:01:29 2021
From: pawelz at pld-linux.org (=?UTF-8?Q?Pawe=C5=82_Zuzelski?=)
Date: Wed, 31 Mar 2021 17:01:29 +0200
Subject: =?UTF-8?Q?pull_request_for_dhcp_=E2=80=93_fixed_the_init_script?=
Message-ID: <CABzHJcAFSqXDTR5KWOiCibp+Z1z1gA6403=-qgREn7foesYQjg@mail.gmail.com>

Hi all,

Could someone please review and push https://github.com/pawelz/pld-dhcp
specifically that commit:
https://github.com/pawelz/pld-dhcp/commit/071ac6b61dedf115572076ad17bbbef53226b22c
?

This change fixes broken init for dhcp6.

It's been 10 years since I touched PLD, so I don't really feel comfortable
pushing without supervision even if I still have access to the repo.

Thanks in advance,
Pawe?


From glen at pld-linux.org  Wed Mar 31 18:11:04 2021
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 31 Mar 2021 19:11:04 +0300
Subject: =?UTF-8?Q?Re=3a_pull_request_for_dhcp_=e2=80=93_fixed_the_init_scri?=
 =?UTF-8?Q?pt?=
In-Reply-To: <CABzHJcAFSqXDTR5KWOiCibp+Z1z1gA6403=-qgREn7foesYQjg@mail.gmail.com>
References: <CABzHJcAFSqXDTR5KWOiCibp+Z1z1gA6403=-qgREn7foesYQjg@mail.gmail.com>
Message-ID: <5c807493-1e56-ad04-fccc-25ce7d44ddb5@pld-linux.org>


On 31.03.2021 18:01, Pawe? Zuzelski wrote:
> Hi all,
>
> Could someone please review and push https://github.com/pawelz/pld-dhcp
> specifically that commit:
> https://github.com/pawelz/pld-dhcp/commit/071ac6b61dedf115572076ad17bbbef53226b22c
> ?
>
> This change fixes broken init for dhcp6.
>
> It's been 10 years since I touched PLD, so I don't really feel comfortable
> pushing without supervision even if I still have access to the repo.

you can push to a branch

you can also open a pull request in github





From qboosh at pld-linux.org  Wed Mar 31 22:23:44 2021
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 31 Mar 2021 22:23:44 +0200
Subject: [packages/rpm-pld-macros] - fix typo in debugsource packages
 macro - rel 2
In-Reply-To: <45c4eb111b114539bab16bd567a4a794d75d6e16_refs_heads_master@pld-linux.org>
References: <f62a5c22000a98a4962fec65f376b87db0667e20_refs_heads_master@pld-linux.org>
 <45c4eb111b114539bab16bd567a4a794d75d6e16_refs_heads_master@pld-linux.org>
Message-ID: <20210331202344.GA938@mail>

On Wed, Mar 31, 2021 at 09:33:00PM +0200, baggins wrote:
> commit 45c4eb111b114539bab16bd567a4a794d75d6e16
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Wed Mar 31 21:32:32 2021 +0200
> 
>     - fix typo in debugsource packages macro
>     - rel 2
> 
>  macros.pld          | 2 +-
>  rpm-pld-macros.spec | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> ---
[...]
> @@ -138,7 +138,7 @@ pakietu oraz przy odpluskwianiu samego pakietu.\
>  %ifnarch noarch\
>  %global __debug_package 1\
>  %_debuginfo_template\
> -%{?_debugsource_packages:%_debugsource_template}\
> +%{?%_debugsource_packages:%_debugsource_template}\
>  %endif\
>  %{nil}
>  

Uhm, is it really correct now?
debug source files like these are unpackaged now:

/usr/src/debug/gjs-1.68.0-1.x32
...


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


From baggins at pld-linux.org  Wed Mar 31 22:51:57 2021
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 31 Mar 2021 22:51:57 +0200
Subject: [packages/rpm-pld-macros] - fix typo in debugsource packages
 macro - rel 2
In-Reply-To: <20210331202344.GA938@mail>
References: <f62a5c22000a98a4962fec65f376b87db0667e20_refs_heads_master@pld-linux.org>
 <45c4eb111b114539bab16bd567a4a794d75d6e16_refs_heads_master@pld-linux.org>
 <20210331202344.GA938@mail>
Message-ID: <20210331205157.GA12558@tachikoma>

On Wed, 31 Mar 2021, Jakub Bogusz wrote:

> On Wed, Mar 31, 2021 at 09:33:00PM +0200, baggins wrote:
> > commit 45c4eb111b114539bab16bd567a4a794d75d6e16
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Wed Mar 31 21:32:32 2021 +0200
> > 
> >     - fix typo in debugsource packages macro
> >     - rel 2
> > 
> >  macros.pld          | 2 +-
> >  rpm-pld-macros.spec | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > ---
> [...]
> > @@ -138,7 +138,7 @@ pakietu oraz przy odpluskwianiu samego pakietu.\
> >  %ifnarch noarch\
> >  %global __debug_package 1\
> >  %_debuginfo_template\
> > -%{?_debugsource_packages:%_debugsource_template}\
> > +%{?%_debugsource_packages:%_debugsource_template}\
> >  %endif\
> >  %{nil}
> >  
> 
> Uhm, is it really correct now?
> debug source files like these are unpackaged now:
> 
> /usr/src/debug/gjs-1.68.0-1.x32

It's not, Reverted.

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