From glen at pld-linux.org Sun Nov 1 08:12:07 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 1 Nov 2020 09:12:07 +0200 Subject: rpm4 on carme* In-Reply-To: <20201027222117.GA77656@tachikoma.lan> References: <20201027222117.GA77656@tachikoma.lan> Message-ID: <7203e08d-af41-0c41-a297-2ef0fe464d07@pld-linux.org> On 10/28/20 12:21 AM, Jan R?korajski wrote: > All carme machines are now running rpm 4.16.0. Please test and report > any issues. > [~/rpm/packages/php(ERR) (PHP_5_6)?] ? rpm --version RPM version 4.16.0 [~/rpm/packages/php(ERR) (PHP_5_6)?] ? rpm -q rpm rpm-4.16.0-0.4.x86_64 php.spec @PHP_5_6: warning: line 423: It's not recommended to have unversioned Obsoletes: Obsoletes:?????? phpfi warning: line 439: It's not recommended to have unversioned Obsoletes: Obsoletes:?????? phpfi error: line 527: Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php error: line 527: Only package names are allowed in Obsoletes: Obsoletes:??????? /usr/bin/php error: query of specfile php.spec failed, can't parse php.spec @master: warning: Macro expanded in comment on line 161: %{orgname}-%{version}.tar.xz warning: line 378: It's not recommended to have unversioned Obsoletes: Obsoletes:?????? phpfi error: line 466: Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php error: line 466: Only package names are allowed in Obsoletes: Obsoletes:??????? /usr/bin/php error: query of specfile php.spec failed, can't parse [~/rpm/packages/php(ERR) (master)?] ? From glen at pld-linux.org Sun Nov 1 08:23:36 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 1 Nov 2020 09:23:36 +0200 Subject: rpm4 on carme* In-Reply-To: <20201027222117.GA77656@tachikoma.lan> References: <20201027222117.GA77656@tachikoma.lan> Message-ID: On 10/28/20 12:21 AM, Jan R?korajski wrote: > All carme machines are now running rpm 4.16.0. Please test and report > any issues. i've created wiki section for this topic. https://www.pld-linux.org/packages/rpm#rpm_416_porting_status perhaps we can keep it updated, with documenting at least incompatible changes (changes we have no plans to fix) From qboosh at pld-linux.org Sun Nov 1 15:02:14 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 1 Nov 2020 15:02:14 +0100 Subject: rpm4 on carme* In-Reply-To: References: <20201027222117.GA77656@tachikoma.lan> Message-ID: <20201101140214.GA12380@mail> On Sun, Nov 01, 2020 at 09:23:36AM +0200, Elan Ruusam?e wrote: > > On 10/28/20 12:21 AM, Jan R?korajski wrote: > >All carme machines are now running rpm 4.16.0. Please test and report > >any issues. > > i've created wiki section for this topic. > > > https://www.pld-linux.org/packages/rpm#rpm_416_porting_status > > > perhaps we can keep it updated, with documenting at least incompatible > changes (changes we have no plans to fix) One such change, just found accidentally (libreoffice.spec) - spaces around operators in BR were used because of preferred style, in rpm.org they are obligatory: -%{?with_system_hunspell:BuildRequires: hunspell-devel >=1.2.2} +%{?with_system_hunspell:BuildRequires: hunspell-devel >= 1.2.2} Original notation caused parse error. (no need to change anything in rpm, just fix a few(?) specs in repo) -- Jakub Bogusz http://qboosh.pl/ From gotar at polanet.pl Tue Nov 3 05:18:11 2020 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 3 Nov 2020 05:18:11 +0100 Subject: glibc-ldconfig => glibc-ld reconsiderations Message-ID: <20201103041811.GA10777@polanet.pl> Hello, today I've come into the issue related to the commit: http://git.pld-linux.org/gitweb.cgi?p=packages/glibc.git;a=commitdiff;h=4139e8458f99923b5290c8ce523d5d801c135ced During the upgrade of some older machine I've been put (sure, with some --nodeps --force -N magic due to the state of the system) into such condition: Upgrading... glibc-libcrypt ################################################## glibc ################################################## sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference /bin/sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference error: %trigger(glibc-2.32-6.x86_64) scriptlet failed, exit status 127 sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference /bin/sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference error: %trigger(glibc-2.32-6.x86_64) scriptlet failed, exit status 127 sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference /bin/sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference error: %trigger(glibc-2.32-6.x86_64) scriptlet failed, exit status 127 localedb-src ################################################## sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference /bin/sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference error: %post(localedb-src-2.32-6.x86_64) scriptlet failed, exit status 127 iconv ################################################## glibc-misc ################################################## glibc-devel ################################################## /bin/run-parts: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference Putting aside the reasons and a way I did this and fixed afterwards, I think this shows that ldconfig is NOT coupled with dynamic linker MORE than the linker to the library. Since apparently glibc and /%{_lib}/ld-linux.so.2 are not separatable, I hereby ask for reverting this commit. -- Tomasz Pala From qboosh at pld-linux.org Tue Nov 3 17:03:54 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 3 Nov 2020 17:03:54 +0100 Subject: glibc-ldconfig => glibc-ld reconsiderations In-Reply-To: <20201103041811.GA10777@polanet.pl> References: <20201103041811.GA10777@polanet.pl> Message-ID: <20201103160354.GA7835@mail> On Tue, Nov 03, 2020 at 05:18:11AM +0100, Tomasz Pala wrote: > Hello, > > today I've come into the issue related to the commit: > > http://git.pld-linux.org/gitweb.cgi?p=packages/glibc.git;a=commitdiff;h=4139e8458f99923b5290c8ce523d5d801c135ced > > During the upgrade of some older machine I've been put (sure, with some > --nodeps --force -N magic due to the state of the system) into such > condition: > > > Upgrading... > glibc-libcrypt ################################################## > glibc ################################################## > sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > /bin/sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > error: %trigger(glibc-2.32-6.x86_64) scriptlet failed, exit status 127 > sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > /bin/sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf > version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference error: %trigger(glibc-2.32-6.x86_64) scriptlet failed, exit status 127 > sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > /bin/sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > error: %trigger(glibc-2.32-6.x86_64) scriptlet failed, exit status 127 > localedb-src ################################################## > sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > /bin/sh: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > error: %post(localedb-src-2.32-6.x86_64) scriptlet failed, exit status 127 > iconv ################################################## > glibc-misc ################################################## > glibc-devel ################################################## > /bin/run-parts: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference > > > Putting aside the reasons and a way I did this and fixed afterwards, > I think this shows that ldconfig is NOT coupled with dynamic > linker MORE than the linker to the library. > > Since apparently glibc and /%{_lib}/ld-linux.so.2 are not separatable, I > hereby ask for reverting this commit. Original reasons were in this thread: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2018-October/025628.html http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2018-October/025650.html But the solution is wrong because of the above link time references. For me it seems that better way would be to: - revert this commit - disable AutoReqProv for ldcondig - add "Confilicts: glibc < (version before introducing rtld(GNU_HASH))" instead -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Tue Nov 3 20:55:04 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 3 Nov 2020 20:55:04 +0100 Subject: rpm4 on carme* In-Reply-To: <20201101140214.GA12380@mail> References: <20201027222117.GA77656@tachikoma.lan> <20201101140214.GA12380@mail> Message-ID: <20201103195504.GA11965@mail> More differences/issues: * patch run with different args: --no-backup-if-mismatch '--fuzz=0' - there is no .orig file when patching fails, so updating patches needs more effort - fuzz=0 will require updating many patches in repo * rpmbuild with non-UTF-8 locale in environment fails on some packages with gettext catalogs, e.g.: Pakiet libreoffice-i18n-cs: nieprawid?owe kodowanie utf-8 w| Classdict: GNU message catalog (little endian), revision 0.0, 674 messages, Project-Id-Version: PACKAGE VERSION 'Barva textu aktivn??ho v??b?\233ru' -- B??dny lub niepe?ny znak wielobajtowy It's side effect of libmagic trying to extract too many information in rules for "gnu" files; I'm going to patch Magdir/gnu rules and disable printing of text next to Project-Id-Version. I don't know what it was meant for, but it doesn't show anything useful now (just some semi-random translation). * absolute symlinks are reported as warning (even if they cross /) (my personal preference is to use relative symlinks unless they cross /, in which case I prefer absolute ones) * symlinks are always packaged with 777 mode and using %attr() for symlink is reported as warning -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Fri Nov 6 13:11:44 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 6 Nov 2020 14:11:44 +0200 Subject: build logs missing Message-ID: build logs appear to be missing. last entry 7 days ago - http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=neovim&id=975831a2-5126-44fc-aaa9-ff309f1ccd60&action=tail - http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&ns=&cnt=50&off=0 From glen at pld-linux.org Fri Nov 6 13:38:34 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 6 Nov 2020 14:38:34 +0200 Subject: [packages/rpm/rpm.org] - drop lua hacks and look for default lua version - don't obsolete rpm-getdeps, this rpm does not su In-Reply-To: <20201024163002.GD2270@starbug> References: <56b257d37fdc0fc47edc11d3db8abd38239a0cef_refs_heads_rpm.org@pld-linux.org> <20201024153404.h2svmopef4tnequ5@kalarepa> <20201024163002.GD2270@starbug> Message-ID: <37525782-d858-807f-6f06-98aba8bac0da@pld-linux.org> On 24.10.2020 19:30, Jan R?korajski via pld-devel-en wrote: > TBH lua packaging in PLD is a mess. I'm going to drasticly simplify it > by gradually getting rid of all versioned luaXX packages. another sign of the mess: ? rpm -q --what-provides lua-devel lua50-devel-5.0.3-5.x86_64 lua51-devel-5.1.5-6.x86_64 lua54-devel-5.4.1-2.x86_64 ? could we have template-specs/lua.spec which documents current style lua packages be written? 1. lua-devel >= 5.1 2. lua51-devel 3. pkgconfig(lua) >= 5.1 4. ... ? From glen at pld-linux.org Fri Nov 6 14:10:17 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 6 Nov 2020 15:10:17 +0200 Subject: [packages/rpm/rpm.org] - drop lua hacks and look for default lua version - don't obsolete rpm-getdeps, this rpm does not su In-Reply-To: <20201024163002.GD2270@starbug> References: <56b257d37fdc0fc47edc11d3db8abd38239a0cef_refs_heads_rpm.org@pld-linux.org> <20201024153404.h2svmopef4tnequ5@kalarepa> <20201024163002.GD2270@starbug> Message-ID: <7e17029d-9f4e-e709-de3d-77cba3ac5588@pld-linux.org> On 24.10.2020 19:30, Jan R?korajski via pld-devel-en wrote: > TBH lua packaging in PLD is a mess. I'm going to drasticly simplify it > by gradually getting rid of all versioned luaXX packages. this makes litle sense what is now, seems only 5.1 is present and it's assumed as a default version: $ rpm -qpl lua-lpeg-0.12.2-1.x86_64.rpm /usr/lib64/lua/5.1/lpeg.so /usr/lib64/lua/5.1/lpeg.so.0.12.2 /usr/share/doc/lua-lpeg-0.12.2 /usr/share/doc/lua-lpeg-0.12.2/HISTORY.gz /usr/share/doc/lua-lpeg-0.12.2/lpeg-128.gif /usr/share/doc/lua-lpeg-0.12.2/lpeg.html /usr/share/doc/lua-lpeg-0.12.2/re.html /usr/share/doc/lua-lpeg-0.12.2/test.lua.gz /usr/share/lua/5.1/re.lua the packages should be versioned with lua version, or only one version be included in distro. also, there's luajit, which is (i think) same language level as lua 5.3. From glen at pld-linux.org Fri Nov 6 14:19:33 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 6 Nov 2020 15:19:33 +0200 Subject: [packages/rpm/rpm.org] - drop lua hacks and look for default lua version - don't obsolete rpm-getdeps, this rpm does not su In-Reply-To: <20201024163002.GD2270@starbug> References: <56b257d37fdc0fc47edc11d3db8abd38239a0cef_refs_heads_rpm.org@pld-linux.org> <20201024153404.h2svmopef4tnequ5@kalarepa> <20201024163002.GD2270@starbug> Message-ID: On 24.10.2020 19:30, Jan R?korajski via pld-devel-en wrote: > TBH lua packaging in PLD is a mess. I'm going to drasticly simplify it > by gradually getting rid of all versioned luaXX packages. also packaging should add lua-x.y.pc pkgconfig path, so would not need to maintain patches in projects like this: -LUA_INCLUDE := $(shell $(PKG_CONFIG) --cflags lua-$(LUA_VERSION_MAJ_MIN) 2>/dev/null || echo "-I/usr/include/lua$(LUA_VER -LUA_LIB := $(shell $(PKG_CONFIG) --libs lua-$(LUA_VERSION_MAJ_MIN) 2>/dev/null || echo "-llua$(LUA_VERSION_MAJ_MIN)") +LUA_INCLUDE := $(shell $(PKG_CONFIG) --cflags lua$(LUA_VERSION_MAJ_MIN) 2>/dev/null || echo "-I/usr/include/lua$(LUA_VERS +LUA_LIB := $(shell $(PKG_CONFIG) --libs lua$(LUA_VERSION_MAJ_MIN) 2>/dev/null || echo "-llua$(LUA_VERSION_MAJ_MIN)") ?INCLUDES = $(LUA_INCLUDE) From glen at pld-linux.org Fri Nov 6 14:54:54 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 6 Nov 2020 15:54:54 +0200 Subject: rpm4 on carme* In-Reply-To: <20201027222117.GA77656@tachikoma.lan> References: <20201027222117.GA77656@tachikoma.lan> Message-ID: <19184536-a268-9229-c138-d6f4bb0cbf0f@pld-linux.org> On 28.10.2020 00:21, Jan R?korajski wrote: > All carme machines are now running rpm 4.16.0. Please test and report > any issues. > --blink option is gone. the option was useful to tell what was previous version installed of the same package. $ rpm -q libvterm --blink rpm: --blink: unknown option From qboosh at pld-linux.org Fri Nov 6 15:36:25 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 6 Nov 2020 15:36:25 +0100 Subject: build logs missing In-Reply-To: References: Message-ID: <20201106143625.GA13642@mail> On Fri, Nov 06, 2020 at 02:11:44PM +0200, Elan Ruusam?e wrote: > build logs appear to be missing. last entry 7 days ago > > > - > http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=neovim&id=975831a2-5126-44fc-aaa9-ff309f1ccd60&action=tail > > - > http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&ns=&cnt=50&off=0 Probably related to tons of "builder queue problem" emails with content like: | there were problems sending files from queue | /home/users/builderth/pld-builder.new/spool/buildlogs: | problems: | [src: | /home/users/builderth/pld-builder.new/spool/buildlogs/th-i686.6e721a93-e258-4b58-b9f7-f7ed931b29ef.openjdk11.spec.log] | | sending incremental file list | rsync: [generator] failed to set permissions on | "/openjdk11,6e721a93-e258-4b58-b9f7-f7ed931b29ef.bz2" (in | pld-buildlogs-th-i686): Operation not supported (95) -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Fri Nov 6 15:38:16 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 6 Nov 2020 15:38:16 +0100 Subject: [packages/rpm/rpm.org] - drop lua hacks and look for default lua version - don't obsolete rpm-getdeps, this rpm does not su In-Reply-To: <37525782-d858-807f-6f06-98aba8bac0da@pld-linux.org> References: <56b257d37fdc0fc47edc11d3db8abd38239a0cef_refs_heads_rpm.org@pld-linux.org> <20201024153404.h2svmopef4tnequ5@kalarepa> <20201024163002.GD2270@starbug> <37525782-d858-807f-6f06-98aba8bac0da@pld-linux.org> Message-ID: <20201106143816.GB13642@mail> On Fri, Nov 06, 2020 at 02:38:34PM +0200, Elan Ruusam?e wrote: > On 24.10.2020 19:30, Jan R?korajski via pld-devel-en wrote: > > >TBH lua packaging in PLD is a mess. I'm going to drasticly simplify it > >by gradually getting rid of all versioned luaXX packages. > > > another sign of the mess: > > ??? rpm -q --what-provides lua-devel > > lua50-devel-5.0.3-5.x86_64 > lua51-devel-5.1.5-6.x86_64 > lua54-devel-5.4.1-2.x86_64 Uh, my fault with missing %if ... %endif clauses in recent changes in lua40.spec and lua51.spec (in which I wanted to drop lua-devel provides). -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Fri Nov 6 15:43:36 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 6 Nov 2020 15:43:36 +0100 Subject: [packages/rpm/rpm.org] - drop lua hacks and look for default lua version - don't obsolete rpm-getdeps, this rpm does not su In-Reply-To: <20201106143816.GB13642@mail> References: <56b257d37fdc0fc47edc11d3db8abd38239a0cef_refs_heads_rpm.org@pld-linux.org> <20201024153404.h2svmopef4tnequ5@kalarepa> <20201024163002.GD2270@starbug> <37525782-d858-807f-6f06-98aba8bac0da@pld-linux.org> <20201106143816.GB13642@mail> Message-ID: <20201106144336.GC13642@mail> On Fri, Nov 06, 2020 at 03:38:16PM +0100, Jakub Bogusz wrote: > On Fri, Nov 06, 2020 at 02:38:34PM +0200, Elan Ruusam?e wrote: > > On 24.10.2020 19:30, Jan R?korajski via pld-devel-en wrote: > > > > >TBH lua packaging in PLD is a mess. I'm going to drasticly simplify it > > >by gradually getting rid of all versioned luaXX packages. > > > > > > another sign of the mess: > > > > ??? rpm -q --what-provides lua-devel > > > > lua50-devel-5.0.3-5.x86_64 > > lua51-devel-5.1.5-6.x86_64 > > lua54-devel-5.4.1-2.x86_64 > > Uh, my fault with missing %if ... %endif clauses in recent changes in > lua40.spec and lua51.spec (in which I wanted to drop lua-devel > provides). Fixed in lua40-4.0.1-13. lua51.spec was already OK (since lua51-5.1.5-7). lua50.spec also provides lua-devel only when built with default_lua, but this package was not present in Th. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Fri Nov 6 16:46:23 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 6 Nov 2020 16:46:23 +0100 Subject: [th-admin@pld-linux.org: [all] builder queue problem] Message-ID: <20201106154623.GA15284@mail> Who is able to fix it? ----- Forwarded message from PLD all builder ----- From: PLD all builder X-PLD-Builder: all To: th-admin at pld-linux.org, jpalus at fastmail.com, qboosh at pld-linux.org, arekm at pld-linux.org, glen at pld-linux.org Date: Fri, 06 Nov 2020 15:44:09 +0000 Subject: [all] builder queue problem there were problems sending files from queue /home/users/builderth/pld-builder.new/spool/buildlogs: problems: [src: /home/users/builderth/pld-builder.new/spool/buildlogs/th-i686.6e721a93-e258-4b58-b9f7-f7ed931b29ef.openjdk11.spec.log] sending incremental file list rsync: [generator] failed to set permissions on "/openjdk11,6e721a93-e258-4b58-b9f7-f7ed931b29ef.bz2" (in pld-buildlogs-th-i686): Operation not supported (95) sent 124 bytes received 186 bytes 206.67 bytes/sec total size is 116,001 speedup is 374.20 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=3.2.3] [src: /home/users/builderth/pld-builder.new/spool/buildlogs/th-i686.C180FFC5-F623-4893-A2C5-FF510AC06FF3.alien.spec.log] sending incremental file list th-i686.C180FFC5-F623-4893-A2C5-FF510AC06FF3.alien.spec.log rsync: [receiver] failed to set permissions on "/.alien,C180FFC5-F623-4893-A2C5-FF510AC06FF3.bz2.HgbMHo" (in pld-buildlogs-th-i686): Operation not supported (95) sent 3,171 bytes received 209 bytes 2,253.33 bytes/sec total size is 3,007 speedup is 0.89 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=3.2.3] [src: /home/users/builderth/pld-builder.new/spool/buildlogs/th-i686.26e08e9b-4ddf-466a-8181-babe17566b88.percona-server.spec.log] [...] ----- End forwarded message ----- -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Fri Nov 6 17:40:48 2020 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Fri, 6 Nov 2020 17:40:48 +0100 Subject: [th-admin@pld-linux.org: [all] builder queue problem] In-Reply-To: <20201106154623.GA15284@mail> References: <20201106154623.GA15284@mail> Message-ID: <7f348f69-76d7-fb20-9009-642fa16fb43a@maven.pl> W dniu 06.11.2020 o?16:46, Jakub Bogusz pisze: > Who is able to fix it? https://sourceware.org/bugzilla/show_bug.cgi?id=26401 workaround in rsync added and installed on buildlogs. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Fri Nov 6 20:49:56 2020 From: atler at pld-linux.org (Jan Palus) Date: Fri, 6 Nov 2020 20:49:56 +0100 Subject: rpm4 on carme* In-Reply-To: <20201027222117.GA77656@tachikoma.lan> References: <20201027222117.GA77656@tachikoma.lan> Message-ID: <20201106194956.v2un4kbwxcecdrvu@kalarepa> On 27.10.2020 23:21, Jan R?korajski wrote: > All carme machines are now running rpm 4.16.0. Please test and report > any issues. * poldek appears to still enforce directory deps while rpms does not (that concerns mainly /usr/lib/.build-id subdirs) * rpm.org is missing %{__ln} macro. spotted only single occurrence in xrdp.spec From qboosh at pld-linux.org Sat Nov 7 20:41:33 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 7 Nov 2020 20:41:33 +0100 Subject: th-i686: non-deterministic libreoffice build failures Message-ID: <20201107194133.GA20167@stranger.qboosh.pl> - 2 times libreoffice-6.4.7.2-1 build succeeded (test build for the first time, but production build only for third time) - first production build try failed with: [build UNO] oovbaapi mkdir -p /tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/workdir/UnoApiTarget/ && RESPONSEFILE=/tmp/B.EyZchp/BUILD/tmp/gbuild.bLZ8Ja && LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"/tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/instdir/program:/tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/instdir/program" /tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/workdir/LinkTarget/Executable/unoidl-write /tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/workdir/UnoApiTarget/udkapi.rdb /tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/workdir/UnoApiTarget/offapi.rdb /tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/oovbaapi @${RESPONSEFILE} /tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/workdir/UnoApiTarget/oovbaapi.rdb && rm -f ${RESPONSEFILE} Bad input : cannot parse line 36: "out-of-range long-typed constant ooo.vba.word.WdMappedDataFields.wdJobTitle value 18444492273895866368" make[1]: *** [/tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/solenv/gbuild/UnoApiTarget.mk:45: /tmp/B.EyZchp/BUILD/libreoffice-6.4.7.2/workdir/UnoApiTarget/oovbaapi.rdb] Error 1 libreoffice-6.4.7.2/oovbaapi/ooo/vba/word/WdMappedDataFields.idl:36 is: const long wdJobTitle = 8; so where 18444492273895866368 (0xfff8000000000000) comes from? - second production build try failed with: [build GAL] txtshapes S=/tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2 && I=$S/instdir && W=$S/workdir && rm -f $W/Gallery/txtshapes/* && RESPONSEFILE=/tmp/B.u63hZR/BUILD/tmp/gbuild.w3RGKM && ( LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program" $I/program/gengal.bin --build-tree --destdir file://$S/extras/source/gallery --name "txtshapes" --path $W/Gallery/txtshapes --filenames file://$RESPONSEFILE ) && rm $RESPONSEFILE && touch $W/Gallery/txtshapes.done Work on gallery 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/workdir/Gallery/txtshapes' Existing themes: 0 Existing themes: 1 Using DestDir: file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Circle01-DarkBlue.svg' (1) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Circle02-LightBlue.svg' (2) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Circle03-Green.svg' (3) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Circle04-DarkRed.svg' (4) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Circle05-Orange.svg' (5) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Hexagon01-DarkBlue.svg' (6) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Hexagon02-Blue.svg' (7) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Hexagon03-Green.svg' (8) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Hexagon04-DarkRed.svg' (9) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Hexagon05-Orange.svg' (10) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Leaf01-DarkBlue.svg' (11) Imported file 'file:///tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/extras/source/gallery/txtshapes/Leaf02-LightBlue.svg' (12) Illegal instruction make[1]: *** [/tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/solenv/gbuild/Gallery.mk:55: /tmp/B.u63hZR/BUILD/libreoffice-6.4.7.2/workdir/Gallery/txtshapes.done] Error 132 Non-deterministic "Illegal instruction" looks strange... Isn't it some hardware (memory/CPU/overheating) problem? -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Sat Nov 7 21:08:21 2020 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Sat, 7 Nov 2020 21:08:21 +0100 Subject: th-i686: non-deterministic libreoffice build failures In-Reply-To: <20201107194133.GA20167@stranger.qboosh.pl> References: <20201107194133.GA20167@stranger.qboosh.pl> Message-ID: <93bbec57-5d08-3293-a2db-6239c4f44b5e@maven.pl> W dniu 07.11.2020 o?20:41, Jakub Bogusz pisze: > - 2 times libreoffice-6.4.7.2-1 build succeeded (test build for the > first time, but production build only for third time) > Isn't it some hardware (memory/CPU/overheating) problem? Seems so :/ > [19931.491454] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 1.629 msecs > [19942.574679] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 1.699 msecs > [21077.039482] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) > [21473.484527] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 1.913 msecs > [92395.657432] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 1.980 msecs > [94015.850608] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.110 msecs > [98816.923495] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) > [103682.947948] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) > [106632.756009] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 5.010 msecs > [110604.168949] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 3.628 msecs > [194820.091834] traps: gengal.bin[1793] trap invalid opcode ip:f5ec05ae sp:ffbae130 error:0 > [194820.091845] in libvcllo.so[f5e85000+58e000] > [197048.485216] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) > [202937.058984] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 6.038 msecs > [271665.277752] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) > [283391.859836] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.533 msecs -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Tue Nov 10 18:18:43 2020 From: atler at pld-linux.org (Jan Palus) Date: Tue, 10 Nov 2020 18:18:43 +0100 Subject: rpm4 on carme* In-Reply-To: <20201106194956.v2un4kbwxcecdrvu@kalarepa> References: <20201027222117.GA77656@tachikoma.lan> <20201106194956.v2un4kbwxcecdrvu@kalarepa> Message-ID: <20201110171843.cwfwxku2w27ytljj@pine> On 06.11.2020 20:49, Jan Palus wrote: > On 27.10.2020 23:21, Jan R?korajski wrote: > > All carme machines are now running rpm 4.16.0. Please test and report > > any issues. > > * poldek appears to still enforce directory deps while rpms does not > (that concerns mainly /usr/lib/.build-id subdirs) > > * rpm.org is missing %{__ln} macro. spotted only single occurrence in > xrdp.spec * missing __bash macro * most noarch conditions stopped working now since 4.16 < 4.6 From qboosh at pld-linux.org Tue Nov 10 18:45:10 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 10 Nov 2020 18:45:10 +0100 Subject: th-x86_64: strange runtime linker failure Message-ID: <20201110174510.GA4455@stranger.qboosh.pl> I'm trying to debug libgda5 build failure: | + javac getsp.java | javac: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory | error: Bad exit status from /tmp/B.4ZeOy1/BUILD/tmp/rpm-tmp.33887 (%build) /usr/bin/javac is a symlink to /usr/lib64/jvm/icedtea8-3.17.0/bin/javac and ldd shows: | linux-vdso.so.1 (0x00007fff6bad1000) | libjli.so => /usr/lib64/jvm/icedtea8-3.17.0/bin/../lib/amd64/jli/libjli.so (0x00007f5c2ce8f000) | libc.so.6 => /lib64/libc.so.6 (0x00007f5c2cc5b000) | libz.so.1 => /lib64/libz.so.1 (0x00007f5c2cc41000) | libdl.so.2 => /lib64/libdl.so.2 (0x00007f5c2cc3b000) | libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5c2cc1a000) | /lib64/ld-linux-x86-64.so.2 (0x00007f5c2cea7000) libjli.so is found by $ORIGIN/../lib/amd64/jli RPATH. But: | $ /usr/lib64/jvm/icedtea8-3.17.0/bin/javac -help | /usr/lib64/jvm/icedtea8-3.17.0/bin/javac: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory `strace -f /usr/lib64/jvm/icedtea8-3.17.0/bin/javac -help` shows something strange: | # src : https://buildlogs.pld-linux.org/pld/th/x86_64/FAIL/command,bd4d8466-aafa-4f38-ab38-45d3dd906832.bz2 | # date : 2020/11/10 18:21:26 | execve("/usr/lib64/jvm/icedtea8-3.17.0/bin/javac", ["/usr/lib64/jvm/icedtea8-3.17.0/b"..., "-help"], 0x7ffd2c6b3340 /* 33 vars */) = 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | brk(NULL) = 0x56350d9df000 | arch_prctl(0x3001 /* ARCH_??? */, 0x7fff5b7713e0) = -1 EINVAL (Invalid argument) | readlink("/proc/self/exe", "/usr/bin/rsync", 4096) = 14 ^^^^^^^^^^^^^^^^ ??? | mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6f30ec0000 | access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) | openat(AT_FDCWD, "/usr/bin/../lib/amd64/jli/tls/x86_64/x86_64/libjli.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) ^^^^^^^^ | stat("/usr/bin/../lib/amd64/jli/tls/x86_64/x86_64", 0x7fff5b770580) = -1 ENOENT (No such file or directory) ^^^^^^^^ execve shows proper path, but why readlink("/proc/self/exe") returns "/usr/bin/rsync" and $ORIGIN is resolved as /usr/bin instead of /usr/lib64/jvm/icedtea8-3.17.0/bin ??? -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Tue Nov 10 18:49:57 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 10 Nov 2020 18:49:57 +0100 Subject: th-x86_64: strange runtime linker failure In-Reply-To: <20201110174510.GA4455@stranger.qboosh.pl> References: <20201110174510.GA4455@stranger.qboosh.pl> Message-ID: <20201110174957.GA6960@mail> Oh, and one more th-x86_64 malfunction: it stopped sending e-mail notifications to the requester (well, at least to me). (BTW, javac from the same package, i.e. icedtea8-jdk-3.17.0-1.x86_64, works just fine on carme) -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Tue Nov 10 20:03:25 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 10 Nov 2020 20:03:25 +0100 Subject: missing mail logs form th-x86_64 [SOLVED: th-x86_64: strange runtime linker failure] In-Reply-To: <20201110174510.GA4455@stranger.qboosh.pl> References: <20201110174510.GA4455@stranger.qboosh.pl> Message-ID: <20201110190325.GA9350@mail> On Tue, Nov 10, 2020 at 06:45:10PM +0100, Jakub Bogusz wrote: > `strace -f /usr/lib64/jvm/icedtea8-3.17.0/bin/javac -help` shows something strange: > > | # src : https://buildlogs.pld-linux.org/pld/th/x86_64/FAIL/command,bd4d8466-aafa-4f38-ab38-45d3dd906832.bz2 > | # date : 2020/11/10 18:21:26 > | execve("/usr/lib64/jvm/icedtea8-3.17.0/bin/javac", ["/usr/lib64/jvm/icedtea8-3.17.0/b"..., "-help"], 0x7ffd2c6b3340 /* 33 vars */) = 0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > | brk(NULL) = 0x56350d9df000 > | arch_prctl(0x3001 /* ARCH_??? */, 0x7fff5b7713e0) = -1 EINVAL (Invalid argument) > | readlink("/proc/self/exe", "/usr/bin/rsync", 4096) = 14 > ^^^^^^^^^^^^^^^^ ??? > | mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6f30ec0000 > | access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) > | openat(AT_FDCWD, "/usr/bin/../lib/amd64/jli/tls/x86_64/x86_64/libjli.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > ^^^^^^^^ > | stat("/usr/bin/../lib/amd64/jli/tls/x86_64/x86_64", 0x7fff5b770580) = -1 ENOENT (No such file or directory) > ^^^^^^^^ > > execve shows proper path, but why readlink("/proc/self/exe") returns > "/usr/bin/rsync" and $ORIGIN is resolved as /usr/bin instead of > /usr/lib64/jvm/icedtea8-3.17.0/bin ??? Problem solved by `mount -t proc proc /proc`. There were some stale /proc contents, most likely rsynced from some live system in 2009 (that's why /proc/self/exe points to rsync). But missing e-mail logs still remain. -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Fri Nov 13 08:55:21 2020 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Fri, 13 Nov 2020 08:55:21 +0100 Subject: missing mail logs form th-x86_64 [SOLVED: th-x86_64: strange runtime linker failure] In-Reply-To: <20201110190325.GA9350@mail> References: <20201110174510.GA4455@stranger.qboosh.pl> <20201110190325.GA9350@mail> Message-ID: <0e0ac56c-3828-a456-eb49-0dcc0171da0c@maven.pl> W dniu 10.11.2020 o?20:03, Jakub Bogusz pisze: > > Problem solved by `mount -t proc proc /proc`. > There were some stale /proc contents, most likely rsynced from some live > system in 2009 (that's why /proc/self/exe points to rsync). Builders no longer run in vservers. kernel 5.9 on them. proc wasn't mounted properly after this migration (which is now fixed) > > But missing e-mail logs still remain. And that should be fixed, too (untested yet; dns propagation). -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Fri Nov 13 10:36:29 2020 From: atler at pld-linux.org (Jan Palus) Date: Fri, 13 Nov 2020 10:36:29 +0100 Subject: missing mail logs form th-x86_64 [SOLVED: th-x86_64: strange runtime linker failure] In-Reply-To: <0e0ac56c-3828-a456-eb49-0dcc0171da0c@maven.pl> References: <20201110174510.GA4455@stranger.qboosh.pl> <20201110190325.GA9350@mail> <0e0ac56c-3828-a456-eb49-0dcc0171da0c@maven.pl> Message-ID: <20201113093629.gkhyzqrd7rmqv75h@kalarepa> On 13.11.2020 08:55, Arkadiusz Mi?kiewicz wrote: > W dniu 10.11.2020 o?20:03, Jakub Bogusz pisze: > > > > > Problem solved by `mount -t proc proc /proc`. > > There were some stale /proc contents, most likely rsynced from some live > > system in 2009 (that's why /proc/self/exe points to rsync). > > Builders no longer run in vservers. kernel 5.9 on them. proc wasn't > mounted properly after this migration (which is now fixed) Could you also check if /dev/shm is mounted? I suppose that's why firefox is failing now: 0:40.96 sl = self._semlock = _multiprocessing.SemLock( 0:40.96 OSError: [Errno 38] Function not implemented From arekm at maven.pl Fri Nov 13 10:48:03 2020 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Fri, 13 Nov 2020 10:48:03 +0100 Subject: missing mail logs form th-x86_64 [SOLVED: th-x86_64: strange runtime linker failure] In-Reply-To: <20201113093629.gkhyzqrd7rmqv75h@kalarepa> References: <20201110174510.GA4455@stranger.qboosh.pl> <20201110190325.GA9350@mail> <0e0ac56c-3828-a456-eb49-0dcc0171da0c@maven.pl> <20201113093629.gkhyzqrd7rmqv75h@kalarepa> Message-ID: <021c2d19-761a-ff6f-b8ba-48e97f55af4f@maven.pl> W dniu 13.11.2020 o?10:36, Jan Palus via pld-devel-en pisze: > On 13.11.2020 08:55, Arkadiusz Mi?kiewicz wrote: >> W dniu 10.11.2020 o?20:03, Jakub Bogusz pisze: >> >>> >>> Problem solved by `mount -t proc proc /proc`. >>> There were some stale /proc contents, most likely rsynced from some live >>> system in 2009 (that's why /proc/self/exe points to rsync). >> >> Builders no longer run in vservers. kernel 5.9 on them. proc wasn't >> mounted properly after this migration (which is now fixed) > > Could you also check if /dev/shm is mounted? I suppose that's why > firefox is failing now: > > 0:40.96 sl = self._semlock = _multiprocessing.SemLock( > 0:40.96 OSError: [Errno 38] Function not implemented It's mounted since my previous mail (was also broken, like proc). -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Sat Nov 14 01:28:29 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sat, 14 Nov 2020 02:28:29 +0200 Subject: rpm4 on carme* In-Reply-To: <20201027222117.GA77656@tachikoma.lan> References: <20201027222117.GA77656@tachikoma.lan> Message-ID: <4033127d-e93d-b346-1803-b8ca6b99f9e0@pld-linux.org> On 10/28/20 12:21 AM, Jan R?korajski wrote: > All carme machines are now running rpm 4.16.0. Please test and report > any issues. > hrmib integration seems to be missing. ? l -rt /var/cache/hrmib/ -rt|tail -rw-r--r-- 1 root root 0 Oct 26 10:23 rpm-perlprov-4.16.0-0.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 rpm-lib-4.16.0-0.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 rpm-devel-4.16.0-0.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 rpm-build-4.16.0-0.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 rpm-base-4.16.0-0.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 rpm-4.16.0-0.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 python3-rpm-4.16.0-0.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 poldek-libs-0.42.2-3.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 poldek-0.42.2-3.1-th.x86_64 -rw-r--r-- 1 root root 0 Oct 26 10:23 lua54-libs-5.4.1-2.x86_64 ? needed for net-snmp hrSWInstalledTable: - http://www.net-snmp.org/docs/mibs/host.html#hrSWInstalledTable it can be queried with something like this: $ snmpwalk -v 1 -c public localhost hrSWInstalledTable From glen at pld-linux.org Mon Nov 16 15:17:47 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 16 Nov 2020 16:17:47 +0200 Subject: [packages/glibc] disable static pie on %{arm} In-Reply-To: <1a8a80a24f8175825edaccce23bf99bff913b5aa_refs_heads_master@pld-linux.org> References: <1a8a80a24f8175825edaccce23bf99bff913b5aa_refs_heads_master@pld-linux.org> Message-ID: On 11/16/20 3:06 PM, atler wrote: > +%ifnarch %{arm} > +%define with_static_pie 1 > +%endif please register new bcond (and it's default value) with %bcond_with/%bcond_without and typically you undefine bcond on unsupported platform From atler at pld-linux.org Wed Nov 18 10:47:10 2020 From: atler at pld-linux.org (Jan Palus) Date: Wed, 18 Nov 2020 10:47:10 +0100 Subject: rpm4 on carme* In-Reply-To: <20201110171843.cwfwxku2w27ytljj@pine> References: <20201027222117.GA77656@tachikoma.lan> <20201106194956.v2un4kbwxcecdrvu@kalarepa> <20201110171843.cwfwxku2w27ytljj@pine> Message-ID: <20201118094710.q4tkgs64w6m3dsvw@kalarepa> On 10.11.2020 18:18, Jan Palus wrote: > On 06.11.2020 20:49, Jan Palus wrote: > > On 27.10.2020 23:21, Jan R?korajski wrote: > > > All carme machines are now running rpm 4.16.0. Please test and report > > > any issues. > > > > * poldek appears to still enforce directory deps while rpms does not > > (that concerns mainly /usr/lib/.build-id subdirs) > > > > * rpm.org is missing %{__ln} macro. spotted only single occurrence in > > xrdp.spec > > * missing __bash macro > > * most noarch conditions stopped working now since 4.16 < 4.6 * Provides for libraries are not populated if %install does not set executable bit on ELF file. One such notable example is libgcc_s installed with mode 644 by `make install`: rpm5: $ rpm -q --provides libgcc | grep libgcc_s libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libgcc_s.so.1(GCC_3.3) libgcc_s.so.1(GCC_3.3.1) libgcc_s.so.1(GCC_3.4) libgcc_s.so.1(GCC_3.4.2) libgcc_s.so.1(GCC_4.0.0) libgcc_s.so.1(GCC_4.2.0) libgcc_s.so.1(GCC_4.3.0) libgcc_s.so.1(GCC_4.4.0) libgcc_s.so.1(GCC_4.5.0) libgcc_s.so.1(GCC_4.7.0) libgcc_s.so.1(GCC_4.8.0) libgcc_s.so.1(GCC_7.0.0) libgcc_s.so.1(GLIBC_2.0) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libgcc_s.so.1(GCC_3.4.2)(64bit) libgcc_s.so.1(GCC_3.4.4)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libgcc_s.so.1(GCC_4.3.0)(64bit) libgcc_s.so.1(GCC_4.7.0)(64bit) libgcc_s.so.1(GCC_4.8.0)(64bit) libgcc_s.so.1(GCC_7.0.0)(64bit) rpm4: $ rpm -q --provides -p libgcc-10.2.0-1.x86_64.rpm | grep libgcc_s (empty) Aa a workaround we could remove "exeonly" from %__elf_flags in /usr/lib/rpm/fileattrs/elf.attr but ideally RPM should not look at actual file mode on disk but rather on mode configured in %files. Other such example: ossp-uuid * possibly similar case but I haven't debugged it: perl-modules does not provide perl(unicore::Name) * Requires(triggerpostun) is not supported (pam.spec) * Obsoletes fails if it does not contain "package name only" examples: systemd.spec: Obsoletes: virtual(init-daemon) (illegal char '(') perl.spec: Obsoletes: perl-Params::Check < %perl_modverrel Params::Check 99 (illegal char ':') * similar thing in Provides: perl.spec: Provides: perldoc = 3.14_02 at 5.30.3 (illegal char '@') From qboosh at pld-linux.org Fri Nov 20 20:48:05 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 20 Nov 2020 20:48:05 +0100 Subject: th-i686 not working again Message-ID: <20201120194805.GA28208@stranger.qboosh.pl> It seems that th-i686 builder is dead or got stuck on openjdk11 build. Who can fix it? -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Fri Nov 20 21:04:45 2020 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Fri, 20 Nov 2020 21:04:45 +0100 Subject: th-i686 not working again In-Reply-To: <20201120194805.GA28208@stranger.qboosh.pl> References: <20201120194805.GA28208@stranger.qboosh.pl> Message-ID: <9831909e-ee7b-9bb8-b67c-774ebbb4bfd8@maven.pl> W dniu 20.11.2020 o?20:48, Jakub Bogusz pisze: > It seems that th-i686 builder is dead or got stuck on openjdk11 build. > > Who can fix it? I but only on the site (if at all). It doesn't see disks (in bios). Maybe I'll get there in the weekend. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Sun Nov 22 17:00:50 2020 From: atler at pld-linux.org (Jan Palus) Date: Sun, 22 Nov 2020 17:00:50 +0100 Subject: rpm4 on carme* In-Reply-To: <20201118094710.q4tkgs64w6m3dsvw@kalarepa> References: <20201027222117.GA77656@tachikoma.lan> <20201106194956.v2un4kbwxcecdrvu@kalarepa> <20201110171843.cwfwxku2w27ytljj@pine> <20201118094710.q4tkgs64w6m3dsvw@kalarepa> Message-ID: <20201122160050.o2eta4yibvkxkhet@pine> * adding to the list of invalid chars in Obsoletes: '/' (msmtp: Obsoletes: /usr/lib/sendmail) * python-Cython built with rpm.org has weird unsatisfied R: python2.7dist(setuptools) / python3.8dist(setuptools) python-setuptools built with rpm.org does not have such P: From arekm at maven.pl Sun Nov 22 17:33:31 2020 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Sun, 22 Nov 2020 17:33:31 +0100 Subject: rpm4 on carme* In-Reply-To: <20201122160050.o2eta4yibvkxkhet@pine> References: <20201027222117.GA77656@tachikoma.lan> <20201106194956.v2un4kbwxcecdrvu@kalarepa> <20201110171843.cwfwxku2w27ytljj@pine> <20201118094710.q4tkgs64w6m3dsvw@kalarepa> <20201122160050.o2eta4yibvkxkhet@pine> Message-ID: <88c61521-9f59-e219-67b1-b0d4b38df77f@maven.pl> W dniu 22.11.2020 o?17:00, Jan Palus pisze: > * adding to the list of invalid chars in Obsoletes: '/' (msmtp: Obsoletes: /usr/lib/sendmail) > > * python-Cython built with rpm.org has weird unsatisfied R: python2.7dist(setuptools) / python3.8dist(setuptools) Could these be https://rpm.org/user_doc/boolean_dependencies.html that are not handled by poldek ? And "/" could be forbidden due to that. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From ngompa13 at gmail.com Sun Nov 22 17:41:49 2020 From: ngompa13 at gmail.com (Neal Gompa) Date: Sun, 22 Nov 2020 11:41:49 -0500 Subject: rpm4 on carme* In-Reply-To: <88c61521-9f59-e219-67b1-b0d4b38df77f@maven.pl> References: <20201027222117.GA77656@tachikoma.lan> <20201106194956.v2un4kbwxcecdrvu@kalarepa> <20201110171843.cwfwxku2w27ytljj@pine> <20201118094710.q4tkgs64w6m3dsvw@kalarepa> <20201122160050.o2eta4yibvkxkhet@pine> <88c61521-9f59-e219-67b1-b0d4b38df77f@maven.pl> Message-ID: On Sun, Nov 22, 2020 at 11:34 AM Arkadiusz Mi?kiewicz via pld-devel-en wrote: > > W dniu 22.11.2020 o 17:00, Jan Palus pisze: > > * adding to the list of invalid chars in Obsoletes: '/' (msmtp: Obsoletes: /usr/lib/sendmail) > > > > * python-Cython built with rpm.org has weird unsatisfied R: python2.7dist(setuptools) / python3.8dist(setuptools) > > Could these be https://rpm.org/user_doc/boolean_dependencies.html that > are not handled by poldek ? > > And "/" could be forbidden due to that. I don't think Cython has a ranged dependency to trigger a boolean dependency expression. At least in Fedora, Cython generates a "python3.9dist(setuptools)" dependency. I would expect python3-setuptools to have a generated "Provides: python3.8dist(setuptools)" stanza from the pythondist generator. -- ?????????/ Always, there's only one truth! From atler at pld-linux.org Sun Nov 22 18:24:07 2020 From: atler at pld-linux.org (Jan Palus) Date: Sun, 22 Nov 2020 18:24:07 +0100 Subject: th-i686 not working again In-Reply-To: <9831909e-ee7b-9bb8-b67c-774ebbb4bfd8@maven.pl> References: <20201120194805.GA28208@stranger.qboosh.pl> <9831909e-ee7b-9bb8-b67c-774ebbb4bfd8@maven.pl> Message-ID: <20201122172407.ith6czawwu6ickyw@pine> On 20.11.2020 21:04, Arkadiusz Mi?kiewicz wrote: > W dniu 20.11.2020 o?20:48, Jakub Bogusz pisze: > > It seems that th-i686 builder is dead or got stuck on openjdk11 build. > > > > Who can fix it? > > I but only on the site (if at all). It doesn't see disks (in bios). > > Maybe I'll get there in the weekend. Hopefully it gets back soon, but in order to help it get up to speed whoever has proper permissions feel free to skip following build requests on th-i686: test builds: 6d9c45e9-c958-4ea9-bf8f-d0fe6c7f93e9 b71ae8d3-f41c-431a-87e6-859f0c31bfa9 0365cd79-867e-44db-898a-65e0ce51b547 8057abcf-eab0-460d-8de3-4d1f4aa87c20 8a3fc358-957a-4be0-9cc5-812e54e1359b 8698b6d0-c807-4b3d-825a-0e991ab384bc 915e9cd4-6f21-446f-87f5-94872b7af0ea ee2e7ddb-33f9-4056-a27a-bd60feb456d6 851179c8-8766-4aec-ae87-9981365c8e56 release builds: f3f8bb5c-3dcd-4240-b049-299936296db7 (thunderbird 78.4.3 superseded by 78.5.0) 89fe1778-4cd1-4b66-954b-19599dc088c3 (qt5-qtwebkit will fail) From baggins at pld-linux.org Sun Nov 22 19:06:29 2020 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 22 Nov 2020 19:06:29 +0100 Subject: th-i686 not working again In-Reply-To: <20201122172407.ith6czawwu6ickyw@pine> References: <20201120194805.GA28208@stranger.qboosh.pl> <9831909e-ee7b-9bb8-b67c-774ebbb4bfd8@maven.pl> <20201122172407.ith6czawwu6ickyw@pine> Message-ID: <20201122180629.GA126679@starbug.lan> On Sun, 22 Nov 2020, Jan Palus wrote: > On 20.11.2020 21:04, Arkadiusz Mi?kiewicz wrote: > > W dniu 20.11.2020 o?20:48, Jakub Bogusz pisze: > > > It seems that th-i686 builder is dead or got stuck on openjdk11 build. > > > > > > Who can fix it? > > > > I but only on the site (if at all). It doesn't see disks (in bios). > > > > Maybe I'll get there in the weekend. > > Hopefully it gets back soon, but in order to help it get up to speed > whoever has proper permissions feel free to skip following build > requests on th-i686: [...] Done. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Mon Nov 23 20:34:27 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 23 Nov 2020 21:34:27 +0200 Subject: rpm4 on carme* In-Reply-To: <20201027222117.GA77656@tachikoma.lan> References: <20201027222117.GA77656@tachikoma.lan> Message-ID: <93bcc52e-2052-f6ef-54d9-fa41c9533ee1@pld-linux.org> On 10/28/20 12:21 AM, Jan R?korajski wrote: > All carme machines are now running rpm 4.16.0. Please test and report > any issues. > the "Obsoletes: foo" pattern to replace a package does longer seem to work. php*-devel packages obsolete each other, so if you install php70-devel it will remove installed php74-devel, etc but now it fails, because it does not like the reverse dependency (php74-devel also obsoletes php70-devel). Processing dependencies... php74-devel-7.4.12-2.x86_64 obsoleted by php70-devel-7.0.33-8.x86_64 There are 1 package to install, 1 to remove: A php70-devel-7.0.33-8.x86_64 R php74-devel-7.4.12-2.x86_64 This operation will free 1.3MB of disk space. Need to get 463.0KB of archives (463.0KB to download). th-arch::php70-devel-7.0.33-8.x86_64.rpm [463.0K (133.9K/s)] php70-devel-7.0.33-8.x86_64.rpm: digests OK Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 1... warning: /root/.poldek-cache/ftp_ftp1.pld-linux.org.dists.th.PLD.x86.64.RPMS/php70-devel-7.0.33-8.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: NOKEY error: Failed dependencies: ??????? php70-devel is obsoleted by (installed) php74-devel-4:7.4.12-2.x86_64 There were errors poldek:/all-avail> From arekm at maven.pl Tue Nov 24 14:56:40 2020 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Tue, 24 Nov 2020 14:56:40 +0100 Subject: th-i686 not working again In-Reply-To: <9831909e-ee7b-9bb8-b67c-774ebbb4bfd8@maven.pl> References: <20201120194805.GA28208@stranger.qboosh.pl> <9831909e-ee7b-9bb8-b67c-774ebbb4bfd8@maven.pl> Message-ID: W dniu 20.11.2020 o?21:04, Arkadiusz Mi?kiewicz pisze: > W dniu 20.11.2020 o?20:48, Jakub Bogusz pisze: >> It seems that th-i686 builder is dead or got stuck on openjdk11 build. >> >> Who can fix it? > > I but only on the site (if at all). It doesn't see disks (in bios). > > Maybe I'll get there in the weekend. > It's back. Not sure for how long though (this machine is ~10 years old). -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Fri Nov 27 15:57:48 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 27 Nov 2020 16:57:48 +0200 Subject: rpm4 on carme* In-Reply-To: <20201027222117.GA77656@tachikoma.lan> References: <20201027222117.GA77656@tachikoma.lan> Message-ID: On 10/28/20 12:21 AM, Jan R?korajski wrote: > All carme machines are now running rpm 4.16.0. Please test and report > any issues. > can't install packages built with 4.15 to install upgrade packages on rpm 4.5 error: php53-zip-5.3.29-51.1.x86_64: req rpmlib(FileDigests) <= 4.6.0-1 not found, upgrade rpm error: php53-common-5.3.29-51.1.x86_64: req rpmlib(FileDigests) <= 4.6.0-1 not found, upgrade rpm it was possible to upgrade ac->th using rpm/poldek on ac pointing poldek to th repos and run poldek --upgrade-dist i guess have to use ac->th-2019->th in the future if distro packages built with rpm 4.16 From glen at pld-linux.org Fri Nov 27 16:09:23 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 27 Nov 2020 17:09:23 +0200 Subject: rpm4 on carme* In-Reply-To: References: <20201027222117.GA77656@tachikoma.lan> Message-ID: <98b50c2f-e694-2c4c-a0b5-8642b93c6ba9@pld-linux.org> On 11/27/20 4:57 PM, Elan Ruusam?e wrote: > On 10/28/20 12:21 AM, Jan R?korajski wrote: > >> All carme machines are now running rpm 4.16.0. Please test and report >> any issues. >> > can't install packages built with 4.15 to install upgrade packages on > rpm 4.5 > > > error: php53-zip-5.3.29-51.1.x86_64: req rpmlib(FileDigests) <= > 4.6.0-1 not found, upgrade rpm > error: php53-common-5.3.29-51.1.x86_64: req rpmlib(FileDigests) <= > 4.6.0-1 not found, upgrade rpm > > > it was possible to upgrade ac->th using rpm/poldek on ac pointing > poldek to th repos and run poldek --upgrade-dist > > i guess have to use ac->th-2019->th in the future if distro packages > built with rpm 4.16 > to revert to previous state: #?? Algorithm to use for generating file checksum digests on build. #?? If not specified or 0, MD5 is used. #?? WARNING: non-MD5 is backwards incompatible with rpm < 4.6! #?? The supported algorithms may depend on the underlying crypto #?? implementation but generally at least the following are supported: #?? 1?? MD5 #?? 2?? SHA1 #?? 8?? SHA256 (default) #?? 9?? SHA384 #?? 10? SHA512 # %_source_filedigest_algorithm?? 1 %_binary_filedigest_algorithm?? 1 From glen at pld-linux.org Sat Nov 28 19:24:55 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sat, 28 Nov 2020 20:24:55 +0200 Subject: [packages/waf] - updated python(abi) dependency, compile python library In-Reply-To: <067625ee001423484c515b4c67c3749ead1cc693_refs_heads_master@pld-linux.org> References: <067625ee001423484c515b4c67c3749ead1cc693_refs_heads_master@pld-linux.org> Message-ID: On 11/27/20 10:17 PM, qboosh wrote: > -Requires: python(abi) = %{py_ver} > > +Requires: python(abi) = %{py3_ver} shouldn't this be namespace to python3 name? Requires: python3(abi) = %{py3_ver} From qboosh at pld-linux.org Sat Nov 28 19:38:23 2020 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 28 Nov 2020 19:38:23 +0100 Subject: [packages/waf] - updated python(abi) dependency, compile python library In-Reply-To: References: <067625ee001423484c515b4c67c3749ead1cc693_refs_heads_master@pld-linux.org> Message-ID: <20201128183823.GA6440@mail> On Sat, Nov 28, 2020 at 08:24:55PM +0200, Elan Ruusam?e wrote: > > On 11/27/20 10:17 PM, qboosh wrote: > >-Requires: python(abi) = %{py_ver} > > > >+Requires: python(abi) = %{py3_ver} > > > shouldn't this be namespace to python3 name? > > > Requires: python3(abi) = %{py3_ver} No, to be consistent with current python3 package: $ rpm -qP python3-libs | grep abi python(abi) = 3.8 Multiple versions can be installed, so it's not necessary to use another namespace. At least for rpm5, not verified with rpm.org yet. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Mon Nov 30 01:06:22 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 30 Nov 2020 02:06:22 +0200 Subject: [packages/waf] - updated python(abi) dependency, compile python library In-Reply-To: <20201128183823.GA6440@mail> References: <067625ee001423484c515b4c67c3749ead1cc693_refs_heads_master@pld-linux.org> <20201128183823.GA6440@mail> Message-ID: <0dbbae9d-d9f7-14b0-ce46-88cae3ee101e@pld-linux.org> On 11/28/20 8:38 PM, Jakub Bogusz wrote: > On Sat, Nov 28, 2020 at 08:24:55PM +0200, Elan Ruusam?e wrote: >> On 11/27/20 10:17 PM, qboosh wrote: >>> -Requires: python(abi) = %{py_ver} >>> >>> +Requires: python(abi) = %{py3_ver} >> >> shouldn't this be namespace to python3 name? >> >> >> Requires: python3(abi) = %{py3_ver} > No, to be consistent with current python3 package: > > $ rpm -qP python3-libs | grep abi > python(abi) = 3.8 > > Multiple versions can be installed, so it's not necessary to use another > namespace. At least for rpm5, not verified with rpm.org yet. > all python3 eggs are namespaced under python3. and it makes sense, as package may require python2 and python3 at the same time. i don't think "abi" should be any more special than the python eggs $ rpm -qp --provides python3-git-2.1.11-3.noarch.rpm python3egg(gitpython) = 2.1.11 python3-git = 2.1.11-3 $ rpm -qp --provides python-git-2.1.11-3.noarch.rpm pythonegg(gitpython) = 2.1.11 python-git = 2.1.11-3 I'm sure reusing same namespace for different purpose will cause problems on upgrading. perhaps upgrading python3 could obsolete python2 as python(abi) got upgraded From glen at pld-linux.org Mon Nov 30 01:09:31 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 30 Nov 2020 02:09:31 +0200 Subject: [packages/llvm] add lowmem bcond for reducing memory requirements during build In-Reply-To: <1431eb62de5fe504a3dae0baf3e524632814224c_refs_heads_master@pld-linux.org> References: <1b02e37b88f3324895641bc208d25bccb7df1c6a_refs_heads_master@pld-linux.org> <1431eb62de5fe504a3dae0baf3e524632814224c_refs_heads_master@pld-linux.org> Message-ID: On 11/29/20 1:10 PM, atler wrote: > +%ifarch %{arm} aarch64 > +%define lowmem 1 > +%endif you need to define with_lowmem here From glen at pld-linux.org Mon Nov 30 08:21:04 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 30 Nov 2020 09:21:04 +0200 Subject: distfiles fetcher down Message-ID: new distfiles not fetched from commits. From glen at pld-linux.org Mon Nov 30 12:15:43 2020 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 30 Nov 2020 13:15:43 +0200 Subject: disk full: cvs In-Reply-To: References: Message-ID: -------- Forwarded Message -------- Subject: Cron ~/rpm/PLD-doc/notify-specsupdate.sh Date: Mon, 30 Nov 2020 12:01:01 +0100 From: (Cron Daemon) To: glen at pld-linux.org can't create temporary directory /tmp/cvs-serv16277 No space left on device