From baggins at pld-linux.org Mon Nov 1 23:15:05 2021 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 1 Nov 2021 23:15:05 +0100 Subject: [packages/dracut] - bash is *required* for dracut initramfs to work correctly, rel 3 In-Reply-To: <20211031105600.7jais6u4utwplvsa@kalarepa> References: <272c7dd7eb5dfbcd6be88d0c4a584fd9f36163c4_refs_heads_master@pld-linux.org> <63a4b90ecfdd4ac023ab8542fd6af60f4c80516e_refs_heads_master@pld-linux.org> <20211031000603.siaiyvmu3mifoyv5@kalarepa> <20211031105600.7jais6u4utwplvsa@kalarepa> Message-ID: 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/ From zawadaa at gmail.com Tue Nov 2 13:00:22 2021 From: zawadaa at gmail.com (Andrzej Zawadzki) Date: Tue, 2 Nov 2021 13:00:22 +0100 Subject: [packages/dracut] - bash is *required* for dracut initramfs to work correctly, rel 3 In-Reply-To: References: <272c7dd7eb5dfbcd6be88d0c4a584fd9f36163c4_refs_heads_master@pld-linux.org> <63a4b90ecfdd4ac023ab8542fd6af60f4c80516e_refs_heads_master@pld-linux.org> <20211031000603.siaiyvmu3mifoyv5@kalarepa> <20211031105600.7jais6u4utwplvsa@kalarepa> Message-ID: On 01.11.2021 23:15, Jan Rekorajski wrote: On Sun, 31 Oct 2021, Jan Palus wrote: On 31.10.2021 09:21, Jan Rekorajski wrote: On Sun, 31 Oct 2021, Jan Palus wrote: On 30.10.2021 23:23, baggins wrote: commit 63a4b90ecfdd4ac023ab8542fd6af60f4c80516e Author: Jan Rekorajski [1] 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: [2]https://github.com/dracutdevs/dracut/blob/15398458685d376fef56b1bf6fe09ae7c68 324c1/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. So, can I safely remove entry: hold = dracut* from my config? Last dracut, that works with LUKS was dracut-054. (always good to have PLD Rescue ;-) ) Thanks for fix! -- Andrzej Zawadzki References 1. mailto:baggins at pld-linux.org 2. https://github.com/dracutdevs/dracut/blob/15398458685d376fef56b1bf6fe09ae7c68324c1/src/install/dracut-install.c#L531 From adwol at zonk.pl Sun Nov 7 16:54:27 2021 From: adwol at zonk.pl (Adam Osuchowski) Date: Sun, 7 Nov 2021 16:54:27 +0100 Subject: xorg-font-font-adobe-75dpi package potential corruption Message-ID: There is a problem with xorg-font-font-adobe-75dpi package during install: root at 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 But rpm2cpio and cpio report no errors: root at pldtest:~# ipoldek get xorg-font-font-adobe-75dpi Loading [pndir]th... Loading [pndir]th... 30648 packages read th::xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm [5.3M (5.3M/s)] xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm: digests OK root at pldtest:~# rpm2cpio xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm | cpio -t > /dev/null 11402 blocks root at pldtest:~# echo $? 0 Could somebody look at this? Similiar package xorg-font-font-adobe-100dpi built at the same time causes no problems. From baggins at pld-linux.org Sun Nov 7 23:27:48 2021 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 7 Nov 2021 23:27:48 +0100 Subject: xorg-font-font-adobe-75dpi package potential corruption In-Reply-To: References: Message-ID: On Sun, 07 Nov 2021, Adam Osuchowski wrote: > There is a problem with xorg-font-font-adobe-75dpi package during install: > > root at 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/ From atler at pld-linux.org Thu Nov 11 11:23:36 2021 From: atler at pld-linux.org (Jan Palus) Date: Thu, 11 Nov 2021 11:23:36 +0100 Subject: TEST build ERRORS: onedrive.spec In-Reply-To: References: <673226b0-d6ac-400e-81dd-8220892357da@pld.src.builder> Message-ID: <20211111102336.zffa2ugxricmxnhw@pine> 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. From j.rekorajski at gmail.com Thu Nov 11 12:07:22 2021 From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=) Date: Thu, 11 Nov 2021 12:07:22 +0100 Subject: TEST build ERRORS: onedrive.spec In-Reply-To: <20211111102336.zffa2ugxricmxnhw@pine> References: <673226b0-d6ac-400e-81dd-8220892357da@pld.src.builder> <20211111102336.zffa2ugxricmxnhw@pine> Message-ID: 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 at 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 From arekm at maven.pl Thu Nov 11 12:55:16 2021 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Thu, 11 Nov 2021 12:55:16 +0100 Subject: TEST build ERRORS: onedrive.spec In-Reply-To: References: <673226b0-d6ac-400e-81dd-8220892357da@pld.src.builder> <20211111102336.zffa2ugxricmxnhw@pine> Message-ID: <714fc778-d242-1bf9-2e0d-a84a2a195f3d@maven.pl> W dniu 11.11.2021 o?12:07, Jan R?korajski pisze: > 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. Or just resend any small package from latest tag (I usually send alien.spec for that) because rebuilding package causes poldek indexes regeneration in /spools/ready. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From adwol at zonk.pl Thu Nov 11 22:34:15 2021 From: adwol at zonk.pl (Adam Osuchowski) Date: Thu, 11 Nov 2021 22:34:15 +0100 Subject: samba 4.15.2 symbol version mismatch Message-ID: <808e87d3-f3c3-40e0-aa89-226f013404a2@zonk.pl> Samba 4.15.2-1 from th-test requires SAMBA_4.13.9 symbol root at pldtest1:~# rpm -q samba samba-4.15.2-1.x86_64 root at pldtest1:~# smbd smbd: /usr/lib64/samba/libsamba-security-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) smbd: /usr/lib64/samba/libreplace-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) smbd: /usr/lib64/samba/libsmbd-shim-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) smbd: /usr/lib64/samba/libsamba-debug-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) root at pldtest1:~# winbindd winbindd: /usr/lib64/samba/libsamba-security-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) winbindd: /usr/lib64/samba/libreplace-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) winbindd: /usr/lib64/samba/libsmbd-shim-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) winbindd: /usr/lib64/samba/libsamba-debug-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) root at pldtest1:~# objdump -p /usr/lib64/libsmbldap.so.2 | grep -A6 'Version References' Version References: required from libsamba-security-samba4.so: 0x07275469 0x00 13 SAMBA_4.13.9 required from libreplace-samba4.so: 0x07275469 0x00 12 SAMBA_4.13.9 required from libsmbd-shim-samba4.so: 0x07275469 0x00 11 SAMBA_4.13.9 From arekm at maven.pl Thu Nov 11 22:57:51 2021 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Thu, 11 Nov 2021 22:57:51 +0100 Subject: samba 4.15.2 symbol version mismatch In-Reply-To: <808e87d3-f3c3-40e0-aa89-226f013404a2@zonk.pl> References: <808e87d3-f3c3-40e0-aa89-226f013404a2@zonk.pl> Message-ID: <77b4fbc9-e079-ff3b-fe75-3bf3ae1ed1d6@maven.pl> W dniu 11.11.2021 o?22:34, Adam Osuchowski pisze: > Samba 4.15.2-1 from th-test requires SAMBA_4.13.9 symbol rm /usr/lib64/libsmbldap.so.2 ldconfig not sure why rpm does leaves it in such way > > > root at pldtest1:~# rpm -q samba > samba-4.15.2-1.x86_64 > root at pldtest1:~# smbd > smbd: /usr/lib64/samba/libsamba-security-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) > smbd: /usr/lib64/samba/libreplace-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) > smbd: /usr/lib64/samba/libsmbd-shim-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) > smbd: /usr/lib64/samba/libsamba-debug-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) > root at pldtest1:~# winbindd > winbindd: /usr/lib64/samba/libsamba-security-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) > winbindd: /usr/lib64/samba/libreplace-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) > winbindd: /usr/lib64/samba/libsmbd-shim-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) > winbindd: /usr/lib64/samba/libsamba-debug-samba4.so: version `SAMBA_4.13.9' not found (required by /usr/lib64/libsmbldap.so.2) > root at pldtest1:~# objdump -p /usr/lib64/libsmbldap.so.2 | grep -A6 'Version References' > Version References: > required from libsamba-security-samba4.so: > 0x07275469 0x00 13 SAMBA_4.13.9 > required from libreplace-samba4.so: > 0x07275469 0x00 12 SAMBA_4.13.9 > required from libsmbd-shim-samba4.so: > 0x07275469 0x00 11 SAMBA_4.13.9 > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From baggins at pld-linux.org Sun Nov 14 23:10:12 2021 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 14 Nov 2021 23:10:12 +0100 Subject: Some packages to be removed post openssl 3.0.0 update In-Reply-To: References: Message-ID: 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/ From glen at pld-linux.org Wed Nov 17 09:40:41 2021 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 17 Nov 2021 10:40:41 +0200 Subject: carme: indexes broken Message-ID: ? sudo poldek --update --upa Loading [pndir]th-noarch... Applying packages.ndir.2021.11.07-22.26.45.gz... Applying packages.ndir.2021.11.14-21.17.58.gz... Applying packages.ndir.2021.11.14-21.49.17.gz... error: packages NetworkManager-apidocs-1.32.12-1 and NetworkManager-apidocs-1.32.12-1 are equal to me, give up Aborted From arekm at maven.pl Wed Nov 17 10:01:49 2021 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Wed, 17 Nov 2021 10:01:49 +0100 Subject: carme: indexes broken In-Reply-To: References: Message-ID: W dniu 17.11.2021 o?09:40, Elan Ruusam?e pisze: > ? sudo poldek --update --upa poldek --clean-whole done -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Tue Nov 23 22:41:09 2021 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 23 Nov 2021 23:41:09 +0200 Subject: [packages/cronie] Rel 4; make cronie restart itself when PAM problems happen. In-Reply-To: <428b9c73df902f6232312751a0c38060cf3cdbea_refs_heads_master@pld-linux.org> References: <7e9736c4327f8cad517f02d317b0d6be7cbbddea_refs_heads_master@pld-linux.org> <428b9c73df902f6232312751a0c38060cf3cdbea_refs_heads_master@pld-linux.org> Message-ID: <693fa9e7-25a2-cf49-7d59-7e630eff769e@pld-linux.org> On 23.11.2021 12:29, arekm wrote: > commit 428b9c73df902f6232312751a0c38060cf3cdbea > Author: Arkadiusz Mi?kiewicz > Date: Tue Nov 23 11:25:06 2021 +0100 > > Rel 4; make cronie restart itself when PAM problems happen. > > On glibc/pam upgrades cronie can be very unhappy: > > Feb 9 13:52:01 firma /usr/sbin/crond[6592]: (root) FAILED > to authorize user with PAM (Modu? jest nieznany) > > because crond is inked with old stuff and can't dlopen newer pam modules. > > Exact cause (like which symbol) is not known because crond > is using PAM_SILENT flag which silences most of pam error messages. > > Add hacky script to make crond self cure (this problem happened way > too many times for me). > > cronie.spec | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > --- > diff --git a/cronie.spec b/cronie.spec > index 2255574..c7b5da6 100644 > --- a/cronie.spec > +++ b/cronie.spec > @@ -18,7 +18,7 @@ Summary: Cron daemon for executing programs at set times > Summary(pl.UTF-8): Demon cron do uruchamiania program?w o zadanym czasie > Name: cronie > Version: 1.5.7 > -Release: 2 > +Release: 4 > License: MIT and BSD and GPL v2 > Group: Daemons > Source0: https://github.com/cronie-crond/cronie/releases/download/%{name}-%{version}/%{name}-%{version}.tar.gz > @@ -166,6 +166,18 @@ cat > $RPM_BUILD_ROOT%{_sysconfdir}/cron/cron.deny << 'EOF' > # NOT allowed to use the local cron daemon > EOF > > +cat > $RPM_BUILD_ROOT%{_sysconfdir}/cron.daily/check-crond << 'EOF' > +#!/bin/sh > + > +# ugly and limited hack. make cronie restart itself > +if [ -x /bin/awk -a -x /bin/grep -a -f /var/log/cron ]; then -a is bashism, use [ cond1 ] && [ cond2 ] && cond3 > + LC_ALL=C /bin/awk -v d="$(LC_ALL=C date "+%b %e")" ' $1 " " $2 ~ d' /var/log/cron \ > + | /bin/grep -qE "PAM.*(Modu. jest nieznany|Module is unknown)" \ why full paths? cron resets PATH to sane value, and can be overriden if wanted > + && echo "crond is failing on PAM, restarting ( https://github.com/cronie-crond/cronie/issues/87 )" >&2 \ > + && /sbin/service crond restart > +fi > +EOF > + why not implement execve(argv) in crond itself? and so far we've added %trigger to glibc, etc to restart cron daemons From qboosh at pld-linux.org Wed Nov 24 05:36:58 2021 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 24 Nov 2021 05:36:58 +0100 Subject: [packages/gstreamer] - up to 1.19.3 In-Reply-To: References: <7831d0c429a28545eebc2bcdc04996ae64d58690_refs_heads_master@pld-linux.org> Message-ID: <20211124043658.GA16294@mail> 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 I was going to merge them soon (lack of time was the obstacle). 1.19.x is devel line AFAIK. -- Jakub Bogusz http://qboosh.pl/ From baggins at pld-linux.org Wed Nov 24 09:14:17 2021 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Wed, 24 Nov 2021 09:14:17 +0100 Subject: [packages/gstreamer] - up to 1.19.3 In-Reply-To: <20211124043658.GA16294@mail> References: <7831d0c429a28545eebc2bcdc04996ae64d58690_refs_heads_master@pld-linux.org> <20211124043658.GA16294@mail> Message-ID: 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/ From arekm at maven.pl Wed Nov 24 14:00:09 2021 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Wed, 24 Nov 2021 14:00:09 +0100 Subject: TEST build OK: openjdk8.spec - openjdk 8 and 9 hangs on glibc 2.34 in vserver guest In-Reply-To: <20211022093710.v25jx4erszaje2gk@pine> References: <20211022081206.sxkzfnajgyncxtcq@pine> <20211022093710.v25jx4erszaje2gk@pine> Message-ID: W dniu 22.10.2021 o?11:37, Jan Palus pisze: > On 22.10.2021 10:44, Jan R?korajski wrote: >> 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. > > Currently openjdk8 requires either JDK 1.7 or 1.8 for build, I guess we > can patch it and try to build with openjdk11, no guarantees it would > work though. Not sure what is the difference but I had no issues > building openjdk8 1.8.0.312 with openjdk8 1.8.0.302 and glibc 2.34 on > x86_64, aarch64 and armv7hnl. I'll try to reproduce in fresh VM. For me our openjdk8 from ftp hangs on just doing "java -version". Not always. Sometimes I need to run that 5-10 times but I do get the hang easily. kernel 4.9.194, glibc 2.34, x86_64, vserver guest while (true); do date; java -version; done openjdk version "1.8.0_302-ga" OpenJDK Runtime Environment (build 1.8.0_302-ga-1) OpenJDK 64-Bit Server VM (build 25.302-b1, mixed mode) Build Date : pon, 2 sie 2021, 16:46:33 Doing the same on kernel 5.15.2 (VM on proxmox) and -version works. 4.4.279 on vserver host, glibc 2.34 - works. 4.4.279 butin vserver guest, glibc 2.34 hangs. 4.4.279 but glibc 2.33 in vserver guest - works. openjdk9-9.0.4.12-1.x86_64 also hangs in vserver guest with glibc 2.34 openjdk10-10.0.2.13-1.x86_64 works openjdk11-11.0.13-1.x86_64 works So vserver guest + glibc 2.34 + openjdk 8 and 9 is hanging on futexes. Easy way of testing if you don't have glibc 2.34 installed: - install openjdk8 from ftp (--nofollow --nodeps can be useful to prevent in dragging latest nss and thus glibc 2.3 - only working "java" binary is needed) - copy 2.34 *.so libs to some path - patchelf --set-interpreter /path/to/glibc-2.34-test-libs/ld-linux-x86-64.so.2 /usr/lib64/jvm/openjdk8-1.8.0.302/bin/java - run: while (true); do date; LD_LIBRARY_PATH=/path/to/glibc-2.34-test-libs/ java -version; done ps. builders stopped using vservers on 7 november 2021 and use 5.x kernels -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From arekm at maven.pl Wed Nov 24 19:55:41 2021 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Wed, 24 Nov 2021 19:55:41 +0100 Subject: TEST build OK: openjdk8.spec - openjdk 8 and 9 hangs on glibc 2.34 in vserver guest In-Reply-To: References: <20211022081206.sxkzfnajgyncxtcq@pine> <20211022093710.v25jx4erszaje2gk@pine> Message-ID: W dniu 24.11.2021 o?14:00, Arkadiusz Mi?kiewicz pisze: > W dniu 22.10.2021 o?11:37, Jan Palus pisze: >> On 22.10.2021 10:44, Jan R?korajski wrote: >>> 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. >> >> Currently openjdk8 requires either JDK 1.7 or 1.8 for build, I guess we >> can patch it and try to build with openjdk11, no guarantees it would >> work though. Not sure what is the difference but I had no issues >> building openjdk8 1.8.0.312 with openjdk8 1.8.0.302 and glibc 2.34 on >> x86_64, aarch64 and armv7hnl. I'll try to reproduce in fresh VM. > > For me our openjdk8 from ftp hangs on just doing "java -version". Not > always. Sometimes I need to run that 5-10 times but I do get the hang > easily. kernel 4.9.194, glibc 2.34, x86_64, vserver guest > > while (true); do date; java -version; done > > openjdk version "1.8.0_302-ga" > OpenJDK Runtime Environment (build 1.8.0_302-ga-1) > OpenJDK 64-Bit Server VM (build 25.302-b1, mixed mode) > > Build Date : pon, 2 sie 2021, 16:46:33 More fun with that. working system, glibc 2.34, on any kernel mkdir /test/ rsync -avPH / /test/ --exclude /test/ --exclude /proc --exclude /sys mount /proc /test/proc -o bind chroot /test/; java -version - hangs at some retry mkdir -p /test/sys/devices/system/cpu chroot /test/; java -version - no hangs (so proc is mounted but /sys is not; just dir exists) -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Wed Nov 24 21:04:02 2021 From: atler at pld-linux.org (Jan Palus) Date: Wed, 24 Nov 2021 21:04:02 +0100 Subject: TEST build OK: openjdk8.spec - openjdk 8 and 9 hangs on glibc 2.34 in vserver guest In-Reply-To: References: <20211022081206.sxkzfnajgyncxtcq@pine> <20211022093710.v25jx4erszaje2gk@pine>

Message-ID: <20211124200402.6vpyympsv57zvn6i@pine> On 24.11.2021 19:55, Arkadiusz Mi?kiewicz via pld-devel-en wrote: > W dniu 24.11.2021 o?14:00, Arkadiusz Mi?kiewicz pisze: > > W dniu 22.10.2021 o?11:37, Jan Palus pisze: > >> On 22.10.2021 10:44, Jan R?korajski wrote: > >>> 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. > >> > >> Currently openjdk8 requires either JDK 1.7 or 1.8 for build, I guess we > >> can patch it and try to build with openjdk11, no guarantees it would > >> work though. Not sure what is the difference but I had no issues > >> building openjdk8 1.8.0.312 with openjdk8 1.8.0.302 and glibc 2.34 on > >> x86_64, aarch64 and armv7hnl. I'll try to reproduce in fresh VM. > > > > For me our openjdk8 from ftp hangs on just doing "java -version". Not > > always. Sometimes I need to run that 5-10 times but I do get the hang > > easily. kernel 4.9.194, glibc 2.34, x86_64, vserver guest > > > > while (true); do date; java -version; done > > > > openjdk version "1.8.0_302-ga" > > OpenJDK Runtime Environment (build 1.8.0_302-ga-1) > > OpenJDK 64-Bit Server VM (build 25.302-b1, mixed mode) > > > > Build Date : pon, 2 sie 2021, 16:46:33 > > More fun with that. > > working system, glibc 2.34, on any kernel > > mkdir /test/ > rsync -avPH / /test/ --exclude /test/ --exclude /proc --exclude /sys > mount /proc /test/proc -o bind > chroot /test/; java -version - hangs at some retry > > mkdir -p /test/sys/devices/system/cpu > chroot /test/; java -version - no hangs > (so proc is mounted but /sys is not; just dir exists) Great finding! Indeed the following is a quick reproducer for any java8 version -- openjdk8 302/312, icedtea8 and even Oracle JDK8 202: systemd-run --wait -t -p InaccessiblePaths=/sys /usr/lib64/jvm/openjdk8/bin/java -version So far couldn't reproduce with openjdk11 and FWIW it does not reproduce on aarch64. From atler at pld-linux.org Wed Nov 24 21:30:03 2021 From: atler at pld-linux.org (Jan Palus) Date: Wed, 24 Nov 2021 21:30:03 +0100 Subject: TEST build OK: openjdk8.spec - openjdk 8 and 9 hangs on glibc 2.34 in vserver guest In-Reply-To: <20211124200402.6vpyympsv57zvn6i@pine> References: <20211022081206.sxkzfnajgyncxtcq@pine> <20211022093710.v25jx4erszaje2gk@pine>

<20211124200402.6vpyympsv57zvn6i@pine> Message-ID: <20211124203003.ixdc5zjd25ehc3ri@pine> On 24.11.2021 21:04, Jan Palus wrote: > > More fun with that. > > > > working system, glibc 2.34, on any kernel > > > > mkdir /test/ > > rsync -avPH / /test/ --exclude /test/ --exclude /proc --exclude /sys > > mount /proc /test/proc -o bind > > chroot /test/; java -version - hangs at some retry > > > > mkdir -p /test/sys/devices/system/cpu > > chroot /test/; java -version - no hangs > > (so proc is mounted but /sys is not; just dir exists) > > Great finding! Indeed the following is a quick reproducer for any java8 > version -- openjdk8 302/312, icedtea8 and even Oracle JDK8 202: > > systemd-run --wait -t -p InaccessiblePaths=/sys /usr/lib64/jvm/openjdk8/bin/java -version > > So far couldn't reproduce with openjdk11 and FWIW it does not reproduce > on aarch64. If I had to guess... Code that opens /sys/devices/system/cpu is found in glibc: https://sourceware.org/git?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getsysstats.c;h=1391e360b8f8e86ce39a56d4bf1117f37d07eed9;hb=ae37d06c7d127817ba43850f0f898b793d42aea7#l95 Notice that result is different between case in which directory does not exist (1) and exists but is empty (0). Now looking at java8 code there's a juicy comment right next to getting number of CPUs: // Most versions of linux have a bug where the number of processors are // determined by looking at the /proc file system. In a chroot environment, // the system call returns 1. This causes the VM to act as if it is // a single processor and elide locking (see is_MP() call). static bool unsafe_chroot_detected = false; static const char *unstable_chroot_error = "/proc file system not found.\n" "Java may be unstable running multithreaded in a chroot " "environment on Linux when /proc filesystem is not mounted."; void os::Linux::initialize_system_info() { set_processor_count(sysconf(_SC_NPROCESSORS_CONF)); But... the code in glibc does not look at /proc... at least not in 2.34. I suppose this is the commit to be blamed for this regression: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f13fb81ad3159543741e9132685335002a6d5df2 glibc 2.33 used to look at /proc too, but it no longer does in 2.34. Will check how openjdk11 handles that, but if any of this is true I'd say the easiest fix would be to always lock and not optimize based on cpu count. From arekm at maven.pl Wed Nov 24 22:47:50 2021 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Wed, 24 Nov 2021 22:47:50 +0100 Subject: TEST build OK: openjdk8.spec - openjdk 8 and 9 hangs on glibc 2.34 in vserver guest In-Reply-To: <20211124203003.ixdc5zjd25ehc3ri@pine> References: <20211022081206.sxkzfnajgyncxtcq@pine> <20211022093710.v25jx4erszaje2gk@pine>

<20211124200402.6vpyympsv57zvn6i@pine> <20211124203003.ixdc5zjd25ehc3ri@pine> Message-ID: <6c980bb5-f6e3-1d2c-f81a-722695c5adcc@maven.pl> W dniu 24.11.2021 o?21:30, Jan Palus pisze: > I suppose this is the commit to be blamed for this regression: > > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f13fb81ad3159543741e9132685335002a6d5df2 > > glibc 2.33 used to look at /proc too, but it no longer does in 2.34. Yes, f13fb81ad3159543741e9132685335002a6d5df2 is the first bad commit commit f13fb81ad3159543741e9132685335002a6d5df2 Author: Adhemerval Zanella Date: Thu Mar 25 14:04:37 2021 -0300 linux: Remove /proc/cpuinfo fallback on alpha and sparc There is no much gain in fallback to cpuinfo if sysfs is no present, usually on restricted environment neither will be present. It also simplifies the code and make all architecture use the sched_getaffinity as the sysfs fallback. Checked on sparc64-linux-gnu. sysdeps/unix/sysv/linux/alpha/getsysstats.c | 38 ----------------------------- sysdeps/unix/sysv/linux/getsysstats.c | 22 +---------------- sysdeps/unix/sysv/linux/sparc/getsysstats.c | 38 ----------------------------- 3 files changed, 1 insertion(+), 97 deletions(-) delete mode 100644 sysdeps/unix/sysv/linux/alpha/getsysstats.c delete mode 100644 sysdeps/unix/sysv/linux/sparc/getsysstats.c glibc people will reintroduce fallback (but based on /proc/stat). In mean time sysfs got mounted on builders and I also saw your changes to make multiprocessor default in openjdk 8 -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Thu Nov 25 10:27:44 2021 From: atler at pld-linux.org (Jan Palus) Date: Thu, 25 Nov 2021 10:27:44 +0100 Subject: TEST build OK: openjdk8.spec In-Reply-To: References: <35c6dd94-dee7-4ae5-b497-eba599e823b2@pld.src.builder> Message-ID: <20211125092744.zqfmy6wfxte676hg@pine> On 25.11.2021 06:10, PLD th-x86_64 builder wrote: > openjdk8.spec (test): OK > > --- openjdk8.spec:test: > not upgrading > Build-Time: user:3197.59s sys:651.63s real:1129.22s (faults io:14177 non-io:93385165) Supposedly build took about ~20m, while email with confirmation came after ~9h. Is there any issue with openjdk8 remaining or is it builder related? From arekm at maven.pl Thu Nov 25 10:57:17 2021 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Thu, 25 Nov 2021 10:57:17 +0100 Subject: TEST build OK: openjdk8.spec In-Reply-To: <20211125092744.zqfmy6wfxte676hg@pine> References: <35c6dd94-dee7-4ae5-b497-eba599e823b2@pld.src.builder> <20211125092744.zqfmy6wfxte676hg@pine> Message-ID: <535bc85f-11cf-1cf7-dfa9-6f0f10b94f86@maven.pl> W dniu 25.11.2021 o?10:27, Jan Palus pisze: > On 25.11.2021 06:10, PLD th-x86_64 builder wrote: >> openjdk8.spec (test): OK >> >> --- openjdk8.spec:test: >> not upgrading >> Build-Time: user:3197.59s sys:651.63s real:1129.22s (faults io:14177 non-io:93385165) > > Supposedly build took about ~20m, while email with confirmation came > after ~9h. Is there any issue with openjdk8 remaining or is it builder > related? builder related, cron was stopped. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Sun Nov 28 15:05:39 2021 From: atler at pld-linux.org (Jan Palus) Date: Sun, 28 Nov 2021 15:05:39 +0100 Subject: [projects/template-specs] looks like github changed download URLs :( In-Reply-To: <865867d6d375f2f793d5019947efeea053446f38_refs_heads_master@pld-linux.org> References: <3bd9c7f5f8bffe14031f7f5fd87b11e8f05d5177_refs_heads_master@pld-linux.org> <865867d6d375f2f793d5019947efeea053446f38_refs_heads_master@pld-linux.org> Message-ID: <20211128140539.35hggxu4qrudxvao@pine> On 28.11.2021 10:46, baggins wrote: > commit 865867d6d375f2f793d5019947efeea053446f38 > Author: Jan R?korajski > Date: Sun Nov 28 10:46:28 2021 +0100 > > looks like github changed download URLs :( > > template.spec | 1 + > 1 file changed, 1 insertion(+) > --- > diff --git a/template.spec b/template.spec > index f90e1a5..15c891e 100644 > --- a/template.spec > +++ b/template.spec > @@ -12,6 +12,7 @@ License: - (enter GPL/GPL v2/GPL v3/LGPL/BSD/BSD-like/other license name here) > Group: Applications > # SF URL: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz > # github URL https://github.com/USER/PROJECT/archive/v%{version}/%{name}-%{version}.tar.gz > +# new(?) github URL https://github.com/USER/PROJECT/archive/refs/tags/v%{version}.tar.gz > Source0: %{name}-%{version}.tar.gz > # Source0-md5: - > #Source1: - Let's wait for outcome of: https://github.com/github/feedback/discussions/8149 https://github.community/t/download-url-not-working-anymore/1269 before switching urls. Might turn out to be unintentional change.