Re: DISTFILES: kicad: ERRORS: kicad-packages3D-8.0.2.tar.bz2
What happens here? ENOSPC? Offending file is ~700MB big. On Mon, Apr 29, 2024 at 09:04:51PM +0200, qboosh wrote: > Request by: qboosh > > FATAL: cannot move ./upload/kicad-packages3D-8.0.2.tar.bz2 to > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b > ERROR: cannot write > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b/kicad-packages3D-8.0.2.tar.bz2.link > > Files fetched: 0 > > ALREADY GOT: > https://gitlab.com/kicad/code/kicad/-/archive/8.0.2/kicad-8.0.2.tar.bz2 > 957ba90492d8bf60f4ff55b3910f1cbd kicad-8.0.2.tar.bz2 > ALREADY GOT: > https://gitlab.com/kicad/services/kicad-doc/-/archive/8.0.2/kicad-doc-8.0.2.tar.bz2 > 5c1b5dc997be84b08d59d78a5a9fcd3e kicad-doc-8.0.2.tar.bz2 > ALREADY GOT: > https://gitlab.com/kicad/libraries/kicad-symbols/-/archive/8.0.2/kicad-symbols-8.0.2.tar.bz2 > 060c52586965f15b867ee0683aa642ae kicad-symbols-8.0.2.tar.bz2 > ALREADY GOT: > https://gitlab.com/kicad/libraries/kicad-footprints/-/archive/8.0.2/kicad-footprints-8.0.2.tar.bz2 > c9537b5ccaa9581ff32d157837a13c38 kicad-footprints-8.0.2.tar.bz2 > ALREADY GOT: > https://gitlab.com/kicad/libraries/kicad-templates/-/archive/8.0.2/kicad-templates-8.0.2.tar.bz2 > 20932897d55d49386a1e2431a2aeef5f kicad-templates-8.0.2.tar.bz2 > > > -- > Virtually Yours: distfiles. > ___ > pld-cvs-commit mailing list > pld-cvs-com...@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
builders->ftp uploads defunct
Since Saturday new packages don't appear in th-test. Could it be fixed? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/gobject-introspection] - updated to 1.80.0; added bootstrap bcond for glib 2.78->2.80 transition
On Sun, Mar 10, 2024 at 10:56:22AM +0100, Jan Palus wrote: > Shouldn't it be the other way around -- "bootstrap" bcond in glib2 for > building without introspection? Currently while gobject-introspection > does not build-time depend on glib2-devel >= 2.80, it does runtime > depend on glib2 >= 2.80 (both in rpm deps and linked dynamic library) > which cannot be satisfied to build glib2 2.80. Oh, I wasn't aware of g-ir-scanner dependency to build introspection files in glib2 (I had gobject-introspection-devel 1.78 installed). So now I added "introspection" bcond to glib2.spec to allow bootstrapping from scratch. Previously I added "bootstrap" bcond in gobject-introspection as a way to cleanly build+upgrade on existing system (it's not possible to cleanly upgrade glib2 built with introspection without removing or upgrading to 1.80 existing gobject-introspection 1.78 package due to files conflict). So I could build whole glib2 2.80 and gobject-introspection 1.80 and upgrade them both simultaneously. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1
On Sun, Feb 04, 2024 at 03:04:21PM +0100, Witold Filipczyk via pld-devel-en wrote: > Dnia Sat, Feb 03, 2024 at 08:56:25PM +0100, Jakub Bogusz napisał(a): > > On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote: > > > commit 3b3013be1262989c7a7df78ffab6d797766b6486 > > > Author: Witold Filipczyk > > > Date: Sat Feb 3 20:24:04 2024 +0100 > > > > > > - updated to 5.249.0; rel 0.1 > > > > > > kf5-attica.spec | 41 - > > > 1 file changed, 20 insertions(+), 21 deletions(-) > > > > Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now? > > OK. What to do with plasma (now kp5-*) and KDE Gear (now ka5-*) ? No idea about starting prefix (should "kp" and "ka" be preserved or changed), but AFAICS files/dirs are getting "6" suffix now, so IMO number should be updated (or dropped, if KDE 6 is going to instantly replace KDE 5). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1
On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote: > commit 3b3013be1262989c7a7df78ffab6d797766b6486 > Author: Witold Filipczyk > Date: Sat Feb 3 20:24:04 2024 +0100 > > - updated to 5.249.0; rel 0.1 > > kf5-attica.spec | 41 - > 1 file changed, 20 insertions(+), 21 deletions(-) Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/mysql] Started work on 8.1.0 upgrade and also started making this package coinstallable with other mysql/ma
On Fri, Oct 20, 2023 at 07:01:56PM +0200, arekm wrote:
> commit 616994dbf9872356085c234c4c1efaa050d74ce3
> Author: Arkadiusz Miśkiewicz
> Date: Fri Oct 20 19:01:24 2023 +0200
>
> Started work on 8.1.0 upgrade and also started making this package
> coinstallable with other mysql/mariadb/percona servers
> +%define majorver81
> +Name:mysql%{majorver}
Please, use "8.1" (and similar scheme) not "81" in such cases.
If they e.g. start using 24.x as version number next year, our suffixes would
go crazy.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/shared-mime-info] fix build with doc; rel 2
On Mon, Oct 09, 2023 at 02:59:52PM +0200, atler wrote: > commit dabbd0362fbd2a2345f450a5efceb62eb321741b > Author: Jan Palus > Date: Mon Oct 9 14:11:26 2023 +0200 > > fix build with doc; rel 2 > > replace unicode apostrophe with ascii one. from: > https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/254 We can also use: SP_ENCODING=utf-8 \ db2html data/shared-mime-info-spec.xml to build with Unicode. But yes, using Unicode for just single apostrophe is excessive... -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
itstool 2.0.7 vs [packages/mate-utils] up to 1.26.1
On Wed, May 10, 2023 at 10:07:32AM +0200, atler wrote:
> commit 8aa16867d2911b7b77adf7d0041e2b455f560fc9
> Author: Jan Palus
> Date: Wed May 10 10:07:19 2023 +0200
>
> up to 1.26.1
>
> mate-utils.spec | 4 ++--
It (usually) fails for me with itstool 2.0.7. With itstool 2.0.6 it succeeded.
```
if ! test -d "pt/"; then mkdir "pt/"; fi
if test -d "C"; then d="../"; else
d="/home/comp/rpm/BUILD/mate-utils-1.26.1/gsearchtool/help/"; fi; \
mo="pt/pt.mo"; \
if test -f "${mo}"; then mo="../${mo}"; else
mo="/home/comp/rpm/BUILD/mate-utils-1.26.1/gsearchtool/help/${mo}"; fi; \
(cd "pt/" && itstool -m "${mo}" ${d}/C/index.docbook ${d}/C/legal.xml) && \
touch "pt/pt.stamp"
Memory fault
```
or
```
if ! test -d "pt/"; then mkdir "pt/"; fi
if test -d "C"; then d="../"; else
d="/home/comp/rpm/BUILD/mate-utils-1.26.1/gsearchtool/help/"; fi; \
mo="pt/pt.mo"; \
if test -f "${mo}"; then mo="../${mo}"; else
mo="/home/comp/rpm/BUILD/mate-utils-1.26.1/gsearchtool/help/${mo}"; fi; \
(cd "pt/" && itstool -m "${mo}" ${d}/C/index.docbook ${d}/C/legal.xml) && \
touch "pt/pt.stamp"
Traceback (most recent call last):
File "/usr/bin/itstool", line 1647, in
doc.merge_translations(translations, opts.lang, strict=opts.strict)
File "/usr/bin/itstool", line 1016, in merge_translations
lcnode.setProp(attr, origlang)
File "/usr/lib/python3.10/site-packages/libxml2.py", line 3640, in setProp
if ret is None:raise treeError('xmlSetProp() failed')
libxml2.treeError: xmlSetProp() failed
```
(sometimes it succeeds)
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Fri, Jul 22, 2022 at 11:03:54AM +0200, Jan Rękorajski wrote: > Can someone explain why are we using split sources/packages for Qt? Beside build time and space requirements, I see one more reason now: rebuilding after dependent package soname change is more painful. Current case: jasper 3.x. Split case: just qt5-qtimageformats.spec to rebuild Monolithic case: whole qt6.spec to rebuild -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
ruby packages building from .gem
How is it supposed to work (taking ruby-ffi.spec as example)?
.gem itself is tar archive containing metadata.gz and data.tar.gz.
But rpm uses "gem unpack", which unpacks data.tar.gz from inside.
And build fails with:
+ cd ffi-1.9.25
+ /usr/lib/rpm/gem_helper.rb spec
/usr/lib/rpm/gem_helper.rb:77:in `open': No such file or directory @ rb_sysopen
- metadata.gz (Errno::ENOENT)
from /usr/lib/rpm/gem_helper.rb:77:in `'
What's wrong here, how to fix it properly/nice?
I can fix the build by adding `%{__tar} xf %{SOURCE0} metadata.gz`
but I wouldn't call it nice.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rust on carme-x32
On Thu, Jan 19, 2023 at 09:14:51AM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 18.01.2023 16:08, Jakub Bogusz wrote: > >Could rust be installed on carme-x32? > > > >I'd like to (try to) fix mozjs102 build (required for new gjs), but > >I cannot install rust myself because of x86_64 packages requirements. > > > > > > Should be available now. I need cargo as well (requires 64-bit curl, libgit2 and openssl libs). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On Wed, Jan 18, 2023 at 01:02:34PM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 18.01.2023 09:56, Jan Palus wrote: > >On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: > >>On 17.01.2023 12:23, Jan Palus wrote: > >>>Noticed during build of kodi-addon-inputstream-adaptive that contrary to > >>>x86_64 and i686, x32 builder downloaded external sources successfully: > >> > >>bind was installed there and seems that even if there is no access to > >>/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 > >> > >>Uninstalled. > >> > >>The best would be to change UID of "builder" user used inside of chroot > >>and drop all outgoing packets coming from it at iptables level. > > > >Or perhaps modify pld-builder to make each rpmbuild invocation in a new > >network namespace via `unshare -n -c`. That would effectively cut whole > >network for the process. > > We can try that... commited. i686 and x86_64 say: "unshare: unshare failed: Operation not permitted" Still waiting for x32 (seems busy with openjdks). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
rust on carme-x32
Could rust be installed on carme-x32? I'd like to (try to) fix mozjs102 build (required for new gjs), but I cannot install rust myself because of x86_64 packages requirements. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python3-git-filter-repo] - new, separated from git-filter-repo.spec (now with python metadata, required for e.g. b4)
On Mon, Oct 17, 2022 at 09:14:27PM +0300, Elan Ruusamäe wrote: > wth. how is this any good? > > just add the -n python3-git-filter-repo to main git-filter-repo package! > > with your package split and the require-line in old spec, you force us > to keep two .spec files up todate with each release of git-filter-repo, > additionally deal with sending to builders, and in proper order as well. > > why? github package doesn't contain metadata for python package (or data to generate them). pypi package doesn't contain docs for git side. Alternative solution could be single spec with both sources. But I didn't know the direction in which the distribution of this package would evolve, the last release so far was almost year ago. Now I see there is 2.38.0, I'll check it in few days. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc 2.36 *.o files debug extraction broken
On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote: > On 16.08.2022 20:31, Jakub Bogusz wrote: > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > > section: > > ... > > > For now only i686 builds are affected because x86_64 and x32 glibc-devel > > packages > > haven't been updated on builders. > > > > > > Any guesses what changed? > > I believe to be responsible for this, specifically with this debugedit > commit: > > commit bd392272c04d608257eb999670d85261d5125d93 > Author: Jan Palus > Date: Tue Jun 7 11:39:01 2022 > > bring back patch from rpm 4.16 for no exe bit when searching debuginfo; > rel 2 > > which now considers non-executable object file matching pattern > found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* > > Which in turn causes object file to be passed to `eu-strip` directly > responsible for stripping .note.GNU-stack section. > > Fix proposals: > > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared > object\) > 2. modify macros to invoke `find-debuginfo` with `--keep-section > .note.GNU-stack` > 3. both 1 and 2 I think it would be safer to revert to not touching *.o files (by default). BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove from *.a/*.so? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
glibc 2.36 *.o files debug extraction broken
In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack section: (before installing) $ objdump -h ../BUILD/glibc-2.36.debuginfo/builddir/csu/crtn.o ../BUILD/glibc-2.36.debuginfo/builddir/csu/crtn.o: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0034 2**0 ALLOC 3 .note.gnu.property 0044 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .init 0005 0078 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 5 .fini 0005 007d 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .note.GNU-stack 0082 2**0 CONTENTS, READONLY 7 .debug_line 005a 0084 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 8 .debug_info 0022 00d9 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 9 .debug_abbrev 0012 00fb 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 10 .debug_aranges 0028 0110 2**3 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 11 .debug_str004f 0133 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 12 .debug_ranges 0020 0184 2**3 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS (after) /home/users/qboosh/tmp/glibc-2.36-i686-root-qboosh.debuginfo/usr/lib/crtn.o: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0034 2**0 ALLOC 3 .note.gnu.property 0044 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .init 0005 0078 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 5 .fini 0005 007d 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .gnu_debuglink 0020 0084 2**2 CONTENTS, READONLY With debuginfo packages disabled, .note.GNU-stack section is still present. It results in binaries executable stack and linker features misdetection due to new warning: /usr/bin/ld: warning: /usr/lib/gcc/i686-pld-linux/11.3.0/../../../crtn.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker affecting e.g. gjs: Compiler for C++ supports link arguments -Bsymbolic-functions: NO meson.build:78:12: ERROR: Problem encountered: -Bsymbolic-functions not supported, configure with -Dbsymbolic_functions=false or gcab: Compiler for C supports link arguments -Wl,-z,relro: NO Compiler for C supports link arguments -Wl,-z,now: NO + missing symbol versioning For now only i686 builds are affected because x86_64 and x32 glibc-devel packages haven't been updated on builders. Any guesses what changed? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
RFC: shell completions policy change?
As more and more packages are getting bash/zsh completions, separate
completions packages are becoming useless (harder to find, even not suggested).
My proposal:
1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
level) dirs to filesystem package and package bash/zsh[/fish] completion
files just with commands (existing bash-/zsh-[/fish-] packages to be merged and
obsoleted). [preferred]
Fortunately completion files don't have shebangs, which would generate
bash/zsh dependencies.
2) at least add Suggests for completions packages in packages with
commands to complete
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pam broken
On Tue, Jun 07, 2022 at 01:03:41PM +0300, Elan Ruusamäe wrote: > On 06.06.2022 19:37, Jakub Bogusz wrote: > >On Mon, Jun 06, 2022 at 06:48:47PM +0300, Elan Ruusamäe wrote: > >>Jun 6 18:27:31 ldap2 sudo: PAM unable to > >>dlopen(/lib64/security/pam_unix.so): /lib64/libnsl.so.2: undefined symbol: > >>key_secretkey_is_set, version TIRPC_0.3.2 > >>Jun 6 18:27:31 ldap2 sudo: PAM adding faulty module: > >>/lib64/security/pam_unix.so > >> > >> > >>anyone wants to fix missing dependency error? > >rpm -q libtirpc? > > > Thu Nov 2 17:11:07 2017 libtirpc-1.0.1-1.x86_64 So it's libtirpc that's broken; key_secretkey_is_set export has been fixed in 1.0.3 - I bumped libnsl dependency on libtirpc. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pam broken
On Mon, Jun 06, 2022 at 06:48:47PM +0300, Elan Ruusamäe wrote: > Jun 6 18:27:31 ldap2 sudo: PAM unable to > dlopen(/lib64/security/pam_unix.so): /lib64/libnsl.so.2: undefined symbol: > key_secretkey_is_set, version TIRPC_0.3.2 > Jun 6 18:27:31 ldap2 sudo: PAM adding faulty module: > /lib64/security/pam_unix.so > > > anyone wants to fix missing dependency error? rpm -q libtirpc? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
openldap build
It seems that openldap currently doesn't build without openldap-devel already installed - probably because libslapi isn't installed before slapd-shared module. Could sb look at it? I have no more time today becase I'm leaving. I'll return on Sunday, then I can get back to it. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python (3.10) dirs
On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan Rękorajski wrote: > On Tue, 19 Apr 2022, Jan Rękorajski wrote: > > > On Mon, 18 Apr 2022, Jakub Bogusz wrote: > > > > > After recent python3.10 changes meson started to use /usr/share for > > > purelib, but automake's pythondir is broken now: > > > > > > pythondir (platform-indepdendent) is wrong: > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > /usr/share/python2.7/site-packages > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > /usr/lib/python3.10/site-packages > > > > > > pyexecdir is OK: > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > /usr/lib64/python2.7/site-packages > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > /usr/lib64/python3.10/site-packages > > > > What package version do you have? Python3 shows /usr/share for me: > > > > $ python3 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm > > -q python3 > > :1: DeprecationWarning: The distutils package is deprecated and > > slated for removal in Python 3.12. Use setuptools or check PEP 632 for > > potential alternatives > > :1: DeprecationWarning: The distutils.sysconfig module is > > deprecated, use sysconfig instead > > /usr/share/python3.10/site-packages > > python3-3.10.4-5.x86_64 > > > > On a side note, distutils is deprecated... > > The problematic dir seems to be coming from > /usr/share/python3.10/site-packages/distutils-precedence.pth > from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' > there. It's automake's standard AM_PATH_PYTHON that refers to distutils. Maybe we should rework revert-debian-python-hacks.patch ... -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
python (3.10) dirs
After recent python3.10 changes meson started to use /usr/share for purelib, but automake's pythondir is broken now: pythondir (platform-indepdendent) is wrong: $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" /usr/share/python2.7/site-packages $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" /usr/lib/python3.10/site-packages pyexecdir is OK: $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" /usr/lib64/python2.7/site-packages $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" /usr/lib64/python3.10/site-packages -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/dssim2] - do not obsolete a library if not providing it
On Wed, Feb 23, 2022 at 01:20:38AM +0100, baggins wrote:
> commit 0131577abe142917eac5751e6df84cfde8721c79
> Author: Jan Rękorajski
> Date: Wed Feb 23 01:20:12 2022 +0100
>
> - do not obsolete a library if not providing it
[...]
> @@ -24,7 +24,6 @@ BuildRequires: rpmbuild(macros) >= 2.004
> BuildRequires: rust
> BuildRequires: tar >= 1:1.22
> BuildRequires: xz
> -Obsoletes: dssim < 2
> ExclusiveArch: %{x8664} %{ix86} x32 aarch64 armv6hl armv7hl armv7hnl
> BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
>
dssim package is not a library, but an older version of dssim tool.
Library is contained in dssim-libs package.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD mail/requests problems
On Tue, Jan 18, 2022 at 07:25:16PM +0100, Jan Rękorajski wrote: > On Tue, 18 Jan 2022, Arkadiusz Miśkiewicz via pld-devel-en wrote: > > > On 17.01.2022 18:37, Jakub Bogusz wrote: > > > On Sun, Jan 16, 2022 at 09:41:05PM +0100, Jakub Bogusz wrote: > > >> - distfiles fetch request don't seem to be handled (since a few days) or > > >> no > > >> mail report is sent (both for requester nor pld-commit list) > > > > > > It seems distfiles are not fetching anything new at all (both by git or > > > manual mail requests), and reports are not sent. > > > > > >> - I don't get any build logs since yesterday > > >> > > >> - only some (http) build requests are handled (one per ? hours) > > > > > > This one seems partially solved: ignored requests fail because of > > > missing files on distfiles - but again, I don't get any mail reports > > > about failed build from src builder. > > > > disk was fully filled on MX due to some spammers. > > There is still something wrong. I'm not getting any response from > failed(?) requests. > > Ex. trying to build the kernel from head does not yield any response, not > even build failure. Like the build request went to /dev/null. 404 Not Found (/distfiles/by-md5/d/5/d571392436365678b420e4dece216514/patch-5.16.1.xz) (I've just sent fetchsrc request for kernel.spec to fix it) But why src builder doesn't send failure notifications? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD mail/requests problems
On Sun, Jan 16, 2022 at 09:41:05PM +0100, Jakub Bogusz wrote: > - distfiles fetch request don't seem to be handled (since a few days) or no > mail report is sent (both for requester nor pld-commit list) It seems distfiles are not fetching anything new at all (both by git or manual mail requests), and reports are not sent. > - I don't get any build logs since yesterday > > - only some (http) build requests are handled (one per ? hours) This one seems partially solved: ignored requests fail because of missing files on distfiles - but again, I don't get any mail reports about failed build from src builder. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
PLD mail/requests problems
- distfiles fetch request don't seem to be handled (since a few days) or no mail report is sent (both for requester nor pld-commit list) - I don't get any build logs since yesterday - only some (http) build requests are handled (one per ? hours) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
cargo-vendor broken with openssl 3?
``` [qboosh@carme-pld dssim-3.0.2]$ cargo vendor Updating crates.io index error: failed to sync Caused by: failed to load pkg lockfile Caused by: failed to get `imgref` as a dependency of package `dssim-core v3.1.0 (/home/users/qboosh/rpm/BUILD/dssim-3.0.2/dssim-core)` Caused by: failed to fetch `https://github.com/rust-lang/crates.io-index` Caused by: network failure seems to have happened if a proxy or similar is necessary `net.git-fetch-with-cli` may help here https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli Caused by: the SSL certificate is invalid; class=Ssl (16); code=Certificate (-17) ``` Fetching `https://github.com/rust-lang/crates.io-index` with curl works. cargo-vendor works for me with rust 1.57.0 built with openssl 1.1.1l. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/iputils] - epoch 3 (s20190709 > 20210722), BR: pkgconfig
On Tue, Dec 07, 2021 at 09:51:58PM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: > W dniu 07.12.2021 o 21:05, qboosh pisze: > > commit 3a2973d1fda11d4c2c73488d06ab1c940768ce15 > > Author: Jakub Bogusz > > Date: Tue Dec 7 21:05:33 2021 +0100 > > > > - epoch 3 (s20190709 > 20210722), BR: pkgconfig > > Hmm. My initial plan was to keep sXYZ scheme but: > > [arekm@ixion ~]$ rpmvercmp s20190709 20210722 > s20190709 < 20210722 > [arekm@ixion ~]$ rpmvercmp 20210722 s20190709 > 20210722 > s20190709 > [arekm@ixion ~]$ rpm --version > RPM version 4.16.1.3 > > You say otherwise, why? Uh. rpm 4.5 and rpm5 say $ rpmvercmp s20190709 20210722 s20190709 > 20210722 $ rpmvercmp 20210722 s20190709 20210722 < s20190709 so it's not properly defined if it varies between versions/implementations -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/gstreamer] - up to 1.19.3
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 Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/ca-certificates] Rel 6; make sure we don't include expired certs
On Fri, Oct 01, 2021 at 12:36:20PM +0200, arekm wrote: > commit 0818a4328225cca2d41e43f0fa816f38bb3cbe69 > Author: Arkadiusz Miśkiewicz > Date: Fri Oct 1 12:36:07 2021 +0200 > > Rel 6; make sure we don't include expired certs Unfortunately ix86 `date` doesn't know y2038+... | date: invalid date 'Oct 25 08:25:55 2043 GMT' -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
systemd vs split /usr
meson.build from systemd 249 says: "split-usr mode is going to be removed" (and sysusers.d location is already broken/inconsistent in this version, I'm going to patch it) Any plans related to this? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: qt4 broken on i686
On Sun, Sep 19, 2021 at 08:17:47PM +0200, Jan Rękorajski wrote:
> On Thu, 19 Aug 2021, Jakub Bogusz wrote:
>
> > On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan Rękorajski wrote:
> > > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> > > infinite looping (ex. meinproc4 in kde4-kig).
> > >
> > > I'm running out of ideas[1] and time to troubleshoot this and would
> > > appreciate if anyone would be willing to try and figure out WTF is
> > > broken there.
> > >
> > > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> > > glibc 2.34 issue, but I don't have resources at hand to validate it.
> >
> > I don't know yet if it's related to glibc, gcc or binutils, but simple
> > testcase is searching in empty QMap:
> >
> > ```
> > #include
> >
> > int main()
> > {
> > QMap mm;
> > mm.constFind(999);
> > }
> > ```
> >
> > It hangs even on carme-x86_64.
> >
> > Issue is probably related to shared_null static field (SIOF?)
>
> My take is on gcc 11. I downgraded everything but gcc and it still crashed.
>
> To verify that it's indeed gcc I need to rebuild it (gcc) locally due to
> intertwined deps preventing simple package downgrade.
I tried to investigate the issue deeper - and the last I found was:
The symbol _ZN8QMapData11shared_nullE (demangled: QMapData::shared_null)
resides both in executable (objdump -T from i686):
0804c040 gDO .bss 0048 Base_ZN8QMapData11shared_nullE
and libQtCore.so.4:
002fa460 gDO .data 0048 Base_ZN8QMapData11shared_nullE
When compiled in current Th, the code in executable sees symbol mapped
from executable and the library sees symbol mapped from library.
IIRC when compiled on slightly older system (qt4 built with gcc 7 or 8,
glibc 2.33 etc.) in both cases symbol address was the same.
But in my current system (i686, glibc-2.34, binutils-2.37, gcc-8.4.0, qt4
rebuilt in this environment) the result is the same as in Th: there are
two instances of this symbol and testcase hangs.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpmlib(ShortCircuited)
On Tue, Aug 24, 2021 at 03:12:32PM +0300, Elan Ruusamäe wrote:
> https://www.pld-linux.org/packages/rpm#spec_development
>
> *
>rpm.org rpm generates|rpmlib(ShortCircuited)|dependencies when
>package is build using|--short-circuit|option. To disable that
>add|%disable_short_circuited_deps 1|to ~/.rpmmacros
>
>
> # rpm -Uhv
> /home/users/glen/rpm/packages/RPMS/zabbix-common-5.4.3-0.1.x86_64.rpm
> error: Failed dependencies:
> rpmlib(ShortCircuited) <= 4.9.0-1 is needed by
> zabbix-common-5.4.3-0.1.x86_64
>
>
> this does not seem to work, can't even find matching such macro:
>
> $ grep -r short_circuited_deps /usr/lib/rpm|wc -l
> 0
I suppose it needs to be set at the time of creating .rpm file, not
installing it.
Test exist in (patched) rpm code, not external macros:
rpm/shortcircuited-deps.patch:+ (rc = packageBinaries(spec, cookie,
((didBuild == 0) && !rpmExpandNumeric("%{?disable_short_circuited_deps}")
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Empty %files file
On Tue, Aug 24, 2021 at 11:30:43AM -0400, Neal Gompa wrote: > On Tue, Aug 24, 2021 at 6:19 AM Elan Ruusamäe wrote: > > > > > > error: Empty %files file > > /home/users/glen/rpm/packages/BUILD.x86_64-linux/zabbix-5.4.3/debugsourcefiles.list > > > > is this something specific to carme? > > > > > > and how to prevent the error and proceed? > > > > That happens when your compilation flags aren't being respected and > debuginfo isn't getting built properly for -debuginfo and -debugsource > subpackages to be generated. Explaining further: - if binary packages don't contain any native code (just scripts, data or some bytecode), then -debuginfo is empty (and solution is to set _enable_debug_packages to 0) - if there is some native code, -debuginfo is created - if there is no enough debug information, -debugsource packages are not created; the reason can be lack of compiler/linker flags (or binary stripping in %install stage), but also if binaries are created by compiler not supported by rpm debuginfo machinery (like golang or rust); in the last case, solution is to disable debugsource packages (define _debugsource_packages to 0); in other case, solution is to properly pass compiler flags or disable stripping in build system -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: qt4 broken on i686
On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan Rękorajski wrote:
> New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> infinite looping (ex. meinproc4 in kde4-kig).
>
> I'm running out of ideas[1] and time to troubleshoot this and would
> appreciate if anyone would be willing to try and figure out WTF is
> broken there.
>
> [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> glibc 2.34 issue, but I don't have resources at hand to validate it.
I don't know yet if it's related to glibc, gcc or binutils, but simple
testcase is searching in empty QMap:
```
#include
int main()
{
QMap mm;
mm.constFind(999);
}
```
It hangs even on carme-x86_64.
Issue is probably related to shared_null static field (SIOF?)
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
glibc upgrade on builders + binaries colour with rpm.org [Re: ERRORS: COMMAND]
I tried: $ make-request -b 'th-x86_64 th-x32' -c 'poldek -n th-all -n th-ready-all -n th-test-all -Uvg glibc' But poldek failed with "Aborted"... how to perform glibc upgrade on th-x86_64 and th-x32? I want to upgrade because of messed colour of /usr/bin/iconv binary (to see if it helps, or there is something wrong with colour selection in rpm.org) - currently: th-x32 contains 64-bit /usr/bin/iconv th-x86_64 contains 32-bit /usr/bin/iconv which don't use host native iconv modules (but require iconv modules from matching binary ABI). On Sun, May 09, 2021 at 06:36:56PM +, PLD th-x86_64 builder wrote: > COMMAND (): FAILED [...] > > --- COMMAND:: > Build-Time: user:14.55s sys:4.78s real:19.36s (faults io:1 non-io:1378587) > > > > *** buildlog for COMMAND > Loading [pndir]th... > Loading [pndir]th... > Loading [pndir]th-i686... > Loading [pndir]th-x32... > Loading [pndir]th-ready... > Loading [pndir]th-ready... > Loading [pndir]th-i686-ready... > Loading [pndir]th-x32-ready... > Loading [pndir]th-test... > Loading [pndir]th-test... > Loading [pndir]th-i686-test... > Loading [pndir]th-x32-test... > 75168 packages read > warn: glibc: ambiguous name > glibc-2.33-4.i686: equal version installed, skipped > glibc-2.33-4.x32: equal version installed, skipped > glibc-2.33-4.x86_64: equal version installed, skipped > Processing dependencies... > glibc-2.33-4.i686 obsoleted by glibc-2.33-5.i686 > Aborted > Begin-PLD-Builder-Info > Build-Time: user:14.55s sys:4.78s real:19.36s (faults io:1 non-io:1378587) > > End-PLD-Builder-Info > -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: query about debuginfo
On Mon, Apr 12, 2021 at 10:12:12PM +0200, Arkadiusz Miśkiewicz wrote:
> W dniu 12.04.2021 o 21:53, Arkadiusz Miśkiewicz pisze:
> > W dniu 12.04.2021 o 21:20, Peri Noid pisze:
> >> Dnia poniedziałek, 12 kwietnia 2021 20:56:49 CEST Arkadiusz Miśkiewicz
> >> pisze:
> >> [...]
> >>> Should we change our default rpm macro?
> >>>
> >>> $ rpm --showrc|grep CMAKE_BUILD_TYPE
> >>> -DCMAKE_BUILD_TYPE=%{!?debug:PLD}%{?debug:Debug} \
> >>
> >> Yes please! Make it either conditional or "the opposite". I couldn't
> >> compile
> >> kile recently just becouse of this since I didn't understand the source of
> >> the
> >> problem.
> >>
> >
> > I have no idea why we use PLD there.
>
> Probably to avoid default release optimizations that cmake adds (because
> we use our own CFLAGS etc).
That's the reason AFAIR.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: query about debuginfo
On Fri, Apr 09, 2021 at 03:27:11PM +0100, Krzysztof Mrozowicz via pld-devel-en
wrote:
> Hi, I updated the wesnoth package to newer version and it built on my
> computer with no problems. When I tried to build it on the builders,
> it failed with error saying that debugsourcefiles.list is empty.
That's because package was compiled without debugging information, so
rpm couldn't find source files for compiled binaries.
After adjusting build to use PLD-specific compiler flags, debug packages
are created.
> I updated my environment to what is in th-test and was able to
> reproduce the error on my computer, so something got changed in macros
> or rpm there...
Older rpm didn't complain on empty debug packages.
> This was the first time when I saw this kind of error so I asked
> google and found some solution:
>
> add %global debug_package %{nil} to the spec
We're rather using "%define _enable_debug_packages 0"
to disable debug packages completely (which must be done when no
native binaries are packaged, but package can't be noarch e.g. because
of arch-dependent file paths or arch-dependenty bytecode).
If binary debuginfo packages are created, but source files cannot be
found (e.g. because of language not supported by rpm debugsource
mechanism, like rust), we can disable just debugsource packages by
"%define _debugsource_packages 0"
(see gnome-tour.spec for example).
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-pld-macros] - fix typo in debugsource packages macro - rel 2
On Wed, Mar 31, 2021 at 09:33:00PM +0200, baggins wrote:
> commit 45c4eb111b114539bab16bd567a4a794d75d6e16
> Author: Jan Rękorajski
> Date: Wed Mar 31 21:32:32 2021 +0200
>
> - fix typo in debugsource packages macro
> - rel 2
>
> macros.pld | 2 +-
> rpm-pld-macros.spec | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> ---
[...]
> @@ -138,7 +138,7 @@ pakietu oraz przy odpluskwianiu samego pakietu.\
> %ifnarch noarch\
> %global __debug_package 1\
> %_debuginfo_template\
> -%{?_debugsource_packages:%_debugsource_template}\
> +%{?%_debugsource_packages:%_debugsource_template}\
> %endif\
> %{nil}
>
Uhm, is it really correct now?
debug source files like these are unpackaged now:
/usr/src/debug/gjs-1.68.0-1.x32
...
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [projects/template-specs] use %cargo_* macros
On Tue, Mar 30, 2021 at 06:46:46PM +0300, Elan Ruusamäe wrote:
[...]
> >@@ -40,19 +41,17 @@ EOF
> > %build
> > export CARGO_HOME="$(pwd)/.cargo"
> >
> >-cargo -v build \
> >+%cargo_build \
> > %ifarch x32
> > --target x86_64-unknown-linux-gnux32 \
> > %endif
> >---release \
> > --frozen
> >
> > %install
> > rm -rf $RPM_BUILD_ROOT
> > export CARGO_HOME="$(pwd)/.cargo"
> >
> >-cargo -vv \
> >-install \
> >+%cargo_install \
> > --frozen \
> > --path . \
> > --root $RPM_BUILD_ROOT%{_prefix}
>
>
> why not include the crate based build options also into common macros?
>
>
> also, in template-specs/rust.spec, there's comment for source0, creating
> crate, maybe an universal script could be provided by macros package?
I'd enhance %cargo_build at least by adding x32 --target option.
When it comes to crates, It'd better to find some generic solution for
packaging creates system-wide instead of vendoring everything
everywhere. I'm aware Fedora has some, but I didn't have enough time to
do a research.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On Tue, Mar 23, 2021 at 12:18:36PM -0400, Neal Gompa wrote: > On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusamäe wrote: > > > > > > On 23.03.2021 12:59, Neal Gompa wrote: > > > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe wrote: > > >> i found some odd inconsistency: > > >> > > >> > > >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: > > >> virtual(init-daemon) > > >> error: line 319: Only package names are allowed in Obsoletes: > > >> Obsoletes:virtual(init-daemon) > > >> > > >> > > >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some > > >> other tags; > > >> > > >> > > >> Requires: webserver(indexfile) > > >> Requires: webserver(php) >= 4.2.0 > > >> Suggests: php(openssl) > > >> Suggests: webserver(setenv) > > >> Provides: group(eventum) > > >> Provides: user(eventum) > > >> > > > Obsoletes has to be a real package name, but virtual names are allowed > > > for other tags. > > Why? > > > This was always the case in RPM, but it started enforcing it in RPM 4.13. > > > > PLD has used virtual obsoletes for the time i've used it (since 2004). > > > > and we are using it when multiple packages provide something common, say: > > > > 'init-daemon" > > > > they are mutually exclusive, so installing one, must uninstall the other. > > > > and if adding new "virtual(init-daemon)" virtual, without need to update > > other packages, they all can have O/P: virtual(init-daemon) > > > > > > now rpm enforces that each of those packages must cross reference all > > 'the other' virtuals... duh! > > > > RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts. > > For example, the following is enough to get the behavior you want: > > Provides: init-daemon > Conflicts: init-daemon Uhm, AFAIR such combo was treated as self-conflict by some RPM-based package management software, thus making package non-installable... Does it have well defined semantics now? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/crossmingw32-pango] - rpm.org+meson combo require to redefine all dirs
On Sun, Mar 14, 2021 at 10:31:25PM +0100, qboosh wrote:
> commit f5e59fe05417d0d72ef5e99cb896e81fdb32885a
> Author: Jakub Bogusz
> Date: Sun Mar 14 22:32:30 2021 +0100
>
> - rpm.org+meson combo require to redefine all dirs; disable debug packages
>
> crossmingw32-pango.spec | 9 +
> 1 file changed, 9 insertions(+)
> ---
> diff --git a/crossmingw32-pango.spec b/crossmingw32-pango.spec
> index b0b1e43..5d32499 100644
> --- a/crossmingw32-pango.spec
> +++ b/crossmingw32-pango.spec
> @@ -45,6 +45,14 @@ BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
> %define _libdir %{_prefix}/lib
> %define _pkgconfigdir %{_prefix}/lib/pkgconfig
> %define _dlldir /usr/share/wine/windows/system
> +# rpm.org needs redefining these (redefining _prefix don't change them)
> +%define _bindir %{_prefix}/bin
> +%define _sbindir%{_prefix}/sbin
> +%define _includedir %{_prefix}/include
> +%define _libexecdir %{_prefix}/libexec
> +%define _datadir%{_prefix}/share
> +%define _infodir%{_datadir}/info
> +%define _mandir %{_datadir}/man
> %define __pkgconfig_provides%{nil}
> %define __pkgconfig_requires%{nil}
> # for meson 0.50+, keep __cc/__cxx as host compiler and pass %{target}-* in
> meson-cross.txt
In rpm5 packaging _*dir macros were defined relative to _prefix.
In rpm.org rpm/platform/*-linux/macros files define absolute _*dir macros
(instead of relative to %{_prefix}):
| # configure macros.
| #
| %_prefix/usr
| %_exec_prefix /usr
| %_bindir/usr/bin
| %_sbindir /usr/sbin
| %_libexecdir/usr/libexec
| %_datarootdir %{_prefix}/share
| %_datadir /usr/share
| %_sysconfdir/etc
| %_sharedstatedir/var/lib
| %_localstatedir /var
| %_lib lib
| %_libdir/usr/lib
| %_includedir/usr/include
| %_oldincludedir /usr/include
| %_infodir /usr/share/info
| %_mandir/usr/share/man
Is it intentional change?
meson doesn't allow --{bin,sbin,include,libexec,data,info,man}dir outside
--prefix,
so in case of cross* packages I needed to additionally redefine more macros,
even
though some dirs are not actually used (just %meson macro passes them).
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python-sympy] - up to 1.7.1, python 2 no longer supported
On Fri, Mar 12, 2021 at 10:25:36AM +0100, Jan Rękorajski wrote: > On Fri, Mar 12, 2021 at 9:55 AM Elan Ruusamäe wrote: > > > > > On 12.03.2021 00:32, baggins wrote: > > > commit a7afb2642f193eb728569b130fd57bdc8acadd02 > > > Author: Jan Rękorajski > > > Date: Thu Mar 11 23:32:30 2021 +0100 > > > > > > - up to 1.7.1, python 2 no longer supported > > > > > > python-sympy-nodisplay.patch | 25 - > > > python-sympy.spec| 8 +++- > > > 2 files changed, 3 insertions(+), 30 deletions(-) > > > --- > > > diff --git a/python-sympy.spec b/python-sympy.spec > > > index cb6d2e4..6c9214c 100644 > > > --- a/python-sympy.spec > > > +++ b/python-sympy.spec > > > @@ -2,20 +2,19 @@ > > > # Conditional build: > > > %bcond_without doc # HTML and PDF documentation > > > %bcond_without tests # unit tests > > > -%bcond_without python2 # CPython 2.x module > > > +%bcond_with python2 # CPython 2.x module > > > %bcond_without python3 # CPython 3.x module > > > > > > > i agree with what qboosh has been doing in this cases: > > > > 1. git ssh copy python-foo to python3-foo > > > > 2. update python3-foo to be python3 only > > > > 3. update python3-foo to new version, stb > > > > 4. disable python3 from python-foo, relup, stb > > > > And I very much do not agree with that. > Python 2 must die. If upstream decides to drop python2 support, we should > too, > we should not keep old odd versions indefinitely[1]. This creates chaos > because > we end up with inconsistent mess. > > [1] We may, but only for a very strong reasons, ex. a ton of packages would > break. Python 2 is dying, more and more (mostly very common) packages are dropping support, but there are still/will be "long tails" of not ported single packages. Mainstream is slowly porting from gtk+ 3 to gtk 4 and we still have gtk+ 1. Ofc, there is no sense to keep all active forever, python2 packages can fade out from the "loose" (non-required) ends. For the active cases - as we didn't go Fedora way with renaming all python 2.x packages to python2-*, I see two possibilities: a) python-foo.spec with python2-only module/version of module or python2/3 modules and python3-foo.spec with python3-only module/version of module b) python-foo.spec:master branch with python3-only module/version of module or python2/3 modules and python-foo.spec:PYTHON2 branch with last supported python2 version I personally prefer a) because: - we can build all active packages from repo heads (I am aware of just two exceptions from this "rule": kernel.spec and php.spec) - in case of python3-only spec, we need only one package preamble (b) case requires dummy base package and "-n python3-foo" subpackage) In case of b), in python3-only cases apidocs should be packaged as "%package -n python3-*-apidocs", not "%package apidocs". > it takes extra steps to do that, but i think it's worth the effort in > > long term. > > > > it's weird to have python-foo to build python3-foo, > > and the python3-foo will be cleaner without having to support two python > > versions. > > > > What we should do here is to just drop python2 from python-foo, what I'll > do once > the dust after current 3.9 / rpm deps rebuild settles. Keeping dead python2 boilerplate in spec (just with bcond off) after updating to python3-only version makes no sense... As for establishing some python2/3 packaging/migration policy - where to Obsolete python-* packages after dropping python2 variants? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: warning: tag 273 type(0x6) != implicit type(0x0)
On Tue, Mar 09, 2021 at 02:36:10PM +0200, Elan Ruusamäe wrote: > |Upgrading... 1:ImageMagick-libs > ### [ 20%] 2:ImageMagick > ### [ 40%] ==> warning: tag 273 > type(0x6) != implicit type(0x0) 3:php53-pecl-imagick > ### [ 60%] what can you say > about those messages? 1. what does it mean? 2. what's the impact (what's > missing, what's broken) package itself seems okay, `php -m` shows the > module. | Looks like some rpm format incompatibilities. Which rpm is used to install, which was used to built this package? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
rpm.org python dependency generator
What about python provides change (python3egg vs python3dist, probably similarly for python2)? While python3 packaged will be rebuilt anyway due to python 3.9, there is no need to rebuild python2 packages (other than provides scheme change). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/platform] - initial
On Sun, Jan 17, 2021 at 11:13:51AM +0100, arekm wrote:
> commit 3a74dc283894e74d4fb8411e8c3f9cea22e42920
> Author: Arkadiusz Miśkiewicz
> Date: Sun Jan 17 11:13:34 2021 +0100
>
> - initial
>
> platform.spec | 57 +
> +Source0:
> https://github.com/Pulse-Eight/platform/archive/p8-%{name}-%{version}.tar.gz
> +%files
> +%defattr(644,root,root,755)
> +%doc README.md
> +%attr(755,root,root) %{_libdir}/libp8-%{name}.so.*.*
> +%attr(755,root,root) %ghost %{_libdir}/libp8-%{name}.so.2
> +
> +%files devel
> +%defattr(644,root,root,755)
> +%{_includedir}/p8-%{name}
> +%attr(755,root,root) %{_libdir}/libp8-%{name}.so
> +%{_libdir}/p8-%{name}
> +%{_pkgconfigdir}/p8-%{name}.pc
I'd suggest "p8-platform" package Name here.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
bash 5.1.0
# rpm -Fhv bash-5.1.0-1.i686.rpm error: Failed dependencies: mktemp < 1.6 conflicts with rpm-build-tools-4.9-6.noarch It's caused by soname provides from dynamic builtins (which don't have .so extension) $ rpm -qpP bash-5.1.0-1.i686.rpm | grep mktemp mktemp -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
cvs/git down
Who has access to host system or console? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/waf] - updated python(abi) dependency, compile python library
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 Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
th-i686 not working again
It seems that th-i686 builder is dead or got stuck on openjdk11 build. Who can fix it? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
missing mail logs form th-x86_64 [SOLVED: th-x86_64: strange runtime linker failure]
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) =
> 0x7f6f30ec
> | 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 Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: th-x86_64: strange runtime linker failure
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 Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
th-x86_64: strange runtime linker failure
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 (0x7fff6bad1000)
| libjli.so =>
/usr/lib64/jvm/icedtea8-3.17.0/bin/../lib/amd64/jli/libjli.so
(0x7f5c2ce8f000)
| libc.so.6 => /lib64/libc.so.6 (0x7f5c2cc5b000)
| libz.so.1 => /lib64/libz.so.1 (0x7f5c2cc41000)
| libdl.so.2 => /lib64/libdl.so.2 (0x7f5c2cc3b000)
| libpthread.so.0 => /lib64/libpthread.so.0 (0x7f5c2cc1a000)
| /lib64/ld-linux-x86-64.so.2 (0x7f5c2cea7000)
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) =
0x7f6f30ec
| 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 Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
th-i686: non-deterministic libreoffice build failures
- 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 1892273895866368"
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 1892273895866368 (0xfff8) 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 Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
[th-ad...@pld-linux.org: [all] builder queue problem]
Who is able to fix it? - Forwarded message from PLD all builder - From: PLD all builder X-PLD-Builder: all To: th-ad...@pld-linux.org, jpa...@fastmail.com, qbo...@pld-linux.org, ar...@pld-linux.org, g...@pld-linux.org Date: Fri, 06 Nov 2020 15:44:09 + 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 Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm/rpm.org] - drop lua hacks and look for default lua version - don't obsolete rpm-getdeps, this rpm does not su
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 Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm/rpm.org] - drop lua hacks and look for default lua version - don't obsolete rpm-getdeps, this rpm does not su
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 Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm4 on carme*
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 Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc-ldconfig => glibc-ld reconsiderations
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 Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm4 on carme*
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 Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm4 on carme*
On Tue, Oct 27, 2020 at 11:21:17PM +0100, Jan Rękorajski wrote: > All carme machines are now running rpm 4.16.0. Please test and report > any issues. One so far (very short testing): rpm -qi prints summaries/decriptions in UTF-8 regardless of current locale encoding. (anyway, great work with bringing rpm.org!) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
tzdata 2020d vs syslog-ng tests
On Sun, Oct 25, 2020 at 06:42:03PM +0100, qboosh wrote: > commit 2571715fc93df9e82c9e7a06eb9c225e4196b713 > Author: Jakub Bogusz > Date: Sun Oct 25 18:41:54 2020 +0100 > > - added tests-fixes patch (fixes test_python_ack_tracker test); new 4 > tests failing (due to tzdata 2020d or todays DST change?) It seems the first cause (tzdata 2020d installed on carme), as syslog-ng built fine on builders. Either there are some issues in 2020d, or syslog-ng tests need update(?). The differences is not just 1h, so the cause aren't probably only DST adustments. FAIL: lib/rewrite/tests/test_rewrite ### # # FAIL: ASSERTION FAILED; actual_length=25 expected_length=25, # actual= '1971-01-01T00:00:00+00:00', # expected= '1971-01-01T09:00:00+09:00' # ### FAIL: lib/timeutils/tests/test_unixtime [^[[0;34m^[[0m] ^[[0;1mlib/timeutils/tests/test_unixtime.c^[[0m:^[[0;31m236^[[0m: Assertion failed: The expression ut.ut_sec == 1572760800 - 1 is false. [^[[0;34m^[[0m] ^[[0;1mlib/timeutils/tests/test_unixtime.c^[[0m:^[[0;31m304^[[0m: Assertion failed: The expression ut.ut_sec == 1572134400 - 1 is false. [^[[0;34m^[[0m] ^[[0;1mlib/timeutils/tests/test_unixtime.c^[[0m:^[[0;31m115^[[0m: Assertion failed: The expression ut.ut_sec == 1552201200 - 1 is false. [^[[0;34m^[[0m] ^[[0;1mlib/timeutils/tests/test_unixtime.c^[[0m:^[[0;31m175^[[0m: Assertion failed: The expression ut.ut_sec == 1553994000 - 1 is false. [^[[0;34m^[[0m] ^[[0;1mlib/timeutils/tests/test_unixtime.c^[[0m:^[[0;31m380^[[0m: Assertion failed: The expression ut.ut_gmtoff == -5*3600 is false. [^[[0;34m^[[0m] ^[[0;1mlib/timeutils/tests/test_unixtime.c^[[0m:^[[0;31m383^[[0m: Assertion failed: The expression ut.ut_gmtoff == -4*3600 is false. [^[[0;34m^[[0m] ^[[0;1mlib/timeutils/tests/test_unixtime.c^[[0m:^[[0;31m391^[[0m: Assertion failed: The expression ut.ut_gmtoff == -4*3600 is false. [^[[0;34m^[[0m] ^[[0;1mlib/timeutils/tests/test_unixtime.c^[[0m:^[[0;31m395^[[0m: Assertion failed: The expression ut.ut_gmtoff == -5*3600 is false. FAIL: modules/timestamp/tests/test_date [^[[0;34m^[[0m] ^[[0;1mmodules/timestamp/tests/test_date.c^[[0m:^[[0;31m163^[[0m: Assertion failed: incorrect date parsed msg=Tue, 27 Jan 2015 11:48:46 format=%a, %d %b %Y %T, result=2015-01-27T11:48:46+00:00, expected=2015-01-27T11:48:46-07:00 FAIL: tests/unit/test_zone [^[[0;34m^[[0m] ^[[0;1mtests/unit/test_zone.c^[[0m:^[[0;31m90^[[0m: Assertion failed: unixtimestamp: 1603647707 TimeZoneName (America/Louisville) localtime offset(-14400), timezone file offset(0) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/util-linux] Fix typo in todo
On Sat, Oct 24, 2020 at 02:20:15PM +0200, glen wrote: > commit 79371f7655367e9072086b08b9ebc4836eed65bb > Author: Elan Ruusamäe > Date: Sat Oct 24 15:19:37 2020 +0300 > > Fix typo in todo > > util-linux.spec | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > --- > diff --git a/util-linux.spec b/util-linux.spec > index 37e4dd3..8be8c4f 100644 > --- a/util-linux.spec > +++ b/util-linux.spec > @@ -1,5 +1,5 @@ > # TODO > -# - remote chfn/chsh (BR: libuser >= 0.58)? - but PLD uses pwdutils/shadow > implementation currently > +# - remove chfn/chsh (BR: libuser >= 0.58)? - but PLD uses pwdutils/shadow > implementation currently Not a typo. | AC_ARG_WITH([user], AS_HELP_STRING([--without-user], [compile without libuser (remote chsh)]), | [], [with_user=check] chfn and chsh from util-linux could have functionality of changing data in remotely managed passwd database (via libuser). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
th-i686 builder dead?
It doesn't report builds, neither via mail nor queue.html. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rust on carme-x32?
On Tue, Oct 06, 2020 at 09:47:36PM +0200, Arkadiusz Miśkiewicz wrote:
> W dniu 06.10.2020 o 15:14, Jakub Bogusz via pld-devel-en pisze:
> > Can we have rust and cargo installed on carme-x32?
> > It requires a few x86_64 libraries, so I cannot install with accessible
> > poldek commands.
> >
> >
>
> > poldek:/all-avail> install cargo-1.44.1-2.x32 rust-1.44.1-2.x32
[...]
> > curl-libs-7.72.0-1.x86_64 marks libbrotli-1.0.9-2.x86_64 (cap
> > libbrotlidec.so.1()(64bit))
> > curl-libs-7.72.0-1.x86_64 marks c-ares-1.16.1-1.x86_64 (cap
> > libcares.so.2()(64bit))
> > curl-libs-7.72.0-1.x86_64 marks heimdal-libs-7.7.0-2.x86_64 (cap
> > libgssapi.so.3()(64bit))
> > heimdal-libs-7.7.0-2.x86_64 marks libcom_err-1.45.6-1.x86_64 (cap
> > libcom_err.so.2()(64bit))
> > heimdal-libs-7.7.0-2.x86_64 marks sqlite3-libs-3.33.0-1.x86_64 (cap
> > libsqlite3.so.0()(64bit))
> > curl-libs-7.72.0-1.x86_64 marks libidn2-2.3.0-1.x86_64 (cap
> > libidn2.so.0()(64bit))
> > libidn2-2.3.0-1.x86_64 marks libunistring-0.9.10-1.x86_64 (cap
> > libunistring.so.2()(64bit))
> > curl-libs-7.72.0-1.x86_64 marks openldap-libs-2.4.49-1.x86_64 (cap
> > liblber-2.4.so.2()(64bit))
> > openldap-libs-2.4.49-1.x86_64 marks cyrus-sasl-libs-2.1.27-1.x86_64 (cap
> > libsasl2.so.3()(64bit))
> > curl-libs-7.72.0-1.x86_64 marks nghttp2-libs-1.41.0-1.x86_64 (cap
> > libnghttp2.so.14()(64bit))
> > curl-libs-7.72.0-1.x86_64 marks libpsl-0.21.0-1.x86_64 (cap
> > libpsl.so.5()(64bit))
> > curl-libs-7.72.0-1.x86_64 marks librtmp-2.4-1.20190331.2.x86_64 (cap
> > librtmp.so.0()(64bit))
> > librtmp-2.4-1.20190331.2.x86_64 marks gnutls-libs-3.6.15-2.x86_64 (cap
> > libgnutls.so.30()(64bit))
> >gnutls-libs-3.6.15-2.x86_64 marks nettle-3.6-1.x86_64 (cap
> > libhogweed.so.6()(64bit))
> >gnutls-libs-3.6.15-2.x86_64 marks p11-kit-0.23.21-1.x86_64 (cap
> > libp11-kit.so.0()(64bit))
> > p11-kit-0.23.21-1.x86_64 marks libffi-3.3-1.x86_64 (cap
> > libffi.so.7()(64bit))
> > p11-kit-0.23.21-1.x86_64 marks systemd-libs-246.6-1.x86_64 (cap
> > libsystemd.so.0()(64bit))
> > systemd-libs-246.6-1.x86_64 marks acl-2.2.53-1.x86_64 (cap
> > libacl.so.1()(64bit))
> > systemd-libs-246.6-1.x86_64 marks libblkid-2.36-1.x86_64 (cap
> > libblkid.so.1()(64bit))
> > systemd-libs-246.6-1.x86_64 marks libcap-libs-2.43-1.x86_64 (cap
> > libcap.so.2()(64bit))
> > systemd-libs-246.6-1.x86_64 marks cryptsetup-2.3.4-1.x86_64 (cap
> > libcryptsetup.so.12()(64bit))
> > cryptsetup-2.3.4-1.x86_64 marks libargon2-20190702-1.x86_64 (cap
> > libargon2.so.1()(64bit))
> > cryptsetup-2.3.4-1.x86_64 marks device-mapper-libs-2.03.10-1.x86_64
> > (cap libdevmapper.so.1.02()(64bit))
> >device-mapper-libs-2.03.10-1.x86_64 marks libaio-0.3.112-1.x86_64
> > (cap libaio.so.1()(64bit))
> >device-mapper-libs-2.03.10-1.x86_64 marks libselinux-2.9-4.x86_64
> > (cap libselinux.so.1()(64bit))
> > libselinux-2.9-4.x86_64 marks pcre-8.44-1.x86_64 (cap
> > libpcre.so.1()(64bit))
> >device-mapper-libs-2.03.10-1.x86_64 marks udev-libs-246.6-1.x86_64
> > (cap libudev.so.1()(64bit))
> > cryptsetup-2.3.4-1.x86_64 marks json-c-0.14-1.x86_64 (cap
> > libjson-c.so.5()(64bit))
> > cryptsetup-2.3.4-1.x86_64 marks popt-1.17-3.x86_64 (cap
> > libpopt.so.0()(64bit))
> > cryptsetup-2.3.4-1.x86_64 marks libuuid-2.36-1.x86_64 (cap
> > libuuid.so.1()(64bit))
> > systemd-libs-246.6-1.x86_64 marks libgcrypt-1.8.6-1.x86_64 (cap
> > libgcrypt.so.20()(64bit))
> > libgcrypt-1.8.6-1.x86_64 marks libgpg-error-1.39-1.x86_64 (cap
> > libgpg-error.so.0()(64bit))
> > systemd-libs-246.6-1.x86_64: required "libip4tc.so.2()(64bit)" is provided
> > by the following packages:
> > a) iptables-libs-1.8.5-1.x86_64
> > b) iptables-vserver-libs-1.8.5-1.x86_64
> > Which one do you want to install ('Q' to abort)?
> > [iptables-libs-1.8.5-1.x86_64]
> > systemd-libs-246.6-1.x86_64 marks iptables-libs-1.8.5-1.x86_64 (cap
> > libip4tc.so.2()(64bit))
> > systemd-libs-246.6-1.x86_64 marks kmod-libs-27-1.x86_64 (cap
> > libkmod.so.2()(64bit))
> > systemd-libs-246.6-1.x86_64 marks lz4-libs-1.9.2-1.x86_64 (cap
> > liblz4.so.1()(64bit))
> > systemd-libs-246.6-1.x86_64 marks libmount-2.36-1.x86_64 (cap
> > libmount.so.1()(64bit))
> > systemd-libs-246.6-1.x86_64 marks pam-libs-1.4.0-1.x86_64 (cap
> > libpam.so.0()(64bit))
> > pam-libs-1.4.0-1
Re: [packages/mpdecimal] - up to 2.5.0
On Tue, Oct 06, 2020 at 04:26:50PM +0200, arekm wrote:
> commit bede0ed9de64c316b06ae86643a2df9422faf130
> Author: Arkadiusz Miśkiewicz
> Date: Tue Oct 6 16:26:44 2020 +0200
>
> - up to 2.5.0
>
> mpdecimal-cpython.patch | 113
>
> mpdecimal.spec | 15 ---
> 2 files changed, 10 insertions(+), 118 deletions(-)
> ---
[...]
> -# Source0-md5: aa63cab5d06a96855a44da2db90a29d9
> -Patch0: %{name}-cpython.patch
> +# Source0-md5: 3cacb882f59f795f4ed6822d80bd2f7d
> +Patch0: build.patch
"build.patch" is missing in git.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
rust on carme-x32?
Can we have rust and cargo installed on carme-x32? It requires a few x86_64 libraries, so I cannot install with accessible poldek commands. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: OK: rust.spec
On Mon, Oct 05, 2020 at 01:12:44AM +0200, Jan Rękorajski wrote: > On Sun, 04 Oct 2020, PLD th-x32 builder wrote: > > > rust.spec (auto/th/rust-1.44.1-2): OK > > > > --- rust.spec:auto/th/rust-1.44.1-2: > > upgrading packages > > Build-Time: user:22480.24s sys:327.35s real:7031.10s (faults io:17 > > non-io:47582180) > > > > Files queued for ftp: > > 13348158 rust-debuginfo-1.44.1-2.x32.rpm > > 10224 zsh-completion-cargo-1.44.1-2.x32.rpm > > 8428 bash-completion-cargo-1.44.1-2.x32.rpm > >4034573 cargo-1.44.1-2.x32.rpm > > 14821218 rust-doc-1.44.1-2.noarch.rpm > > 8969 rust-lldb-1.44.1-2.noarch.rpm > > 10439 rust-gdb-1.44.1-2.noarch.rpm > > 9304 rust-debugger-common-1.44.1-2.noarch.rpm > > 56994390 rust-1.44.1-2.x32.rpm > >410 rust-1.44.1-2.src.rpm.uploadinfo > > Unfortunately this build does not produce x32 output. It appeared that gnux32 ABI is not default for this compiler, one must add --target=x86_64-unknown-linux-gnux32 to rustc or cargo. With few hacks (simulating crosscompilation in rust part) and fixing one vendored package librsvg built as x32. ow I'm trying with mozjs78, which blocks more packages (e.g. current polkit or gnome-shell). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Strange multilib `poldek -i` behaviour [Re: OK: COMMAND]
I tried to execute: `poldek -iv openssl-devel-1.1.1g-1.x86_64 zlib-devel-1.2.11-2.x86_64` And why it refused with "equal version installed"? `rpm -q openssl-devel zlib-devel` returned: openssl-devel-1.1.1g-1.x32 zlib-devel-1.2.11-2.x32 Adding `--force` helped (but only -devel packages were installed, I must have installed openssl.x86_64 manually). On Sun, Oct 04, 2020 at 12:23:09PM +, PLD th-x32 builder wrote: > COMMAND (): OK > > --- COMMAND:: > Build-Time: user:2.00s sys:0.18s real:2.22s (faults io:0 non-io:30899) > > > > *** buildlog for COMMAND > Loading [pndir]th-x86_64... > Loading [pndir]th-x86_64-ready... > Loading [pndir]th-x86_64-test... > 22166 packages read > openssl-devel-1.1.1g-1.x86_64: equal version installed, skipped > zlib-devel-1.2.11-2.x86_64: equal version installed, skipped > Nothing to do > Begin-PLD-Builder-Info > Build-Time: user:2.00s sys:0.18s real:2.22s (faults io:0 non-io:30899) > > End-PLD-Builder-Info > -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
TeX packaging: texmf dirs
What is the difference between /usr/share/texmf and /usr/share/texmf-dist? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-pld-macros] - version 1.749: fixed _ver_* macros
On Mon, Sep 28, 2020 at 07:07:54PM +0200, Jakub Bogusz wrote:
> On Mon, Sep 28, 2020 at 04:41:21PM +0200, Jan Palus wrote:
> > On 27.09.2020 20:17, qboosh wrote:
> > > commit a04002a841905f8c84ca1c955e047676994c1ef2
> > > Author: Jakub Bogusz
> > > Date: Sun Sep 27 20:20:03 2020 +0200
> > >
> > > - version 1.749: fixed _ver_* macros
> > ...
> > > -# BuildRequires: rpmbuild(macros) >= 1.748
> > > -%_ver_lt() %(test rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1 -eq 2;
> > > echo $?)
> > > -%_ver_ge() !%(test rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1 -eq 2;
> > > echo $?)
> > > +# BuildRequires: rpmbuild(macros) >= 1.749
> > > +%_ver_lt() %(test $(rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1; echo
> > > $?) -eq 2; echo $?)
> > > +%_ver_ge() %(test $(rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1; echo
> > > $?) -ne 2; echo $?)
> >
> > Isn't it the other way? -ne 2 for_ver_lt and -eq 2 for _ver_ge?
> >
> > "Satisfied condition" in terms of test return code (0) is the opposite
> > of "satisfied condition" as interpreted by rpm (1).
>
> Ouch, you're right.
Fixed in 1.750.
> > ie rapidjson has:
> >
> > %if %{_ver_ge "%{_rpmversion}" "4.6"}
> >
> > which I suppose does not work correctly at the moment.
>
> After fixing conditions it would work.
>
> But throws parse error when too old (or no) macros are installed, so
> I tried the following:
>
> > while glabels has:
> >
> > %if 0%{?_ver_ge "%{_rpmversion}" "4.6"}
> >
> > but I don't quite get it, I thought %{? construct is only to check if
> > something is defined or does it somehow interpret return value?
>
> %{?macro} construct returns macro value if it's defined.
>
> But unfortunately it appears that doesn't pass arguments to macro, so the
> result is equal to just %{_ver_ge} :/
>
> %{?_ver_ge:%_ver_ge x y} works, but needs more keystrokes...
> I'll try to look for nicer solution.
A little nicer proposal:
%if "%{_ver_ge '%{_rpmversion}' '4.6'}" == "1"
Both false comparison or unexpanded macro evaluates to false condition.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-pld-macros] - version 1.749: fixed _ver_* macros
On Mon, Sep 28, 2020 at 04:41:21PM +0200, Jan Palus wrote:
> On 27.09.2020 20:17, qboosh wrote:
> > commit a04002a841905f8c84ca1c955e047676994c1ef2
> > Author: Jakub Bogusz
> > Date: Sun Sep 27 20:20:03 2020 +0200
> >
> > - version 1.749: fixed _ver_* macros
> ...
> > -# BuildRequires: rpmbuild(macros) >= 1.748
> > -%_ver_lt() %(test rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1 -eq 2; echo $?)
> > -%_ver_ge() !%(test rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1 -eq 2; echo $?)
> > +# BuildRequires: rpmbuild(macros) >= 1.749
> > +%_ver_lt() %(test $(rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1; echo $?) -eq
> > 2; echo $?)
> > +%_ver_ge() %(test $(rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1; echo $?) -ne
> > 2; echo $?)
>
> Isn't it the other way? -ne 2 for_ver_lt and -eq 2 for _ver_ge?
>
> "Satisfied condition" in terms of test return code (0) is the opposite
> of "satisfied condition" as interpreted by rpm (1).
Ouch, you're right.
> ie rapidjson has:
>
> %if %{_ver_ge "%{_rpmversion}" "4.6"}
>
> which I suppose does not work correctly at the moment.
After fixing conditions it would work.
But throws parse error when too old (or no) macros are installed, so
I tried the following:
> while glabels has:
>
> %if 0%{?_ver_ge "%{_rpmversion}" "4.6"}
>
> but I don't quite get it, I thought %{? construct is only to check if
> something is defined or does it somehow interpret return value?
%{?macro} construct returns macro value if it's defined.
But unfortunately it appears that doesn't pass arguments to macro, so the
result is equal to just %{_ver_ge} :/
%{?_ver_ge:%_ver_ge x y} works, but needs more keystrokes...
I'll try to look for nicer solution.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
carme-x32
seems dead? $ ssh-carme-x32 Connection closed by 193.239.45.154 port 22 -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Long mail delivery time
On Thu, Aug 20, 2020 at 11:59:13AM +0200, Jan Palus via pld-devel-en wrote: > Recently mails sent to PLD mailing lists take longer than usual before > they reach me. Any idea where that 23min delay is coming from? No idea, but I'm seeing even 1-2h delays in the same step. adamg? > Received: from lists.pld-linux.org (lists.pld-linux.org [178.217.190.85]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 > bits)) > (No client certificate requested) > by mx4.messagingengine.com (Postfix) with ESMTPS > for ; Thu, 20 Aug 2020 04:56:51 -0400 (EDT) > Received: from lists.pld-linux.org (localhost [127.0.0.1]) > by lists.pld-linux.org (Postfix) with ESMTP id 55E6CB6A7BF; > Thu, 20 Aug 2020 10:33:42 +0200 (CEST) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/Firebird] - updated to 3.0.5.33220 - pidfile moved to /run/fireird/
On Thu, Mar 05, 2020 at 02:53:56PM +0100, bszx wrote:
> @@ -427,7 +427,7 @@ fi
> %attr(640,root,root) %config(noreplace) %verify(not md5 mtime size)
> /etc/sysconfig/firebird
> %attr(640,root,root) %config(noreplace) %verify(not md5 mtime size)
> %{_sysconfdir}/tmpfiles.d/firebird.conf
> %attr(755,root,root) %{ibdir}/bin/fbguard
> -%dir %attr(770,root,firebird) /var/run/firebird
> +%dir %attr(770,root,firebird) /run/firebird
> %{systemdunitdir}/firebird.service
>
> %files classic
I don't see much sense in packaging subdir on such volatile filesystem
(tmpfs)...
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
poldek th-x32 glibc upgrade problem [builder-th-...@pld-linux.org: ERRORS: COMMAND]
Why poldek ignores glibc-2.31-5.x86_64 upgrade, even when specified explicitly on command line? (I started with "-n th-all -Uvg glibc", then tried to add more and more explicit package names... but in each case third arch glibc (base) package is ignored and upgrade fails). make-request -b th-x32 -c 'poldek -n th-all -Uvg glibc-2.31-5.x32 glibc-2.31-5.x86_64 glibc-2.31-5.i686 glibc-headers-2.31-5.x32 glibc-devel-2.31-5.x86_64 glibc-devel-2.31-5.i686 glibc-devel-2.31-5.x32 glibc-misc-2.31-5.x32' - Forwarded message from PLD th-x32 builder - X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.qboosh.pl X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00, DNS_FROM_AHBL_RHSBL,FH_DATE_PAST_20XX,SUBJ_ALL_CAPS autolearn=no version=3.2.5 X-Original-To: p...@qboosh.pl X-Entity-Ref-ID: 1db2b888-15e5-40dc-8e53-43e928caf59f From: PLD th-x32 builder To: qbo...@pld-linux.org X-PLD-Builder: th-x32 Cc: pld-logs...@lists.pld-linux.org Date: Sat, 25 Apr 2020 14:35:15 + Subject: ERRORS: COMMAND COMMAND (): FAILED --- COMMAND:: Build-Time: user:12.38s sys:6.49s real:18.92s (faults io:0 non-io:1501190) *** buildlog for COMMAND Loading [pndir]th... Loading [pndir]th... Loading [pndir]th-x86_64... Loading [pndir]th-i686... 65598 packages read Processing dependencies... glibc-2.31-1.i686 obsoleted by glibc-2.31-5.i686 glibc-2.31-5.i686 marks glibc-ld-2.31-5.i686 (cap glibc-ld = 6:2.31-5) glibc-ld-2.31-1.i686 obsoleted by glibc-ld-2.31-5.i686 glibc-2.31-1.x32 obsoleted by glibc-2.31-5.x32 glibc-devel-2.31-1.x32 obsoleted by glibc-devel-2.31-5.x32 glibc-devel-2.31-5.x32 marks glibc-devel-utils-2.31-5.x32 (cap glibc-devel-utils = 6:2.31-5) glibc-devel-utils-2.31-1.x32 obsoleted by glibc-devel-utils-2.31-5.x32 greedy upgrade glibc-devel-2.31-1.x86_64 to 2.31-5.x86_64 (unresolved glibc-devel-utils = 6:2.31-1) glibc-devel-2.31-1.x86_64 obsoleted by glibc-devel-2.31-5.x86_64 glibc-devel-2.31-5.x86_64 marks glibc-libcrypt-2.31-5.x86_64 (cap glibc-libcrypt(x86_64) = 6:2.31-5) glibc-libcrypt-2.31-1.x86_64 obsoleted by glibc-libcrypt-2.31-5.x86_64 glibc-devel-2.31-1.i686 obsoleted by glibc-devel-2.31-5.i686 greedy upgrade glibc-static-2.31-1.x32 to 2.31-5.x32 (unresolved glibc-devel = 6:2.31-1) glibc-static-2.31-1.x32 obsoleted by glibc-static-2.31-5.x32 glibc-devel-2.31-5.i686 marks glibc-libcrypt-2.31-5.i686 (cap glibc-libcrypt(i686) = 6:2.31-5) glibc-libcrypt-2.31-1.i686 obsoleted by glibc-libcrypt-2.31-5.i686 glibc-devel-2.31-5.x32 marks glibc-libcrypt-2.31-5.x32 (cap glibc-libcrypt(x32) = 6:2.31-5) glibc-libcrypt-2.31-1.x32 obsoleted by glibc-libcrypt-2.31-5.x32 glibc-headers-2.31-1.x32 obsoleted by glibc-headers-2.31-5.x32 glibc-misc-2.31-1.x32 obsoleted by glibc-misc-2.31-5.x32 There are 13 packages to install (7 marked by dependencies), 13 to remove: U glibc-2.31.(1 => 5).i686 glibc-2.31.(1 => 5).x32 U glibc-devel-2.31.(1 => 5).i686 glibc-devel-2.31.(1 => 5).x32 U glibc-devel-utils-2.31.(1 => 5).x32 U glibc-headers-2.31.(1 => 5).x32 glibc-ld-2.31.(1 => 5).i686 U glibc-libcrypt-2.31.(1 => 5).i686 U glibc-libcrypt-2.31.(1 => 5).x32 glibc-misc-2.31.(1 => 5).x32 U glibc-static-2.31.(1 => 5).x32 A glibc-devel-2.31-5.x86_64 glibc-libcrypt-2.31-5.x86_64 This operation will use 1.6KB of disk space. Need to get 8.3MB of archives. Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 1... Preparing...## error: Install/Erase problems: file /usr/share/doc/glibc-2.31/NEWS.gz from install of glibc-2.31-5.i686 conflicts with file from package glibc-2.31-1.x86_64 file /usr/share/doc/glibc-2.31/NEWS.gz from install of glibc-2.31-5.x32 conflicts with file from package glibc-2.31-1.x86_64 Begin-PLD-Builder-Info Build-Time: user:12.38s sys:6.49s real:18.92s (faults io:0 non-io:1501190) End-PLD-Builder-Info ----- End forwarded message - -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: libc 2.31/i686: operation not permitted for preserving timestamps
On Tue, Mar 24, 2020 at 09:20:19PM +0200, Elan Ruusamäe wrote: > On 3/16/20 11:46 PM, Elan Ruusamäe wrote: > >i've got reports that cp -a (or just cp --preserve=timestamps) fails > >on i686 and glibc 2.31 > does i686 even work for someone really? Which kernel and fs? I don't see such problems, glibc 2.31 on 4.19.x, xfs. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/poldek] - up to 0.42.1 - turn off tests running
On Mon, Mar 16, 2020 at 10:15:33PM +0100, mis wrote: > commit 651f3f75747a091b5c3df9f9ac9fc8a93734cf8c > Author: mis > Date: Mon Mar 16 22:13:04 2020 +0100 > > - up to 0.42.1 > - turn off tests running > > FIXME: some tests use internal, non-exported libpoldek symbols > (undefined reference to `poldek_conf_sections', etc errors). We have > to build with -O0 to make them linkable and then build again for > production use. Or link tests with static libpoldek? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
th-x32 builder stuck
What happened to th-x32? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [projects/template-specs] - stop including perl macros, it's not needed, rpm does this on its own
On Sun, Jan 26, 2020 at 06:55:19PM +0100, Jan Rękorajski wrote:
> On Sun, 26 Jan 2020, Jakub Bogusz wrote:
>
> > On Sat, Jan 25, 2020 at 02:06:07PM +0100, baggins wrote:
> > > commit f75adea6b3f6c1343989e98a27167605ed55b780
> > > Author: Jan Rękorajski
> > > Date: Sat Jan 25 14:03:53 2020 +0100
> > >
> > > - stop including perl macros, it's not needed, rpm does this on its
> > > own
> >
> > I wonder how to specify dependency on rpm(-build) which includes
> > perl/php/* macros now.
> >
> > Currently building e.g. perl-* module with 1 month old rpm succeeds, but
> > results
> > in missing perl() reqs/provs.
>
> Only if you don't have rpm-*perlprov package. And it still wouldn't work
> even if you had that include, since it's just a bunch of macros from
> rpm-build package. Macros, that have been loaded automagically since $YEARS.
Oh, I was wrong about the way it works.
The perl/etc. macro files were indeed included, but until recent changes
%__perl_{provides,requires} macros were redefined to %{nil} in macros.build.
Then manual inclusion of macros.perl etc. in .spec redefined
%__perl_{provides,requires}
macros again to proper scripts.
After these commits:
e821f14cac60b7f9bf62abcbb848e114a92abc2f
cdc9189ebe27f76cf935f813eb75c89ec246604f
%__{perl,php,mono}_{provides,requires} macros are always defined to point to
actual scripts, so the manual inclusion of macros.{mono,perl,php} in specs is
obsolete since cdc9189ebe27f76cf935f813eb75c89ec246604f, first packaged as
rpm-pld-macros-build-1.744-3.
So it looks like after removal of manual provides the rpmbuild(macros)
dependency
should be bumped to 1.745 (after version bump in rpm-pld-macros).
(if I haven't missed something... after "solving" 4 boxes of Ikea
puzzles I'm a bit tired)
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [projects/template-specs] - stop including perl macros, it's not needed, rpm does this on its own
On Sat, Jan 25, 2020 at 02:06:07PM +0100, baggins wrote:
> commit f75adea6b3f6c1343989e98a27167605ed55b780
> Author: Jan Rękorajski
> Date: Sat Jan 25 14:03:53 2020 +0100
>
> - stop including perl macros, it's not needed, rpm does this on its own
I wonder how to specify dependency on rpm(-build) which includes
perl/php/* macros now.
Currently building e.g. perl-* module with 1 month old rpm succeeds, but results
in missing perl() reqs/provs.
Maybe change rpm-*prov Provides to "= 1:%{version}" and bump
rpm-*prov dependencies to 1:1.745?
This would force upgrade to new rpm macros packaging/processing due to
name changes (just remember not to provide rpm-build-macros in new macros
packages to
ensure they won't satisfy older rpm-build dependencies).
The other thing is that some packages intentionally didn't include
macros.perl or macros.php to avoid unwanted perl() / pear() dependencies
autogeneration, but can be handled by _noautoreq_{perl,pear} now.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
poldek - strange orphans processing [Re: OK: COMMAND]
I asked to greedy remove itk. It removed itk-devel by dependency, as it should, but why it removed itcl-devel too??? On Thu, Jan 16, 2020 at 04:45:38PM +, PLD th-i686 builder wrote: > COMMAND (): OK > > --- COMMAND:: > Build-Time: user:0.70s sys:0.21s real:1.16s (faults io:0 non-io:62263) > > > > *** buildlog for COMMAND > mark itk-4.1.0-1.i686 > Processing dependencies... > itk-4.1.0-1.i686 marks itk-devel-4.1.0-1.i686 (req itk = 4.1.0-1) > itk-devel-4.1.0-1.i686 marks orphaned itcl-devel-4.1.1-1.i686 (req > itcl-devel >= 4.1) > There are 3 packages to remove (2 marked by dependencies): > R itk-4.1.0-1.i686 > D itcl-devel-4.1.1-1.i686 itk-devel-4.1.0-1.i686 > This operation will free 226.5KB of disk space. > Running pm-command.sh --erase --root /... > Begin-PLD-Builder-Info > Build-Time: user:0.70s sys:0.21s real:1.16s (faults io:0 non-io:62263) > > End-PLD-Builder-Info > -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/apr] - up to 1.7.0
On Sat, Jan 11, 2020 at 10:00:30PM +0100, arekm wrote:
> commit 48dac5e93206c31066f91484526df2e4c2c29480
> Author: Arkadiusz Miśkiewicz
> Date: Sat Jan 11 22:00:22 2020 +0100
>
> - up to 1.7.0
>
> apr.spec | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
> ---
> diff --git a/apr.spec b/apr.spec
> index 90514c4..9ccc5e3 100644
> --- a/apr.spec
> +++ b/apr.spec
> @@ -5,17 +5,18 @@
[...]
> Patch1: %{name}-libtool.patch
> # disable some things that require recent kernel
> Patch2: %{name}-disable-features.patch
> +Patch3: x
Missing in repo.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/shadow] - shadow puts everything into /bin and /sbin - that's ok but provide symlinks for old (pwdutils) loc
On Tue, Jan 07, 2020 at 05:58:46PM +0100, Arkadiusz Miśkiewicz via pld-devel-en
wrote:
> On 07/01/2020 17:06, Jakub Bogusz wrote:
> > On Tue, Jan 07, 2020 at 01:36:44PM +0100, arekm wrote:
> >> commit 2bb4da0ffecbbc08e6e25336b3e1e012b7cd61a5
> >> Author: Arkadiusz Miśkiewicz
> >> Date: Tue Jan 7 13:36:34 2020 +0100
> >>
> >> - shadow puts everything into /bin and /sbin - that's ok but provide
> >> symlinks for old (pwdutils) locations
> > [...]
> >> +# compatibility with old locations (and pwdutils)
> >> +install -d $RPM_BUILD_ROOT%{_bindir}
> >> +for f in chage chfn chsh expiry faillog gpasswd newgrp newgidmap passwd
> >> newuidmap sg; do
> >> + ln -s /bin/${f} $RPM_BUILD_ROOT%{_bindir}/${f}
> >> +done
> >> +install -d $RPM_BUILD_ROOT%{_sbindir}
> >> +for f in chgpasswd chpasswd groupadd groupdel groupmems groupmod grpck
> >> grpconv grpunconv logoutd newusers pwck pwconv pwunconv useradd userdel
> >> usermod vigr vipw; do
> >> + ln -s /sbin/${f} $RPM_BUILD_ROOT%{_sbindir}/${f}
> >> +done
> >> +
[...]
> >> +%attr(755,root,root) /sbin/groupmems
> >> %attr(755,root,root) %{_sbindir}/groupmems
> >> +%attr(755,root,root) /sbin/groupmod
> >> %attr(755,root,root) %{_sbindir}/groupmod
> > [...]
> >
> > Uhhh, please, no.
>
> It's ugly but I don't see any other solution that would work.
>
> > Either go traditional way and distribute binaries over directories (like
> > in coreutils),
>
> To goal is not to diverge from upstream.
Upstream installs everything to prefix given to configure.
Or /bin + /sbin, if it's told so to %configure in spec.
> or maybe it's time to go merged-/usr distro-wide?
> >
> > Are there still any profits from using local / with network or host shared
> > /usr?
>
> Does it matter for this case?
Debian moved to merged /usr too, in such case both paths work regardless
of actual install paths.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/shadow] - shadow puts everything into /bin and /sbin - that's ok but provide symlinks for old (pwdutils) loc
On Tue, Jan 07, 2020 at 01:36:44PM +0100, arekm wrote:
> commit 2bb4da0ffecbbc08e6e25336b3e1e012b7cd61a5
> Author: Arkadiusz Miśkiewicz
> Date: Tue Jan 7 13:36:34 2020 +0100
>
> - shadow puts everything into /bin and /sbin - that's ok but provide
> symlinks for old (pwdutils) locations
[...]
> +# compatibility with old locations (and pwdutils)
> +install -d $RPM_BUILD_ROOT%{_bindir}
> +for f in chage chfn chsh expiry faillog gpasswd newgrp newgidmap passwd
> newuidmap sg; do
> + ln -s /bin/${f} $RPM_BUILD_ROOT%{_bindir}/${f}
> +done
> +install -d $RPM_BUILD_ROOT%{_sbindir}
> +for f in chgpasswd chpasswd groupadd groupdel groupmems groupmod grpck
> grpconv grpunconv logoutd newusers pwck pwconv pwunconv useradd userdel
> usermod vigr vipw; do
> + ln -s /sbin/${f} $RPM_BUILD_ROOT%{_sbindir}/${f}
> +done
> +
[...]
> +%attr(4755,root,root) /bin/chfn
> %attr(4755,root,root) %{_bindir}/chfn
> +%attr(4755,root,root) /bin/chsh
> %attr(4755,root,root) %{_bindir}/chsh
> +%attr(4755,root,root) /bin/expiry
> %attr(4755,root,root) %{_bindir}/expiry
> +%attr(4755,root,root) /bin/gpasswd
> %attr(4755,root,root) %{_bindir}/gpasswd
> +%attr(4755,root,root) /bin/passwd
> %attr(4755,root,root) %{_bindir}/passwd
> +%attr(4755,root,root) /bin/chage
> %attr(4755,root,root) %{_bindir}/chage
> +%attr(755,root,root) /bin/faillog
> %attr(755,root,root) %{_bindir}/faillog
> +%attr(4755,root,root) /bin/newgrp
> %attr(4755,root,root) %{_bindir}/newgrp
> +%attr(755,root,root) /bin/sg
> %attr(755,root,root) %{_bindir}/sg
> +%attr(755,root,root) /sbin/chgpasswd
> %attr(755,root,root) %{_sbindir}/chgpasswd
> +%attr(755,root,root) /sbin/chpasswd
> %attr(755,root,root) %{_sbindir}/chpasswd
> +%attr(755,root,root) /sbin/groupadd
> %attr(755,root,root) %{_sbindir}/groupadd
> +%attr(755,root,root) /sbin/groupdel
> %attr(755,root,root) %{_sbindir}/groupdel
> +%attr(755,root,root) /sbin/groupmems
> %attr(755,root,root) %{_sbindir}/groupmems
> +%attr(755,root,root) /sbin/groupmod
> %attr(755,root,root) %{_sbindir}/groupmod
[...]
Uhhh, please, no.
Either go traditional way and distribute binaries over directories (like
in coreutils), or maybe it's time to go merged-/usr distro-wide?
Are there still any profits from using local / with network or host shared /usr?
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
cvs acl.pl not executable
Is it intentional? $ cvs ci ... uid_gid.db.txt cvs commit: cannot exec /cvsroot/CVSROOT/acl.pl: Permission denied cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
DNS problems on builders [Fwd: [all] builder queue problem]
It seems that builders (at least src builder) experiences some problems with resolving hosts in PLD domain... One example below. But also some build requests fail on resolving distfiles to build src.rpm. - Forwarded message from PLD all builder - From: PLD all builder X-PLD-Builder: all To: qbo...@pld-linux.org, drae...@pld-linux.org Date: Sat, 26 Oct 2019 18:13:28 + Subject: [all] builder queue problem there were problems sending files from queue /home/pld/builderth/pld-builder.new/spool/buildlogs: problems: [src: /home/pld/builderth/pld-builder.new/spool/buildlogs/th-src.4a568948-241c-4d51-bbde-e994c7e0187c.liblouisutdml.spec.log] rsync: getaddrinfo: buildlogs.pld-linux.org 873: No address associated with hostname rsync error: error in socket IO (code 10) at clientserver.c(125) [sender=3.1.2] - End forwarded message - -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
th-x32 builder stuck or dead?
What happened to th-x32 builder? It either got stuck building python3-typed_ast-1.4.0-2 or died... carme-x32 builds python3-typed_ast-1.4.0-2 without problems. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/librsvg] - updated dependencies; librsvg since 2.42 is partially in rust (what with th-x32?)
On Wed, Jan 30, 2019 at 09:05:10PM +0100, Jan Rękorajski wrote: > On Wed, 30 Jan 2019, Jakub Bogusz wrote: > > > On Wed, Jan 30, 2019 at 08:20:00PM +0100, qboosh wrote: > > > commit fc65f7f1cf360e29b7e44b9835dece9805ad9dbc > > > Author: Jakub Bogusz > > > Date: Wed Jan 30 20:25:13 2019 +0100 > > > > > > - updated dependencies; librsvg since 2.42 is partially in rust (what > > > with th-x32?) > > > > According to rust project site, code generation and std lib is supported > > on x32, but there is no rustc hosted on x32 system - I assume that x86_64 > > rustc must be used... > > 1. librsvg-c for x32? https://lwn.net/Articles/771355/ > 2. get rust functional on x32 (I'm fine with x86_64 runtime and x32 stdlib) > 3. drop x32 possibly? https://lwn.net/Articles/774734/ Followup: eog 3.34 already (optionally) requires rust-based librsvg >= 2.44), so sticking to 2.40.x is no longer an option. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
multilib on carme-x32
Can we have some multilib packages on carme-x32? At least glibc.x86_64 for now. I'd like to try to build rust std library there (there is no hosted rustc or cargo on this arch, so x86_64 ones must be used). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: What happened to distfiles?
On Sun, Sep 01, 2019 at 06:34:38PM +0200, Arkadiusz Miśkiewicz wrote: > On 01/09/2019 17:22, Jakub Bogusz wrote: > > On Thu, Aug 29, 2019 at 12:50:26PM +0200, Arkadiusz Miśkiewicz wrote: > >> On 28/08/2019 20:56, Jakub Bogusz wrote: > >>> Downloading works, but uploading doesn't: > >>> > >>> - Forwarded message from distfi...@distfiles.pld-linux.org - > >>> > >>> From: > >>> To: qbo...@pld-linux.org > >>> Subject: DISTFILES: glpk: ERRORS: glpk-4.65.tar.gz > >>> X-distfiles-program: file-fetcher.pl > >>> Date: Wed, 28 Aug 2019 16:22:43 +0200 > >>> > >>> scp problems: scp -pr -B -q > >>> ./tmp/6b636521-54cc-4839-bf3e-3ab6408ed2ed/470a984a8b1c0e027bdb6d5859063fe8/ > >>> pldd...@distfiles.pld-linux.org:ftp//by-md5/4/7: > >>> lost connection > >>> > >>> The command has exited with a non-zero status. > >>> > >>> Files fetched: 0 > >> > >> tons of defunct sshds. Try now. > > > > It worked for a few days, but now it seems to be broken again... > > That's some syslog-ng problem. It seems to be getting stuck and all apps > writting to /dev/log also hang. > > Restarting syslog-ng fixed the problem for now. It seems it happened again (on df). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
What happened to distfiles?
Downloading works, but uploading doesn't: - Forwarded message from distfi...@distfiles.pld-linux.org - From: To: qbo...@pld-linux.org Subject: DISTFILES: glpk: ERRORS: glpk-4.65.tar.gz X-distfiles-program: file-fetcher.pl Date: Wed, 28 Aug 2019 16:22:43 +0200 scp problems: scp -pr -B -q ./tmp/6b636521-54cc-4839-bf3e-3ab6408ed2ed/470a984a8b1c0e027bdb6d5859063fe8/ pldd...@distfiles.pld-linux.org:ftp//by-md5/4/7: lost connection The command has exited with a non-zero status. Files fetched: 0 -- Virtually Yours: distfiles. - End forwarded message - -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
[builder-th-i...@pld-linux.org: ERRORS: COMMAND]
FHS package is too old on th-i686 (missing "ta" man dir), but it cannot be simply upgraded. Could sb do it manually (possibly adding /proc to netsharedpath or so)? - Forwarded message from PLD th-i686 builder - COMMAND (): FAILED --- COMMAND:: Build-Time: user:7.09s sys:1.02s real:8.32s (faults io:0 non-io:114006) *** buildlog for COMMAND Loading [pndir]ready... Loading [pndir]th-test... Loading [pndir]th-test... Loading [pndir]th-ready... Loading [pndir]th-ready... Loading [pndir]th... Loading [pndir]th... 31996 packages read Removed 371 duplicate packages from available set Processing dependencies... FHS-3.0-2.i686 obsoleted by FHS-3.0-3.i686 There are 1 package to install, 1 to remove: I FHS-3.0-3.i686 R FHS-3.0-2.i686 Need to get 51.9KB of archives. Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 1... Preparing...## FHS ## error: unpacking of archive failed on file /proc: cpio: chown failed - Inappropriate ioctl for device Begin-PLD-Builder-Info Build-Time: user:7.09s sys:1.02s real:8.32s (faults io:0 non-io:114006) End-PLD-Builder-Info - End forwarded message - -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: upgrade failed ERRORS: python3.spec
??? Build failed on tests, but builder says, that only upgrade failed... And what are "foo" RPMs it tried to install? python3.spec produces different packages. On Sat, Aug 03, 2019 at 06:14:49PM +, PLD th-x86_64 builder wrote: > python3.spec (auto/th/python3-3.7.4-2): FAILED > > --- python3.spec:auto/th/python3-3.7.4-2: > upgrading packages > error: open of > /tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm > failed: No such file or directory > package upgrade failed > Build-Time: user:5378.04s sys:169.65s real:5102.93s (faults io:0 > non-io:28072151) > > Files queued for ftp: > 0 foo-0.1-1.noarch.rpm > 0 foo-0.1-1.src.rpm > 98 python3-3.7.4-2.src.rpm.uploadinfo [...] > Total duration: 2 min 41 sec > Tests result: FAILURE then FAILURE > make: *** [Makefile:1078: test] Error 2 > error: Bad exit status from /tmp/B.LdDK2F/BUILD/tmp/rpm-tmp.77271 (%build) > > > RPM build errors: > Bad exit status from /tmp/B.LdDK2F/BUILD/tmp/rpm-tmp.77271 (%build) > ended at: Sat Aug 3 20:14:48 2019, done in 1:24:51.824189 > + chmod -R u+rwX /tmp/B.LdDK2F/BUILD > + rm -rf /tmp/B.LdDK2F/tmp /tmp/B.LdDK2F/BUILD > copy rpm files to cache_dir: /spools/ready > cp: cannot stat > '/tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm': > No such file or directory > cp: cannot stat > '/tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/SRPMS/foo-0.1-1.src.rpm': > No such file or directory > Begin-PLD-Builder-Info > upgrading packages > error: open of > /tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm > failed: No such file or directory > package upgrade failed > End-PLD-Builder-Info > + rm -rf /tmp/B.LdDK2F > Begin-PLD-Builder-Info > Build-Time: user:5378.04s sys:169.65s real:5102.93s (faults io:0 > non-io:28072151) > > Files queued for ftp: > 0 foo-0.1-1.noarch.rpm > 0 foo-0.1-1.src.rpm > 98 python3-3.7.4-2.src.rpm.uploadinfo > > End-PLD-Builder-Info > -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/Vulkan-Loader] new package
On Fri, May 24, 2019 at 01:21:38AM +0300, Elan Ruusamäe wrote: > > On 23/05/2019 21:13, jajcus wrote: > >+BuildRequires: python3 >= 3 > > python3 was unfortunately started with epoch: 1, copy paste from python.spec > > otoh, if as you don't have more specific version here, just drop the > version construct? I prefer to specify version - in case given package gets renamed some day. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
No space on cvs/git machine root
$ git push Enter passphrase for key '/home/comp/.ssh/id_rsa': Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 343 bytes | 343.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) remote: fatal: write failure on standard output: Brak miejsca na urządzeniu remote: error: unable to write file python-pyatspi.spec remote: Emitting a message to the fedmsg bus. remote: * Publishing information for 1 commits remote: 2019-04-11 07:16:50 failed to write to main log: length=78 result=-1 errno=28 (No space left on device) remote: Error in hook hooks/post-receive.python.d/slug_hook.py remote: [Errno 28] No space left on device To ssh://git.pld-linux.org/packages/python-pyatspi 151ef17..1b8df80 HEAD -> master -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Fwd: ERRORS: openchange.spec
On Wed, Apr 10, 2019 at 10:43:02AM +0200, Adam Golebiowski wrote: > Hi, > > I suggest to drop openchange. The project is effectively dead: > - last commit from Dec 2015 [0] > - openchange.org domain expired and noone bothered to renew - got hijacked > - samba's wiki on openchange also states lack of development [1] > > There are some alternatives like sogo [2], [3] for those that need such > functionality. > > [0] https://github.com/openchange/openchange/commits/master > [1] https://wiki.samba.org/index.php/OpenChange > [2] https://sogo.nu/ > [3] https://github.com/inverse-inc/sogo AFAIK to sole purpose of preserving openchange is evolution MAPI module (evolution-mapi). As long as it's maintained (relying on openchange), there is a reason to keep openchange. For the time being, Fedora is still maintaining openchange patches, so we can use them. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Missing buildlogs
On Sun, Feb 24, 2019 at 12:57:05PM +0100, Jan Palus wrote: > Looks like starting with gcc build > (https://srcbuilder.pld-linux.org/th/queue.html#184029) > buildlogs went missing. Can someone check? Probably because: 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-x86_64.a13106f0-19e0-4e4b-bb97-80a070419923.libatomic_ops.spec.log] @ERROR: invalid uid ftp rsync error: error starting client-server protocol (code 5) at main.c(1648) [sender=3.1.2] [...] (from the tons of emails I'm getting from builders...) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/librsvg] - updated dependencies; librsvg since 2.42 is partially in rust (what with th-x32?)
On Wed, Jan 30, 2019 at 08:20:00PM +0100, qboosh wrote: > commit fc65f7f1cf360e29b7e44b9835dece9805ad9dbc > Author: Jakub Bogusz > Date: Wed Jan 30 20:25:13 2019 +0100 > > - updated dependencies; librsvg since 2.42 is partially in rust (what > with th-x32?) According to rust project site, code generation and std lib is supported on x32, but there is no rustc hosted on x32 system - I assume that x86_64 rustc must be used... -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL
llvm built successfully for all Th archs. BTW - ouch... 1889870589 llvm-debuginfo-7.0.0-3.x86_64.rpm -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
