Re: ssh configuration on builders [Re: [all] builder queue problem]
On Mon, 01 Jul 2024, Jakub Bogusz wrote: > openssh 9.8p1 dropped DSA keys support by default (could be brought back > by --enable-dsa-keys), so "+ssh_dss" (which apparently exists in current > configuration) became invalid. > > So either these options should be removed from builder configuration or > DSA keys support restored in openssh.spec. Disabled DSA on ep09. > On Mon, Jul 01, 2024 at 05:10:17PM +, PLD all builder wrote: > > there were problems sending files from queue > > /home/pld/builderth/pld-builder.new/spool/ftp: > > problems: > > [src: > > /home/pld/builderth/pld-builder.new/spool/ftp/3f092c05-a1fe-410a-adca-148f6352e974] > > > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, > > command sftp > > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: /etc/ssh/ssh_config line 55: Applying options for * > > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > > /etc/ssh/ssh_config: terminating, 2 bad configuration options > > scp: Connection closed [...] -- 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
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
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
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
The horrible mess called PHP
Tho whoever is interested in PHP. TL;DR Make PHP packaging sustainable or all versioned php packages will be deleted and replaced by a single php package tracking head. 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. 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, if it gets anything at all. If there is a real need to keep old versions of php, then whoever needs this, please figure out a packang model that won't require enormous cognitive load on anyone trying to deal with randmon php packages. You have been warned, Your maintainer -- 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
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
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
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
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: [packages/pam] - add triggers for removed modules
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
Retired packages after ffmpeg update
The packages listed below will be removed from Th as they either do not build at all or do not build with ffmpeg 6. All of them are unmaintined antiques (no upstream updates for 5-10 years), and fixing them would require too much effort, especially that for most of them replacements exist. IDFBTerm DirectFB LiTE cherokee gmerlin libdlna libstk moc mpeg4ip opal pHash qtav strigi transcode x262 zoneminder -- 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: Inconsistent repo metadata
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
PLD Th 2022 snapshot released
2022 snapshot of PLD/Linux Th has been released. It is available on ftp://ftp.pld-linux.org/dists/th/2022/PLD/ and as poldek sources th-2022. The main highlights of this release are: kernels 6.1.1, 5.15.85, 5.10.161, 5.4.228, 4.19.269, 4.14.302, 4.9.336 and 4.4.302 (4.4 and 4.9 have vserver enabled) RPM 4.17.1.1 OpenSSL 3.0.7 GCC 12.2.0 LLVM 15.0.5 glibc 2.36 GNOME 42 KDE5 5.101 / 22.12 XFCE 4.18 -- 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 fresh
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: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script
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
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: Qt packaging
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
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
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
Qt packaging
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). -- 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?
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:
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
Our sip and probably PyQt5 are broken
While trying to build new calibre I found out that our sip is quite broken. It wants the files in /usr/lib64/python3.10/site-packages/PyQt5/bindings while we install in /usr/share/sip/PyQt5 and then building calibre fails with: SIPing 3 files... /usr/bin/python3 -c from sipbuild.tools.build import main; main(); --verbose --no-make --qmake /usr/bin/qmake-qt5 Querying qmake about your Qt installation... /usr/bin/qmake-qt5 -query These bindings will be built: pictureflow. Generating the pictureflow bindings... -c: Q_PID is undefined The only reference I found is calibre author screaming at broken sip packagig: http://www.mobileread.mobi/forums/showthread.php?p=4132792 I'll try to figure out what's going on, but I wouldn't mind if someone beats me to 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: mongodb and framewave will be dropped from th
On Mon, 13 Jun 2022, Elan Ruusamäe wrote: > On 12.06.2022 20:09, Jan Rękorajski wrote: > > > Please don't think about updating mongodb past 4.0.3, as any later > > version uses very restrictive license that's risky and we don't > > want it in PLD. > > i'm sure people have discovered docker for deploying such servers. > > please consider adding that license note to the .spec as well, perhaps > linking to this thread. You are welcome to do the update then. I'm not going to spend my scarce time at updating package that was neglected for the past 10 years. Just make sure to add a license warning in %post (something like we have for vserver in kernel.spec). -- 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
mongodb and framewave will be dropped from th
Hi, Both mongodb and framewave are antique and require python2 scons for building, thus do not build anymore. Both have no direct dependencies, so drop should be painless. Please don't think about updating mongodb past 4.0.3, as any later version uses very restrictive license that's risky and we don't want it in PLD. -- 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/poldek] - add basic support for boolean deps, rel 10
On Wed, 08 Jun 2022, Jan Palus wrote: > On 20.05.2022 22:22, Jan Rękorajski wrote: > > On Fri, 20 May 2022, baggins wrote: > > > > > commit 2d94f8f7056fbe16b90a171b66282cae45b9070b > > > Author: Jan Rękorajski > > > Date: Fri May 20 17:13:44 2022 +0200 > > > > > > - add basic support for boolean deps, rel 10 > > > > > > > > > https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html > > > > > > Only Requires are supported, 'with' and 'without' don't check if > > > the dependency is satisfied by the same package, 'or' could be > > > improved > > > to do lazy evaluation. > > > > If anyone feels like doing some hacking, feel free to build up on this. > > > > And, of course, please test. > > Regarding testing looks like I'm not able to install python3-packaging > now: > > poldek:/all-avail> install python3-packaging > ... > Processing dependencies... > ((python3.10dist(pyparsing) < 3.0.5 or python3.10dist(pyparsing) > 3.0.5) > with python3.10dist(pyparsing) >= 2.0.2) required by python3-packaging > error: python3-packaging-21.3-4.noarch: req python3.10dist(pyparsing) < > 3.0.5 not found > python3-packaging-21.3-4.noarch marks python3-pyparsing-3.0.7-3.noarch > (cap python3.10dist(pyparsing) > 3.0.5) > There are 2 packages to install (1 marked by dependencies): > A python3-packaging-21.3-4.noarch python3-pyparsing-3.0.7-3.noarch > This operation will use 1.4MB of disk space. > Need to get 277.3KB of archives (277.3KB to download). > > error: 1 unresolved dependency > There were errors Poldek code be tricky. I admit I don't have good insight into ins and outs of it. This should be fixed in rel 13. > And regarding hacking, what's the ownership status for poldek? Any chance on > broader write access to upstream repo? I have not heard from the author for a long time :( Maybe we should fork it and keep it in our git under projects/ ? Author in CC. -- 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/poldek] - add basic support for boolean deps, rel 10
On Fri, 20 May 2022, baggins wrote: > commit 2d94f8f7056fbe16b90a171b66282cae45b9070b > Author: Jan Rękorajski > Date: Fri May 20 17:13:44 2022 +0200 > > - add basic support for boolean deps, rel 10 > > > https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html > > Only Requires are supported, 'with' and 'without' don't check if > the dependency is satisfied by the same package, 'or' could be improved > to do lazy evaluation. If anyone feels like doing some hacking, feel free to build up on this. And, of course, please test. -- 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/phonon-qt5] - initial version, copy of phonon repo
On Sun, 15 May 2022, Krzysztof Mrozowicz via pld-devel-en wrote: > Dnia 2022-05-15, o godz. 16:28:16 > Jan Rękorajski napisał(a): > > > On Sat, 14 May 2022, mrozowik wrote: > > > > > commit 0b8c3fb5a1bd048461aa4623ca1114928e5737eb > > > Author: Krzysztof Mrozowicz > > > Date: Sat May 14 13:10:01 2022 + > > > > > > - initial version, copy of phonon repo > > > > You should have done this with 'ssh g...@git.pld-linux.org copy phonon > > phonon-qt5' to keep the history. > > > > Please do so next time. > > Well, I tried. I received a message (from what I remember) that either I > don't have permissions to run the copy command, or the repo > already exists. When I checked, the repo was there, totally empty, so I > used it. Ah, ok, copy won't work if the destination is already there, even if it's empty. What does make sense as it could destroy previous incarnation history. -- 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/phonon-qt5] - initial version, copy of phonon repo
On Sat, 14 May 2022, mrozowik wrote: > commit 0b8c3fb5a1bd048461aa4623ca1114928e5737eb > Author: Krzysztof Mrozowicz > Date: Sat May 14 13:10:01 2022 + > > - initial version, copy of phonon repo You should have done this with 'ssh g...@git.pld-linux.org copy phonon phonon-qt5' to keep the history. Please do so next time. -- 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: python (3.10) dirs
On Tue, 26 Apr 2022, Jan Rękorajski wrote: > On Tue, 26 Apr 2022, Jakub Bogusz wrote: > > > On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan Rękorajski wrote: > > > On Tue, 19 Apr 2022, Jan Rękorajski wrote: > > > > > > > On Mon, 18 Apr 2022, Jakub Bogusz wrote: > > > > > > > > > After recent python3.10 changes meson started to use /usr/share for > > > > > purelib, but automake's pythondir is broken now: > > > > > > > > > > pythondir (platform-indepdendent) is wrong: > > > > > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > > > /usr/share/python2.7/site-packages > > > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > > > /usr/lib/python3.10/site-packages > > > > > > > > > > pyexecdir is OK: > > > > > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > > > /usr/lib64/python2.7/site-packages > > > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > > > /usr/lib64/python3.10/site-packages > > > > > > > > What package version do you have? Python3 shows /usr/share for me: > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; > > > > rpm -q python3 > > > > :1: DeprecationWarning: The distutils package is deprecated and > > > > slated for removal in Python 3.12. Use setuptools or check PEP 632 for > > > > potential alternatives > > > > :1: DeprecationWarning: The distutils.sysconfig module is > > > > deprecated, use sysconfig instead > > > > /usr/share/python3.10/site-packages > > > > python3-3.10.4-5.x86_64 > > > > > > > > On a side note, distutils is deprecated... > > > > > > The problematic dir seems to be coming from > > > /usr/share/python3.10/site-packages/distutils-precedence.pth > > > from python3-setuptools-62.0.0-1.noarch. Plain python should return > > > 'share' there. > > > > It's automake's standard AM_PATH_PYTHON that refers to distutils. > > > > Maybe we should rework revert-debian-python-hacks.patch ... > > Maybe I just fixed this in python3-setuptools-62.0.0-2 with a ~1 liner More to the point, python3 has all paths as we want them, but if you install python3-setuptool it will override stdlib sysconfig with its own implementation. And that was what was broken. -- 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: python (3.10) dirs
On Tue, 26 Apr 2022, Jakub Bogusz wrote: > On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan Rękorajski wrote: > > On Tue, 19 Apr 2022, Jan Rękorajski wrote: > > > > > On Mon, 18 Apr 2022, Jakub Bogusz wrote: > > > > > > > After recent python3.10 changes meson started to use /usr/share for > > > > purelib, but automake's pythondir is broken now: > > > > > > > > pythondir (platform-indepdendent) is wrong: > > > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > > /usr/share/python2.7/site-packages > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > > /usr/lib/python3.10/site-packages > > > > > > > > pyexecdir is OK: > > > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > > /usr/lib64/python2.7/site-packages > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > > /usr/lib64/python3.10/site-packages > > > > > > What package version do you have? Python3 shows /usr/share for me: > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; > > > rpm -q python3 > > > :1: DeprecationWarning: The distutils package is deprecated and > > > slated for removal in Python 3.12. Use setuptools or check PEP 632 for > > > potential alternatives > > > :1: DeprecationWarning: The distutils.sysconfig module is > > > deprecated, use sysconfig instead > > > /usr/share/python3.10/site-packages > > > python3-3.10.4-5.x86_64 > > > > > > On a side note, distutils is deprecated... > > > > The problematic dir seems to be coming from > > /usr/share/python3.10/site-packages/distutils-precedence.pth > > from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' > > there. > > It's automake's standard AM_PATH_PYTHON that refers to distutils. > > Maybe we should rework revert-debian-python-hacks.patch ... Maybe I just fixed this in python3-setuptools-62.0.0-2 with a ~1 liner -- 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: python (3.10) dirs
On Tue, 19 Apr 2022, Jan Rękorajski wrote: > On Mon, 18 Apr 2022, Jakub Bogusz wrote: > > > After recent python3.10 changes meson started to use /usr/share for > > purelib, but automake's pythondir is broken now: > > > > pythondir (platform-indepdendent) is wrong: > > > > $ python2 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > /usr/share/python2.7/site-packages > > > > $ python3 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > /usr/lib/python3.10/site-packages > > > > pyexecdir is OK: > > > > $ python2 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > /usr/lib64/python2.7/site-packages > > > > $ python3 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > /usr/lib64/python3.10/site-packages > > What package version do you have? Python3 shows /usr/share for me: > > $ python3 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm > -q python3 > :1: DeprecationWarning: The distutils package is deprecated and > slated for removal in Python 3.12. Use setuptools or check PEP 632 for > potential alternatives > :1: DeprecationWarning: The distutils.sysconfig module is deprecated, > use sysconfig instead > /usr/share/python3.10/site-packages > python3-3.10.4-5.x86_64 > > On a side note, distutils is deprecated... The problematic dir seems to be coming from /usr/share/python3.10/site-packages/distutils-precedence.pth from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' there. -- 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: python (3.10) dirs
On Mon, 18 Apr 2022, Jakub Bogusz wrote: > After recent python3.10 changes meson started to use /usr/share for > purelib, but automake's pythondir is broken now: > > pythondir (platform-indepdendent) is wrong: > > $ python2 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > /usr/share/python2.7/site-packages > > $ python3 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > /usr/lib/python3.10/site-packages > > pyexecdir is OK: > > $ python2 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > /usr/lib64/python2.7/site-packages > > $ python3 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > /usr/lib64/python3.10/site-packages What package version do you have? Python3 shows /usr/share for me: $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm -q python3 :1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives :1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead /usr/share/python3.10/site-packages python3-3.10.4-5.x86_64 On a side note, distutils is deprecated... -- 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
Please follow up on your library updates
Please check http://ep09.pld-linux.org/~pldth/main-ready-test.txt after upgrading a library that includes soname change and update packages with dependencies broken by library upgrade. I'm more and more inclined to either plain delete packages with broken dependencies or delete and revert upgaded library, depending on impact. I'm fed up cleaning up every time someone decides it's fine to upgrade a library that leaves a lot of packages stranded. Sincerely, Your Th maintainer. -- 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: Problem with qscintilla/Qt5 linking(?)
On Fri, 08 Apr 2022, Jan Palus wrote:
> On 08.04.2022 09:53, Jan Palus wrote:
> > On 08.04.2022 09:01, Jan Rękorajski wrote:
> > >
> > > Python 3.10.4 (main, Apr 1 2022, 09:00:14) [GCC 11.2.0 20220208
> > > (release)] on linux
> > > Type "help", "copyright", "credits" or "license" for more information.
> > > >>> from PyQt5 import Qsci
> > > Traceback (most recent call last):
> > > File "", line 1, in
> > > ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined
> > > symbol: _ZTI11QsciPrinter
> > >
> > > As far as I can see the symbol is there, recompiling qscintilla2 does
> > > not fix it.
> > >
> > > Could someone more versed in the linker(?) take a look at it?
> >
> > Unfortunately it has not much to do with linking, but rather with qmake.
> >
> > Above symbol is defined in libqscintilla2_qt5.so which is not linked to the
> > module, that's the reason for undefined symbol:
> >
> > x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
> > -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1 -shared
> > -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o
> > -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5
> > /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so
> > /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
> >
> > I guess linking to libqscintilla2_qt5.so should come from:
> >
> > Python/configure.py:
> > qmake = {'CONFIG': 'qscintilla2'...
> >
> > but perhaps due to the way we build python module it can't find newly built
> > qscintilla2? No idea.
> >
> > A brute force workaround is to BR: qscintilla2-qt5-devel so it finds system
> > config.
>
> Fixed in 2.11.6-2.
Thanks, I wonder how that symbol was defined if our rpm post-checks didn't
catch it's missing.
--
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
Problem with qscintilla/Qt5 linking(?)
Python 3.10.4 (main, Apr 1 2022, 09:00:14) [GCC 11.2.0 20220208 (release)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from PyQt5 import Qsci Traceback (most recent call last): File "", line 1, in ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined symbol: _ZTI11QsciPrinter As far as I can see the symbol is there, recompiling qscintilla2 does not fix it. Could someone more versed in the linker(?) take a look at 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
opnjdk* jar broken on x86_64
Any ideas how the below could broke? Same thing works on i686 and x32. I installed i686 jar on x86_64 builder to unblock libreoffice and openjdk11 rebilds for now. Tested with openjdk11 and openjdk12: Notice that the original CRC is not what jar put in the archive. [builder2@ymir ~]$ S=/home/users/builder2/rpm/BUILD/libreoffice-7.2.0.3 && I=$S/instdir && W=$S/workdir && mkdir -p $W/JavaClassSet/Jar/unoloader/META-INF && echo Manifest-Version: 1.0 > $W/JavaClassSet/Jar/u noloader/META-INF/MANIFEST.MF && echo "Solar-Version: 7.2.0.3" >> $W/JavaClassSet/Jar/unoloader/META-INF/MANIFEST.MF && cat $S/ridljar/source/unoloader/com/sun/star/lib/unoloader/manifest >> $W/JavaClassSet/J ar/unoloader/META-INF/MANIFEST.MF && mkdir -p $I/program/classes/ && cd $W/JavaClassSet/Jar/unoloader && jar cfm $I/program/classes/unoloader.jar $W/JavaClassSet/Jar/unoloader/META-INF/MANIFEST.MF META-INF com && cd $W/JavaClassSet/Jar/unoloader/ && jar uf $I/program/classes/unoloader.jar module-info.class java.util.zip.ZipException: invalid entry CRC (expected 0x85cff2ff but got 0x341ef68c) at java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:410) at java.base/java.util.zip.ZipInputStream.read(ZipInputStream.java:199) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107) at jdk.jartool/sun.tools.jar.Main.copy(Main.java:1248) at jdk.jartool/sun.tools.jar.Main.update(Main.java:977) at jdk.jartool/sun.tools.jar.Main.run(Main.java:366) at jdk.jartool/sun.tools.jar.Main.main(Main.java:1680) [builder2@ymir unoloader]$ cat $W/JavaClassSet/Jar/unoloader/META-INF/MANIFEST.MF Manifest-Version: 1.0 Solar-Version: 7.2.0.3 Sealed: true [builder2@ymir unoloader]$ unzip /home/users/builder2/rpm/BUILD/libreoffice-7.2.0.3/instdir/program/classes/unoloader.jar -d /tmp/foo Archive: /home/users/builder2/rpm/BUILD/libreoffice-7.2.0.3/instdir/program/classes/unoloader.jar creating: /tmp/foo/META-INF/ inflating: /tmp/foo/META-INF/MANIFEST.MF bad CRC ff00bd06 (should be 8ea870b0) inflating: /tmp/foo/META-INF/M creating: /tmp/foo/com/ creating: /tmp/foo/com/sun/ creating: /tmp/foo/com/sun/star/ creating: /tmp/foo/com/sun/star/lib/ creating: /tmp/foo/com/sun/star/lib/unoloader/ inflating: /tmp/foo/com/sun/star/lib/unoloader/UnoClassLoader.class inflating: /tmp/foo/com/sun/star/lib/unoloader/UnoLoader$1.class inflating: /tmp/foo/com/sun/star/lib/unoloader/UnoLoader.class [builder2@ymir unoloader]$ cat /tmp/foo/META-INF/MANIFEST.MF Manifest-Version: 1.0 Solar-Version: 7.2.0.3 Sealed: true Created-By: 12.0.2 (PLD-Linux) [builder2@ymir unoloader]$ cksfv /tmp/foo/META-INF/MANIFEST.MF ; Generated by cksfv v1.3.14 on 2022-03-30 at 11:12.18 ; Project web site: http://www.iki.fi/shd/foss/cksfv/ ; ; 95 11:08.40 2022-03-30 /tmp/foo/META-INF/MANIFEST.MF /tmp/foo/META-INF/MANIFEST.MF FF00BD06 [builder2@ymir unoloader]$ cksfv $W/JavaClassSet/Jar/unoloader/META-INF/MANIFEST.MF ; Generated by cksfv v1.3.14 on 2022-03-30 at 11:13.49 ; Project web site: http://www.iki.fi/shd/foss/cksfv/ ; ; 58 11:13.38 2022-03-30 /home/users/builder2/rpm/BUILD/libreoffice-7.2.0.3/workdir/JavaClassSet/Jar/unoloader/META-INF/MANIFEST.MF /home/users/builder2/rpm/BUILD/libreoffice-7.2.0.3/workdir/JavaClassSet/Jar/unoloader/META-INF/MANIFEST.MF E269E4CE -- 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
guile dependencies
If anyone cares about g-wrap, guile-gnome-platform, guile-clutter and serveez then please fix them (especially g-wrap as it's dependency for most other packages) or I will eventually remove them from Th. Background: these packages are old (>=7 years) and do not build with guile 3.0. -- 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
gstreamer 0.10 to be removed
The old gstreamer 0.10 and all its dependencies will soon be removed from Th. All packages depending on it are more than 10 years old and unmaintained, there is no point keeping them, The following packages will be removed: banshee gnome-subtitles google-gadgets gstreamer-plugins-moodbar java-gnu-classpath last-exit libgnome-media-profiles longomatch perl-GStreamer-Interfaces perl-GStreamer psi-plugin-psimedia radiotray swfdec ucview_plugins xfce4-mixer and xfce4-volumed are obsoleted by xfce4-pulseaudio-plugin and xfce4-volumed-pulse, respectively gcompris is obsoleted by its successor gcompris-qt -- 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/dssim2] - do not obsolete a library if not providing it
On Wed, 23 Feb 2022, Jakub Bogusz wrote:
> On Wed, Feb 23, 2022 at 01:20:38AM +0100, baggins wrote:
> > commit 0131577abe142917eac5751e6df84cfde8721c79
> > Author: Jan Rękorajski
> > Date: Wed Feb 23 01:20:12 2022 +0100
> >
> > - do not obsolete a library if not providing it
> [...]
> > @@ -24,7 +24,6 @@ BuildRequires:rpmbuild(macros) >= 2.004
> > BuildRequires: rust
> > BuildRequires: tar >= 1:1.22
> > BuildRequires: xz
> > -Obsoletes: dssim < 2
> > ExclusiveArch: %{x8664} %{ix86} x32 aarch64 armv6hl armv7hl armv7hnl
> > BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
> >
>
> dssim package is not a library, but an older version of dssim tool.
> Library is contained in dssim-libs package.
Revert the commit then and tell me which packages should be left and
which removed from ftp.
--
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
Next set of packages to be removed (old openexr dependent stuff)
The below packages will be removed because they were either drop upstream, or are unmaintanied for years and do not build anymore. cinepaint ctl (ctlrender, openexr_ctl, openexr_ctl-progs) luminance-hdr openexr_viewers -- 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: TEST build ERRORS: openjdk13.spec
On Mon, 14 Feb 2022, Jan Palus wrote: > On 14.02.2022 07:53, PLD th-x32 builder wrote: > > openjdk13.spec (HEAD): FAILED > > > > --- openjdk13.spec:HEAD: > > Build-Time: user:84614.73s sys:141.38s real:38812.14s (faults io:17121 > > non-io:15931222) > > Did it die of "natural causes" or someone grew impatient? Build passed > on carme-x32 but admittedly it takes around 13h to complete. strace told me it was sitting at futex() call. I didn't believe it would progress past that so I killed the build. Feel free to retry. -- 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
KDE 4 is going away
Due to Qt4 breakage on ix86 we can't properly rebuild KDE4 base building blocks anymore. Besides, it's an antique. Thus, ALL kde4 and dependant packages will be removed from Th real soon 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: lwn.net 3 years subscription and missing Szymon Siwek
On Wed, 26 Jan 2022, Arkadiusz Miśkiewicz via pld-devel-en wrote: > Hello. > > Does anyone have contact with Szymon Siwek ? > > Our lwn.net subscription is going to expire and we want to renew it. He > was participating but it seems that he doesn't use it since 2019. > > In case we won't be able to contact him we are looking for one person > who is interested in 3 years lwn.net subcription for ~148PLN (1$/month). > > Deadline is tomorrow. Just in case, I'm interested. -- 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: cargo(?)/rust(?) broken on x32
On Mon, 24 Jan 2022, Jan Palus wrote: > On 23.01.2022 23:17, Jan Rękorajski wrote: > > cargo does not pass --target down to rust on x32 again. > > > > http://buildlogs.pld-linux.org//index.php?dist=th=x32=0=dssim2=2684320f-141d-452b-8608-4959b7d844e0=tail > > > > Could it be related to > > http://git.pld-linux.org/gitweb.cgi?p=packages/rust.git;a=commit;h=62473c9552f86f55f6f591df14ca1755ecdb5cd6 > > or just new rust breaking cross compilation again for the sake of it? > > Mentioned commit should result in exactly same spec file after parsing > as before for all archs but armv7hnl. Actually rust on x32 predated > it anyway at the time of mentioned build. > > target is passed down correctly: > - rustc invocations that lack it are for build scripts that are built > for host > - other rustc invocations have target passed down correctly > > Objects that are built incorrectly are not coming from rust sources, > these are compiled from assembler files which seem to be simply > miscompiled for x32. Fixed on master now. Thanks a lot. I wonder what's wrong with my local setup. I have x32 builder environment with the same packages installed, yet cargo tries to build 64bit stuff in x32 environment... -- 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
cargo(?)/rust(?) broken on x32
cargo does not pass --target down to rust on x32 again. http://buildlogs.pld-linux.org//index.php?dist=th=x32=0=dssim2=2684320f-141d-452b-8608-4959b7d844e0=tail Could it be related to http://git.pld-linux.org/gitweb.cgi?p=packages/rust.git;a=commit;h=62473c9552f86f55f6f591df14ca1755ecdb5cd6 or just new rust breaking cross compilation again for the sake of 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: PLD mail/requests problems
On Tue, 18 Jan 2022, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 17.01.2022 18:37, Jakub Bogusz wrote: > > On Sun, Jan 16, 2022 at 09:41:05PM +0100, Jakub Bogusz wrote: > >> - distfiles fetch request don't seem to be handled (since a few days) or no > >> mail report is sent (both for requester nor pld-commit list) > > > > It seems distfiles are not fetching anything new at all (both by git or > > manual mail requests), and reports are not sent. > > > >> - I don't get any build logs since yesterday > >> > >> - only some (http) build requests are handled (one per ? hours) > > > > This one seems partially solved: ignored requests fail because of > > missing files on distfiles - but again, I don't get any mail reports > > about failed build from src builder. > > disk was fully filled on MX due to some spammers. There is still something wrong. I'm not getting any response from failed(?) requests. Ex. trying to build the kernel from head does not yield any response, not even build failure. Like the build request went to /dev/null. -- 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: qt4 broken on i686
16652 builder+ 20 0 59.2m 14.5m 99.34 0.036 1196:11 R /usr/bin/meinproc4 --check --cache /tmp/B.helc_nsl/BUI+ 16653 builder+ 20 0 59.2m 14.4m 99.34 0.036 1196:10 R /usr/bin/meinproc4 --stylesheet /usr/share/apps/ksgmlt+ meinproc4 is consistently hanging on i686 to the point I've been disabling docs in kde4 packages. Killed On Tue, Jan 18, 2022 at 11:42 AM Jan Palus wrote: > > On 18.08.2021 22:34, Jan Rękorajski wrote: > > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or > > infinite looping (ex. meinproc4 in kde4-kig). > > > > I'm running out of ideas[1] and time to troubleshoot this and would > > appreciate if anyone would be willing to try and figure out WTF is > > broken there. > > > > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a > > glibc 2.34 issue, but I don't have resources at hand to validate it. > > Looks like kde4-kig is causing issues again. Could someone check what's > the binary name that's hanging and kill it? Perhaps it's something that > needs a rebuild with workaround since avogadro built just fine. > ___ > 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 | 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: freshness report not updating
On Sat, 08 Jan 2022, Jan Palus wrote: > Report at http://ep09.pld-linux.org/~pldth/qa.php?q=freshness stopped > receiving updates despite timestamp claiming it was ran recently. > For example uriparser or libsigsegv are missing. Fixed. Client repo desync. -- 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
Update on PLD Th snapshots
Hi, I'm going to delete old snapshots from ftp. By old I mean older than 3 years (2012-2018). There is no value in keepeing them, and the promise was that we keep the last 3 years worth. If you need the old packages, you have time till the end of January 2022 to get them. After that everything older than 2018 will be deleted, -- 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
PLD Th 2021 snapshot released
2021 snapshot of PLD/Linux Th has been released. It is available on ftp://ftp.pld-linux.org/dists/th/2021/PLD/ and as poldek sources th-2021. The main highlights of this release are: kernels 5.15.12, 5.10.89, 5.4.169, 4.19.223, 4.14.260, 4.9.295 and 4.4.297 (4.4 and 4.9 have vserver enabled) RPM 4.16.1.3 OpenSSL 3.0.1 GCC 11.2.0 LLVM 13.0.0 glibc 2.34 GNOME 41 KDE5 5.89 / 21.12 MATE Desktop Environment 1.26 -- 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: php pear deps not generating
On Fri, 17 Dec 2021, Arkadiusz Miśkiewicz via pld-devel-en wrote: > > Hi. > > Is anything new needed with rpm 4.16 to get php pear deps filled? > > I'm testing build on php-pear-Archive_Tar.spec and php.req/prov are not > used and thus no pear() deps gets generated. There was something wrong with it and I disabled it over a year ago. I honestly can't remember what was wrong, so feel free to reenable and retest. It's in rpm-pld-macros package, file attr.php. -- 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/gstreamer] - up to 1.19.3
On Wed, 24 Nov 2021, Jakub Bogusz wrote: > On Wed, Nov 24, 2021 at 12:31:05AM +0100, baggins wrote: > > commit dfdf0fe8490feef0e9470ff28698c97632c5732c > > Author: Jan Rękorajski > > Date: Wed Nov 24 00:30:55 2021 +0100 > > > > - up to 1.19.3 > > See dev-1.18 branch / DEVEL-1.18 branches on other gstreamer-*.spec And this is why I don't like branched development of packages, these branches get lost and lead to work duplication. I can understand that for the core components, where doing an update is fragile, but for common cases please do development on master. > I was going to merge them soon (lack of time was the obstacle). Please do, and let's bump to 1.19.3, it's almost stable and backtracking is not worth the work here. > 1.19.x is devel line AFAIK. Yes. These people really should fix that sick versioning scheme. -- 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: Some packages to be removed post openssl 3.0.0 update
On Sun, 31 Oct 2021, Jan Rękorajski wrote: > There are a few packages that do not build either because of OpenSSL > incompatibilities or/and because they are FUBAR. > > Unless someone fixes the packages below, I will remove them in ~two > weeks. > > php 5.2 > ekg > ipsec-tools (abandoned by upstream, do not use) > libetebase > megacmd > mosh The time has come. OpenSSL 3.0 is now in Th and above mentioned packages (except PHP) have been removed. If someone reaally needs pre-3.0 packages, I had temporarily[1] copied pre-update PLD repo as PLD-openssl1 https://ftp.th.pld-linux.org/dists/th/PLD-openssl1 [1] meaning will be removed by the end of year. -- 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: TEST build ERRORS: onedrive.spec
This should do the trick (if I didn't mess up poldek options) make-request -t -c 'rm -f /spools/ready/* ; poldek --mkidxz -s /spools/ready ; poldek --up' Basically builders have a local spool with most recently built packages and this on rare occasions goes out of sync. On Thu, Nov 11, 2021 at 11:23 AM Jan Palus wrote: > > On 11.11.2021 10:18, PLD th-x86_64 builder wrote: > > onedrive.spec (HEAD): FAILED > > > > --- onedrive.spec:HEAD: > > Build-Time: user:6.04s sys:1.07s real:9.30s (faults io:2 non-io:303950) > > > > > > > > *** buildlog for onedrive.spec > > request from: atler > ... > > rpm: error: Failed build dependencies: > > rpm: ldc is needed by onedrive-2.4.13-1.x86_64 > > rpm: Building target platforms: x86_64-pld-linux > > rpm: Building for target x86_64-pld-linux > > updating poldek cache... > > ready is up to date > > th is up to date > > th is up to date > > th-ready is up to date > > th-ready is up to date > > th-test is up to date > > th-test is up to date > > checking conflicting packages in BRed packages > > poldek: Loading [pndir]ready... > > poldek: Loading [pndir]th-test... > > poldek: Loading [pndir]th-test... > > poldek: Loading [pndir]th-ready... > > poldek: Loading [pndir]th-ready... > > poldek: Loading [pndir]th... > > poldek: Loading [pndir]th... > > poldek: 34666 packages read > > poldek: Removed 5065 duplicate packages from available set > > poldek: Processing dependencies... > > poldek: There are 1 package to install: > > poldek: A ldc-1.28.0-2.x86_64 > > poldek: This operation will use 24.4MB of disk space. > > poldek: Need to get 4.3MB of archives. > > poldek: error: /spools/ready/ldc-1.28.0-2.x86_64.rpm: No such file or > > directory > > Can someone check? Package is there in th-test but for someone reason > builder cannot find it. > ___ > 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 | 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: xorg-font-font-adobe-75dpi package potential corruption
On Sun, 07 Nov 2021, Adam Osuchowski wrote: > There is a problem with xorg-font-font-adobe-75dpi package during install: > > root@pldtest:~# ipoldek install xorg-font-font-adobe-75dpi > Loading [pndir]th... > Loading [pndir]th... > 30648 packages read > Processing dependencies... > There are 1 package to install: > A xorg-font-font-adobe-75dpi-1.0.3-2.noarch > This operation will use 5.4MB of disk space. > xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm: digests OK > Need to get 5.3MB of archives. > xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm: digests OK > xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm: digests signatures OK > Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps > 0... > Verifying... # [100%] > Preparing... # [100%] > Updating / installing... >1:xorg-font-font-adobe-75dpi-1.0.3-# [100%] > error: unpacking of archive failed: cpio: Bad magic > error: xorg-font-font-adobe-75dpi-1.0.3-2.noarch: install failed > There were errors Must be corrupted file. Rebuilt package in PLD-th (rel 3). -- 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/dracut] - bash is *required* for dracut initramfs to work correctly, rel 3
On Sun, 31 Oct 2021, Jan Palus wrote: > On 31.10.2021 09:21, Jan Rękorajski wrote: > > On Sun, 31 Oct 2021, Jan Palus wrote: > > > > > On 30.10.2021 23:23, baggins wrote: > > > > commit 63a4b90ecfdd4ac023ab8542fd6af60f4c80516e > > > > Author: Jan Rękorajski > > > > Date: Sat Oct 30 23:21:06 2021 +0200 > > > > > > > > - bash is *required* for dracut initramfs to work correctly, rel 3 > > > > > > At some point dracut started to pretend mksh is supported as /bin/sh > > > inside initramfs but that's simply not true. Default fallback is > > > whatever system /bin/sh is linked which in our case is mksh hence broken > > > initramfs in some cases. Going back to previous default "dash" helped in > > > my case (lvm) -- are you sure it really needs bash? And perhaps maybe > > > > I know for certain that mksh does not. And very silently at that. Initramfs > > just doesn't detect encrypted partitions. > > > > > let's leave a possibility to customize shell and instead of hardcoding > > > bash use: > > > > > > add_dracutmodules+=" bash " > > > > > > which effectively changes default shell. > > > > I'm not so sure. What I found in the code is that dracut first installs > > /bin/sh and then shell modules (00bash, 00dash, 00mksh) as needed. > > But, those modules do not create /bin/sh if it already exists, and since > > that symlink is installed first it will not be re-created. > > Works for me. The place where dracut installs /bin/sh -> mksh is at first > script with /bin/sh shebang: > > https://github.com/dracutdevs/dracut/blob/15398458685d376fef56b1bf6fe09ae7c68324c1/src/install/dracut-install.c#L531 > > Hence shell modules (bash/dash/mksh) are ordered with 00 before any such > script could be installed. Tested dash, works. Generic initramfs detected and booted off encrypted root. > > > (At some point I was going to add `add_dracutmodules+=" dash "` but must > > > have forgotten). > > > > Dracut already requires and installs bash into the initramfs for its own > > needs. I'd rather stick to my "fix" to make absolutely sure it's there > > and as /bin/sh to avoid new surprises. > > > > Besides /etc/dracut.conf.d/01-dist.conf is marked in package as > > config(noreplace) and you may end up with .rpmnew and effectively a > > noop. > > True. We could add a new file like 00-default-shell.conf though. Feel free to change it to a config if you prefer. -- 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
Some packages to be removed post openssl 3.0.0 update
There are a few packages that do not build either because of OpenSSL incompatibilities or/and because they are FUBAR. Unless someone fixes the packages below, I will remove them in ~two weeks. php 5.2 ekg ipsec-tools (abandoned by upstream, do not use) libetebase megacmd mosh -- Jan Rękorajski| PLD/Linux SysAdm | 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/dracut] - bash is *required* for dracut initramfs to work correctly, rel 3
On Sun, 31 Oct 2021, Jan Palus wrote: > On 30.10.2021 23:23, baggins wrote: > > commit 63a4b90ecfdd4ac023ab8542fd6af60f4c80516e > > Author: Jan Rękorajski > > Date: Sat Oct 30 23:21:06 2021 +0200 > > > > - bash is *required* for dracut initramfs to work correctly, rel 3 > > At some point dracut started to pretend mksh is supported as /bin/sh > inside initramfs but that's simply not true. Default fallback is > whatever system /bin/sh is linked which in our case is mksh hence broken > initramfs in some cases. Going back to previous default "dash" helped in > my case (lvm) -- are you sure it really needs bash? And perhaps maybe I know for certain that mksh does not. And very silently at that. Initramfs just doesn't detect encrypted partitions. > let's leave a possibility to customize shell and instead of hardcoding > bash use: > > add_dracutmodules+=" bash " > > which effectively changes default shell. I'm not so sure. What I found in the code is that dracut first installs /bin/sh and then shell modules (00bash, 00dash, 00mksh) as needed. But, those modules do not create /bin/sh if it already exists, and since that symlink is installed first it will not be re-created. > > (At some point I was going to add `add_dracutmodules+=" dash "` but must > have forgotten). Dracut already requires and installs bash into the initramfs for its own needs. I'd rather stick to my "fix" to make absolutely sure it's there and as /bin/sh to avoid new surprises. Besides /etc/dracut.conf.d/01-dist.conf is marked in package as config(noreplace) and you may end up with .rpmnew and effectively a noop. -- Jan Rękorajski| PLD/Linux SysAdm | 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: How to update rust vendored crates contents?
On Fri, 29 Oct 2021, Elan Ruusamäe wrote: > On 29.10.2021 00:04, Jan Rękorajski wrote: > > > Does anyone know how to update vendored crates in a rust package? > > > > The problem is that only the latest and greates rust openssl crate > > supports openssl 3.0.0, but libetebase and sccache list an old version. > > > > I tried to change the versions in Cargo.lock but it gets confused about > > checksums and dependencies. Removing checksum entries seem to move > > things forward but does not pull other, intermediate deps. > > > > Is there way to make that pull all the right crates automagically? > > can you point to specific package, and/or your previous attempts (push > as branch perhaps) See above, libetebase and sccache And pushing to branch is not going to work because it breaks at vendoring crates. Edit Cargo.lock and update openssl and openssl-sys versions, try `cargo vandor` and watch it fail. I'll try to solve it a different way, let's see if making rust-openssl as a separate package will work. -- Jan Rękorajski| PLD/Linux SysAdm | 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
How to update rust vendored crates contents?
Does anyone know how to update vendored crates in a rust package? The problem is that only the latest and greates rust openssl crate supports openssl 3.0.0, but libetebase and sccache list an old version. I tried to change the versions in Cargo.lock but it gets confused about checksums and dependencies. Removing checksum entries seem to move things forward but does not pull other, intermediate deps. Is there way to make that pull all the right crates automagically? -- Jan Rękorajski| PLD/Linux SysAdm | 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: TEST build OK: openjdk8.spec
Ah, it wasn't icedtea but openjdk8 that was installed on i686 and x86_64. I'm uninstalling it and blocking in poldek on builders so that we have only openjdk11 installable there. On Fri, Oct 22, 2021 at 10:38 AM Jan Rękorajski wrote: > > 17461 ?Ss 0:00 | \_ rpmbuild > -bb --define _smp_mflags -j9 --define _make_opts -Otarget --define > _pld_builder 1 --define _topdir /tmp/B.0338pl28 --defin > 17597 ?S 0:00 | \_ /bin/sh > -e /tmp/B.0338pl28/BUILD/tmp/rpm-tmp.xcCtoN > 17640 ?S 0:00 | \_ > /bin/bash ./configure LDFLAGS=-Wl,--as-needed > -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc > CFLAGS=-O2 -fw > 17643 ?S 0:00 | \_ > bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/con > 17826 ?S 0:00 | > \_ bash -c . > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga > 17828 ?S 0:00 | > | \_ bash -c . > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u31 > 18249 ?S 0:00 | > | | \_ bash -c . > /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure > /tmp/B.0338pl28/BUILD/jdk8u-jdk > 18250 ?Sl 0:02 | > | | \_ /usr/lib/jvm/openjdk8/bin/java -version > 17829 ?S 0:00 | > | \_ tee -a ./configure.log > 17827 ?S 0:00 | > \_ tee -a ./configure.log > > strace: Process 18250 attached > futex(0xf7ee3b28, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 18251, NULL, > FUTEX_BITSET_MATCH_ANY^C > strace: Process 18250 detached > > > icedtea8 nie lubi się z glibc 2.34? > > Utłukłem oba. > > On Fri, Oct 22, 2021 at 10:12 AM Jan Palus wrote: > > > > On 21.10.2021 10:08, PLD th-src builder wrote: > > > openjdk8.spec (HEAD): OK > > > > > > --- openjdk8.spec:HEAD: > > > Build-Time: user:12.04s sys:6.78s real:23.38s (faults io:18 non-io:365577) > > > > > > Files queued for ftp: > > > 77449097 openjdk8-1.8.0.312-1.src.rpm > > > > > > > Any clues why the build hanged on th-x86_64 and th-i686? > > ___ > > pld-devel-en mailing list > > pld-devel-en@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > > > -- > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ > bagginspld-linux.org -- 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: TEST build OK: openjdk8.spec
17461 ?Ss 0:00 | \_ rpmbuild -bb --define _smp_mflags -j9 --define _make_opts -Otarget --define _pld_builder 1 --define _topdir /tmp/B.0338pl28 --defin 17597 ?S 0:00 | \_ /bin/sh -e /tmp/B.0338pl28/BUILD/tmp/rpm-tmp.xcCtoN 17640 ?S 0:00 | \_ /bin/bash ./configure LDFLAGS=-Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc CFLAGS=-O2 -fw 17643 ?S 0:00 | \_ bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/con 17826 ?S 0:00 | \_ bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga 17828 ?S 0:00 | | \_ bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure /tmp/B.0338pl28/BUILD/jdk8u-jdk8u31 18249 ?S 0:00 | | | \_ bash -c . /tmp/B.0338pl28/BUILD/jdk8u-jdk8u312-ga/common/autoconf/configure /tmp/B.0338pl28/BUILD/jdk8u-jdk 18250 ?Sl 0:02 | | | \_ /usr/lib/jvm/openjdk8/bin/java -version 17829 ?S 0:00 | | \_ tee -a ./configure.log 17827 ?S 0:00 | \_ tee -a ./configure.log strace: Process 18250 attached futex(0xf7ee3b28, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 18251, NULL, FUTEX_BITSET_MATCH_ANY^C strace: Process 18250 detached icedtea8 nie lubi się z glibc 2.34? Utłukłem oba. On Fri, Oct 22, 2021 at 10:12 AM Jan Palus wrote: > > On 21.10.2021 10:08, PLD th-src builder wrote: > > openjdk8.spec (HEAD): OK > > > > --- openjdk8.spec:HEAD: > > Build-Time: user:12.04s sys:6.78s real:23.38s (faults io:18 non-io:365577) > > > > Files queued for ftp: > > 77449097 openjdk8-1.8.0.312-1.src.rpm > > > > Any clues why the build hanged on th-x86_64 and th-i686? > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en -- Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ 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: stbr broken
On Fri, 08 Oct 2021, Elan Ruusamäe wrote: > > On 05.10.2021 16:56, Elan Ruusamäe wrote: > > > > On 05.10.2021 11:29, Elan Ruusamäe wrote: > > > >> > >> Problem while sending request via HTTP: > >> https://srcbuilder.pld-linux.org:1235/: HTTP Error 500: None: 'utf-8' > >> codec can't decode byte 0xe4 in position 205: invalid continuation byte > >> > > > > I suspect this has something to do my gecos field containing ä > > (U+00C4), probably in iso8858-1 not in utf-8 encoding. > > > > > > but until someone fixes it, please stbr: > > > > - python3-markupsafe.spec broken deps http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=0=python3-markupsafe=d4c07d06-86e6-4579-9249-c1e30c2e7525=tail > > - python3-jinja2.spec broken http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=0=python3-jinja2=490ce6df-8790-42c4-86e7-4929a27ab91d=tail > > - nagios-notify.spec done > also stbr apache(2.4.51) (CVE fixes) done -- 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: firefox extensions
On Wed, 06 Oct 2021, Jan Palus wrote: > On 05.10.2021 23:50, Jan Rękorajski wrote: > > On Tue, 05 Oct 2021, Jan Rękorajski wrote: > > > > > I can't figure out what the trigger was, but since recently (92+?, > > > September?) firefox extensions started misbehaving. ex. ublock is > > > not really blocking adds, and if I try to click its icon all I get > > > is a single vertical line instead of the menu. > > > > > > So, does firefox extensions work for you? Any hints what's going on? > > > > > > I did try launching firefox on a clean profile, problem persists, and > > > the same thing happens on both mozilla-firefox-bin and PLD compiled > > > package. > > > > I also did try downgrading to 91.0 and it looks the same, so, what could > > have changed recently that broke JavaScript(?) in forefox? > > It appears to be sandbox/seccomp related so perhaps glibc just like > chrome? Workaround: > > - install ublock > - modify "security.sandbox.content.level" from "4" to "2" Works up to here ;) > - restart firefox and bring back "security.sandbox.content.level" to "4" > - restart firefox and enjoy ublock Bringing back to "4" breaks extensions again. > No idea what's wrong exactly though. According to https://wiki.mozilla.org/Security/Sandbox#Content_Levels it's "Read access to most of the filesystem" that's problematic (yes, "3" already breaks stuff). Oh, well, at least there is a workaround. Thanks a lot. -- Jan Rękorajski| PLD/Linux SysAdm | 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: firefox extensions
On Tue, 05 Oct 2021, Jan Rękorajski wrote: > I can't figure out what the trigger was, but since recently (92+?, > September?) firefox extensions started misbehaving. ex. ublock is > not really blocking adds, and if I try to click its icon all I get > is a single vertical line instead of the menu. > > So, does firefox extensions work for you? Any hints what's going on? > > I did try launching firefox on a clean profile, problem persists, and > the same thing happens on both mozilla-firefox-bin and PLD compiled > package. I also did try downgrading to 91.0 and it looks the same, so, what could have changed recently that broke JavaScript(?) in forefox? -- Jan Rękorajski| PLD/Linux SysAdm | 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
firefox extensions
I can't figure out what the trigger was, but since recently (92+?, September?) firefox extensions started misbehaving. ex. ublock is not really blocking adds, and if I try to click its icon all I get is a single vertical line instead of the menu. So, does firefox extensions work for you? Any hints what's going on? I did try launching firefox on a clean profile, problem persists, and the same thing happens on both mozilla-firefox-bin and PLD compiled package. -- Jan Rękorajski| PLD/Linux SysAdm | 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/icu/icu-67] - build icu67 packages, qt4 does not build correctly with gcc 11, so let's fulfill the icu dependenc
On Thu, 16 Sep 2021, Jan Palus wrote: > On 28.08.2021 10:46, baggins wrote: > > commit 2cee6d28a25b124dbe274691e5c3d5969b3514ec > > Author: Jan Rękorajski > > Date: Sat Aug 28 10:45:38 2021 +0200 > > > > - build icu67 packages, qt4 does not build correctly with gcc 11, so > > let's fulfill the icu dependency with this > > > > This package is somewhat problematic due to the way poldek works. On one > of my machines still with icu 67 that's what happened: > > harfbuzz-icu-2.8.2-1.x86_64 obsoleted by harfbuzz-icu-2.9.1-1.x86_64 > > > [256/384] > harfbuzz-icu-2.9.1-1.x86_64 marks libicu-69.1-1.x86_64 (cap > libicuuc.so.69()(64bit)) > libicu-67.1-1.x86_64 obsoleted by libicu-69.1-1.x86_64 >orphaned QtCore-4.8.7-28.x86_64 marks libicu67-67.1-4.x86_64 (cap libicu = > 67.1) > > QtCore pulled libicu67 to satisfy broken dep, but it also left plenty of > other packages depending on libicu in old version since libicu67 > satisfied broken dep. In other words upgrade of libicu to 69 does not > pull all packages that should be upgraded. This in turn will likely lead > to multiple libicu versions being loaded for a single application which > in turn means problems. That's unfortunate. I would happily get rid of this, but to do so, we need to figure a way to reliably rebuild qt using gcc 11 -- Jan Rękorajski| PLD/Linux SysAdm | 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: qt4 broken on i686
On Thu, 19 Aug 2021, Jakub Bogusz wrote:
> On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan Rękorajski wrote:
> > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> > infinite looping (ex. meinproc4 in kde4-kig).
> >
> > I'm running out of ideas[1] and time to troubleshoot this and would
> > appreciate if anyone would be willing to try and figure out WTF is
> > broken there.
> >
> > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> > glibc 2.34 issue, but I don't have resources at hand to validate it.
>
> I don't know yet if it's related to glibc, gcc or binutils, but simple
> testcase is searching in empty QMap:
>
> ```
> #include
>
> int main()
> {
> QMap mm;
> mm.constFind(999);
> }
> ```
>
> It hangs even on carme-x86_64.
>
> Issue is probably related to shared_null static field (SIOF?)
My take is on gcc 11. I downgraded everything but gcc and it still crashed.
To verify that it's indeed gcc I need to rebuild it (gcc) locally due to
intertwined deps preventing simple package downgrade.
--
Jan Rękorajski| PLD/Linux
SysAdm | 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: kodi rebuild error
On Fri, 20 Aug 2021, Krzysztof Mrozowicz via pld-devel-en wrote: > Hi, > I updated libfmt which caused a need to rebuild few other packages. > When I'm trying to rebuild kodi, I'm getting: > > rpm: error: Failed build dependencies: > rpm: squish-devel conflicts with kodi-18.4-5.x86_64 > > What should I do in this situation? I believe squish-devel needs to be > uninstalled from builders, but how can I do it? This should get uninstalled automatically, you hit a builder bug. Fixed now: http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=0=kodi=77157a1d-2efb-4149-acc0-4e7d2515e3ea=tail -- 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: BuildConflicts on builders
On Thu, 19 Aug 2021, Jan Palus wrote: > Did > http://git.pld-linux.org/?p=projects/pld-builder.new.git;a=commit;h=b2679a6 > land on builders yet? If not would it be possible to deploy it? Done. -- 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
qt4 broken on i686
New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or infinite looping (ex. meinproc4 in kde4-kig). I'm running out of ideas[1] and time to troubleshoot this and would appreciate if anyone would be willing to try and figure out WTF is broken there. [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a glibc 2.34 issue, but I don't have resources at hand to validate it. -- 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: TEST build ERRORS: gtk-webkit.spec
On Thu, 12 Aug 2021, Jan Palus wrote: > On 12.08.2021 04:45, PLD th-x86_64 builder wrote: > > gtk-webkit.spec (HEAD): FAILED > ... > > /usr/bin/ld: cannot find /usr/lib64/libXcomposite.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libXdamage.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libXfixes.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libXrender.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libXt.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libSM.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libuuid.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libICE.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libX11.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libxcb.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libXau.so: Too many open files > > /usr/bin/ld: cannot find /usr/lib64/libXdmcp.so: Too many open files > > /usr/bin/ld: cannot find -lbsd > > /usr/bin/ld: cannot find -ldl > > /usr/bin/ld: cannot find -lz > > /usr/bin/ld: cannot find /usr/lib64/libstdc++.so: Too many open files > > /usr/bin/ld: cannot find -lm > > /usr/bin/ld: cannot find -lc > > /usr/bin/ld: cannot find -lgcc_s > > /usr/bin/ld: cannot find /usr/lib64/gcc/x86_64-pld-linux/11.2.0/crtendS.o: > > Too many open files > > /usr/bin/ld: cannot find > > /usr/lib64/gcc/x86_64-pld-linux/11.2.0/../../../../lib64/crtn.o: Too many > > open files > > collect2: error: ld returned 1 exit status > > make[1]: *** [GNUmakefile:45096: libwebkitgtk-1.0.la] Error 1 > > make[1]: Leaving directory '/tmp/B.C1fudw/BUILD/webkitgtk-2.4.11' > > make: *** [GNUmakefile:30370: all] Error 2 > > error: Bad exit status from /tmp/B.C1fudw/BUILD/tmp/rpm-tmp.w010mY (%build) > > Would it be possible to raise limit of opened file descriptors on > builders? Seems that 4k is the best that can be done. I sent gtk-webkit test build, let's see if that is 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
PLD/Linux IRC channel moved to Libera Chat
After the recent events and freenode changes[1], PLD IRC channel has been moved to Libera Chat - https://libera.chat/ [1] Witnessed first hand: https://www.devever.net/~hl/freenode_suicide -- 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/rust] bump required libgit2 version
On Thu, May 27, 2021 at 4:19 PM atler wrote: > commit 1f9b856019ac20736ccec408a735866922e0748a > Author: Jan Palus > Date: Thu May 27 16:18:28 2021 +0200 > > bump required libgit2 version > > rust.spec | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Please bump also rust to 1.52.1, there is some breakage in 1.52.0 -- 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
rust on x32
Hi, Could someone with rust build chain knowlegde look at rust on x32? My findings so far are that it does not build with target x86_64-...-gnux32, so we would have to build the compiler for x86_64 and just the stdlib for gnux32, the docs say that rust is a cross compiler by default... so, should be doable even without pulling binary x32 stdlib for bootstrapping. I'll give it a shot if no one beats me to 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: glibc upgrade on builders + binaries colour with rpm.org [Re: ERRORS: COMMAND]
On Sun, 09 May 2021, Jakub Bogusz wrote: > I tried: > $ make-request -b 'th-x86_64 th-x32' -c 'poldek -n th-all -n th-ready-all -n > th-test-all -Uvg glibc' > > But poldek failed with "Aborted"... how to perform glibc upgrade on > th-x86_64 and th-x32? > > I want to upgrade because of messed colour of /usr/bin/iconv binary (to > see if it helps, or there is something wrong with colour selection in rpm.org) > - currently: > th-x32 contains 64-bit /usr/bin/iconv > th-x86_64 contains 32-bit /usr/bin/iconv > which don't use host native iconv modules (but require iconv modules from > matching binary ABI). $ make-request -b th-x86_64 -t -c 'poldek -n th-test -n th-i686-test -n th-x32-test -n th-ready -n th-i686-ready -n th-x32-ready -n th -n th-i686 -n th-x32 --up' $ make-request -b th-x86_64 -t -c 'poldek -O "particle install = no" -n th-test -n th-i686-test -n th-x32-test -n th-test -n th-i686-ready -n th-x32-ready -n th -n th-i686 -n th-x32 -uvg glibc-2.33-5.i686 glibc-2.33-5.x32 glibc-2.33-5.x86_64 ldconfig-2.33-5.x86_64 glibc-devel-utils-2.33-5.x86_64 --force' without --force install fails with Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0... Verifying... Preparing... file /sbin/glibc-postinst conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /sbin/sln conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/getconf conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/getent conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/iconv conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/locale conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/zdump conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/sbin/zic conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 Begin-PLD-Builder-Info For x32 it was: $ make-request -b th-x32 -t -c 'poldek -O "particle install = no" -n th-test -n th-i686-test -n th-x86_64-test -uvg glibc-2.33-5.i686 glibc-2.33-5.x32 glibc-2.33-5.x86_64 ldconfig-2.33-5.x32 --force' again, without --force fails with Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0... Verifying... Preparing... file /usr/bin/mtrace from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/bin/xtrace from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/share/man/ja/man1/mtrace.1.gz from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/share/man/ja/man1/sprof.1.gz from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/share/man/man1/mtrace.1.gz from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/share/man/man1/sprof.1.gz from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /sbin/glibc-postinst conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /sbin/sln conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/getconf conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/getent conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/iconv conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/locale conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/zdump conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/sbin/zic conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 Begin-PLD-Builder-Info -- 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/python-sympy] - up to 1.7.1, python 2 no longer supported
On Sat, 13 Mar 2021, Jakub Bogusz wrote: > On Fri, Mar 12, 2021 at 10:25:36AM +0100, Jan Rękorajski wrote: > > On Fri, Mar 12, 2021 at 9:55 AM Elan Ruusamäe wrote: > > > > > > > > On 12.03.2021 00:32, baggins wrote: > > > > commit a7afb2642f193eb728569b130fd57bdc8acadd02 > > > > Author: Jan Rękorajski > > > > Date: Thu Mar 11 23:32:30 2021 +0100 > > > > > > > > - up to 1.7.1, python 2 no longer supported > > > > > > > > python-sympy-nodisplay.patch | 25 - > > > > python-sympy.spec| 8 +++- > > > > 2 files changed, 3 insertions(+), 30 deletions(-) > > > > --- > > > > diff --git a/python-sympy.spec b/python-sympy.spec > > > > index cb6d2e4..6c9214c 100644 > > > > --- a/python-sympy.spec > > > > +++ b/python-sympy.spec > > > > @@ -2,20 +2,19 @@ > > > > # Conditional build: > > > > %bcond_without doc # HTML and PDF documentation > > > > %bcond_without tests # unit tests > > > > -%bcond_without python2 # CPython 2.x module > > > > +%bcond_with python2 # CPython 2.x module > > > > %bcond_without python3 # CPython 3.x module > > > > > > > > > > i agree with what qboosh has been doing in this cases: > > > > > > 1. git ssh copy python-foo to python3-foo > > > > > > 2. update python3-foo to be python3 only > > > > > > 3. update python3-foo to new version, stb > > > > > > 4. disable python3 from python-foo, relup, stb > > > > > > > And I very much do not agree with that. > > Python 2 must die. If upstream decides to drop python2 support, we should > > too, > > we should not keep old odd versions indefinitely[1]. This creates chaos > > because > > we end up with inconsistent mess. > > > > [1] We may, but only for a very strong reasons, ex. a ton of packages would > > break. > > Python 2 is dying, more and more (mostly very common) packages are dropping > support, > but there are still/will be "long tails" of not ported single packages. > > Mainstream is slowly porting from gtk+ 3 to gtk 4 and we still have gtk+ 1. > > Ofc, there is no sense to keep all active forever, python2 packages can > fade out from the "loose" (non-required) ends. > > For the active cases - as we didn't go Fedora way with renaming all > python 2.x packages to python2-*, I see two possibilities: > > a) python-foo.spec with python2-only module/version of module or python2/3 > modules > and python3-foo.spec with python3-only module/version of module > > b) python-foo.spec:master branch with python3-only module/version of module > or python2/3 modules > and python-foo.spec:PYTHON2 branch with last supported python2 version > > I personally prefer a) because: > - we can build all active packages from repo heads (I am aware of just two > exceptions from this "rule": kernel.spec and php.spec) > > - in case of python3-only spec, we need only one package preamble > (b) case requires dummy base package and "-n python3-foo" subpackage) > > In case of b), in python3-only cases apidocs should be packaged as > "%package -n python3-*-apidocs", not "%package apidocs". I'm fine with a) as long as we make sure to mark the old python2 package in a way there is no confusion that it's dead and should ot be built. My problem is that it's hard to keep up with all those packages and having both python- and python3- packages gets confusing. > > it takes extra steps to do that, but i think it's worth the effort in > > > long term. > > > > > > it's weird to have python-foo to build python3-foo, > > > and the python3-foo will be cleaner without having to support two python > > > versions. > > > > > > > What we should do here is to just drop python2 from python-foo, what I'll > > do once > > the dust after current 3.9 / rpm deps rebuild settles. > > Keeping dead python2 boilerplate in spec (just with bcond off) after updating > to python3-only version makes no sense... > > > As for establishing some python2/3 packaging/migration policy - where to > Obsolete python-* packages after dropping python2 variants? In the new python3-* package? At least that is what I've been doing so far. P.S. All this mess because of one person's obsession with unicode :( -- 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: pam 1.5
On Thu, 18 Feb 2021, Elan Ruusamäe wrote: > > On 17.02.2021 16:40, Elan Ruusamäe wrote: > > > > https://github.com/linux-pam/linux-pam/releases/tag/v1.5.0 > > > > > > * Removed deprecated pam_cracklib module, use pam_passwdqc (from > > passwdqc project) > > or pam_pwquality (from libpwquality project) instead. > > * Removed deprecated pam_tally and pam_tally2 modules, use > > pam_faillock instead. > > > > > > what's our action? > > > > 1. follow the flow and remove them as well? > > > > 2. alternatively could copy them from 1.4.0 tarball, so at least we > > don't lag behind because afraid to update to 1.5.x > > > > > > if someone really needs those removed modules, a separate .spec is > > more appropriate solution to the problem. > > > > there's also pam-pld-1.1.2-1.tar.gz included in pam.spec, there's no > info how that file was generated. > > could put the two new abandoned modules there as well. altho i feel > better to just create new tarball with tally and cracklib I would just drop them, my memory tells me pam_tally* were barely working at best and I don't see a problem moving from cracklib to passwdqc. The caveat is we would have to update all appropriate configs and add the package and all required deps. FYI pam-pld tarball comes from http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/pam/ -- 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/rpm-pld-macros] - fix typo in debugsource packages macro - rel 2
On Thu, 01 Apr 2021, Elan Ruusamäe wrote:
>
> On 01.04.2021 10:02, Bartek Szady wrote:
> >
> > Well...
> >
> > rpm --define '_debugsource_packages 0' --eval
> > '%{?%_debugsource_packages:%_debugsource_template}'
> >
> > worked as I had expected (it evaluated to nothing) not because
> > %_debugsource_packages was evaluated to false but because
> > %{%_debugsource_packages} was undefined :-(
> >
> >
> > Is there any way to undefine a macro in .rpmmacros ?
Disabling _debugsource_packages should work with rpm-pld-macros 2.005.
--
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: pull request for dhcp – fixed the init script
On Thu, 01 Apr 2021, Jan Rękorajski wrote: > On Thu, 01 Apr 2021, Paweł Zuzelski wrote: > > > On Wed, Mar 31, 2021 at 6:11 PM Elan Ruusamäe wrote: > > > On 31.03.2021 18:01, Paweł Zuzelski wrote: > > > > Hi all, > > > > > > > > Could someone please review and push https://github.com/pawelz/pld-dhcp > > > > specifically that commit: > > > > > > https://github.com/pawelz/pld-dhcp/commit/071ac6b61dedf115572076ad17bbbef53226b22c > > > > ? > > > > > > > > This change fixes broken init for dhcp6. > > > > > > > > It's been 10 years since I touched PLD, so I don't really feel > > comfortable > > > > pushing without supervision even if I still have access to the repo. > > > > > > you can push to a branch > > > > > > you can also open a pull request in github > > > > Ah, thank you. I haven't realized that those repos are actually hosted on > > github. I created a PR there. > > Well, github is just a mirror. I fetched and pushed your changes to PLD repo. > > BTW, don't worry about pushing directly, it's not irreversible. OTOH, how did you manage to build this antique? Some old ggc? http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=0=dhcp=e1ea81ba-b170-4cbc-b96e-79ce976fff46=tail -- 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: pull request for dhcp – fixed the init script
On Thu, 01 Apr 2021, Paweł Zuzelski wrote: > On Wed, Mar 31, 2021 at 6:11 PM Elan Ruusamäe wrote: > > On 31.03.2021 18:01, Paweł Zuzelski wrote: > > > Hi all, > > > > > > Could someone please review and push https://github.com/pawelz/pld-dhcp > > > specifically that commit: > > > > https://github.com/pawelz/pld-dhcp/commit/071ac6b61dedf115572076ad17bbbef53226b22c > > > ? > > > > > > This change fixes broken init for dhcp6. > > > > > > It's been 10 years since I touched PLD, so I don't really feel > comfortable > > > pushing without supervision even if I still have access to the repo. > > > > you can push to a branch > > > > you can also open a pull request in github > > Ah, thank you. I haven't realized that those repos are actually hosted on > github. I created a PR there. Well, github is just a mirror. I fetched and pushed your changes to PLD repo. BTW, don't worry about pushing directly, it's not irreversible. -- 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/rpm-pld-macros] - fix typo in debugsource packages macro - rel 2
On Wed, 31 Mar 2021, Jakub Bogusz wrote:
> On Wed, Mar 31, 2021 at 09:33:00PM +0200, baggins wrote:
> > commit 45c4eb111b114539bab16bd567a4a794d75d6e16
> > Author: Jan Rękorajski
> > Date: Wed Mar 31 21:32:32 2021 +0200
> >
> > - fix typo in debugsource packages macro
> > - rel 2
> >
> > macros.pld | 2 +-
> > rpm-pld-macros.spec | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> > ---
> [...]
> > @@ -138,7 +138,7 @@ pakietu oraz przy odpluskwianiu samego pakietu.\
> > %ifnarch noarch\
> > %global __debug_package 1\
> > %_debuginfo_template\
> > -%{?_debugsource_packages:%_debugsource_template}\
> > +%{?%_debugsource_packages:%_debugsource_template}\
> > %endif\
> > %{nil}
> >
>
> Uhm, is it really correct now?
> debug source files like these are unpackaged now:
>
> /usr/src/debug/gjs-1.68.0-1.x32
It's not, Reverted.
--
Jan Rękorajski| PLD/Linux
SysAdm | 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/rpm] - x32 patch fixes
On Tue, Mar 23, 2021 at 1:59 PM Jan Palus wrote:
> On 23.03.2021 08:53, baggins wrote:
> > commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> > Author: Jan Rękorajski
> > Date: Tue Mar 23 08:52:27 2021 +0100
> >
> > - x32 patch fixes
> >
> > x32.patch | 10 +++---
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> > ---
> > diff --git a/x32.patch b/x32.patch
> > index 38aa140..f7ab616 100644
> > --- a/x32.patch
> > +++ b/x32.patch
> > -@@ -190,10 +201,14 @@
> > - # skip architectures for which we dont have full config parameters
> > - [ -z "$CANONARCH" ] && continue
> > -
> > -- if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> > -+ if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> > +@@ -190,6 +201,10 @@
> > LIB=${LIB}64
> > fi
>
> This hunk should either be brought back or CANONCOLOR for x86_64 should
> be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.
>
Can you restore this hunk and rebuild rpm? I can't do it till evening :(
It should probably even be 'if [ "$OS" = "linux" ] && [ "$CANONARCH" =
"x86_64"] || [ "$CANONCOLOR" = 3 ]; then'
--
Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
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: rpm 4.16.1.2 from rpm.org has landed in Th
On Mon, 22 Mar 2021, Arkadiusz Miśkiewicz wrote:
> W dniu 22.02.2021 o 19:59, Jan Rękorajski pisze:
> > rpm 4.16.1.2 and all dependant packages are now available in th-test.
> >
> > More details about the update can be found on
> >
> > https://www.pld-linux.org/packages/rpm
> >
> > Th builders has been upgraded and all builds will now use rpm.org rpm.
> >
>
> rm /etc/mkshrc
> in poldek: install --reinstall mksh
>
> Doesn't put in /etc/mkshrc back in with 4.16.
>
> Is there a workaround? (I used this method to get configs from package
> back on the fs)
Looks WAI to me. Don't use 'missingok' for config files?
%config(noreplace,missingok) %verify(not md5 mtime size) %{_sysconfdir}/mkshrc
--
Jan Rękorajski| PLD/Linux
SysAdm | 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: rpm 4.16 landed -> errors!
On Wed, 17 Mar 2021, Neal Gompa wrote: > On Wed, Mar 17, 2021 at 2:48 PM Jan Rękorajski wrote: > > > > Neal, > > > > Do you have any references to such issues? Like bug reports, or docs? > > I'd like to link them to the rpm migration page on our wiki. > > > > Not offhand, but I know that this change to RPM[1] (and a few other > fun quirks of bdb) is what started causing things to trip up in > containers with rpmdb rebuilds. It should basically go away once the > conversion to sqlite rpmdb is done. There is information about how > OverlayFS handles directory renames in the Linux kernel > documentation[2]. This affected YUM too[3], though DNF has workarounds > built into it now[4]. For this specific issue, you can avoid this by > regenerating the container entirely from scratch instead of using an > upgrade to fix it. > > More generally, I advise being careful with OverlayFS and being > mindful of the pitfalls[2]. I personally use Btrfs instead, which > neatly avoids this and is a lot more performant. Thanks. > (As an aside, can someone rebase the DNF package manager stack in PLD? > It's pretty old and broken...) You mean this? I did an update of dnf packages recently. There are a few things left to do but most should be up to date. poldek:/all-avail> ls dnf* dnf-4.6.1-5.noarch dnf-automatic-4.6.1-5.noarch dnf-plugin-cow-0.0.2-1.noarch dnf-plugin-diff-1.1-1.noarch dnf-plugin-kickstart-4.0.13-2.noarch dnf-plugin-leaves-4.0.19-1.noarch dnf-plugin-local-4.0.19-1.noarch dnf-plugin-migrate-4.0.19-1.noarch dnf-plugin-ovl-0.0.3-1.noarch dnf-plugin-post-transaction-actions-4.0.19-1.noarch dnf-plugin-rpmconf-4.0.13-2.noarch dnf-plugin-show-leaves-4.0.19-1.noarch dnf-plugin-showvars-4.0.13-2.noarch dnf-plugin-snapper-4.0.13-2.noarch dnf-plugin-system-upgrade-4.0.13-2.noarch dnf-plugin-torproxy-4.0.13-2.noarch dnf-plugin-tracer-4.0.13-2.noarch dnf-plugin-versionlock-4.0.19-1.noarch dnf-plugins-core-4.0.19-1.noarch dnf-plugins-extras-common-4.0.13-2.noarch dnf-utils-4.0.19-1.noarch dnfdaemon-0.3.20-2.noarch -- Jan Rękorajski| PLD/Linux SysAdm | 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: rpm 4.16 landed -> errors!
On Tue, 16 Mar 2021, Neal Gompa wrote: > On Tue, Mar 16, 2021 at 1:39 PM Jan Rękorajski wrote: > > > > On Tue, 16 Mar 2021, Elan Ruusamäe wrote: > > > > > > > > On 16.03.2021 16:45, Elan Ruusamäe wrote: > > > > > > > > the automatic upgrade is failing: > > > > > > > > - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214 > > > > > > > oh, and user is left without rpmdb: > > > > > > > > > [@46a17bd0ade9 /]# rpm -q rpm poldek > > > warning: Found bdb Packages database while attempting sqlite backend: > > > using bdb backend. > > > warning: Generating 6 missing index(es), please wait... > > > package rpm is not installed > > > package poldek is not installed > > > > > > [@46a17bd0ade9 /]# rpm -q rpm poldek > > > warning: Found bdb Packages database while attempting sqlite backend: > > > using bdb backend. > > > package rpm is not installed > > > package poldek is not installed > > > [@46a17bd0ade9 /]# > > > > First, regarding lost database. > > You do have a backup of the database from before the update: > > > > Backup of the rpm database has been created in > > /var/lib/rpm.rpmbackup-4.16.1.2-6 > > > > There is also the new database, that rpm was unable to move: > > > > error: replace files in /var/lib/rpm with files from > > /var/lib/rpmrebuilddb.42 to recover > > > > Is /var/lib/rpm a mountpoint? That would be the explanation that comes > > to mind. There must be something that prevented rpm from renaming temporary > > directory in /var/lib to rpm. > > > > I've been (live) testing upgrade path and I assumed it does work. > > Never encountered problems after squashing rpm5 oddities. > > > > I've been also asking over and over for testing and no one came with any > > issues like this. > > > > This is probably an overlayfs specific issue, I've seen various > problems with renames (which is what rpm does for rebuilding > databases) in containers. Neal, Do you have any references to such issues? Like bug reports, or docs? I'd like to link them to the rpm migration page on our wiki. -- Jan Rękorajski| PLD/Linux SysAdm | 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/crossmingw32-pango] - rpm.org+meson combo require to redefine all dirs
On Tue, 16 Mar 2021, Jakub Bogusz wrote:
> On Sun, Mar 14, 2021 at 10:31:25PM +0100, qboosh wrote:
> > commit f5e59fe05417d0d72ef5e99cb896e81fdb32885a
> > Author: Jakub Bogusz
> > Date: Sun Mar 14 22:32:30 2021 +0100
> >
> > - rpm.org+meson combo require to redefine all dirs; disable debug
> > packages
> >
> > crossmingw32-pango.spec | 9 +
> > 1 file changed, 9 insertions(+)
> > ---
> > diff --git a/crossmingw32-pango.spec b/crossmingw32-pango.spec
> > index b0b1e43..5d32499 100644
> > --- a/crossmingw32-pango.spec
> > +++ b/crossmingw32-pango.spec
> > @@ -45,6 +45,14 @@ BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id
> > -u -n)
> > %define_libdir %{_prefix}/lib
> > %define_pkgconfigdir %{_prefix}/lib/pkgconfig
> > %define_dlldir /usr/share/wine/windows/system
> > +# rpm.org needs redefining these (redefining _prefix don't change them)
> > +%define_bindir %{_prefix}/bin
> > +%define_sbindir%{_prefix}/sbin
> > +%define_includedir %{_prefix}/include
> > +%define_libexecdir %{_prefix}/libexec
> > +%define_datadir%{_prefix}/share
> > +%define_infodir%{_datadir}/info
> > +%define_mandir %{_datadir}/man
> > %define__pkgconfig_provides%{nil}
> > %define__pkgconfig_requires%{nil}
> > # for meson 0.50+, keep __cc/__cxx as host compiler and pass %{target}-*
> > in meson-cross.txt
>
> In rpm5 packaging _*dir macros were defined relative to _prefix.
> In rpm.org rpm/platform/*-linux/macros files define absolute _*dir macros
> (instead of relative to %{_prefix}):
>
> | # configure macros.
> | #
> | %_prefix/usr
> | %_exec_prefix /usr
> | %_bindir/usr/bin
> | %_sbindir /usr/sbin
> | %_libexecdir/usr/libexec
> | %_datarootdir %{_prefix}/share
> | %_datadir /usr/share
> | %_sysconfdir/etc
> | %_sharedstatedir/var/lib
> | %_localstatedir /var
> | %_lib lib
> | %_libdir/usr/lib
> | %_includedir/usr/include
> | %_oldincludedir /usr/include
> | %_infodir /usr/share/info
> | %_mandir/usr/share/man
>
> Is it intentional change?
>
> meson doesn't allow --{bin,sbin,include,libexec,data,info,man}dir outside
> --prefix,
> so in case of cross* packages I needed to additionally redefine more macros,
> even
> though some dirs are not actually used (just %meson macro passes them).
Side effect. We had this defined in our macros.pld.in, in rpm.org it's
in the per-platform definitions created by the rpm.
I believe it should be pretty straighforward to patch platform.in to use
relative defs. Just add a patch.
--
Jan Rękorajski| PLD/Linux
SysAdm | 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: rpm 4.16 landed -> errors!
On Tue, 16 Mar 2021, Elan Ruusamäe wrote: > > On 16.03.2021 16:45, Elan Ruusamäe wrote: > > > > the automatic upgrade is failing: > > > > - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214 > > > oh, and user is left without rpmdb: > > > [@46a17bd0ade9 /]# rpm -q rpm poldek > warning: Found bdb Packages database while attempting sqlite backend: > using bdb backend. > warning: Generating 6 missing index(es), please wait... > package rpm is not installed > package poldek is not installed > > [@46a17bd0ade9 /]# rpm -q rpm poldek > warning: Found bdb Packages database while attempting sqlite backend: > using bdb backend. > package rpm is not installed > package poldek is not installed > [@46a17bd0ade9 /]# First, regarding lost database. You do have a backup of the database from before the update: Backup of the rpm database has been created in /var/lib/rpm.rpmbackup-4.16.1.2-6 There is also the new database, that rpm was unable to move: error: replace files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.42 to recover Is /var/lib/rpm a mountpoint? That would be the explanation that comes to mind. There must be something that prevented rpm from renaming temporary directory in /var/lib to rpm. I've been (live) testing upgrade path and I assumed it does work. Never encountered problems after squashing rpm5 oddities. I've been also asking over and over for testing and no one came with any issues like this. -- Jan Rękorajski| PLD/Linux SysAdm | 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/libmodulemd] - finished packaging - rel 1
On Sun, 14 Mar 2021, Elan Ruusamäe wrote:
>
> On 13.03.2021 23:08, baggins wrote:
> > commit 7e23c54ef08faf4f8e8c57688903d25d7b5aa6d4
> > Author: Jan Rękorajski
> > Date: Sat Mar 13 22:07:34 2021 +0100
> ...
> > +%package -n python2-%{name}
> > +Summary: Python 2 bindings for %{name}
>
> this is new, we have been consistent and packaging python 2 packages as
> python-, not python2-
>
>
> has this policy have been changed? are we massively migrating to that
> scheme?
>
> in some earlier email to pld-devel-en you wrote you target dropping
> python2 from th,
>
> so it does not make sense to start changing python 2 packaging scheme now.
>
>
> if there is packaging change, it should include clear announcement, and
> preferrably prior discussion.
It would cost you less energy to fix that copy-pasto than write a wall
of text of nitpicking.
--
Jan Rękorajski| PLD/Linux
SysAdm | 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/python-sympy] - up to 1.7.1, python 2 no longer supported
On Fri, Mar 12, 2021 at 9:55 AM Elan Ruusamäe wrote: > > On 12.03.2021 00:32, baggins wrote: > > commit a7afb2642f193eb728569b130fd57bdc8acadd02 > > Author: Jan Rękorajski > > Date: Thu Mar 11 23:32:30 2021 +0100 > > > > - up to 1.7.1, python 2 no longer supported > > > > python-sympy-nodisplay.patch | 25 - > > python-sympy.spec| 8 +++- > > 2 files changed, 3 insertions(+), 30 deletions(-) > > --- > > diff --git a/python-sympy.spec b/python-sympy.spec > > index cb6d2e4..6c9214c 100644 > > --- a/python-sympy.spec > > +++ b/python-sympy.spec > > @@ -2,20 +2,19 @@ > > # Conditional build: > > %bcond_without doc # HTML and PDF documentation > > %bcond_without tests # unit tests > > -%bcond_without python2 # CPython 2.x module > > +%bcond_with python2 # CPython 2.x module > > %bcond_without python3 # CPython 3.x module > > > > i agree with what qboosh has been doing in this cases: > > 1. git ssh copy python-foo to python3-foo > > 2. update python3-foo to be python3 only > > 3. update python3-foo to new version, stb > > 4. disable python3 from python-foo, relup, stb > And I very much do not agree with that. Python 2 must die. If upstream decides to drop python2 support, we should too, we should not keep old odd versions indefinitely[1]. This creates chaos because we end up with inconsistent mess. [1] We may, but only for a very strong reasons, ex. a ton of packages would break. it takes extra steps to do that, but i think it's worth the effort in > long term. > > it's weird to have python-foo to build python3-foo, > and the python3-foo will be cleaner without having to support two python > versions. > What we should do here is to just drop python2 from python-foo, what I'll do once the dust after current 3.9 / rpm deps rebuild settles. -- Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ 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: warning: tag 273 type(0x6) != implicit type(0x0)
On Tue, 09 Mar 2021, Elan Ruusamäe wrote: > |Upgrading... 1:ImageMagick-libs > ### [ 20%] 2:ImageMagick > ### [ 40%] ==> warning: tag 273 > type(0x6) != implicit type(0x0) 3:php53-pecl-imagick > ### [ 60%] what can you say > about those messages? 1. what does it mean? 2. what's the impact (what's > missing, what's broken) package itself seems okay, `php -m` shows the > module. | Harmless. This is RPMTAG_SHA256HEADER = RPMTAG_SIG_BASE+17, that does not exist in rpm5. So when rpm5 sees an unknown tag it assumes it should have no type and then emits the warning. -- Jan Rękorajski| PLD/Linux SysAdm | 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: OK: python-traceback2.spec
On Mon, 01 Mar 2021, Jan Palus wrote: > On 01.03.2021 01:18, Jan Rękorajski wrote: > > On Mon, 01 Mar 2021, Jan Palus wrote: > > > > > On 01.03.2021 01:08, Jan Rękorajski wrote: > > > > On Mon, 01 Mar 2021, Jan Palus wrote: > > > > > > > > > On 28.02.2021 23:29, PLD th-x86_64 builder wrote: > > > > > > python-traceback2.spec (HEAD): OK > > > > > > > > > > > > --- python-traceback2.spec:HEAD: > > > > > > upgrading packages > > > > > > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 > > > > > > non-io:334751) > > > > > > > > > > > > Files queued for ftp: > > > > > > 22657 python3-traceback2-1.4.0-4.noarch.rpm > > > > > > 19641 python-traceback2-1.4.0-4.noarch.rpm > > > > > >144 python-traceback2-1.4.0-4.src.rpm.uploadinfo > > > > > > > > > > > > > > > > Any idea why builders did not upgrade to this release (still on > > > > > 1.4.0-2)? > > > > > > > > Does not seem installed at all > > > > > > > > https://srcbuilder.pld-linux.org/th/queue.html#215039 > > > > > > Little confused then, what's the meaning of "rpm -qa of builder:" in > > > build details? ie: > > > > > > http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=qatxt > > > > Query done at: 2021-02-28 03:00:01.083405 > > > > Out of date? I can take a look at this tomorrow if no one beats me to it. > > Thanks that explains. Actually it made me realize that `rpm -qa` for > every build is the same global link. So far I was under impression that > `rpm -qa` would be done for each request before build or at least that > would make more sense to me. Can it be changed this way? That would require some reengineering. This is currently run on builders as a cronjob. http://git.pld-linux.org/?p=projects/pld-builder.new.git;a=blob;f=PLD_Builder/maintainer.py -- Jan Rękorajski| PLD/Linux SysAdm | 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: TEST build ERRORS: vtk.spec
On Mon, 01 Mar 2021, Jan Palus wrote: > On 01.03.2021 11:59, PLD th-src builder wrote: > > vtk.spec (HEAD): FAILED > > > > --- vtk.spec:HEAD: > > Build-Time: user:1.17s sys:0.84s real:7.29s (faults io:435 non-io:44415) > > > > > > > > *** buildlog for vtk.spec > > request from: atler > > started at: Mon Mar 1 12:59:52 2021 > > building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps > > --http --define '_pld_builder 1' -bs -r HEADvtk.spec 2>&1 > > > > Cloning into 'vtk'... > > Already on 'master' > > Your branch is up to date with 'origin/master'. > > Already up to date. > > sh: /usr/bin/tclsh: inaccessible or not found > > error: /home/users/builder/rpm/packages/vtk/vtk.spec: line 399: Macro > > %tcl_version has empty body > > Name (NVR) query failed > > internal error: cache_rpm_dump not called! (missing %prep?) > > internal error: cache_rpm_dump not called! (missing %prep?) > > internal error: cache_rpm_dump not called! (missing %prep?) > > internal error: cache_rpm_dump not called! (missing %prep?) > > internal error: cache_rpm_dump not called! (missing %prep?) > > internal error: cache_rpm_dump not called! (missing %prep?) > > WARNING! Spec name (vtk) does not agree with package name () > > I suppose tcl should be installed on src builder. That's half of the solution. The other half is to fix the macro to not expand to nothing. I'll take care of both. -- Jan Rękorajski| PLD/Linux SysAdm | 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: OK: python-traceback2.spec
On Mon, 01 Mar 2021, Jan Palus wrote: > On 01.03.2021 01:08, Jan Rękorajski wrote: > > On Mon, 01 Mar 2021, Jan Palus wrote: > > > > > On 28.02.2021 23:29, PLD th-x86_64 builder wrote: > > > > python-traceback2.spec (HEAD): OK > > > > > > > > --- python-traceback2.spec:HEAD: > > > > upgrading packages > > > > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751) > > > > > > > > Files queued for ftp: > > > > 22657 python3-traceback2-1.4.0-4.noarch.rpm > > > > 19641 python-traceback2-1.4.0-4.noarch.rpm > > > >144 python-traceback2-1.4.0-4.src.rpm.uploadinfo > > > > > > > > > > Any idea why builders did not upgrade to this release (still on > > > 1.4.0-2)? > > > > Does not seem installed at all > > > > https://srcbuilder.pld-linux.org/th/queue.html#215039 > > Little confused then, what's the meaning of "rpm -qa of builder:" in > build details? ie: > > http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=qatxt Query done at: 2021-02-28 03:00:01.083405 Out of date? I can take a look at this tomorrow if no one beats me to it. -- Jan Rękorajski| PLD/Linux SysAdm | 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: OK: python-traceback2.spec
On Mon, 01 Mar 2021, Jan Palus wrote: > On 28.02.2021 23:29, PLD th-x86_64 builder wrote: > > python-traceback2.spec (HEAD): OK > > > > --- python-traceback2.spec:HEAD: > > upgrading packages > > Build-Time: user:7.14s sys:1.64s real:8.86s (faults io:3 non-io:334751) > > > > Files queued for ftp: > > 22657 python3-traceback2-1.4.0-4.noarch.rpm > > 19641 python-traceback2-1.4.0-4.noarch.rpm > >144 python-traceback2-1.4.0-4.src.rpm.uploadinfo > > > > Any idea why builders did not upgrade to this release (still on > 1.4.0-2)? Does not seem installed at all https://srcbuilder.pld-linux.org/th/queue.html#215039 -- Jan Rękorajski| PLD/Linux SysAdm | 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/bind] Use relative symlinks, remove %attr for symlinks
On Sat, 27 Feb 2021, glen wrote: > commit bf478371683c84f5ab0a5c76d8b93427e2c3992a > Author: Elan Ruusamäe > Date: Sat Feb 27 22:04:20 2021 +0200 > > Use relative symlinks, remove %attr for symlinks > > All for rpm 4.16 compatibility: > > - Explicit %attr() mode not applicable to symlink > - Absolute symlink You don't need to do relative symlinks, I patched our rpm for this. http://git.pld-linux.org/gitweb.cgi?p=packages/rpm.git;a=commit;h=d42a01a648b725059ec32c6c369af2563f0fcb28 -- 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
noarch subpackages
$ testmvpkg ready PLD * ERR: kernel-4.4-4.4.258-1 moving would remove archs: th-noarch ERR: kernel-4.19-4.19.177-1 moving would remove archs: th-noarch ERR: kernel-4.14-4.14.222-1 moving would remove archs: th-noarch ERR: kernel-4.9-4.9.258-1 moving would remove archs: th-noarch ERR: kernel-5.4-5.4.100-1 moving would remove archs: th-noarch I've just had enough of the "if BLARGH BuildArch: noarch" BS. We have had an rpm that supports it for almost 10 years (maybe more, I can't remember if 4.4.9 didn't support it really). I am removing *all* contitionals on noarch subpackages and consecutively will drop %noarchpackage from rpm macros. Time to move on with the times, if anyone wants to support antiquated rpm version, please do it on a branch. -- 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: rpm.org python dependency generator
On Fri, 26 Feb 2021, Jan Rękorajski wrote: > On Fri, 26 Feb 2021, Jakub Bogusz wrote: > > > What about python provides change (python3egg vs python3dist, probably > > similarly for python2)? > > > > While python3 packaged will be rebuilt anyway due to python 3.9, there > > is no need to rebuild python2 packages (other than provides scheme > > change). > > I'm inclined to switch. We don't use those deps in *Requires, and since > we already have to rebuild ~1000 packages for python3 upgrade, we can as > well rebuild everything. A side effect will be rpm.org ecosystem > compatible dependencies. One more thing, rpm5 had directory dependencies, while rpm.org does not, so those versioned pythonX.Ydist() deps are the way forward to figure out that we need a version related update. -- 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: rpm.org python dependency generator
On Fri, 26 Feb 2021, Jakub Bogusz wrote: > What about python provides change (python3egg vs python3dist, probably > similarly for python2)? > > While python3 packaged will be rebuilt anyway due to python 3.9, there > is no need to rebuild python2 packages (other than provides scheme > change). I'm inclined to switch. We don't use those deps in *Requires, and since we already have to rebuild ~1000 packages for python3 upgrade, we can as well rebuild everything. A side effect will be rpm.org ecosystem compatible dependencies. -- 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
