Re: The horrible mess called PHP

2024-06-20 Thread Jan Rękorajski
On Sun, 16 Jun 2024, Arkadiusz Miśkiewicz via pld-devel-en wrote:

[...]
> 
> But you did disable dependency generator for PEAR
> 
> Author: Jan Rękorajski 
> Date:   Sat Oct 17 10:02:30 2020 +0200
> - disable php pear dependency generators - ver 1.753
> 
> and that causes now that rebuilding pear packages produce new packages 
> that do not provide things that existing packages want.
> 
> If you disabled this to get rid of pear specific deps then all pear 
> packages need to be rebuild.

I think I know why I disabled it back then.
With rpm5, the dependency generators could be selected by hand in the
spec, this is not the case with rpm.org. Now, that dependency generator
is run on every package, it picks up a lot of BS that has to be excepted
with _noautoreq_pear - see latest updates to zabbix and occ packages.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: The horrible mess called PHP

2024-06-16 Thread Jan Rękorajski
On Sun, 16 Jun 2024, Jan Rękorajski wrote:

> On Sun, 16 Jun 2024, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> 
[...]
> > 
> > But you did disable dependency generator for PEAR
> > 
> > Author: Jan Rękorajski 
> > Date:   Sat Oct 17 10:02:30 2020 +0200
> > - disable php pear dependency generators - ver 1.753
> > 
> > and that causes now that rebuilding pear packages produce new packages 
> > that do not provide things that existing packages want.
> > 
> > If you disabled this to get rid of pear specific deps then all pear 
> > packages need to be rebuild.
> 
> Hah, good point. I might have disabled it because of dependency problems
> seteaming from constant installs/removals of the php runtime.
> 
> I'm going to reenable that and test if it still works.

Ok, we have two dependency generators for php pear. One written in perl
and that one seem to work, and the second in php that seems to be
completely broken:

Runtime version 7.4.

First:

PHP Warning:  require_once(PHP/CompatInfo.php): failed to open stream: No such 
file or directory in /usr/lib/rpm/php.req.php on line 123
PHP Fatal error:  require_once(): Failed opening required 'PHP/CompatInfo.php' 
(include_path='.:/usr/share/pear:/usr/share/php') in /usr/lib/rpm/php.req.php 
on line 123

After installing php-pear-PHP_CompatInfo:

PHP Parse error:  syntax error, unexpected 'new' (T_NEW) in 
/usr/share/pear/Event/Dispatcher.php on line 249

I'll reenable the old one and we'll deal with the problems as they
appear.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: The horrible mess called PHP

2024-06-16 Thread Jan Rękorajski
On Sun, 16 Jun 2024, Arkadiusz Miśkiewicz via pld-devel-en wrote:

> On 15/06/2024 22:34, Jan Rękorajski wrote:
> 
> > TL;DR Make PHP packaging sustainable or all versioned php packages will
> > be deleted and replaced by a single php package tracking head.
> 
> I'm using almost all old PHPs, including old 4 one. DON'T delete these.
> 
> (I'm using few pear packages, too)
> 
> > 
> > The current model of packaging PHP runtime is not sustainable. >
> > The dependencies are a complete mess, packages (build)require
> > php-something, but none of the versioned phpXY-something provides
> > this.
> 
> Be more specific and I'll try to fix things related to php packages. Now 
> I have to guess what are you talking about.

$ builder -bi -R php-pear-PEAR.spec
[...]
Install dependencies: php-pcre php-xml
Loading [pndir]th-test...
Loading [pndir]th-test...
Loading [pndir]th-ready...
Loading [pndir]th-ready...
Loading [pndir]th...
Loading [pndir]th...
34536 packages read
Removed 2036 duplicate packages from available set
error: php-pcre: no such package
error: php-xml: no such package

Because spec:

%define php_name php%{?php_suffix}
[...]
BuildRequires: %{php_name}-pcre

Basically you need to set %php_suffix manually. This should be automated
at the spec level. Maybe something akin to what I did for kernel
packages. Or maybe "pick the latest runtime if not overriden" at macro
definition level.

And to make it better, all php runtimes should be parallel-installable,
including devel, excluding /usr/bin/php link.

> > This leads to a lot of manual labor when rebuilding php-pecl
> > packages (run this magical command for managing installed deps
> > and pray it works).
> > 
> > This also leades to even worse mess for PEAR packages. The dependency
> > generator needs /usr/bin/php and it gets a random one,
> 
> Does output that it produces depend on php version? AFAIK any php is ok 
> for it to produce the same output.

I have no idea, never used PHP. The script looks pretty generic, tho.

> > if it gets
> > anything at all.
> 
> But you did disable dependency generator for PEAR
> 
> Author: Jan Rękorajski 
> Date:   Sat Oct 17 10:02:30 2020 +0200
> - disable php pear dependency generators - ver 1.753
> 
> and that causes now that rebuilding pear packages produce new packages 
> that do not provide things that existing packages want.
> 
> If you disabled this to get rid of pear specific deps then all pear 
> packages need to be rebuild.

Hah, good point. I might have disabled it because of dependency problems
seteaming from constant installs/removals of the php runtime.

I'm going to reenable that and test if it still works.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: The horrible mess called PHP

2024-06-16 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 15/06/2024 22:34, Jan Rękorajski wrote:


TL;DR Make PHP packaging sustainable or all versioned php packages will
be deleted and replaced by a single php package tracking head.


I'm using almost all old PHPs, including old 4 one. DON'T delete these.

(I'm using few pear packages, too)



The current model of packaging PHP runtime is not sustainable. >
The dependencies are a complete mess, packages (build)require
php-something, but none of the versioned phpXY-something provides
this.


Be more specific and I'll try to fix things related to php packages. Now 
I have to guess what are you talking about.



This leads to a lot of manual labor when rebuilding php-pecl
packages (run this magical command for managing installed deps
and pray it works).

This also leades to even worse mess for PEAR packages. The dependency
generator needs /usr/bin/php and it gets a random one,


Does output that it produces depend on php version? AFAIK any php is ok 
for it to produce the same output.



if it gets
anything at all.


But you did disable dependency generator for PEAR

Author: Jan Rękorajski 
Date:   Sat Oct 17 10:02:30 2020 +0200
- disable php pear dependency generators - ver 1.753

and that causes now that rebuilding pear packages produce new packages 
that do not provide things that existing packages want.


If you disabled this to get rid of pear specific deps then all pear 
packages need to be rebuild.


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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: freshness report not updating

2024-06-11 Thread Jan Palus
On 11.06.2024 09:41, Jan Rękorajski wrote:
> On Sat, 08 Jun 2024, Jan Rękorajski wrote:
> 
> > On Sun, 05 May 2024, Jan Palus wrote:
> > 
> > > Looks like new entries don't appear in freshness report
> > > (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although
> > > interestingly old items that made it to the list disappear after they
> > > were sent to builders.
> > 
> > The problem is that SPECS pseudorepo has not been updated since May 1st,
> > probably due to disk space issues. I'll see if I can do something with
> > it.
> 
> Took me a while, but problem solved.
> 
> The SPECS repo had a stale lock preventing it from being updated (-‸ლ)
> 
> There was a second issue, the Refs repo had (i) grown to enormous size
> and (ii) has been badly damaged to the point that git gc consistently
> failed. Since Refs.git is just a tracker of all refs in packages repos,
> I could and did recreate it from scratch saving 25G of space
> (free went up from 3.7G to 32G).
> 
> Since we only really care about the HEAD state of Refs.git it would ge
> good to prune it more regularly, so that we don't end up in this state
> again.

Thanks!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: freshness report not updating

2024-06-11 Thread Jan Rękorajski
On Sat, 08 Jun 2024, Jan Rękorajski wrote:

> On Sun, 05 May 2024, Jan Palus wrote:
> 
> > Looks like new entries don't appear in freshness report
> > (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although
> > interestingly old items that made it to the list disappear after they
> > were sent to builders.
> 
> The problem is that SPECS pseudorepo has not been updated since May 1st,
> probably due to disk space issues. I'll see if I can do something with
> it.

Took me a while, but problem solved.

The SPECS repo had a stale lock preventing it from being updated (-‸ლ)

There was a second issue, the Refs repo had (i) grown to enormous size
and (ii) has been badly damaged to the point that git gc consistently
failed. Since Refs.git is just a tracker of all refs in packages repos,
I could and did recreate it from scratch saving 25G of space
(free went up from 3.7G to 32G).

Since we only really care about the HEAD state of Refs.git it would ge
good to prune it more regularly, so that we don't end up in this state
again.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: freshness report not updating

2024-06-08 Thread Jan Rękorajski
On Sun, 05 May 2024, Jan Palus wrote:

> Looks like new entries don't appear in freshness report
> (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although
> interestingly old items that made it to the list disappear after they
> were sent to builders.

The problem is that SPECS pseudorepo has not been updated since May 1st,
probably due to disk space issues. I'll see if I can do something with
it.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: DISTFILES: kicad: ERRORS: kicad-packages3D-8.0.2.tar.bz2

2024-04-29 Thread Jan Rękorajski
On Mon, 29 Apr 2024, Jan Rękorajski wrote:

> On Mon, 29 Apr 2024, Jakub Bogusz wrote:
> 
> > What happens here?
> > ENOSPC?
> > 
> > Offending file is ~700MB big.
> 
> Yeah, cvs/git vm is out of disk space (that's where the files are
> fetched):
> 
> /dev/mapper/cvs-cvs xfs45G   45G  316M 100% /cvs/root
> 
> Who can run lvextend/xfs_resize there?

Answering myself. I can and added 1G.

We may need to get that PV/VG bigger tho, 90% of repo space is taken by
Refs.git that tracks individual package repos history.

> 
> > On Mon, Apr 29, 2024 at 09:04:51PM +0200, qboosh wrote:
> > > Request by: qboosh
> > > 
> > > FATAL: cannot move ./upload/kicad-packages3D-8.0.2.tar.bz2 to 
> > > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b
> > > ERROR: cannot write 
> > > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b/kicad-packages3D-8.0.2.tar.bz2.link
> > > 
> > > Files fetched: 0
> > > 
> > > ALREADY GOT: 
> > > https://gitlab.com/kicad/code/kicad/-/archive/8.0.2/kicad-8.0.2.tar.bz2
> > >   957ba90492d8bf60f4ff55b3910f1cbd  kicad-8.0.2.tar.bz2
> > > ALREADY GOT: 
> > > https://gitlab.com/kicad/services/kicad-doc/-/archive/8.0.2/kicad-doc-8.0.2.tar.bz2
> > >   5c1b5dc997be84b08d59d78a5a9fcd3e  kicad-doc-8.0.2.tar.bz2
> > > ALREADY GOT: 
> > > https://gitlab.com/kicad/libraries/kicad-symbols/-/archive/8.0.2/kicad-symbols-8.0.2.tar.bz2
> > >   060c52586965f15b867ee0683aa642ae  kicad-symbols-8.0.2.tar.bz2
> > > ALREADY GOT: 
> > > https://gitlab.com/kicad/libraries/kicad-footprints/-/archive/8.0.2/kicad-footprints-8.0.2.tar.bz2
> > >   c9537b5ccaa9581ff32d157837a13c38  kicad-footprints-8.0.2.tar.bz2
> > > ALREADY GOT: 
> > > https://gitlab.com/kicad/libraries/kicad-templates/-/archive/8.0.2/kicad-templates-8.0.2.tar.bz2
> > >   20932897d55d49386a1e2431a2aeef5f  kicad-templates-8.0.2.tar.bz2
> > > 
> > > 
> > > -- 
> > > Virtually Yours: distfiles.
> > > ___
> > > pld-cvs-commit mailing list
> > > pld-cvs-com...@lists.pld-linux.org
> > > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
> > 
> > -- 
> > Jakub Boguszhttp://qboosh.pl/
> > ___
> > pld-devel-en mailing list
> > pld-devel-en@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> 
> -- 
> Jan Rękorajski| PLD/Linux
> SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: DISTFILES: kicad: ERRORS: kicad-packages3D-8.0.2.tar.bz2

2024-04-29 Thread Jan Rękorajski
On Mon, 29 Apr 2024, Jakub Bogusz wrote:

> What happens here?
> ENOSPC?
> 
> Offending file is ~700MB big.

Yeah, cvs/git vm is out of disk space (that's where the files are
fetched):

/dev/mapper/cvs-cvs xfs45G   45G  316M 100% /cvs/root

Who can run lvextend/xfs_resize there?

> On Mon, Apr 29, 2024 at 09:04:51PM +0200, qboosh wrote:
> > Request by: qboosh
> > 
> > FATAL: cannot move ./upload/kicad-packages3D-8.0.2.tar.bz2 to 
> > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b
> > ERROR: cannot write 
> > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b/kicad-packages3D-8.0.2.tar.bz2.link
> > 
> > Files fetched: 0
> > 
> > ALREADY GOT: 
> > https://gitlab.com/kicad/code/kicad/-/archive/8.0.2/kicad-8.0.2.tar.bz2
> > 957ba90492d8bf60f4ff55b3910f1cbd  kicad-8.0.2.tar.bz2
> > ALREADY GOT: 
> > https://gitlab.com/kicad/services/kicad-doc/-/archive/8.0.2/kicad-doc-8.0.2.tar.bz2
> > 5c1b5dc997be84b08d59d78a5a9fcd3e  kicad-doc-8.0.2.tar.bz2
> > ALREADY GOT: 
> > https://gitlab.com/kicad/libraries/kicad-symbols/-/archive/8.0.2/kicad-symbols-8.0.2.tar.bz2
> > 060c52586965f15b867ee0683aa642ae  kicad-symbols-8.0.2.tar.bz2
> > ALREADY GOT: 
> > https://gitlab.com/kicad/libraries/kicad-footprints/-/archive/8.0.2/kicad-footprints-8.0.2.tar.bz2
> > c9537b5ccaa9581ff32d157837a13c38  kicad-footprints-8.0.2.tar.bz2
> > ALREADY GOT: 
> > https://gitlab.com/kicad/libraries/kicad-templates/-/archive/8.0.2/kicad-templates-8.0.2.tar.bz2
> > 20932897d55d49386a1e2431a2aeef5f  kicad-templates-8.0.2.tar.bz2
> > 
> > 
> > -- 
> > Virtually Yours: distfiles.
> > ___
> > pld-cvs-commit mailing list
> > pld-cvs-com...@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
> 
> -- 
> Jakub Boguszhttp://qboosh.pl/
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: DISTFILES: kicad: ERRORS: kicad-packages3D-8.0.2.tar.bz2

2024-04-29 Thread Jakub Bogusz
What happens here?
ENOSPC?

Offending file is ~700MB big.


On Mon, Apr 29, 2024 at 09:04:51PM +0200, qboosh wrote:
> Request by: qboosh
> 
> FATAL: cannot move ./upload/kicad-packages3D-8.0.2.tar.bz2 to 
> ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b
> ERROR: cannot write 
> ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b/kicad-packages3D-8.0.2.tar.bz2.link
> 
> Files fetched: 0
> 
> ALREADY GOT: 
> https://gitlab.com/kicad/code/kicad/-/archive/8.0.2/kicad-8.0.2.tar.bz2
>   957ba90492d8bf60f4ff55b3910f1cbd  kicad-8.0.2.tar.bz2
> ALREADY GOT: 
> https://gitlab.com/kicad/services/kicad-doc/-/archive/8.0.2/kicad-doc-8.0.2.tar.bz2
>   5c1b5dc997be84b08d59d78a5a9fcd3e  kicad-doc-8.0.2.tar.bz2
> ALREADY GOT: 
> https://gitlab.com/kicad/libraries/kicad-symbols/-/archive/8.0.2/kicad-symbols-8.0.2.tar.bz2
>   060c52586965f15b867ee0683aa642ae  kicad-symbols-8.0.2.tar.bz2
> ALREADY GOT: 
> https://gitlab.com/kicad/libraries/kicad-footprints/-/archive/8.0.2/kicad-footprints-8.0.2.tar.bz2
>   c9537b5ccaa9581ff32d157837a13c38  kicad-footprints-8.0.2.tar.bz2
> ALREADY GOT: 
> https://gitlab.com/kicad/libraries/kicad-templates/-/archive/8.0.2/kicad-templates-8.0.2.tar.bz2
>   20932897d55d49386a1e2431a2aeef5f  kicad-templates-8.0.2.tar.bz2
> 
> 
> -- 
> Virtually Yours: distfiles.
> ___
> pld-cvs-commit mailing list
> pld-cvs-com...@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit

-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: builders->ftp uploads defunct

2024-04-22 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 22/04/2024 20:58, Jakub Bogusz wrote:

Since Saturday new packages don't appear in th-test.
Could it be fixed?


ENOSPC on ftp disk and stale locks... fixed.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/xz] Revert back to 5.4.6 as 5.6.x are BACKDOORED! https://www.openwall.com/lists/oss-security/2024/03/29

2024-03-30 Thread Mateusz Kocielski
Dnia Sat, Mar 30, 2024 at 01:57:22PM +0100, Jan Palus napisał(a):
> On 30.03.2024 01:49, arekm wrote:
> > commit b369fe78b7b4a02e900fb6fe7ac035a9bba39436
> > Author: Arkadiusz Miśkiewicz 
> > Date:   Fri Mar 29 23:50:59 2024 +0100
> > 
> > Revert back to 5.4.6 as 5.6.x are BACKDOORED! 
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> > 
> >  xz.spec | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > ---
> > diff --git a/xz.spec b/xz.spec
> > index a36b5df..8094d11 100644
> > --- a/xz.spec
> > +++ b/xz.spec
> > @@ -19,8 +19,8 @@ Summary:  LZMA Encoder/Decoder
> >  Summary(pl.UTF-8): Koder/Dekoder LZMA
> >  Name:  xz
> >  Version:   5.4.6
> > -Release:   1
> > -Epoch: 1
> > +Release:   2
> > +Epoch: 2
> >  License:   LGPL v2.1+, helper scripts on GPL v2+
> >  Group: Applications/Archiving
> >  Source0:   
> > https://github.com/tukaani-project/xz/releases/download/v%{version}/%{name}-%{version}.tar.bz2
> 
> Some notes from what I've gathered so far from a rather lengthy HN
> thread:
> 
> - main backdoor appears to affect /usr/sbin/sshd on x86_64 with liblzma
>   being pulled in as an indirect dependency. liblzma can be loaded by
>   libsystemd if sshd was built with additional systemd patches which PLD
>   does not use (unlike Debian and Fedora). So _possibly_ PLD is not
>   affected
> 
> - despite that some claims start to surface that going back to 5.4.6
>   might not be enough so let's see how this drama develops

Hi there,

 I checked manually that the 5.6.1 version from this build [1] seems not
to be vulnerable (I verified it using the signature provided in the original
post [2]).


My suspicion regarding why it was not activated is due to the failure of the
following check on the build machine. The check is a part of the malicious
script which decides if backdoor should be planted.

[...]
if test "x$CC" != 'xgcc' > /dev/null 2>&1;then
exit 0
fi
[...]

The condition fails because CC set during the build is different:
'CC=x86_64-pld-linux-gcc' However, please note that there might be additional
components within the package unknown to us at present.

 Regards,
 Mateusz

[1] 
http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=1==50=0=xz=0a127d4c-eda2-4f14-aedf-4a69d79b5b80=text
[2] https://seclists.org/oss-sec/2024/q1/268
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/xz] Revert back to 5.4.6 as 5.6.x are BACKDOORED! https://www.openwall.com/lists/oss-security/2024/03/29

2024-03-30 Thread Jan Palus
On 30.03.2024 01:49, arekm wrote:
> commit b369fe78b7b4a02e900fb6fe7ac035a9bba39436
> Author: Arkadiusz Miśkiewicz 
> Date:   Fri Mar 29 23:50:59 2024 +0100
> 
> Revert back to 5.4.6 as 5.6.x are BACKDOORED! 
> https://www.openwall.com/lists/oss-security/2024/03/29/4
> 
>  xz.spec | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> ---
> diff --git a/xz.spec b/xz.spec
> index a36b5df..8094d11 100644
> --- a/xz.spec
> +++ b/xz.spec
> @@ -19,8 +19,8 @@ Summary:LZMA Encoder/Decoder
>  Summary(pl.UTF-8):   Koder/Dekoder LZMA
>  Name:xz
>  Version: 5.4.6
> -Release: 1
> -Epoch:   1
> +Release: 2
> +Epoch:   2
>  License: LGPL v2.1+, helper scripts on GPL v2+
>  Group:   Applications/Archiving
>  Source0: 
> https://github.com/tukaani-project/xz/releases/download/v%{version}/%{name}-%{version}.tar.bz2

Some notes from what I've gathered so far from a rather lengthy HN
thread:

- main backdoor appears to affect /usr/sbin/sshd on x86_64 with liblzma
  being pulled in as an indirect dependency. liblzma can be loaded by
  libsystemd if sshd was built with additional systemd patches which PLD
  does not use (unlike Debian and Fedora). So _possibly_ PLD is not
  affected

- despite that some claims start to surface that going back to 5.4.6
  might not be enough so let's see how this drama develops
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/python3] python points to python3 now

2024-03-25 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 25/03/2024 10:22, Jan Palus wrote:

On 25.03.2024 11:05, arekm wrote:

commit d073fb40c26996aedc0c52fdea5af8b596e4f395
Author: Arkadiusz Miśkiewicz 
Date:   Mon Mar 25 09:58:15 2024 +0100

 python points to python3 now

  python3.spec | 4 
  1 file changed, 4 insertions(+)
---
diff --git a/python3.spec b/python3.spec
index 503d98b..686f876 100644
--- a/python3.spec
+++ b/python3.spec
@@ -669,6 +669,9 @@ install -p Tools/patchcheck/reindent.py 
$RPM_BUILD_ROOT%{_bindir}/pyreindent%{py
  %{__mv} $RPM_BUILD_ROOT%{py_incdir}/pyconfig.h 
$RPM_BUILD_ROOT%{py_libdir}/config-%{py_platform}/pyconfig.h
  %{__sed} 
-e's#@PREFIX@#%{_prefix}#g;s#@PY_VER@#%{py_ver}#g;s#@PY_ABI@#%{py_platform}#g' 
%{SOURCE1} > $RPM_BUILD_ROOT%{py_incdir}/pyconfig.h
  
+# python points to python3 now

+ln -s python3 $RPM_BUILD_ROOT%{_bindir}/python
+


I guess all those packages that still meet `ipoldek what-requires 
/usr/bin/python`
might not be happy about it.


I'm not sending these changes to builders to see what other devs will say.

(the intention was to break these packages and get them dropped (or 
fixed) on case by case basis, if problems occur)


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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/python3] python points to python3 now

2024-03-25 Thread Jan Palus
On 25.03.2024 11:05, arekm wrote:
> commit d073fb40c26996aedc0c52fdea5af8b596e4f395
> Author: Arkadiusz Miśkiewicz 
> Date:   Mon Mar 25 09:58:15 2024 +0100
> 
> python points to python3 now
> 
>  python3.spec | 4 
>  1 file changed, 4 insertions(+)
> ---
> diff --git a/python3.spec b/python3.spec
> index 503d98b..686f876 100644
> --- a/python3.spec
> +++ b/python3.spec
> @@ -669,6 +669,9 @@ install -p Tools/patchcheck/reindent.py 
> $RPM_BUILD_ROOT%{_bindir}/pyreindent%{py
>  %{__mv} $RPM_BUILD_ROOT%{py_incdir}/pyconfig.h 
> $RPM_BUILD_ROOT%{py_libdir}/config-%{py_platform}/pyconfig.h
>  %{__sed} 
> -e's#@PREFIX@#%{_prefix}#g;s#@PY_VER@#%{py_ver}#g;s#@PY_ABI@#%{py_platform}#g'
>  %{SOURCE1} > $RPM_BUILD_ROOT%{py_incdir}/pyconfig.h
>  
> +# python points to python3 now
> +ln -s python3 $RPM_BUILD_ROOT%{_bindir}/python
> +

I guess all those packages that still meet `ipoldek what-requires 
/usr/bin/python`
might not be happy about it.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/gobject-introspection] - updated to 1.80.0; added bootstrap bcond for glib 2.78->2.80 transition

2024-03-10 Thread Jakub Bogusz
On Sun, Mar 10, 2024 at 10:56:22AM +0100, Jan Palus wrote:
> Shouldn't it be the other way around -- "bootstrap" bcond in glib2 for
> building without introspection? Currently while gobject-introspection
> does not build-time depend on glib2-devel >= 2.80, it does runtime
> depend on glib2 >= 2.80 (both in rpm deps and linked dynamic library)
> which cannot be satisfied to build glib2 2.80.

Oh, I wasn't aware of g-ir-scanner dependency to build introspection
files in glib2 (I had gobject-introspection-devel 1.78 installed).
So now I added "introspection" bcond to glib2.spec to allow bootstrapping
from scratch.

Previously I added "bootstrap" bcond in gobject-introspection as a way to
cleanly build+upgrade on existing system (it's not possible to cleanly
upgrade glib2 built with introspection without removing or upgrading to
1.80 existing gobject-introspection 1.78 package due to files conflict).
So I could build whole glib2 2.80 and gobject-introspection 1.80 and
upgrade them both simultaneously.


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/gobject-introspection] - updated to 1.80.0; added bootstrap bcond for glib 2.78->2.80 transition

2024-03-10 Thread Jan Palus
On 09.03.2024 22:33, qboosh wrote:
> commit a0c12f9cf03d0222dbb6357f6da0f70e72260664
> Author: Jakub Bogusz 
> Date:   Sat Mar 9 22:31:00 2024 +0100
> 
> - updated to 1.80.0; added bootstrap bcond for glib 2.78->2.80 transition
> 
>  gobject-introspection.spec | 55 
> +-
>  1 file changed, 35 insertions(+), 20 deletions(-)
> ---
> diff --git a/gobject-introspection.spec b/gobject-introspection.spec
> index 0055356..4719aa3 100644
> --- a/gobject-introspection.spec
> +++ b/gobject-introspection.spec
> @@ -2,27 +2,30 @@
>  # Conditional build:
>  %bcond_without   cairo   # cairo support
>  %bcond_without   apidocs # API documentation
> +%bcond_with  bootstrap   # bootstrap from glib < 2.80
>  
>  Summary: Introspection for GObject libraries
>  Summary(pl.UTF-8):   Obserwacja bibliotek GObject
>  Name:gobject-introspection
> -Version: 1.78.1
> +Version: 1.80.0
>  Release: 1
> -License: LGPL v2+ (giscanner) and GPL v2+ (tools)
> +License: LGPL v2+ (libraries, giscanner) and GPL v2+ (tools)
>  Group:   Libraries
> -Source0: 
> https://download.gnome.org/sources/gobject-introspection/1.78/%{name}-%{version}.tar.xz
> -# Source0-md5:   da2677e6b9c91b33c036d2233a96cec3
> +Source0: 
> https://download.gnome.org/sources/gobject-introspection/1.80/%{name}-%{version}.tar.xz
> +# Source0-md5:   003cc22c45be5edf91911050bbcfbde6
> +Source1: https://download.gnome.org/sources/glib/2.80/glib-2.80.0.tar.xz
> +# Source1-md5:   3a51e2803ecd22c2dadcd07d9475ebe3
>  URL: https://wiki.gnome.org/Projects/GObjectIntrospection
>  BuildRequires:   automake
>  BuildRequires:   bison
>  %{?with_cairo:BuildRequires: cairo-gobject-devel}
>  BuildRequires:   flex
>  BuildRequires:   gcc >= 5:3.2
> -BuildRequires:   glib2-devel >= 1:2.78.0
> +%{!?with_bootstrap:BuildRequires:glib2-devel >= 1:2.80.0}
>  BuildRequires:   glibc-misc
>  %{?with_apidocs:BuildRequires:   gtk-doc >= 1.19}
> -BuildRequires:   libffi-devel >= 3.0.0
> -BuildRequires:   meson >= 0.60.0
> +BuildRequires:   libffi-devel >= 7:3.4
> +BuildRequires:   meson >= 1.2.0
>  BuildRequires:   ninja >= 1.5
>  BuildRequires:   pkgconfig
>  BuildRequires:   python3 >= 1:3.6
> @@ -36,7 +39,8 @@ BuildRequires:  rpmbuild(macros) >= 1.752
>  BuildRequires:   tar >= 1:1.22
>  BuildRequires:   xz
>  BuildRequires:   zlib-devel
> -Requires:glib2 >= 1:2.78.0
> +Requires:glib2 >= 1:2.80.0

Shouldn't it be the other way around -- "bootstrap" bcond in glib2 for
building without introspection? Currently while gobject-introspection
does not build-time depend on glib2-devel >= 2.80, it does runtime
depend on glib2 >= 2.80 (both in rpm deps and linked dynamic library)
which cannot be satisfied to build glib2 2.80.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1

2024-02-06 Thread Jakub Bogusz
On Sun, Feb 04, 2024 at 03:04:21PM +0100, Witold Filipczyk via pld-devel-en 
wrote:
> Dnia Sat, Feb 03, 2024 at 08:56:25PM +0100, Jakub Bogusz napisał(a):
> > On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote:
> > > commit 3b3013be1262989c7a7df78ffab6d797766b6486
> > > Author: Witold Filipczyk 
> > > Date:   Sat Feb 3 20:24:04 2024 +0100
> > > 
> > > - updated to 5.249.0; rel 0.1
> > > 
> > >  kf5-attica.spec | 41 -
> > >  1 file changed, 20 insertions(+), 21 deletions(-)
> > 
> > Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now?
> 
> OK. What to do with plasma (now kp5-*) and KDE Gear (now ka5-*) ?

No idea about starting prefix (should "kp" and "ka" be preserved or
changed), but AFAICS files/dirs are getting "6" suffix now, so IMO number
should be updated (or dropped, if KDE 6 is going to instantly replace
KDE 5).


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: TEST build ERRORS: test.spec

2024-02-05 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 05/02/2024 02:02, Jan Palus wrote:


I've tried to replicate the env (i686 VM, XFS) but without success. Not
sure if it's block device driver? XFS? or something else? Can't do much
more without ability to reproduce. Any ideas are welcome.


All builders run on the same physical machine as VMs under proxmox 8.1:
pve-manager/8.1.4/ec5affc9e41f1d79 (running kernel: 6.5.11-8-pve)

Each builder uses two physical SSD disks (crucial: x32 - mx200, i686 - 
mx300, x86_64 - mx500).


SSD are available to VMs as passthru. VMs have soft RAID1 setup inside, 
xfs fs on top of that. It's basically old hardware setup migrated from 3 
different physical machines into one with proxmox.


Providing disk directly to VM seems to be a key to reproduce the problem 
(as I was unable to reproduce it on the same machine when VM visible 
disk was backed by just qcow2 file).


Disks used default options (so no cache, no discard, no io thread, no 
skip replication, async io - io_uring). Virtio interface.


But I noticed that enabling discard on these hard disks (in 
proxmox->VM->Hardware->Hard disk) makes problem go away.


So enabled on all builders.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: TEST build ERRORS: test.spec

2024-02-04 Thread Jan Palus
On 05.02.2024 00:50, PLD th-i686 builder wrote:
> test.spec (cryptsetup-debug): FAILED
...
> + test cafa743b687f1581b71a20ebfc068f9fe12653e945c417311b861c9217e66adf '=' 
> 06e2f159d6d541169da75222a7f0bedd0fc700502d63809f577b48f41eace335

Something concerning is going on i686/x32 builders. All started with
cryptsetup tests failing there without any clear root cause. Code
involved in failing test is pretty straightforward and has no issues as
far as I can tell. Managed to narrow it down to:

- happens only on PLD builders
- happens only on 32-bit archs
- happens only when direct io (O_DIRECT) is involved

The concerning part is that writing with O_DIRECT produces non-sense
result. Parts of write might be missing or they might be scattered in
different places even though they should be contiguous.

Simple reproducer is currently present in test package on
cryptsetup-debug branch.

I've tried to replicate the env (i686 VM, XFS) but without success. Not
sure if it's block device driver? XFS? or something else? Can't do much
more without ability to reproduce. Any ideas are welcome.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1

2024-02-04 Thread Witold Filipczyk via pld-devel-en
Dnia Sat, Feb 03, 2024 at 08:56:25PM +0100, Jakub Bogusz napisał(a):
> On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote:
> > commit 3b3013be1262989c7a7df78ffab6d797766b6486
> > Author: Witold Filipczyk 
> > Date:   Sat Feb 3 20:24:04 2024 +0100
> > 
> > - updated to 5.249.0; rel 0.1
> > 
> >  kf5-attica.spec | 41 -
> >  1 file changed, 20 insertions(+), 21 deletions(-)
> 
> Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now?

OK. What to do with plasma (now kp5-*) and KDE Gear (now ka5-*) ?

> 
> 
> -- 
> Jakub Boguszhttp://qboosh.pl/
> ___
> pld-devel-pl mailing list
> pld-devel...@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1

2024-02-03 Thread Jakub Bogusz
On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote:
> commit 3b3013be1262989c7a7df78ffab6d797766b6486
> Author: Witold Filipczyk 
> Date:   Sat Feb 3 20:24:04 2024 +0100
> 
> - updated to 5.249.0; rel 0.1
> 
>  kf5-attica.spec | 41 -
>  1 file changed, 20 insertions(+), 21 deletions(-)

Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now?


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: New packages not available on ftp

2024-02-01 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 02/02/2024 00:14, Jan Palus wrote:

None of packages built today on builders is available on ftp.
Can someone check?


Something bad happened on ep09 machine (which is main ftp machine; 
doesn't let ssh in; disconnects).


No idea who else beside RMF has access to console on this VM.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/pam] - add triggers for removed modules

2024-01-06 Thread Jan Rękorajski
On Fri, 05 Jan 2024, Jan Palus wrote:

> On 23.12.2023 10:53, baggins wrote:
> > commit 201cb6739a14557a0ec8bf7c3dd171b4fc06afeb
> > Author: Jan Rękorajski 
> > Date:   Sat Dec 23 09:24:52 2023 +0100
> > 
> > - add triggers for removed modules
> > 
> >  pam.spec | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > ---
> > diff --git a/pam.spec b/pam.spec
> > index 8daeb42..a333ab9 100644
> > --- a/pam.spec
> > +++ b/pam.spec
> > @@ -413,7 +413,15 @@ if [ "$1" != 1 ]; then
> >  fi
> >  exit 0
> >  
> > -%triggerpostun -- %{name} < 1:1.1.5-8
> > +%triggerpostun -- %{name} < 1:1.5.3
> > +# removed in 1.5.3
> > +if grep -qs pam_tally /etc/pam.d/system-auth; then
> > +   %{__sed} -i -e '/pam_tally/d' /etc/pam.d/system-auth
> > +fi
> > +if grep -qs pam_cracklib /etc/pam.d/system-auth; then
> > +   %{__sed} -i -e '/pam_cracklib/ s/pam_cracklib/pam_pwquality/; s/$/ 
> > use_authtok/' /etc/pam.d/system-auth
>   
> ^
> 
> What's the reason for "use_authtok" exactly? There is no module left to
> prompt for password now and passwd just fails:
> 
> # passwd
> passwd: Authentication token manipulation error
> passwd: password unchanged

I'd swear I've been following the module docs, but it does not indeed
make sense. I'll fix it asap.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/pam] - add triggers for removed modules

2024-01-05 Thread Jan Palus
On 23.12.2023 10:53, baggins wrote:
> commit 201cb6739a14557a0ec8bf7c3dd171b4fc06afeb
> Author: Jan Rękorajski 
> Date:   Sat Dec 23 09:24:52 2023 +0100
> 
> - add triggers for removed modules
> 
>  pam.spec | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> ---
> diff --git a/pam.spec b/pam.spec
> index 8daeb42..a333ab9 100644
> --- a/pam.spec
> +++ b/pam.spec
> @@ -413,7 +413,15 @@ if [ "$1" != 1 ]; then
>  fi
>  exit 0
>  
> -%triggerpostun -- %{name} < 1:1.1.5-8
> +%triggerpostun -- %{name} < 1:1.5.3
> +# removed in 1.5.3
> +if grep -qs pam_tally /etc/pam.d/system-auth; then
> + %{__sed} -i -e '/pam_tally/d' /etc/pam.d/system-auth
> +fi
> +if grep -qs pam_cracklib /etc/pam.d/system-auth; then
> + %{__sed} -i -e '/pam_cracklib/ s/pam_cracklib/pam_pwquality/; s/$/ 
> use_authtok/' /etc/pam.d/system-auth
  
^

What's the reason for "use_authtok" exactly? There is no module left to
prompt for password now and passwd just fails:

# passwd
passwd: Authentication token manipulation error
passwd: password unchanged
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: DISTFILES: ccache: ERRORS: ccache-4.9.tar.xz

2023-12-31 Thread Jan Palus
On 31.12.2023 13:10, atler wrote:
> Request by: atler
> 
> scp problems: scp -pr -B -q 
> ./tmp/a3fa32b0-8779-4bcb-a2b9-de2c39648f88/6eeab51025bb3492aa197d7d32be3184/ 
> pldd...@distfiles.pld-linux.org:ftp//by-md5/6/e:
> scp: Connection closed
> 
> The command has exited with a non-zero status.
> 
> Files fetched: 0

Same issue twice in a row, no space left perhaps? Can someone have a
look?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/mysql] Started work on 8.1.0 upgrade and also started making this package coinstallable with other mysql/ma

2023-10-20 Thread Jakub Bogusz
On Fri, Oct 20, 2023 at 07:01:56PM +0200, arekm wrote:
> commit 616994dbf9872356085c234c4c1efaa050d74ce3
> Author: Arkadiusz Miśkiewicz 
> Date:   Fri Oct 20 19:01:24 2023 +0200
> 
> Started work on 8.1.0 upgrade and also started making this package 
> coinstallable with other mysql/mariadb/percona servers

> +%define majorver81
> +Name:mysql%{majorver}

Please, use "8.1" (and similar scheme) not "81" in such cases.

If they e.g. start using 24.x as version number next year, our suffixes would 
go crazy.


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/shared-mime-info] fix build with doc; rel 2

2023-10-09 Thread Jakub Bogusz
On Mon, Oct 09, 2023 at 02:59:52PM +0200, atler wrote:
> commit dabbd0362fbd2a2345f450a5efceb62eb321741b
> Author: Jan Palus 
> Date:   Mon Oct 9 14:11:26 2023 +0200
> 
> fix build with doc; rel 2
> 
> replace unicode apostrophe with ascii one. from:
> https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/254

We can also use:

SP_ENCODING=utf-8 \
db2html data/shared-mime-info-spec.xml

to build with Unicode.

But yes, using Unicode for just single apostrophe is excessive...


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: i3lock - spec file

2023-07-12 Thread Jan Palus
On 12.07.2023 17:10, Mateusz Kocielski wrote:
> Dnia Wed, Jul 12, 2023 at 01:22:08PM +0200, Jan Palus napisał(a):
> > 
> > Override pam configuration shipped with i3lock with custom one that has:
> > 
> > auth   include  system-auth
> > 
> > just like (all?) other screensavers/lockers and it should be fine.
> > 
> > Other than this
> > 
> > 1. Fix case in Summary:
> > 2. Update required macros according to linked BuildRequires.txt (for
> >%ninja_* macros)
> > 3. Clone empty pld repository for i3lock or just create a local git
> >repo, commit the spec and pam file and attach output of
> >`git format-patch -1` so authorship will be preserved correctly when
> >applying.
> 
> All done, thanks for reviewing it!

Thanks. Applied and now available in th-test.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: i3lock - spec file

2023-07-12 Thread Mateusz Kocielski
Dnia Wed, Jul 12, 2023 at 01:22:08PM +0200, Jan Palus napisał(a):
> 
> Override pam configuration shipped with i3lock with custom one that has:
> 
> auth   include  system-auth
> 
> just like (all?) other screensavers/lockers and it should be fine.
> 
> Other than this
> 
> 1. Fix case in Summary:
> 2. Update required macros according to linked BuildRequires.txt (for
>%ninja_* macros)
> 3. Clone empty pld repository for i3lock or just create a local git
>repo, commit the spec and pam file and attach output of
>`git format-patch -1` so authorship will be preserved correctly when
>applying.

All done, thanks for reviewing it!

 Regards,
 Mateusz
>From 54d6ec043900d3b74fb9d22f314d7145d545af16 Mon Sep 17 00:00:00 2001
From: Mateusz Kocielski 
Date: Wed, 12 Jul 2023 19:04:44 +0200
Subject: [PATCH] Initial version of i3lock spec

Prepared with helping hand from Jan Palus 
---
 i3lock.pam  |  1 +
 i3lock.spec | 49 +
 2 files changed, 50 insertions(+)
 create mode 100644 i3lock.pam
 create mode 100644 i3lock.spec

diff --git a/i3lock.pam b/i3lock.pam
new file mode 100644
index 000..2a1bcd9
--- /dev/null
+++ b/i3lock.pam
@@ -0,0 +1 @@
+authinclude system-auth
diff --git a/i3lock.spec b/i3lock.spec
new file mode 100644
index 000..34d323b
--- /dev/null
+++ b/i3lock.spec
@@ -0,0 +1,49 @@
+Summary:	Improved screen locker
+Name:		i3lock
+Version:	2.14.1
+Release:	1
+License:	BSD
+Group:		Applications
+Source0:	https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
+# Source0-md5:	33d4bc8256a1566fbac911e405e53fdd
+Source1:	%{name}.pam
+URL:		https://i3wm.org/i3lock/
+BuildRequires:	cairo-devel >= 1.14.4
+BuildRequires:	libev-devel
+BuildRequires:	libxcb-devel
+BuildRequires:	meson >= 0.45.0
+BuildRequires:	ninja
+BuildRequires:	pam-devel
+BuildRequires:	pkgconfig
+BuildRequires:	rpmbuild(macros) >= 1.736
+BuildRequires:	xcb-util-devel
+BuildRequires:	xcb-util-image-devel
+BuildRequires:	xcb-util-xrm-devel
+BuildRequires:	xorg-lib-libxkbcommon-x11-devel
+Requires:	cairo >= 1.14.4
+BuildRoot:	%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
+
+%description
+Minimalist screen locker based on slock.
+
+%prep
+%setup -q
+
+%build
+%meson build
+%ninja_build -C build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+%ninja_install -C build
+install %{SOURCE1} $RPM_BUILD_ROOT/etc/pam.d/i3lock
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(644,root,root,755)
+%doc LICENSE CHANGELOG
+%config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
+%attr(755,root,root) %{_bindir}/i3lock
+%{_mandir}/man1/i3lock.1*
-- 
2.41.0

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: i3lock - spec file

2023-07-12 Thread Jan Palus
On 11.07.2023 20:30, Mateusz Kocielski wrote:
> Dnia Tue, Jul 11, 2023 at 03:59:41PM +, Mateusz Kocielski napisał(a):
> > > That's peculiar -- what screen locker needs suid bit for? Why wheel
> > > group?
> > 
> > Wheel group is taken from my BSD heritage I guess, fixed it. :) It requires
> > PAM for an authentication.
> > 
> > > > %{_mandir}/man1/i3lock.1*
> 
> Hi,
> 
>  those suid privileges were bothering me and I did my homework, it seems that
> on Linux i3lock can work without them because of the unix_chkpwd(8) utility.
> On the FreeBSD (which uses OpenPAM) however SUID is necessary [1]. The reason
> why I couldn't get it work without root privileges was /etc/pam.d/login
> file which is installed with u-r permission by default. I guess there's no
> need to keep it that way since PAM configuration rather not contain any
> secrets. I attached fixed version of the spec file and patch against
> util-linux to set u+r permissions. Thanks for your suggestions!

Override pam configuration shipped with i3lock with custom one that has:

auth   include  system-auth

just like (all?) other screensavers/lockers and it should be fine.

Other than this

1. Fix case in Summary:
2. Update required macros according to linked BuildRequires.txt (for
   %ninja_* macros)
3. Clone empty pld repository for i3lock or just create a local git
   repo, commit the spec and pam file and attach output of
   `git format-patch -1` so authorship will be preserved correctly when
   applying.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: i3lock - spec file

2023-07-11 Thread Mateusz Kocielski
Dnia Tue, Jul 11, 2023 at 03:59:41PM +, Mateusz Kocielski napisał(a):
> > That's peculiar -- what screen locker needs suid bit for? Why wheel
> > group?
> 
> Wheel group is taken from my BSD heritage I guess, fixed it. :) It requires
> PAM for an authentication.
> 
> > > %{_mandir}/man1/i3lock.1*

Hi,

 those suid privileges were bothering me and I did my homework, it seems that
on Linux i3lock can work without them because of the unix_chkpwd(8) utility.
On the FreeBSD (which uses OpenPAM) however SUID is necessary [1]. The reason
why I couldn't get it work without root privileges was /etc/pam.d/login
file which is installed with u-r permission by default. I guess there's no
need to keep it that way since PAM configuration rather not contain any
secrets. I attached fixed version of the spec file and patch against
util-linux to set u+r permissions. Thanks for your suggestions!

[1] - 
https://cgit.freebsd.org/ports/tree/deskutils/i3lock/Makefile?id=924204922ac441410520f46695dd91a87c001ee9#n27

 Regards,
 Mateusz
>From 1e9086102e3c09827475a221ecba2745b519b2e6 Mon Sep 17 00:00:00 2001
From: Mateusz Kocielski 
Date: Tue, 11 Jul 2023 22:11:18 +0200
Subject: [PATCH] Add u+r for /etc/pam.d/ configuration files

---
 util-linux.spec | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/util-linux.spec b/util-linux.spec
index aeb33fa..e84b4f0 100644
--- a/util-linux.spec
+++ b/util-linux.spec
@@ -1344,10 +1344,10 @@ fi
 %attr(755,root,root) /bin/runuser
 %attr(755,root,root) /sbin/runuser
 %attr(4755,root,root) /bin/su
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/runuser
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/runuser-l
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/su
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/su-l
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/runuser
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/runuser-l
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/su
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/su-l
 %{_mandir}/man1/runuser.1*
 %{_mandir}/man1/su.1*
 %lang(cs) %{_mandir}/cs/man1/su.1*
@@ -2240,7 +2240,7 @@ fi
 
 %files -n login
 %defattr(644,root,root,755)
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/login
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/login
 %attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/security/blacklist.login
 %attr(755,root,root) /bin/login
 %{_mandir}/man1/login.1*
-- 
2.41.0

Summary:improved screen locker
Name:   i3lock
Version:2.14.1
Release:1
License:BSD
Group:  Applications
Source0:https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
# Source0-md5:  33d4bc8256a1566fbac911e405e53fdd
URL:https://i3wm.org/i3lock/
BuildRequires:  cairo-devel >= 1.14.4
BuildRequires:  libev-devel
BuildRequires:  libxcb-devel
BuildRequires:  meson >= 0.45.0
BuildRequires:  ninja
BuildRequires:  pam-devel
BuildRequires:  pkgconfig
BuildRequires:  rpmbuild(macros) >= 1.726
BuildRequires:  xcb-util-devel
BuildRequires:  xcb-util-image-devel
BuildRequires:  xcb-util-xrm-devel
BuildRequires:  xorg-lib-libxkbcommon-x11-devel
Requires:   cairo >= 1.14.4
BuildRoot:  %{tmpdir}/%{name}-%{version}-root-%(id -u -n)

%description
Minimalist screen locker based on slock.

%prep
%setup -q

%build
%meson build
%ninja_build -C build

%install
rm -rf $RPM_BUILD_ROOT
%ninja_install -C build

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(644,root,root,755)
%doc LICENSE CHANGELOG
%config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
%attr(755,root,root) %{_bindir}/i3lock
%{_mandir}/man1/i3lock.1*
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: i3lock - spec file

2023-07-11 Thread Mateusz Kocielski
Dnia Tue, Jul 11, 2023 at 01:36:19PM +0200, Jan Palus napisał(a):
> Hi,
> 
> thanks for contributing! Overall looks good. Some comments below.
> 

Hello,

 thanks for your helpful comments, below my comments and fixed version of the
spec.

> > Summary:improved screen locker
> 
> Start summary with capital letter unless it starts with a name that goes
> lower case.
>

It seems that's convention that developers made, so I kept it. Other example
is here: https://github.com/pld-linux/i3/blob/master/i3.spec#L1 . OTOH maybe
it should be changed in both places.

> > Name:   i3lock
> > Version:2.14.1
> > Release:1
> > License:BSD
> > Group:  Applications
> > Source0:https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
> > # Source0-md5:  33d4bc8256a1566fbac911e405e53fdd
> > URL:https://i3wm.org/i3lock/
> > BuildRequires:  cairo-devel
> 
> cairo is required with version at least 1.14.4.

Fixed, thanks.

> > BuildRequires:  libev-devel
> > BuildRequires:  libxcb-devel
> > BuildRequires:  meson >= 0.45.0
> > BuildRequires:  ninja
> > BuildRequires:  pam-devel
> > BuildRequires:  pkgconfig
> > BuildRequires:  xcb-util-devel
> > BuildRequires:  xcb-util-image-devel
> > BuildRequires:  xcb-util-xrm-devel
> > BuildRequires:  xorg-lib-libX11-devel
> 
> Can't see direct dependency on xorg-lib-libX11-devel.

You're right, removed. Did you catch that manually?

> > BuildRequires:  xorg-lib-libxkbcommon-x11-devel
> > BuildRequires:  rpmbuild(macros) >= 1.726
> 
> Keep it sorted and use tabs instead (run adapter script).

That's interesting, I ran this script before sending it to the mailing list.
I'll investigate it later, for now I fixed it manually.
 
> > Requires:   libxcb
> > Requires:   pam
> > Requires:   xcb-util
> > Requires:   xcb-util-image
> > Requires:   xcb-util-xrm
> > Requires:   xorg-lib-libxkbcommon-x11
> 
> No need to give explicit Requires: for libraries linked to main binary
> unless specific version is required (like in case of cair).
> 

Makes sense, fixed.

> > BuildRoot:  %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
> > 
> > %description
> > Minimalist screen locker based on slock.
> > 
> > %prep
> > %setup -q
> > 
> > %build
> > %meson build
> > %ninja_build -C build
> 
> For additional BuildRequires: check:
> 
> http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/PLD-doc/BuildRequires.txt
> > 
> > %install
> > rm -rf $RPM_BUILD_ROOT
> > %ninja_install -C build
> > 
> > %clean
> > rm -rf $RPM_BUILD_ROOT
> > 
> > %files
> > %defattr(644,root,root,755)
> 
> LICENSE states it needs to be distributed with binaries so include it in
> %doc.
> 

Good catch, thanks! Fixed.

> > %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
> > %attr(4755,root,wheel) %{_bindir}/i3lock
> 
> That's peculiar -- what screen locker needs suid bit for? Why wheel
> group?

Wheel group is taken from my BSD heritage I guess, fixed it. :) It requires
PAM for an authentication.

> > %{_mandir}/man1/i3lock.1*

 Thanks,
 Mateusz
Summary:improved screen locker
Name:   i3lock
Version:2.14.1
Release:1
License:BSD
Group:  Applications
Source0:https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
# Source0-md5:  33d4bc8256a1566fbac911e405e53fdd
URL:https://i3wm.org/i3lock/
BuildRequires:  cairo-devel >= 1.14.4
BuildRequires:  libev-devel
BuildRequires:  libxcb-devel
BuildRequires:  meson >= 0.45.0
BuildRequires:  ninja
BuildRequires:  pam-devel
BuildRequires:  pkgconfig
BuildRequires:  rpmbuild(macros) >= 1.726
BuildRequires:  xcb-util-devel
BuildRequires:  xcb-util-image-devel
BuildRequires:  xcb-util-xrm-devel
BuildRequires:  xorg-lib-libxkbcommon-x11-devel
Requires:   cairo >= 1.14.4
BuildRoot:  %{tmpdir}/%{name}-%{version}-root-%(id -u -n)

%description
Minimalist screen locker based on slock.

%prep
%setup -q

%build
%meson build
%ninja_build -C build

%install
rm -rf $RPM_BUILD_ROOT
%ninja_install -C build

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(644,root,root,755)
%doc LICENSE CHANGELOG
%config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
%attr(4755,root,root) %{_bindir}/i3lock
%{_mandir}/man1/i3lock.1*
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: i3lock - spec file

2023-07-11 Thread Jan Palus
Hi,

thanks for contributing! Overall looks good. Some comments below.

On 11.07.2023 10:29, Mateusz Kocielski wrote:
> Hi there,
> 
>  I've prepared spec file to build i3lock [1]. This is my first spec file, so
> please review it carefully. The software requires suid to be able to verify
> password provided by user.
> 
> [1] - https://i3wm.org/i3lock/
> 
>  Thanks,
>  Mateusz

> Summary:  improved screen locker

Start summary with capital letter unless it starts with a name that goes
lower case.

> Name: i3lock
> Version:  2.14.1
> Release:  1
> License:  BSD
> Group:Applications
> Source0:  https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
> # Source0-md5:33d4bc8256a1566fbac911e405e53fdd
> URL:  https://i3wm.org/i3lock/
> BuildRequires:cairo-devel

cairo is required with version at least 1.14.4.

> BuildRequires:libev-devel
> BuildRequires:libxcb-devel
> BuildRequires:meson >= 0.45.0
> BuildRequires:ninja
> BuildRequires:pam-devel
> BuildRequires:pkgconfig
> BuildRequires:xcb-util-devel
> BuildRequires:xcb-util-image-devel
> BuildRequires:xcb-util-xrm-devel
> BuildRequires:xorg-lib-libX11-devel

Can't see direct dependency on xorg-lib-libX11-devel.

> BuildRequires:xorg-lib-libxkbcommon-x11-devel
> BuildRequires:  rpmbuild(macros) >= 1.726

Keep it sorted and use tabs instead (run adapter script).

> Requires: libxcb
> Requires: pam
> Requires: xcb-util
> Requires: xcb-util-image
> Requires: xcb-util-xrm
> Requires: xorg-lib-libxkbcommon-x11

No need to give explicit Requires: for libraries linked to main binary
unless specific version is required (like in case of cair).

> BuildRoot:%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
> 
> %description
> Minimalist screen locker based on slock.
> 
> %prep
> %setup -q
> 
> %build
> %meson build
> %ninja_build -C build

For additional BuildRequires: check:

http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/PLD-doc/BuildRequires.txt
> 
> %install
> rm -rf $RPM_BUILD_ROOT
> %ninja_install -C build
> 
> %clean
> rm -rf $RPM_BUILD_ROOT
> 
> %files
> %defattr(644,root,root,755)

LICENSE states it needs to be distributed with binaries so include it in
%doc.

> %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
> %attr(4755,root,wheel) %{_bindir}/i3lock

That's peculiar -- what screen locker needs suid bit for? Why wheel
group?

> %{_mandir}/man1/i3lock.1*

> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Wrong time (Re: DISTFILES: freetype: freetype-2.13.1.tar.xz freetype-doc-2.13.1.tar.xz ft2demos-2.13.1.tar.xz)

2023-06-30 Thread Jan Palus
On 26.06.2023 10:38, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> On 26.06.2023 10:31, atler wrote:
> > On 26.06.2023 11:24, atler wrote:
> > > Request by: atler
> > > 
> > > 
> > > Files fetched: 1
> > > 
> > > ALREADY GOT: 
> > > https://download.savannah.gnu.org/releases/freetype/freetype-2.13.1.tar.xz
> > >   e4c3f0d8453a2a7993ae784912d6f19a  freetype-2.13.1.tar.xz
> > > STORED: 
> > > https://download.savannah.gnu.org/releases/freetype/freetype-doc-2.13.1.tar.xz
> > >   9eaaf193b0493297d92cd435cd850598  freetype-doc-2.13.1.tar.xz
> > >   Size: 2173864 bytes
> > > ALREADY GOT: 
> > > https://download.savannah.gnu.org/releases/freetype/ft2demos-2.13.1.tar.xz
> > >   d76ec9572d018591a502bfdce312010f  ft2demos-2.13.1.tar.xz
> > > 
> > Not that it bothers me much but looks like it was "11:24 CEST"
> > somewhere while it should have been "10:17 CEST":
> 
> Fixed date (on cvs...)

Looks like there is still some issue:

Received: from cvs.pld-linux.org (cvs.pld-linux.org [217.73.31.16])
by lists.pld-linux.org (Postfix) with ESMTPS
for ;
Fri, 30 Jun 2023 09:29:39 +0200 (CEST)
^^
Received: from git by cvs.pld-linux.org with local (Exim 4.96)
(envelope-from ) id 1qF9gp-0008Hm-0m
for pld-cvs-com...@lists.pld-linux.org;
Fri, 30 Jun 2023 10:41:15 +0200
^^^
To: pld-cvs-com...@lists.pld-linux.org
From: atler 
Subject: [packages/php] icu rebuild
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Wrong time (Re: DISTFILES: freetype: freetype-2.13.1.tar.xz freetype-doc-2.13.1.tar.xz ft2demos-2.13.1.tar.xz)

2023-06-26 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 26.06.2023 10:31, atler wrote:

On 26.06.2023 11:24, atler wrote:

Request by: atler


Files fetched: 1

ALREADY GOT: 
https://download.savannah.gnu.org/releases/freetype/freetype-2.13.1.tar.xz
e4c3f0d8453a2a7993ae784912d6f19a  freetype-2.13.1.tar.xz
STORED: 
https://download.savannah.gnu.org/releases/freetype/freetype-doc-2.13.1.tar.xz
9eaaf193b0493297d92cd435cd850598  freetype-doc-2.13.1.tar.xz
Size: 2173864 bytes
ALREADY GOT: 
https://download.savannah.gnu.org/releases/freetype/ft2demos-2.13.1.tar.xz
d76ec9572d018591a502bfdce312010f  ft2demos-2.13.1.tar.xz


Not that it bothers me much but looks like it was "11:24 CEST"
somewhere while it should have been "10:17 CEST":


Fixed date (on cvs...)

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Wrong time (Re: DISTFILES: freetype: freetype-2.13.1.tar.xz freetype-doc-2.13.1.tar.xz ft2demos-2.13.1.tar.xz)

2023-06-26 Thread atler
On 26.06.2023 11:24, atler wrote:
> Request by: atler
> 
> 
> Files fetched: 1
> 
> ALREADY GOT: 
> https://download.savannah.gnu.org/releases/freetype/freetype-2.13.1.tar.xz
>   e4c3f0d8453a2a7993ae784912d6f19a  freetype-2.13.1.tar.xz
> STORED: 
> https://download.savannah.gnu.org/releases/freetype/freetype-doc-2.13.1.tar.xz
>   9eaaf193b0493297d92cd435cd850598  freetype-doc-2.13.1.tar.xz
>   Size: 2173864 bytes
> ALREADY GOT: 
> https://download.savannah.gnu.org/releases/freetype/ft2demos-2.13.1.tar.xz
>   d76ec9572d018591a502bfdce312010f  ft2demos-2.13.1.tar.xz
> 
Not that it bothers me much but looks like it was "11:24 CEST"
somewhere while it should have been "10:17 CEST":

> Received: from cvs.pld-linux.org (cvs.pld-linux.org [217.73.31.16])
> by lists.pld-linux.org (Postfix) with ESMTPS
> for ;
> Mon, 26 Jun 2023 10:17:03 +0200 (CEST)
> Received: from dfadm by cvs.pld-linux.org with local (Exim 4.96)
> (envelope-from ) id 1qDiSo-00048g-2T
> for pld-cvs-com...@lists.pld-linux.org;
> Mon, 26 Jun 2023 11:24:50 +0200
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Inconsistent repo metadata

2023-06-24 Thread Jan Rękorajski
On Sat, 24 Jun 2023, Jan Palus wrote:

> $ dnf clean all
> $ dnf download rpm-whiteout
> PLD Linux (Th) - Architecture specific
>   16 MB/s |  17 MB 00:01
> PLD Linux (Th) - Architecture independent 
>   13 MB/s |  17 MB 00:01
> Last metadata expiration check: 0:00:05 ago on sob, 24 cze 2023, 20:55:11.
> [MIRROR] rpm-whiteout-1.41-4.noarch.rpm: Interrupted by header callback: 
> Inconsistent server data, reported file Content-Length: 4738, repository 
> metadata states file length: 4610 (please report to repository maintainer)
> [MIRROR] rpm-whiteout-1.41-4.noarch.rpm: Interrupted by header callback: 
> Inconsistent server data, reported file Content-Length: 4738, repository 
> metadata states file length: 4610 (please report to repository maintainer)
> [MIRROR] rpm-whiteout-1.41-4.noarch.rpm: Interrupted by header callback: 
> Inconsistent server data, reported file Content-Length: 4738, repository 
> metadata states file length: 4610 (please report to repository maintainer)
> [MIRROR] rpm-whiteout-1.41-4.noarch.rpm: Interrupted by header callback: 
> Inconsistent server data, reported file Content-Length: 4738, repository 
> metadata states file length: 4610 (please report to repository maintainer)
> [FAILED] rpm-whiteout-1.41-4.noarch.rpm: No more mirrors to try - All mirrors 
> were already tried without success   

Weird. I had to delete repodata and regenerate it from scratch.
Works now.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: remmina not working after llvm upgrade

2023-05-26 Thread Andrzej Zawadzki
   On 26.05.2023 02:18, Jan Palus wrote:

On 25.05.2023 15:41, Krzysztof Mrozowicz via pld-devel-en wrote:

Dnia 2023-05-25, o godz. 14:59:56
Jan Palus [1] napisal/(a):


   Yes, that's after reboot. Could be Mesa, it's upgraded too..

Do you mind sharing output (remmina.strace) of:

strace -o remmina.strace -f -e '/open.*' -z remmina

I observe a similar problem on my computer. The strace file can be
found at [2]https://pastebin.com/KuXzXaYP

Thank you both for sharing strace output. Can you try upgrading
SPIRV-LLVM-Translator* spirv-tools* and Mesa* and see if it helps?

   Works

   Thanks! Now I can log into my favorite OS ;-)

   --

   Andrzej Zawadzki

References

   1. mailto:at...@pld-linux.org
   2. https://pastebin.com/KuXzXaYP
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: remmina not working after llvm upgrade

2023-05-25 Thread Jan Palus
On 25.05.2023 15:41, Krzysztof Mrozowicz via pld-devel-en wrote:
> Dnia 2023-05-25, o godz. 14:59:56
> Jan Palus  napisał(a):
> 
> > > 
> > >Yes, that's after reboot. Could be Mesa, it's upgraded too..  
> > 
> > Do you mind sharing output (remmina.strace) of:
> > 
> > strace -o remmina.strace -f -e '/open.*' -z remmina
> 
> I observe a similar problem on my computer. The strace file can be
> found at https://pastebin.com/KuXzXaYP

Thank you both for sharing strace output. Can you try upgrading
SPIRV-LLVM-Translator* spirv-tools* and Mesa* and see if it helps?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: remmina not working after llvm upgrade

2023-05-25 Thread Krzysztof Mrozowicz via pld-devel-en
Dnia 2023-05-25, o godz. 14:59:56
Jan Palus  napisał(a):

> > 
> >Yes, that's after reboot. Could be Mesa, it's upgraded too..  
> 
> Do you mind sharing output (remmina.strace) of:
> 
> strace -o remmina.strace -f -e '/open.*' -z remmina

I observe a similar problem on my computer. The strace file can be
found at https://pastebin.com/KuXzXaYP

Regards


-- 
Krzysiek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: remmina not working after llvm upgrade

2023-05-25 Thread Jan Palus
On 25.05.2023 13:14, Andrzej Zawadzki wrote:
>On 25.05.2023 12:35, Jan Palus wrote:
> 
> On 25.05.2023 12:04, Andrzej Zawadzki wrote:
> 
>Hi!
> 
>$ remmina
>** Message: 11:54:59.423: Remmina does not log all output statements.
>Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an
>environment variable.
>More info available on the Remmina wiki at:
>[1][1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging
>Load modules from /usr/lib64/remmina/plugins
>Remmina plugin glibsecret (type=Secret) has been registered, but is not
>yet initialized/activated. The initialization order is 2000.
>The glibsecret secret plugin has been initialized and it will be your
>default secret plugin
>(org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227:
>gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
>: CommandLine Error: Option 'use-dbg-addr' registered more than once!
>LLVM ERROR: inconsistency in registered CommandLine options
>Aborted (core dumped)
>Rebuild needed?
> 
> Works fine for me. I doubt Remmina has anything to do with LLVM
> directly so rebuild wouldn't change anything. Judging by Google results
> this could possibly be coming from a Mesa driver. Did you restart your
> GUI session (X/Wayland) after an upgrade to make sure new driver is
> running?
> 
>Yes, that's after reboot. Could be Mesa, it's upgraded too..

Do you mind sharing output (remmina.strace) of:

strace -o remmina.strace -f -e '/open.*' -z remmina
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: remmina not working after llvm upgrade

2023-05-25 Thread Andrzej Zawadzki
   On 25.05.2023 12:35, Jan Palus wrote:

On 25.05.2023 12:04, Andrzej Zawadzki wrote:

   Hi!

   $ remmina
   ** Message: 11:54:59.423: Remmina does not log all output statements.
   Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an
   environment variable.
   More info available on the Remmina wiki at:
   [1][1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging
   Load modules from /usr/lib64/remmina/plugins
   Remmina plugin glibsecret (type=Secret) has been registered, but is not
   yet initialized/activated. The initialization order is 2000.
   The glibsecret secret plugin has been initialized and it will be your
   default secret plugin
   (org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227:
   gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
   : CommandLine Error: Option 'use-dbg-addr' registered more than once!
   LLVM ERROR: inconsistency in registered CommandLine options
   Aborted (core dumped)
   Rebuild needed?

Works fine for me. I doubt Remmina has anything to do with LLVM
directly so rebuild wouldn't change anything. Judging by Google results
this could possibly be coming from a Mesa driver. Did you restart your
GUI session (X/Wayland) after an upgrade to make sure new driver is
running?

   Yes, that's after reboot. Could be Mesa, it's upgraded too..

   --

   Andrzej Zawadzki

References

   1. https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: remmina not working after llvm upgrade

2023-05-25 Thread Jan Palus
On 25.05.2023 12:04, Andrzej Zawadzki wrote:
>Hi!
> 
>$ remmina
>** Message: 11:54:59.423: Remmina does not log all output statements.
>Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an
>environment variable.
>More info available on the Remmina wiki at:
>[1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging
>Load modules from /usr/lib64/remmina/plugins
>Remmina plugin glibsecret (type=Secret) has been registered, but is not
>yet initialized/activated. The initialization order is 2000.
>The glibsecret secret plugin has been initialized and it will be your
>default secret plugin
>(org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227:
>gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
>: CommandLine Error: Option 'use-dbg-addr' registered more than once!
>LLVM ERROR: inconsistency in registered CommandLine options
>Aborted (core dumped)
>Rebuild needed?

Works fine for me. I doubt Remmina has anything to do with LLVM
directly so rebuild wouldn't change anything. Judging by Google results
this could possibly be coming from a Mesa driver. Did you restart your
GUI session (X/Wayland) after an upgrade to make sure new driver is
running?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Qt packaging

2023-03-25 Thread Jakub Bogusz
On Fri, Jul 22, 2022 at 11:03:54AM +0200, Jan Rękorajski wrote:
> Can someone explain why are we using split sources/packages for Qt?

Beside build time and space requirements, I see one more reason now:
rebuilding after dependent package soname change is more painful.

Current case: jasper 3.x.
Split case: just qt5-qtimageformats.spec to rebuild
Monolithic case: whole qt6.spec to rebuild


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: GitHub key needs an update

2023-03-24 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 24.03.2023 12:42, Jan Palus wrote:


That's expected and GitHub host key needs an update, see:
https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/


Updated.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/rpm-pld-macros] Add _metainfodir, rev 2.023

2023-02-22 Thread Elan Ruusamäe


On 22.02.2023 21:38, Jan Palus wrote:

On 22.02.2023 19:55, glen wrote:

commit fa6a978633bd3fbae3c510fb6299ddb67af8da00
Author: Elan Ruusamäe 
Date:   Wed Feb 22 20:54:40 2023 +0200

 Add _metainfodir, rev 2.023
 
 - https://src.fedoraproject.org/rpms/redhat-rpm-config/c/67e46b630d5d0bc74188b2ea5aa36eff5117ddc9?branch=f27

...

--- a/macros.pld
+++ b/macros.pld
@@ -25,6 +25,8 @@
  %_lispdir %{_datadir}/emacs/site-lisp
  %_initddir%{_sysconfdir}/rc.d/init.d
  
+%_metainfodir	%{_datadir}/appdata

Shouldn't this point to non-legacy %{_datadir}/metainfo instead?

https://freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location


changed:

- 
https://github.com/pld-linux/rpm-pld-macros/commit/d242d4da01feb055dbbc7187712e200e07022488


___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/rpm-pld-macros] Add _metainfodir, rev 2.023

2023-02-22 Thread Jan Palus
On 22.02.2023 19:55, glen wrote:
> commit fa6a978633bd3fbae3c510fb6299ddb67af8da00
> Author: Elan Ruusamäe 
> Date:   Wed Feb 22 20:54:40 2023 +0200
> 
> Add _metainfodir, rev 2.023
> 
> - 
> https://src.fedoraproject.org/rpms/redhat-rpm-config/c/67e46b630d5d0bc74188b2ea5aa36eff5117ddc9?branch=f27
...
> --- a/macros.pld
> +++ b/macros.pld
> @@ -25,6 +25,8 @@
>  %_lispdir%{_datadir}/emacs/site-lisp
>  %_initddir   %{_sysconfdir}/rc.d/init.d
>  
> +%_metainfodir%{_datadir}/appdata

Shouldn't this point to non-legacy %{_datadir}/metainfo instead?

https://freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location

Perhaps _appdatadir for legacy locations.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/texlive/TEXLIVE_20080816] fix "sh: syntax error: unexpected '('" during file processing

2023-02-13 Thread Elan Ruusamäe

On 30.01.2023 14:26, atler wrote:

-%define_noautoreq 'perl(path_tre)'
+%define_noautoreq perl\\(path_tre\\)



just use _noautoreq_perl


___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: lists test

2023-02-08 Thread Łukasz Jernaś
W dniu wt., 7.02.2023 o 21:37 Arkadiusz Miśkiewicz via pld-devel-en <
pld-devel-en@lists.pld-linux.org> napisał(a):

> 123...



Nope, doesn't work.

-- 
Łukasz [Deejay1] Jernaś
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: lists test

2023-02-07 Thread Peri Noid
Dnia wtorek, 7 lutego 2023 21:37:29 CET Arkadiusz Miśkiewicz via pld-devel-en 
pisze:
> 123...

Seems to work.
-- 
Łukasz Maśko_o)
Lukasz.Masko(at)ipipan.waw.pl   /\\
Registered Linux User #61028   _\_V
Ubuntu: staroafrykańskie słowo oznaczające "Nie umiem zainstalować Debiana"



___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: rust on carme-x32

2023-01-21 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 20.01.2023 22:04, Jakub Bogusz wrote:

On Thu, Jan 19, 2023 at 09:14:51AM +0100, Arkadiusz Miśkiewicz via pld-devel-en 
wrote:

On 18.01.2023 16:08, Jakub Bogusz wrote:

Could rust be installed on carme-x32?

I'd like to (try to) fix mozjs102 build (required for new gjs), but
I cannot install rust myself because of x86_64 packages requirements.




Should be available now.


I need cargo as well (requires 64-bit curl, libgit2 and openssl libs).


Installed.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: rust on carme-x32

2023-01-20 Thread Jakub Bogusz
On Thu, Jan 19, 2023 at 09:14:51AM +0100, Arkadiusz Miśkiewicz via pld-devel-en 
wrote:
> On 18.01.2023 16:08, Jakub Bogusz wrote:
> >Could rust be installed on carme-x32?
> >
> >I'd like to (try to) fix mozjs102 build (required for new gjs), but
> >I cannot install rust myself because of x86_64 packages requirements.
> >
> >
> 
> Should be available now.

I need cargo as well (requires 64-bit curl, libgit2 and openssl libs).


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: rust on carme-x32

2023-01-19 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 18.01.2023 16:08, Jakub Bogusz wrote:

Could rust be installed on carme-x32?

I'd like to (try to) fix mozjs102 build (required for new gjs), but
I cannot install rust myself because of x86_64 packages requirements.




Should be available now.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: x32 builder has network access

2023-01-18 Thread Jan Palus
On 18.01.2023 16:48, Jakub Bogusz wrote:
> On Wed, Jan 18, 2023 at 01:02:34PM +0100, Arkadiusz Miśkiewicz via 
> pld-devel-en wrote:
> > On 18.01.2023 09:56, Jan Palus wrote:
> > >On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> > >>On 17.01.2023 12:23, Jan Palus wrote:
> > >>>Noticed during build of kodi-addon-inputstream-adaptive that contrary to
> > >>>x86_64 and i686, x32 builder downloaded external sources successfully:
> > >>
> > >>bind was installed there and seems that even if there is no access to
> > >>/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53
> > >>
> > >>Uninstalled.
> > >>
> > >>The best would be to change UID of "builder" user used inside of chroot
> > >>and drop all outgoing packets coming from it at iptables level.
> > >
> > >Or perhaps modify pld-builder to make each rpmbuild invocation in a new
> > >network namespace via `unshare -n -c`. That would effectively cut whole
> > >network for the process.
> > 
> > We can try that... commited.
> 
> i686 and x86_64 say:
> "unshare: unshare failed: Operation not permitted"

Unfortunately it appears it's not possible to create user namespaces in
a chroot:

   EPERM (since Linux 3.9)
  CLONE_NEWUSER was specified in flags and the caller is in a 
chroot environment
  (i.e., the caller's root directory does not match the root  
directory  of  the
  mount namespace in which it resides).
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: x32 builder has network access

2023-01-18 Thread Jakub Bogusz
On Wed, Jan 18, 2023 at 01:02:34PM +0100, Arkadiusz Miśkiewicz via pld-devel-en 
wrote:
> On 18.01.2023 09:56, Jan Palus wrote:
> >On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> >>On 17.01.2023 12:23, Jan Palus wrote:
> >>>Noticed during build of kodi-addon-inputstream-adaptive that contrary to
> >>>x86_64 and i686, x32 builder downloaded external sources successfully:
> >>
> >>bind was installed there and seems that even if there is no access to
> >>/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53
> >>
> >>Uninstalled.
> >>
> >>The best would be to change UID of "builder" user used inside of chroot
> >>and drop all outgoing packets coming from it at iptables level.
> >
> >Or perhaps modify pld-builder to make each rpmbuild invocation in a new
> >network namespace via `unshare -n -c`. That would effectively cut whole
> >network for the process.
> 
> We can try that... commited.

i686 and x86_64 say:
"unshare: unshare failed: Operation not permitted"

Still waiting for x32 (seems busy with openjdks).


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: x32 builder has network access

2023-01-18 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 18.01.2023 09:56, Jan Palus wrote:

On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote:

On 17.01.2023 12:23, Jan Palus wrote:

Noticed during build of kodi-addon-inputstream-adaptive that contrary to
x86_64 and i686, x32 builder downloaded external sources successfully:


bind was installed there and seems that even if there is no access to
/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53

Uninstalled.

The best would be to change UID of "builder" user used inside of chroot
and drop all outgoing packets coming from it at iptables level.


Or perhaps modify pld-builder to make each rpmbuild invocation in a new
network namespace via `unshare -n -c`. That would effectively cut whole
network for the process.


We can try that... commited.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: x32 builder has network access

2023-01-18 Thread Jan Palus
On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> On 17.01.2023 12:23, Jan Palus wrote:
> > Noticed during build of kodi-addon-inputstream-adaptive that contrary to
> > x86_64 and i686, x32 builder downloaded external sources successfully:
> 
> bind was installed there and seems that even if there is no access to
> /etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53
> 
> Uninstalled.
> 
> The best would be to change UID of "builder" user used inside of chroot
> and drop all outgoing packets coming from it at iptables level.

Or perhaps modify pld-builder to make each rpmbuild invocation in a new
network namespace via `unshare -n -c`. That would effectively cut whole
network for the process.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: x32 builder has network access

2023-01-17 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 17.01.2023 12:23, Jan Palus wrote:

Noticed during build of kodi-addon-inputstream-adaptive that contrary to
x86_64 and i686, x32 builder downloaded external sources successfully:


bind was installed there and seems that even if there is no access to 
/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53


Uninstalled.

The best would be to change UID of "builder" user used inside of chroot
and drop all outgoing packets coming from it at iptables level.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: udev-core R >= 4.15

2022-12-22 Thread Jan Palus
On 22.12.2022 11:49, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> udev-core change:
> 
> -Requires:  uname(release) >= 3.13
> +Requires:  uname(release) >= 4.15
> 
> 
> Is this true requirement?

This R: was updated purely based on very first entry in release notes for 251:

Backwards-incompatible changes:

* The minimum kernel version required has been bumped from 3.13 to 4.15,
  and CLOCK_BOOTTIME is now assumed to always exist.

If it actually works with lower kernel versions feel free to adjust.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz

2022-10-31 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 30.10.2022 18:08, Jan Palus wrote:

On 24.10.2022 09:17, Jan Palus wrote:

On 24.10.2022 09:13, atler wrote:

Request by: atler

wget -nv --no-iri --user-agent=PLD/distfiles -O 
./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz
 
https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz:
Cannot write to 
???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz???
 (Success).


Can someone have a look what's that about? Noticed it before for larger
sources like firefox but usually retry succeeded. qt6 on the other hand
fails consistently.


Also fails with `dropin` script after transferring ~264M:

firefox-106.0.2.source.tar.xz54%  264MB   5.1MB/s   00:42 ETA
scp: write remote "./firefox-106.0.2.source.tar.xz": Failure
scp: failed to upload file firefox-106.0.2.source.tar.xz to .


dropin is on cvs and there was no free space there. Added some.

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz

2022-10-30 Thread Jan Palus
On 24.10.2022 09:17, Jan Palus wrote:
> On 24.10.2022 09:13, atler wrote:
> > Request by: atler
> > 
> > wget -nv --no-iri --user-agent=PLD/distfiles -O 
> > ./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz
> >  
> > https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz:
> > Cannot write to 
> > ???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz???
> >  (Success).
> 
> Can someone have a look what's that about? Noticed it before for larger
> sources like firefox but usually retry succeeded. qt6 on the other hand
> fails consistently.

Also fails with `dropin` script after transferring ~264M:

firefox-106.0.2.source.tar.xz54%  264MB   5.1MB/s   00:42 ETA
scp: write remote "./firefox-106.0.2.source.tar.xz": Failure
scp: failed to upload file firefox-106.0.2.source.tar.xz to .
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz

2022-10-24 Thread Jan Palus
On 24.10.2022 09:13, atler wrote:
> Request by: atler
> 
> wget -nv --no-iri --user-agent=PLD/distfiles -O 
> ./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz
>  
> https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz:
> Cannot write to 
> ???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz???
>  (Success).

Can someone have a look what's that about? Noticed it before for larger
sources like firefox but usually retry succeeded. qt6 on the other hand
fails consistently.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: pfa-signpkg resets tty echo after failed password input:

2022-10-20 Thread Elan Ruusamäe


> On 20. Oct 2022, at 15:37, Elan Ruusamäe  wrote:
> 
> 
> 
> pldth@ep09-pld SRPMS/.metadata$ pfa-signpkg test *pecl*
> Checking signatures of 164 files from 17 packages
> 164/164 
> /home/pld/admins/th/ftp/test/x86_64/debuginfo/php82-pecl-xmlrpc-debugsource-1.0.0-1.RC3.1.x86_64.rpm
> Total 164 files to sign
> Enter signing password:
> Signing 164 files
> /home/pld/admins/th/ftp/test/SRPMS/RPMS/php80-pecl-redis-5.3.7-1.src.rpm:
> gpg: signing failed: Bad passphrase
> gpg: signing failed: Bad passphrase
> error: gpg exec failed (2)
> /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm:
> Enter passphrase: lala

Also aborted sign leaves temp files around:


pldth@ep09-pld SRPMS/.metadata$ pfa-signpkg test *pecl*
Checking signatures of 164 files from 17 packages
164/164 
/home/pld/admins/th/ftp/test/x86_64/debuginfo/php82-pecl-xmlrpc-debugsource-1.0.0-1.RC3.1.x86_64.rpm
Total 164 files to sign
Enter signing password:
Signing 164 files
/home/pld/admins/th/ftp/test/SRPMS/RPMS/php80-pecl-redis-5.3.7-1.src.rpm:
/home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm:
File 
'/home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig'
 exists. Overwrite? (y/N) y

And then it seems it’s stuck, no idea what’s going on:


pldth@ep09-pld SRPMS/.metadata$ lsp gpg www
USER   PID LXC   PGRP  STARTED TT  VSZ   RSS 
STAT CMD
pldth28850 -28847 Thu Oct 20 15:37:55 2022 pts/5  8920  5124 
SL+  gpg --no-verbose --no-armor --no-secmem-warning -u e4f1bc2d -sbo 
/home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig
 -



pldth@ep09-pld SRPMS/.metadata$ l 
/home/pld/admins/th/ftp/test/x86_64/debuginfo/*.sig
-rw-r--r-- 1 pldth pldth 0 Oct 20 15:36 
/home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/python3-git-filter-repo] - new, separated from git-filter-repo.spec (now with python metadata, required for e.g. b4)

2022-10-17 Thread Jakub Bogusz
On Mon, Oct 17, 2022 at 09:14:27PM +0300, Elan Ruusamäe wrote:
> wth. how is this any good?
> 
> just add the -n python3-git-filter-repo to main git-filter-repo package!
> 
> with your package split and the require-line in old spec, you force us 
> to keep two .spec files up todate with each release of git-filter-repo, 
> additionally deal with sending to builders, and in proper order as well.
> 
> why?

github package doesn't contain metadata for python package (or data to
generate them).

pypi package doesn't contain docs for git side.

Alternative solution could be single spec with both sources.
But I didn't know the direction in which the distribution of this package
would evolve, the last release so far was almost year ago.

Now I see there is 2.38.0, I'll check it in few days.


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/python3-git-filter-repo] - new, separated from git-filter-repo.spec (now with python metadata, required for e.g. b4)

2022-10-17 Thread Elan Ruusamäe

wth. how is this any good?

just add the -n python3-git-filter-repo to main git-filter-repo package!

with your package split and the require-line in old spec, you force us 
to keep two .spec files up todate with each release of git-filter-repo, 
additionally deal with sending to builders, and in proper order as well.


why?

On 08.10.2022 21:51, qboosh wrote:

commit 61919f8f6ee682327311dfb153d2fb5474d1e622
Author: Jakub Bogusz 
Date:   Sat Oct 8 20:51:52 2022 +0200

 - new, separated from git-filter-repo.spec (now with python metadata, 
required for e.g. b4)

  python3-git-filter-repo.spec | 53 
  1 file changed, 53 insertions(+)
---
diff --git a/python3-git-filter-repo.spec b/python3-git-filter-repo.spec
new file mode 100644
index 000..b402d05
--- /dev/null
+++ b/python3-git-filter-repo.spec
@@ -0,0 +1,53 @@
+Summary:   Quickly rewrite git repository history
+Summary(pl.UTF-8): Szybkie przepisywanie historii repozytorium
+Name:  python3-git-filter-repo
+Version:   2.34.0
+Release:   1
+License:   MIT
+Group: Libraries/Python
+#Source0Download: https://pypi.org/simple/git-filter-repo/
+Source0:   
https://files.pythonhosted.org/packages/source/g/git-filter-repo/git-filter-repo-%{version}.tar.gz
+# Source0-md5: 14825e3c78de704a0244092600bf1fdc
+URL:   https://pypi.org/project/git-filter-repo/
+BuildRequires: python3-modules >= 1:3.5
+BuildRequires: python3-setuptools
+BuildRequires: python3-setuptools_scm
+BuildRequires: rpm-pythonprov
+BuildRequires: rpmbuild(macros) >= 1.714
+Requires:  git-core >= 2.24.0
+Requires:  python3-modules >= 1:3.5
+Conflicts: git-filter-repo < 2.34.0-2
+BuildArch: noarch
+BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
+
+%description
+git filter-repo is a versatile tool for rewriting history.
+
+%description -l pl.UTF-8
+git filter-repo to wszechstronne narzędzie do przepisywania historii.
+
+%prep
+%setup -q -n git-filter-repo-%{version}
+
+# fix #!/usr/bin/env python -> #!/usr/bin/python:
+%{__sed} -i -e '1s,/usr/bin/env python3,%{__python3},' git_filter_repo.py
+
+%build
+%py3_build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+%py3_install
+
+%{__rm} $RPM_BUILD_ROOT%{_bindir}/git-filter-repo
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(644,root,root,755)
+%doc README.md
+%{py3_sitescriptdir}/git_filter_repo.py
+%{py3_sitescriptdir}/__pycache__/git_filter_repo.cpython-*.py[co]
+%{py3_sitescriptdir}/git_filter_repo-%{version}-py*.egg-info


 gitweb:

http://git.pld-linux.org/gitweb.cgi/packages/python3-git-filter-repo.git/commitdiff/61919f8f6ee682327311dfb153d2fb5474d1e622

___
pld-cvs-commit mailing list
pld-cvs-com...@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: freshness report not fresh

2022-09-27 Thread Jan Rękorajski
On Sat, 24 Sep 2022, Jan Palus wrote:

> For some time now freshness report at
> http://ep09.pld-linux.org/~pldth/qa.php?q=freshness does not seem to be
> updated. Can someone have a look?

Fixed. Leftover lock in SPECS repo :/

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: %_usrlibrpm macro gone

2022-09-19 Thread Neal Gompa
On Mon, Sep 19, 2022 at 6:08 PM Elan Ruusamäe  wrote:
>
> rpm-4.17.1.1-1.x86_64
>
> dokuwiki* packages don’t build due that:
>
> ```
>
> + %{_usrlibrpm}/dokuwiki-find-lang.sh 
> /home/users/glen/tmp/dokuwiki-20180422c-x86_64-root-glen dokuwiki.lang
> /home/users/glen/tmp/rpm-tmp.oRtxaL[82]: %{_usrlibrpm}/dokuwiki-find-lang.sh: 
> inaccessible or not found
> ```
>
> What’s the replacement? Should it be restored instead?
>

%_rpmconfigdir is the official macro that points to /usr/lib/rpm.



-- 
真実はいつも一つ!/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: KDE - all form test

2022-09-14 Thread Jan Palus
On 14.09.2022 10:29, Andrzej Zawadzki wrote:
>On 14.09.2022 01:40, Krzysztof Mrozowicz via pld-devel-en wrote:
> 
> Dnia 2022-09-13, o godz. 16:15:06
> Andrzej Zawadzki [1] napisal/(a):
> 
> 
>Qt 5.15.6 - similar problem. For example kwallet doesn't work with
>NetworkManager.
> 
>Downgrade help, so looks like after Qt upgrade rebuild off all kde5
>packages will help.
> 
> I sent all ka5 and kp5 packages to rebuild. They should be done over
> the night. Kf5 were done earlier today due to their update.
> 
> 
>Works now.
> 
>But... should KDE be strictly dependent on the Qt version?
> 
>Second time when Qt update broke my KDE environment.

Ideally KDE should not have strict Qt version dependency as I suppose Qt
should not be breaking compatibility between patch releases. That's the
theory though. For example keepassxc was broken after upgrade as well
due to some missing symbol related to qt concurrent. Either Qt broke ABI
compatibility or keepassxc misused Qt API, whichever is more likely. I
didn't bother to investigate deeper. Unless someone investigates what
and why is broken in KDE and rebuilds just affected packages, I suppose
the best way forward is indeed rebuild everything each time Qt is
upgraded.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: KDE - all form test

2022-09-14 Thread Krzysztof Mrozowicz via pld-devel-en
Dnia 2022-09-14, o godz. 10:29:58
Andrzej Zawadzki  napisał(a):

> Works now.
> 
> But... should KDE be strictly dependent on the Qt version?
> 
> Second time when Qt update broke my KDE environment.

As a non-programmer, I'm guessing that KDE expects that all its
components will be build with the same QT version. The problem is that
the particular components, ka5, kf5, kp5 appear for upgrades at
different times, so if between upgrading let's say kf5 packages and kp5
packages the QT version gets changed, then the problem occurs.
I guess every QT5 upgrade should trigger rebuilding of all ka5, kf5 and
kp5 packages...

-- 
Krzysiek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: KDE - all form test

2022-09-14 Thread Andrzej Zawadzki
   On 14.09.2022 01:40, Krzysztof Mrozowicz via pld-devel-en wrote:

Dnia 2022-09-13, o godz. 16:15:06
Andrzej Zawadzki [1] napisal/(a):


   Qt 5.15.6 - similar problem. For example kwallet doesn't work with
   NetworkManager.

   Downgrade help, so looks like after Qt upgrade rebuild off all kde5
   packages will help.

I sent all ka5 and kp5 packages to rebuild. They should be done over
the night. Kf5 were done earlier today due to their update.


   Works now.

   But... should KDE be strictly dependent on the Qt version?

   Second time when Qt update broke my KDE environment.


   --

   Andrzej Zawadzki

References

   1. mailto:zawa...@gmail.com
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: KDE - all form test

2022-09-13 Thread Krzysztof Mrozowicz via pld-devel-en
Dnia 2022-09-13, o godz. 16:15:06
Andrzej Zawadzki  napisał(a):

>Qt 5.15.6 - similar problem. For example kwallet doesn't work with
>NetworkManager.
> 
>Downgrade help, so looks like after Qt upgrade rebuild off all kde5
>packages will help.

I sent all ka5 and kp5 packages to rebuild. They should be done over
the night. Kf5 were done earlier today due to their update.

-- 
Krzysiek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: KDE - all form test

2022-09-13 Thread Andrzej Zawadzki
   On 1.07.2022 19:22, Peri Noid wrote:

Dnia piatek, 1 lipca 2022 14:31:04 CEST Andrzej Zawadzki pisze:

OK Qt5 was to fresh. I found in logs:


*plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this
library (5.15.5)*

Hmm, rebuild is needed?

I did a full downgrade of Qt5 to 5.15.4 and it works - so yes, the problem is
somewhere there. We're still missing some of Qt5 packets in thre 5.15.5
version to be able to upgrade everything to this version. At least now.

   Hi!

   Qt 5.15.6 - similar problem. For example kwallet doesn't work with
   NetworkManager.

   Downgrade help, so looks like after Qt upgrade rebuild off all kde5
   packages will help.

   --

   Andrzej Zawadzki
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script

2022-08-31 Thread Elan Ruusamäe


> On 31. Aug 2022, at 13:21, Jan Rękorajski  wrote:
> 
> On Wed, Aug 31, 2022 at 11:41 AM Arkadiusz Miśkiewicz via pld-devel-en
>  wrote:
>> 
>> On 31.08.2022 11:27, Jan Rękorajski wrote:
>>> Where will it land now? If you want to protect against landing in
>>> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
>>> I really prefer to be staying in the same directory where I launched
>>> the script in.
>> 
>> Do you include (via source/dot) this script in some other script?
> 
> No, command line.
> My common workflow is cd $package; hack spec; builder ... (often with
> --short-circuit) and back to hacking.

So the working dir restore is irrelevant. As it’s in builder script, doesn’t 
affect any external shell.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script

2022-08-31 Thread Jan Rękorajski
On Wed, Aug 31, 2022 at 11:41 AM Arkadiusz Miśkiewicz via pld-devel-en
 wrote:
>
> On 31.08.2022 11:27, Jan Rękorajski wrote:
> > Where will it land now? If you want to protect against landing in
> > non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
> > I really prefer to be staying in the same directory where I launched
> > the script in.
>
> Do you include (via source/dot) this script in some other script?

No, command line.
My common workflow is cd $package; hack spec; builder ... (often with
--short-circuit) and back to hacking.

-- 
Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script

2022-08-31 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 31.08.2022 11:27, Jan Rękorajski wrote:

Where will it land now? If you want to protect against landing in
non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
I really prefer to be staying in the same directory where I launched
the script in.


Do you include (via source/dot) this script in some other script?

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script

2022-08-31 Thread Jan Palus
On 31.08.2022 11:27, Jan Rękorajski wrote:
> Where will it land now? If you want to protect against landing in
> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
> I really prefer to be staying in the same directory where I launched
> the script in.

I considered doing `test -d` but since this new old $PWD doesn't affect
any other command I've just dropped it entirely. I will bring it back
with test then.

> On Wed, Aug 31, 2022 at 12:59 AM atler  wrote:
> >
> > commit b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> > Author: Jan Palus 
> > Date:   Wed Aug 31 00:55:46 2022 +0200
> >
> > builder: don't bother going back to original $(pwd) at the end of script
> >
> > no real use for it as far as I can tell and ditching it avoids error if
> > original working directory does not exist anymore (because ie it
> > happened to be $RPM_BUILD_ROOT)
> >
> >  builder.sh | 1 -
> >  1 file changed, 1 deletion(-)
> > ---
> > diff --git a/builder.sh b/builder.sh
> > index 058d0de..68bb875 100755
> > --- a/builder.sh
> > +++ b/builder.sh
> > @@ -2756,6 +2756,5 @@ esac
> >  if [ -f "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES" -a 
> > "$REMOVE_BUILD_REQUIRES" != "" ]; then
> > rm "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES"
> >  fi
> > -cd "$__PWD"
> >
> >  # vi:syntax=sh:ts=4:sw=4:noet
> > 
> >
> >  gitweb:
> >
> > http://git.pld-linux.org/gitweb.cgi/packages/rpm-build-tools.git/commitdiff/b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> >
> > ___
> > pld-cvs-commit mailing list
> > pld-cvs-com...@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
> 
> 
> 
> -- 
> Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> bagginspld-linux.org
> ___
> pld-devel-pl mailing list
> pld-devel...@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script

2022-08-31 Thread Jan Rękorajski
Where will it land now? If you want to protect against landing in
non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
I really prefer to be staying in the same directory where I launched
the script in.

On Wed, Aug 31, 2022 at 12:59 AM atler  wrote:
>
> commit b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> Author: Jan Palus 
> Date:   Wed Aug 31 00:55:46 2022 +0200
>
> builder: don't bother going back to original $(pwd) at the end of script
>
> no real use for it as far as I can tell and ditching it avoids error if
> original working directory does not exist anymore (because ie it
> happened to be $RPM_BUILD_ROOT)
>
>  builder.sh | 1 -
>  1 file changed, 1 deletion(-)
> ---
> diff --git a/builder.sh b/builder.sh
> index 058d0de..68bb875 100755
> --- a/builder.sh
> +++ b/builder.sh
> @@ -2756,6 +2756,5 @@ esac
>  if [ -f "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES" -a "$REMOVE_BUILD_REQUIRES" 
> != "" ]; then
> rm "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES"
>  fi
> -cd "$__PWD"
>
>  # vi:syntax=sh:ts=4:sw=4:noet
> 
>
>  gitweb:
>
> http://git.pld-linux.org/gitweb.cgi/packages/rpm-build-tools.git/commitdiff/b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
>
> ___
> pld-cvs-commit mailing list
> pld-cvs-com...@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit



-- 
Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: glibc 2.36 *.o files debug extraction broken

2022-08-16 Thread Jan Palus
On 16.08.2022 21:53, Jakub Bogusz wrote:
> On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote:
> > On 16.08.2022 20:31, Jakub Bogusz wrote:
> > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack
> > > section:
> > 
> > ...
> > 
> > > For now only i686 builds are affected because x86_64 and x32 glibc-devel 
> > > packages
> > > haven't been updated on builders.
> > > 
> > > 
> > > Any guesses what changed?
> > 
> > I believe to be responsible for this, specifically with this debugedit
> > commit:
> > 
> > commit bd392272c04d608257eb999670d85261d5125d93
> > Author: Jan Palus 
> > Date:   Tue Jun 7 11:39:01 2022
> > 
> > bring back patch from rpm 4.16 for no exe bit when searching debuginfo; 
> > rel 2
> > 
> > which now considers non-executable object file matching pattern
> > found in `find-debuginfo`: ^\(.*\):[   ]*.*ELF.*, not stripped.*
> > 
> > Which in turn causes object file to be passed to `eu-strip` directly
> > responsible for stripping .note.GNU-stack section.
> > 
> > Fix proposals:
> > 
> > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared 
> > object\)
> > 2. modify macros to invoke `find-debuginfo` with `--keep-section 
> > .note.GNU-stack`
> > 3. both 1 and 2
> 
> I think it would be safer to revert to not touching *.o files (by
> default).

For the time being implemented 1. not to regress packages initial fix
was done for.

> BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove
> from *.a/*.so?

To be precise it's eu-strip that find-debuginfo invokes. Regarding
actual question these are two different things:

object files (*.o) hold information for linker in .note.GNU-stack
section of ELF file. Linker uses this information when creating shared
objects (*.so) or executables to construct GNU_STACK program header in
output ELF file. GNU_STACK is in turn used by kernel. eu-strip does not
touch ELF program headers at all so it's plain copy. It only operates on
ELF sections. So that's why executable/so files are not affected. (note
that mentioned archives (*.a) are not considered for debuginfo
extraction).

I see a comment in elfutils strip code that intention was to keep all
ELF notes, which while implemented, does not affect .note.GNU-stack.
Most notes appear to be of type SHT_NOTE (that's what implementation
relies on) however .note.GNU-stack is of type SHT_PROGBITS (ref elf(5)).
I will raise a question to elfutils whether this is intended.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: glibc 2.36 *.o files debug extraction broken

2022-08-16 Thread Jakub Bogusz
On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote:
> On 16.08.2022 20:31, Jakub Bogusz wrote:
> > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack
> > section:
> 
> ...
> 
> > For now only i686 builds are affected because x86_64 and x32 glibc-devel 
> > packages
> > haven't been updated on builders.
> > 
> > 
> > Any guesses what changed?
> 
> I believe to be responsible for this, specifically with this debugedit
> commit:
> 
> commit bd392272c04d608257eb999670d85261d5125d93
> Author: Jan Palus 
> Date:   Tue Jun 7 11:39:01 2022
> 
> bring back patch from rpm 4.16 for no exe bit when searching debuginfo; 
> rel 2
> 
> which now considers non-executable object file matching pattern
> found in `find-debuginfo`: ^\(.*\):[   ]*.*ELF.*, not stripped.*
> 
> Which in turn causes object file to be passed to `eu-strip` directly
> responsible for stripping .note.GNU-stack section.
> 
> Fix proposals:
> 
> 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared 
> object\)
> 2. modify macros to invoke `find-debuginfo` with `--keep-section 
> .note.GNU-stack`
> 3. both 1 and 2

I think it would be safer to revert to not touching *.o files (by
default).

BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove
from *.a/*.so?


-- 
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: glibc 2.36 *.o files debug extraction broken

2022-08-16 Thread Jan Palus
On 16.08.2022 20:31, Jakub Bogusz wrote:
> In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack
> section:

...

> For now only i686 builds are affected because x86_64 and x32 glibc-devel 
> packages
> haven't been updated on builders.
> 
> 
> Any guesses what changed?

I believe to be responsible for this, specifically with this debugedit
commit:

commit bd392272c04d608257eb999670d85261d5125d93
Author: Jan Palus 
Date:   Tue Jun 7 11:39:01 2022

bring back patch from rpm 4.16 for no exe bit when searching debuginfo; rel 
2

which now considers non-executable object file matching pattern
found in `find-debuginfo`: ^\(.*\):[   ]*.*ELF.*, not stripped.*

Which in turn causes object file to be passed to `eu-strip` directly
responsible for stripping .note.GNU-stack section.

Fix proposals:

1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared object\)
2. modify macros to invoke `find-debuginfo` with `--keep-section 
.note.GNU-stack`
3. both 1 and 2

Comments welcome.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Qt packaging

2022-08-08 Thread Jan Palus
On 08.08.2022 23:34, Jan Rękorajski wrote:
> On Mon, 08 Aug 2022, Jan Palus wrote:
> 
> > On 08.08.2022 08:32, Jan Rękorajski wrote:
> > > On Fri, 22 Jul 2022, Jan Palus wrote:
> > > 
> > > > On 22.07.2022 11:03, Jan Rękorajski wrote:
> > > > > Can someone explain why are we using split sources/packages for Qt?
> > > > > 
> > > > > I want to add Qt6 and building from the monolythic source is s 
> > > > > much
> > > > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > > > configure -> build -> build docs -> install.
> > > > > 
> > > > > And unless there is a _very_ good reason to use split sources I'm 
> > > > > just going
> > > > > to add a single qt6 package that builds everything (we can still 
> > > > > subpackage
> > > > > bineries as we want them).
> > > > 
> > > > As long as each component is bcondized and there are no "to the exact
> > > > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > > > the other components) rebuild each time qtbase needs a small packaging
> > > > adjustment would be tough on arm, though I'd understand if nobody cared
> > > > about my use case.
> > > 
> > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> > > with qtwebengine.
> > > 
> > > I don't know how it looks on arm, but IMHO no-webengine bcond should be 
> > > enough?
> > 
> > Multiply it by ~4 and it's roughly result for arm. The first part I
> > mean, qtwebengine is so heavy that I build it in AWS.
> > 
> > Anyway no worries, if needed I can add more bconds myself. And thanks a
> > lot for working on qt6!
> 
> Thanks, it's a slow and painful process, and we'll end up with less
> granularity, at least at the beginning. What I want now, is a MVP to be able
> to build current calibre :/
> 
> Out of curiosity, would webengine even build on arm? What I see it
> building is full blown blink/chromium engine. And this thing has lots
> of fancy dependencies, both software and hardware.

Just to be clear when I said "arm" I really meant "aarch64", 32-bit
version of qtwebengine is of not much interest to me. And at least
qtwebengine 5.x builds just fine for aarch64 and using it daily as my
primary web browsing engine. I don't expect qt6 to be much different but
haven't tried to build it so far.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Qt packaging

2022-08-08 Thread Jan Rękorajski
On Mon, 08 Aug 2022, Jan Palus wrote:

> On 08.08.2022 08:32, Jan Rękorajski wrote:
> > On Fri, 22 Jul 2022, Jan Palus wrote:
> > 
> > > On 22.07.2022 11:03, Jan Rękorajski wrote:
> > > > Can someone explain why are we using split sources/packages for Qt?
> > > > 
> > > > I want to add Qt6 and building from the monolythic source is s much
> > > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > > configure -> build -> build docs -> install.
> > > > 
> > > > And unless there is a _very_ good reason to use split sources I'm just 
> > > > going
> > > > to add a single qt6 package that builds everything (we can still 
> > > > subpackage
> > > > bineries as we want them).
> > > 
> > > As long as each component is bcondized and there are no "to the exact
> > > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > > the other components) rebuild each time qtbase needs a small packaging
> > > adjustment would be tough on arm, though I'd understand if nobody cared
> > > about my use case.
> > 
> > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> > with qtwebengine.
> > 
> > I don't know how it looks on arm, but IMHO no-webengine bcond should be 
> > enough?
> 
> Multiply it by ~4 and it's roughly result for arm. The first part I
> mean, qtwebengine is so heavy that I build it in AWS.
> 
> Anyway no worries, if needed I can add more bconds myself. And thanks a
> lot for working on qt6!

Thanks, it's a slow and painful process, and we'll end up with less
granularity, at least at the beginning. What I want now, is a MVP to be able
to build current calibre :/

Out of curiosity, would webengine even build on arm? What I see it
building is full blown blink/chromium engine. And this thing has lots
of fancy dependencies, both software and hardware.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Qt packaging

2022-08-08 Thread Jan Palus
On 08.08.2022 08:32, Jan Rękorajski wrote:
> On Fri, 22 Jul 2022, Jan Palus wrote:
> 
> > On 22.07.2022 11:03, Jan Rękorajski wrote:
> > > Can someone explain why are we using split sources/packages for Qt?
> > > 
> > > I want to add Qt6 and building from the monolythic source is s much
> > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > configure -> build -> build docs -> install.
> > > 
> > > And unless there is a _very_ good reason to use split sources I'm just 
> > > going
> > > to add a single qt6 package that builds everything (we can still 
> > > subpackage
> > > bineries as we want them).
> > 
> > As long as each component is bcondized and there are no "to the exact
> > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > the other components) rebuild each time qtbase needs a small packaging
> > adjustment would be tough on arm, though I'd understand if nobody cared
> > about my use case.
> 
> FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> with qtwebengine.
> 
> I don't know how it looks on arm, but IMHO no-webengine bcond should be 
> enough?

Multiply it by ~4 and it's roughly result for arm. The first part I
mean, qtwebengine is so heavy that I build it in AWS.

Anyway no worries, if needed I can add more bconds myself. And thanks a
lot for working on qt6!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Qt packaging

2022-08-08 Thread Jan Rękorajski
On Mon, 08 Aug 2022, Neal Gompa wrote:

> On Mon, Aug 8, 2022 at 2:32 AM Jan Rękorajski  wrote:
> >
> > On Fri, 22 Jul 2022, Jan Palus wrote:
> >
> > > On 22.07.2022 11:03, Jan Rękorajski wrote:
> > > > Can someone explain why are we using split sources/packages for Qt?
> > > >
> > > > I want to add Qt6 and building from the monolythic source is s much
> > > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > > configure -> build -> build docs -> install.
> > > >
> > > > And unless there is a _very_ good reason to use split sources I'm just 
> > > > going
> > > > to add a single qt6 package that builds everything (we can still 
> > > > subpackage
> > > > bineries as we want them).
> > >
> > > As long as each component is bcondized and there are no "to the exact
> > > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > > the other components) rebuild each time qtbase needs a small packaging
> > > adjustment would be tough on arm, though I'd understand if nobody cared
> > > about my use case.
> >
> > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> > with qtwebengine.
> >
> > I don't know how it looks on arm, but IMHO no-webengine bcond should be 
> > enough?
> >
> 
> The reason most distros don't use the monolithic source is that it's a
> pain to apply patches to it. Qt doesn't actually get developed that
> way, and backporting fixes is more of a pain if you use the monolithic
> build.

Well, we don't have resources to play with backporting changes.
Besides I saw have ex. Fedora packages qt and it is IMO a joke. They don't
build docs, they don't build internal deps, so yeah, it's easy, but it's
half of the functionality.

I'd rather have a package without the backports, but with all bells and
whistles, that is easy to build, rather than either build pain on half
baked.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Qt packaging

2022-08-08 Thread Neal Gompa
On Mon, Aug 8, 2022 at 2:32 AM Jan Rękorajski  wrote:
>
> On Fri, 22 Jul 2022, Jan Palus wrote:
>
> > On 22.07.2022 11:03, Jan Rękorajski wrote:
> > > Can someone explain why are we using split sources/packages for Qt?
> > >
> > > I want to add Qt6 and building from the monolythic source is s much
> > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > configure -> build -> build docs -> install.
> > >
> > > And unless there is a _very_ good reason to use split sources I'm just 
> > > going
> > > to add a single qt6 package that builds everything (we can still 
> > > subpackage
> > > bineries as we want them).
> >
> > As long as each component is bcondized and there are no "to the exact
> > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > the other components) rebuild each time qtbase needs a small packaging
> > adjustment would be tough on arm, though I'd understand if nobody cared
> > about my use case.
>
> FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> with qtwebengine.
>
> I don't know how it looks on arm, but IMHO no-webengine bcond should be 
> enough?
>

The reason most distros don't use the monolithic source is that it's a
pain to apply patches to it. Qt doesn't actually get developed that
way, and backporting fixes is more of a pain if you use the monolithic
build.


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Qt packaging

2022-08-08 Thread Jan Rękorajski
On Fri, 22 Jul 2022, Jan Palus wrote:

> On 22.07.2022 11:03, Jan Rękorajski wrote:
> > Can someone explain why are we using split sources/packages for Qt?
> > 
> > I want to add Qt6 and building from the monolythic source is s much
> > easier. No need for bootstrap, no intertwined build dependencies, just
> > configure -> build -> build docs -> install.
> > 
> > And unless there is a _very_ good reason to use split sources I'm just going
> > to add a single qt6 package that builds everything (we can still subpackage
> > bineries as we want them).
> 
> As long as each component is bcondized and there are no "to the exact
> release" dependencies then I guess it's fine. Doing qtwebengine (and all
> the other components) rebuild each time qtbase needs a small packaging
> adjustment would be tough on arm, though I'd understand if nobody cared
> about my use case.

FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
with qtwebengine.

I don't know how it looks on arm, but IMHO no-webengine bcond should be enough?

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: Qt packaging

2022-07-22 Thread Jan Palus
On 22.07.2022 11:03, Jan Rękorajski wrote:
> Can someone explain why are we using split sources/packages for Qt?
> 
> I want to add Qt6 and building from the monolythic source is s much
> easier. No need for bootstrap, no intertwined build dependencies, just
> configure -> build -> build docs -> install.
> 
> And unless there is a _very_ good reason to use split sources I'm just going
> to add a single qt6 package that builds everything (we can still subpackage
> bineries as we want them).

As long as each component is bcondized and there are no "to the exact
release" dependencies then I guess it's fine. Doing qtwebengine (and all
the other components) rebuild each time qtbase needs a small packaging
adjustment would be tough on arm, though I'd understand if nobody cared
about my use case.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: RFC: shell completions policy change?

2022-07-15 Thread Jan Palus
On 14.07.2022 16:38, Jakub Bogusz wrote:
> As more and more packages are getting bash/zsh completions, separate
> completions packages are becoming useless (harder to find, even not 
> suggested).
> 
> My proposal:
> 1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
> level) dirs to filesystem package and package bash/zsh[/fish] completion
> files just with commands (existing bash-/zsh-[/fish-] packages to be merged 
> and
> obsoleted). [preferred]
> Fortunately completion files don't have shebangs, which would generate
> bash/zsh dependencies.

Never had an issue with finding completions but I'm all for less
subpackages so +1.

> 2) at least add Suggests for completions packages in packages with
> commands to complete
> 
> 
> -- 
> Jakub Boguszhttp://qboosh.pl/
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: RFC: shell completions policy change?

2022-07-14 Thread Jan Rękorajski
On Thu, 14 Jul 2022, Jakub Bogusz wrote:

> As more and more packages are getting bash/zsh completions, separate
> completions packages are becoming useless (harder to find, even not 
> suggested).
> 
> My proposal:
> 1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
> level) dirs to filesystem package and package bash/zsh[/fish] completion
> files just with commands (existing bash-/zsh-[/fish-] packages to be merged 
> and
> obsoleted). [preferred]
> Fortunately completion files don't have shebangs, which would generate
> bash/zsh dependencies.

+1
Yes, it's a pain to find those subpackages.

-- 
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: RFC: shell completions policy change?

2022-07-14 Thread Arkadiusz Miśkiewicz via pld-devel-en

On 14.07.2022 16:38, Jakub Bogusz wrote:

As more and more packages are getting bash/zsh completions, separate
completions packages are becoming useless (harder to find, even not suggested).

My proposal:
1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
level) dirs to filesystem package and package bash/zsh[/fish] completion
files just with commands (existing bash-/zsh-[/fish-] packages to be merged and
obsoleted). [preferred]
Fortunately completion files don't have shebangs, which would generate
bash/zsh dependencies.


+1



2) at least add Suggests for completions packages in packages with
commands to complete


-1

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

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: your mail

2022-07-12 Thread Saleem Ceann Khan Marwat
My bad , I meant PLD English section

My mind is stuck with poldek so I wrote poldek by mistake

On Tue, Jul 12, 2022, 7:44 PM Saleem Ceann Khan Marwat 
wrote:

> Sorry if I posted it in wrong place but I thought I posted it in poldek
> English section
>
> And strangely now there is no more kernel 5.18 available on th , it has
> disappeared from packages available for upgrade
>
> So I'm currently on 5.17
>
> Thanks
>
> On Tue, Jul 12, 2022, 7:41 PM Jan Palus  wrote:
>
>> On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote:
>> > Thanks but that did not help either
>> >
>> > as can be seen from this log
>> > poldek:/all-avail> upgrade *
>> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
>> > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
>> > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
>> > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held
>> package
>> > Nothing to do
>> > poldek:/all-avail> install kernel-5.18.5-1.x86_64
>> > kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64
>> > kernel-sound-alsa-5.18.5-1.x86_64
>> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
>> > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
>> > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
>> > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held
>> package
>> > Nothing to do
>> > poldek:/all-avail> install kernel-5.18.5-1.x86_64
>> >
>> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
>> > Nothing to do
>>
>> And please do post such questions on pld-users-en. Thanks.
>>
>> > On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski 
>> > wrote:
>> >
>> > > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat
>> > >  wrote:
>> > > >
>> > > > Hello,
>> > > >
>> > > > I am having issue with kernel upgrade to 5.18 due to held packages
>> > > >
>> > > > I tried --nodeps --force but still can not upgrade any of the kernel
>> > > > related packages.
>> > > >
>> > > > How to fix this?
>> > >
>> > > Use install instead of upgrade for held (kernel in this case)
>> packages.
>> > >
>> > > The hold in poldek was added to prevent a case when a new kernel would
>> > > have problems starting. Upgrade could possibly leave you without a
>> > > working kernel.
>> > > Hold will not prevent uninstalling, but make sure that new kernel
>> > > boots before doing so :)
>> > >
>> > > --
>> > > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
>> > > bagginspld-linux.org
>> > > ___
>> > > pld-devel-en mailing list
>> > > pld-devel-en@lists.pld-linux.org
>> > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>> > >
>> >
>> >
>> > --
>> > Dr.Saleem Khan Marwat
>> > Abbottabad
>> > Khyber-Pakhtunkhwa
>> > Pakistan
>> > Cell # +92333-5393854
>> > WhatsApp # +92333-5393854
>> > Email: drmar...@gmail.com
>> > Web:  http://saleem-khan.blogspot.com
>> > Registered GNU/Linux User # 413133
>> > Since Aug 2003
>> > ___
>> > pld-devel-en mailing list
>> > pld-devel-en@lists.pld-linux.org
>> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>> ___
>> pld-devel-en mailing list
>> pld-devel-en@lists.pld-linux.org
>> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>>
>
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: your mail

2022-07-12 Thread Saleem Ceann Khan Marwat
Sorry if I posted it in wrong place but I thought I posted it in poldek
English section

And strangely now there is no more kernel 5.18 available on th , it has
disappeared from packages available for upgrade

So I'm currently on 5.17

Thanks

On Tue, Jul 12, 2022, 7:41 PM Jan Palus  wrote:

> On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote:
> > Thanks but that did not help either
> >
> > as can be seen from this log
> > poldek:/all-avail> upgrade *
> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
> > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
> > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held
> package
> > Nothing to do
> > poldek:/all-avail> install kernel-5.18.5-1.x86_64
> > kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64
> > kernel-sound-alsa-5.18.5-1.x86_64
> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
> > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
> > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held
> package
> > Nothing to do
> > poldek:/all-avail> install kernel-5.18.5-1.x86_64
> >
> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> > Nothing to do
>
> And please do post such questions on pld-users-en. Thanks.
>
> > On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski 
> > wrote:
> >
> > > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat
> > >  wrote:
> > > >
> > > > Hello,
> > > >
> > > > I am having issue with kernel upgrade to 5.18 due to held packages
> > > >
> > > > I tried --nodeps --force but still can not upgrade any of the kernel
> > > > related packages.
> > > >
> > > > How to fix this?
> > >
> > > Use install instead of upgrade for held (kernel in this case) packages.
> > >
> > > The hold in poldek was added to prevent a case when a new kernel would
> > > have problems starting. Upgrade could possibly leave you without a
> > > working kernel.
> > > Hold will not prevent uninstalling, but make sure that new kernel
> > > boots before doing so :)
> > >
> > > --
> > > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> > > bagginspld-linux.org
> > > ___
> > > pld-devel-en mailing list
> > > pld-devel-en@lists.pld-linux.org
> > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> > >
> >
> >
> > --
> > Dr.Saleem Khan Marwat
> > Abbottabad
> > Khyber-Pakhtunkhwa
> > Pakistan
> > Cell # +92333-5393854
> > WhatsApp # +92333-5393854
> > Email: drmar...@gmail.com
> > Web:  http://saleem-khan.blogspot.com
> > Registered GNU/Linux User # 413133
> > Since Aug 2003
> > ___
> > pld-devel-en mailing list
> > pld-devel-en@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: your mail

2022-07-12 Thread Jan Palus
On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote:
> Thanks but that did not help either
> 
> as can be seen from this log
> poldek:/all-avail> upgrade *
> error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package
> Nothing to do
> poldek:/all-avail> install kernel-5.18.5-1.x86_64
> kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64
> kernel-sound-alsa-5.18.5-1.x86_64
> error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package
> Nothing to do
> poldek:/all-avail> install kernel-5.18.5-1.x86_64
> 
> error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> Nothing to do

And please do post such questions on pld-users-en. Thanks.

> On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski 
> wrote:
> 
> > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat
> >  wrote:
> > >
> > > Hello,
> > >
> > > I am having issue with kernel upgrade to 5.18 due to held packages
> > >
> > > I tried --nodeps --force but still can not upgrade any of the kernel
> > > related packages.
> > >
> > > How to fix this?
> >
> > Use install instead of upgrade for held (kernel in this case) packages.
> >
> > The hold in poldek was added to prevent a case when a new kernel would
> > have problems starting. Upgrade could possibly leave you without a
> > working kernel.
> > Hold will not prevent uninstalling, but make sure that new kernel
> > boots before doing so :)
> >
> > --
> > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> > bagginspld-linux.org
> > ___
> > pld-devel-en mailing list
> > pld-devel-en@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> >
> 
> 
> -- 
> Dr.Saleem Khan Marwat
> Abbottabad
> Khyber-Pakhtunkhwa
> Pakistan
> Cell # +92333-5393854
> WhatsApp # +92333-5393854
> Email: drmar...@gmail.com
> Web:  http://saleem-khan.blogspot.com
> Registered GNU/Linux User # 413133
> Since Aug 2003
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: your mail

2022-07-12 Thread Jan Palus
On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote:
> Thanks but that did not help either
> 
> as can be seen from this log
> poldek:/all-avail> upgrade *
> error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package
> Nothing to do
> poldek:/all-avail> install kernel-5.18.5-1.x86_64
> kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64
> kernel-sound-alsa-5.18.5-1.x86_64
> error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
> error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package
> Nothing to do
> poldek:/all-avail> install kernel-5.18.5-1.x86_64
> 
> error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
> Nothing to do

You may try `just-install` alias in interactive session or `--nohold`
command line parameter but I strongly recommend `man poldek` and `man
poldek.conf` instead.

> On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski 
> wrote:
> 
> > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat
> >  wrote:
> > >
> > > Hello,
> > >
> > > I am having issue with kernel upgrade to 5.18 due to held packages
> > >
> > > I tried --nodeps --force but still can not upgrade any of the kernel
> > > related packages.
> > >
> > > How to fix this?
> >
> > Use install instead of upgrade for held (kernel in this case) packages.
> >
> > The hold in poldek was added to prevent a case when a new kernel would
> > have problems starting. Upgrade could possibly leave you without a
> > working kernel.
> > Hold will not prevent uninstalling, but make sure that new kernel
> > boots before doing so :)
> >
> > --
> > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> > bagginspld-linux.org
> > ___
> > pld-devel-en mailing list
> > pld-devel-en@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> >
> 
> 
> -- 
> Dr.Saleem Khan Marwat
> Abbottabad
> Khyber-Pakhtunkhwa
> Pakistan
> Cell # +92333-5393854
> WhatsApp # +92333-5393854
> Email: drmar...@gmail.com
> Web:  http://saleem-khan.blogspot.com
> Registered GNU/Linux User # 413133
> Since Aug 2003
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re:

2022-07-12 Thread Saleem Ceann Khan Marwat
Thanks but that did not help either

as can be seen from this log
poldek:/all-avail> upgrade *
error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package
Nothing to do
poldek:/all-avail> install kernel-5.18.5-1.x86_64
kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64
kernel-sound-alsa-5.18.5-1.x86_64
error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package
error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package
error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package
Nothing to do
poldek:/all-avail> install kernel-5.18.5-1.x86_64

error: kernel-5.18.5-1.x86_64: refusing to upgrade held package
Nothing to do


On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski 
wrote:

> On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat
>  wrote:
> >
> > Hello,
> >
> > I am having issue with kernel upgrade to 5.18 due to held packages
> >
> > I tried --nodeps --force but still can not upgrade any of the kernel
> > related packages.
> >
> > How to fix this?
>
> Use install instead of upgrade for held (kernel in this case) packages.
>
> The hold in poldek was added to prevent a case when a new kernel would
> have problems starting. Upgrade could possibly leave you without a
> working kernel.
> Hold will not prevent uninstalling, but make sure that new kernel
> boots before doing so :)
>
> --
> Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> bagginspld-linux.org
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>


-- 
Dr.Saleem Khan Marwat
Abbottabad
Khyber-Pakhtunkhwa
Pakistan
Cell # +92333-5393854
WhatsApp # +92333-5393854
Email: drmar...@gmail.com
Web:  http://saleem-khan.blogspot.com
Registered GNU/Linux User # 413133
Since Aug 2003
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re:

2022-07-08 Thread Jan Rękorajski
On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat
 wrote:
>
> Hello,
>
> I am having issue with kernel upgrade to 5.18 due to held packages
>
> I tried --nodeps --force but still can not upgrade any of the kernel
> related packages.
>
> How to fix this?

Use install instead of upgrade for held (kernel in this case) packages.

The hold in poldek was added to prevent a case when a new kernel would
have problems starting. Upgrade could possibly leave you without a
working kernel.
Hold will not prevent uninstalling, but make sure that new kernel
boots before doing so :)

-- 
Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: KDE - all form test

2022-07-01 Thread Peri Noid
Dnia piątek, 1 lipca 2022 14:31:04 CEST Andrzej Zawadzki pisze:
> OK Qt5 was to fresh. I found in logs:
> 
> 
> *plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this
> library (5.15.5)*
> 
> Hmm, rebuild is needed?

I did a full downgrade of Qt5 to 5.15.4 and it works - so yes, the problem is 
somewhere there. We're still missing some of Qt5 packets in thre 5.15.5 
version to be able to upgrade everything to this version. At least now.
-- 
Łukasz Maśko_o)
Lukasz.Masko(at)ipipan.waw.pl   /\\
Registered Linux User #61028   _\_V
Ubuntu: staroafrykańskie słowo oznaczające "Nie umiem zainstalować Debiana"



___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: KDE - all form test

2022-07-01 Thread Jan Palus
On 01.07.2022 14:31, Andrzej Zawadzki wrote:
> OK Qt5 was to fresh. I found in logs:
> 
> 
> *plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this
> library (5.15.5)*
> Hmm, rebuild is needed?

`rpm -qa 'Qt5*' | grep -F 5.15.4` will likely be the reason. Needs
upgrade to 5.15.5 as well.

> On Fri, Jul 1, 2022 at 2:19 PM Łukasz Maśko  wrote:
> 
> >From which version did you upgrade? Works without major problems for
> >me.
> >--
> >Pozdrawiam. Åukasz MaÅko
> >
> >1 lip 2022 14:04 Andrzej Zawadzki  napisaÅ(a):
> >
> > Hi!
> > My KDE is broken after upgrade (plasma-shell, basically useless).
> >  How
> > this looks on yours computers? ;-)
> > --
> > Andrzej
> >  ___
> >  pld-devel-en mailing list
> >  pld-devel-en@lists.pld-linux.org
> >  http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> > ___
> > pld-devel-en mailing list
> > pld-devel-en@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> >
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


Re: KDE - all form test

2022-07-01 Thread Andrzej Zawadzki
OK Qt5 was to fresh. I found in logs:


*plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this
library (5.15.5)*

Hmm, rebuild is needed?

On Fri, Jul 1, 2022 at 2:19 PM Łukasz Maśko  wrote:

>From which version did you upgrade? Works without major problems for
>me.
>--
>Pozdrawiam. Åukasz MaÅko
>
>1 lip 2022 14:04 Andrzej Zawadzki  napisaÅ(a):
>
> Hi!
> My KDE is broken after upgrade (plasma-shell, basically useless).
>  How
> this looks on yours computers? ;-)
> --
> Andrzej
>  ___
>  pld-devel-en mailing list
>  pld-devel-en@lists.pld-linux.org
>  http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


  1   2   3   4   5   6   7   8   9   10   >