From qboosh at pld-linux.org Sat Dec 1 08:24:29 2018 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 1 Dec 2018 08:24:29 +0100 Subject: pixman tests failures / build logs not mailed from th-i686 Message-ID: <20181201072429.GA9776@mail> When trying to build pixman, on th-i686 tests fail impredictably - at least one of alphamap, composite, tolerance-test, but almost each time set of failing tests is different. Disabling openmp or parallel make seems to lower the number of failures, but doesn't eliminate them (and alphamap doesn't use openmp at all). Tests don't fail on my i686 nor carme-i686. Any ideas? BTW - I'm not getting th-i686 build reports by e-mail (only from th-x32 and th-x86-64). -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Sat Dec 1 12:09:40 2018 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Sat, 1 Dec 2018 12:09:40 +0100 Subject: pixman tests failures / build logs not mailed from th-i686 In-Reply-To: <20181201072429.GA9776@mail> References: <20181201072429.GA9776@mail> Message-ID: <1e8256b8-a5d9-b4db-b8db-b3bb87b6b5dc@maven.pl> On 01/12/2018 08:24, Jakub Bogusz wrote: > When trying to build pixman, on th-i686 tests fail impredictably > - at least one of alphamap, composite, tolerance-test, but almost each > time set of failing tests is different. > Disabling openmp or parallel make seems to lower the number of failures, > but doesn't eliminate them (and alphamap doesn't use openmp at all). > Tests don't fail on my i686 nor carme-i686. > Any ideas? [2285767.849664] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) [2294198.782119] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) [2441072.340785] EDAC MC0: 1 CE Read error on mc#0branch#1channel#0slot#0 (branch:1 channel:0 slot:0 page:0x0 offset:0x0 grain:8 syndrome:0x0 - Corrected error (Branch=1 DRAM-Bank=0 RDWR=Read RAS=0 CAS=0, CE Err=0x10000 (Correctable Non-Mirrored Demand Data ECC))) [2658392.799108] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) [2757594.069188] EDAC MC0: 1 UE Read error on mc#0branch#0channel#0slot#0 or mc#0branch#0channel#1slot#0 (branch:0 slot:0 page:0x0 offset:0x0 grain:8 - Bank=0 Buffer ID = 0 RAS=0 CAS=0 Err=0x2000 (FB-DIMM Configuration Write error on first attempt)) Seems to be some hw problem :-/ > BTW - I'm not getting th-i686 build reports by e-mail (only from th-x32 > and th-x86-64). Fixed. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Sun Dec 2 13:37:18 2018 From: atler at pld-linux.org (Jan Palus) Date: Sun, 2 Dec 2018 13:37:18 +0100 Subject: PLD-doc: PLD-update-TODO - updated In-Reply-To: References: Message-ID: <20181202123718.ifm4m5mrk64565lq@kalarepa> Is this update job working correctly? Just few examples that are out of date: avfs(11) [OLD] 1.0.0 [NEW] 1.0.6 --> 1.0.6 is in Git for a week now ell(12) [OLD] 0.12 [NEW] 0.14 --> the latest version is 0.15 not 0.14 and 0.15 is in repo for 2 weeks now guvcview(12) [OLD] 2.0.5 [NEW] 2.0.6 --> 2.0.6 is in Git for 1.5 months now From arekm at maven.pl Mon Dec 3 20:30:12 2018 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Mon, 3 Dec 2018 20:30:12 +0100 Subject: PLD-doc: PLD-update-TODO - updated In-Reply-To: <20181202123718.ifm4m5mrk64565lq@kalarepa> References: <20181202123718.ifm4m5mrk64565lq@kalarepa> Message-ID: On 02/12/2018 13:37, Jan Palus wrote: > Is this update job working correctly? Just few examples that are out of date: > > > avfs(11) [OLD] 1.0.0 [NEW] 1.0.6 --> 1.0.6 is in Git for a week now > ell(12) [OLD] 0.12 [NEW] 0.14 --> the latest version is 0.15 not 0.14 and 0.15 > is in repo for 2 weeks now > guvcview(12) [OLD] 2.0.5 [NEW] 2.0.6 --> 2.0.6 is in Git for 1.5 months now Script used git.pld-linux.org/SPECS.git repo which is outdated (does anyone know which script updates it?). Changed it to use packages/XYZ directly. Next TODO commit should be up to date. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at delfi.ee Mon Dec 3 21:32:45 2018 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 3 Dec 2018 22:32:45 +0200 Subject: PLD-doc: PLD-update-TODO - updated In-Reply-To: References: <20181202123718.ifm4m5mrk64565lq@kalarepa> Message-ID: <93fe1fa1-ced4-1511-b884-a989a3601f8a@delfi.ee> On 03/12/2018 21:30, Arkadiusz Mi?kiewicz wrote: > On 02/12/2018 13:37, Jan Palus wrote: >> Is this update job working correctly? Just few examples that are out of date: >> >> >> avfs(11) [OLD] 1.0.0 [NEW] 1.0.6 --> 1.0.6 is in Git for a week now >> ell(12) [OLD] 0.12 [NEW] 0.14 --> the latest version is 0.15 not 0.14 and 0.15 >> is in repo for 2 weeks now >> guvcview(12) [OLD] 2.0.5 [NEW] 2.0.6 --> 2.0.6 is in Git for 1.5 months now > Script used git.pld-linux.org/SPECS.git repo which is outdated there were changes? link to commit please? > (does > anyone know which script updates it?). invoked script is: bin/specscommit.sh https://github.com/draenog/gitolite-scripts/blob/0e1e5b24a2b7b43e42ecd17abe2cf0fe9de140a4/bin/specscommit.sh by looking at it, it could be skipped only if gc.pid is present, yet it's not [git at 1822-cvs ~]$ git config hooks.specsrepo /cvs/root/gitolite/repositories/SPECS.git [git at 1822-cvs ~]$ l /cvs/root/gitolite/repositories/SPECS.git/gc.pid ls: cannot access '/cvs/root/gitolite/repositories/SPECS.git/gc.pid': No such file or directory [git at 1822-cvs ~]$ i think the script is invoked from git hooks, as git user crontab is empty. err. missing. some changes to system? > Changed it to use packages/XYZ directly. Next TODO commit should be up > to date. link to commit please? From glen at delfi.ee Mon Dec 3 21:49:18 2018 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 3 Dec 2018 22:49:18 +0200 Subject: PLD-doc: PLD-update-TODO - updated In-Reply-To: <93fe1fa1-ced4-1511-b884-a989a3601f8a@delfi.ee> References: <20181202123718.ifm4m5mrk64565lq@kalarepa> <93fe1fa1-ced4-1511-b884-a989a3601f8a@delfi.ee> Message-ID: On 03/12/2018 22:32, Elan Ruusam?e wrote: > Script used git.pld-linux.org/SPECS.git repo which is outdated it's actually up to date. at least now ``` [~/all-specs (master)?] ? g fetch git://git.pld-linux.org/SPECS From git://git.pld-linux.org/SPECS ?* branch??????????????? HEAD?????? -> FETCH_HEAD [~/all-specs (master)?] ? g show FETCH_HEAD -s commit b17b44c216ebbd6a1f3a7ef85585e27c319365bb (HEAD -> master, origin/master, origin/HEAD) Author: git Date:?? Mon Dec 3 21:20:05 2018 +0100 ??? SPECS updated Mon? 3 Dec 21:20:02 CET 2018 ``` From arekm at maven.pl Mon Dec 3 23:04:10 2018 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Mon, 3 Dec 2018 23:04:10 +0100 Subject: PLD-doc: PLD-update-TODO - updated In-Reply-To: References: <20181202123718.ifm4m5mrk64565lq@kalarepa> <93fe1fa1-ced4-1511-b884-a989a3601f8a@delfi.ee> Message-ID: <8c18e819-9a4f-1d5c-fd98-855ac6c23a7d@maven.pl> On 03/12/2018 21:49, Elan Ruusam?e wrote: > > > On 03/12/2018 22:32, Elan Ruusam?e wrote: >> Script used git.pld-linux.org/SPECS.git repo which is outdated > it's actually up to date. at least now > > ``` > [~/all-specs (master)?] ? g fetch git://git.pld-linux.org/SPECS > From git://git.pld-linux.org/SPECS > ?* branch??????????????? HEAD?????? -> FETCH_HEAD > [~/all-specs (master)?] ? g show FETCH_HEAD -s > commit b17b44c216ebbd6a1f3a7ef85585e27c319365bb (HEAD -> master, > origin/master, origin/HEAD) > Author: git > Date:?? Mon Dec 3 21:20:05 2018 +0100 > > ??? SPECS updated Mon? 3 Dec 21:20:02 CET 2018 It isn't: $ git clone --depth 1 git://git.pld-linux.org/SPECS.git Cloning into 'SPECS'... remote: Enumerating objects: 20235, done. remote: Counting objects: 100% (20235/20235), done. remote: Compressing objects: 100% (19136/19136), done. remote: Total 20235 (delta 1481), reused 15807 (delta 1099)B/s Receiving objects: 100% (20235/20235), 24.62 MiB | 19.02 MiB/s, done. Resolving deltas: 100% (1481/1481), done. Checking out files: 100% (20233/20233), done. $ grep Version SPECS/guvcview.spec Version: 2.0.5 $ git clone --depth 1 git://git.pld-linux.org/packages/guvcview.git Cloning into 'guvcview'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Receiving objects: 100% (3/3), done. $ grep Version guvcview/guvcview.spec Version: 2.0.6 From glen at delfi.ee Mon Dec 3 23:39:01 2018 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 4 Dec 2018 00:39:01 +0200 Subject: [packages/rsync] - downgrade to 3.1.2 due to server segfault In-Reply-To: <615041e096bf687532c390c51043f93d15f4801e_refs_heads_master@pld-linux.org> References: <615041e096bf687532c390c51043f93d15f4801e_refs_heads_master@pld-linux.org> Message-ID: <0658b5a8-9e89-cbdf-c786-a5c1899d52aa@delfi.ee> On 17/04/2018 10:19, baggins wrote: > commit 615041e096bf687532c390c51043f93d15f4801e > Author: Jan R?korajski > Date: Tue Apr 17 09:19:12 2018 +0200 > > - downgrade to 3.1.2 due to server segfault > > rsync.spec | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > --- > diff --git a/rsync.spec b/rsync.spec > index d663909..a257e2d 100644 > --- a/rsync.spec > +++ b/rsync.spec > @@ -1,3 +1,4 @@ > +# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode (both inetd and standalone) can you re-test your scenario? seems working with this test: [~/rpm/packages/rsync(3.1.3) (master)?] ? ~/tmp/rsync-3.1.3-root-glen/usr/bin/rsync --daemon --config ~/tmp/rsync-3.1.3-root-glen/etc/rsyncd/rsyncd.conf --no-detach --log-file=/dev/tty --port=1873 2018/12/04 00:36:46 [4343] rsyncd version 3.1.3 starting, listening on port 1873 maybe fixed with newer glibc [~/rpm/packages/rsync(3.1.3) (master)?] ? q glibc glibc-6:2.28-9.x86_64 From hawk at pld-linux.org Mon Dec 3 23:51:12 2018 From: hawk at pld-linux.org (Marcin Krol) Date: Mon, 3 Dec 2018 23:51:12 +0100 Subject: [packages/rsync] - downgrade to 3.1.2 due to server segfault In-Reply-To: <0658b5a8-9e89-cbdf-c786-a5c1899d52aa@delfi.ee> References: <615041e096bf687532c390c51043f93d15f4801e_refs_heads_master@pld-linux.org> <0658b5a8-9e89-cbdf-c786-a5c1899d52aa@delfi.ee> Message-ID: <5C05B360.9040104@pld-linux.org> >> diff --git a/rsync.spec b/rsync.spec >> index d663909..a257e2d 100644 >> --- a/rsync.spec >> +++ b/rsync.spec >> @@ -1,3 +1,4 @@ >> +# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode >> (both inetd and standalone) FYI... https://www.mail-archive.com/rsync at lists.samba.org/msg32342.html https://git.tld-linux.org/?p=packages/rsync.git;a=blob_plain;f=rsync-popt-segv-fix.patch;hb=2f9fbda0b06f6f40cd54b3b79aa8b2aeeb1eab55 Maybe you'll think of better fix. Upstream probably ignored my report :) M. From glen at delfi.ee Tue Dec 4 00:19:03 2018 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 4 Dec 2018 01:19:03 +0200 Subject: [packages/rsync] - downgrade to 3.1.2 due to server segfault In-Reply-To: <5C05B360.9040104@pld-linux.org> References: <615041e096bf687532c390c51043f93d15f4801e_refs_heads_master@pld-linux.org> <0658b5a8-9e89-cbdf-c786-a5c1899d52aa@delfi.ee> <5C05B360.9040104@pld-linux.org> Message-ID: On 04/12/2018 00:51, Marcin Krol wrote: >>> diff --git a/rsync.spec b/rsync.spec >>> index d663909..a257e2d 100644 >>> --- a/rsync.spec >>> +++ b/rsync.spec >>> @@ -1,3 +1,4 @@ >>> +# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode >>> (both inetd and standalone) > > > FYI... > > https://www.mail-archive.com/rsync at lists.samba.org/msg32342.html > > https://git.tld-linux.org/?p=packages/rsync.git;a=blob_plain;f=rsync-popt-segv-fix.patch;hb=2f9fbda0b06f6f40cd54b3b79aa8b2aeeb1eab55 > > > Maybe you'll think of better fix. Upstream probably ignored my report :) i guessed it might be something to do with std fds. however, rc-scripts no longer closes fd0,1,2, but redirects, but redirects. also there's --redirfds or --closefds option for daemon() to use if the initlog still does some fd closing. you may also try playing with RC_LOGGING=yes vs RC_LOGGING=no to skip initlog completely. .... actually. now i'm looking, and can't find the commit that redirects fds to /dev/null by default. maybe i asked mailing list, and received no response and the forgot the idea/patch. all i found is 2014 commit. which is similar, but something else: http://git.pld-linux.org/?p=projects/rc-scripts.git;a=commitdiff;h=289e29826cf1ce827e69ad3b6af8d2d9933bc875 ``` [~/rpm/packages/rc-scripts/rc-scripts (master)?] ? g show 289e29826cf1ce827e69ad3b6af8d2d9933bc875 commit 289e29826cf1ce827e69ad3b6af8d2d9933bc875 Author: Elan Ruusam?e Date:?? Sun Mar 2 02:40:52 2014 +0200 ??? daemon: always close stdin, avoids weird program deaths; redirect stdin "in", not "out" diff --git a/lib/functions b/lib/functions index 56cab80..e75f61d 100644 --- a/lib/functions +++ b/lib/functions @@ -726,13 +726,14 @@ daemon() { ??????????????? if [ "$closefds" = 1 ]; then ??????????????????????? exec 1>&- ??????????????????????? exec 2>&- -?????????????????????? exec 0>&- +?????????????????????? exec 0<&- ??????????????? elif [ "$redirfds" = 1 ]; then ??????????????????????? exec 1>/dev/null ??????????????????????? exec 2>/dev/null -?????????????????????? exec 0>/dev/null +?????????????????????? exec 0&1 +?????????????????????? exec 0 References: <20181202123718.ifm4m5mrk64565lq@kalarepa> <93fe1fa1-ced4-1511-b884-a989a3601f8a@delfi.ee> <8c18e819-9a4f-1d5c-fd98-855ac6c23a7d@maven.pl> Message-ID: <6ebcfa59-1150-a9a5-6cc9-e84699e38e5f@delfi.ee> On 04/12/2018 00:04, Arkadiusz Mi?kiewicz wrote: > It isn't: the repo is updating (maybe always was), i.e contents of ~/SPECS is being committed to /cvs/root/gitolite/repositories/SPECS.git but your spec is not written to SPECS: ``` root at 1822-cvs services/git# l -rt ~git/SPECS|tail -rw-r----- 1 git git 6.9K Dec? 2 20:36 python-pygobject3.spec -rw-r----- 1 git git? 20K Dec? 2 21:22 qt5-qttools.spec -rw-r----- 1 git git 5.8K Dec? 3 09:46 sysstat.spec -rw-r----- 1 git git? 13K Dec? 3 11:09 sqlite3.spec -rw-r----- 1 git git? 24K Dec? 3 16:12 kernel-tools.spec -rw-r----- 1 git git 7.8K Dec? 3 20:38 ipset.spec -rw-r----- 1 git git 6.6K Dec? 3 22:16 pdflib.spec -rw-r----- 1 git git? 32K Dec? 3 23:45 libvirt.spec -rw-r----- 1 git git 3.5K Dec? 3 23:45 python-libvirt.spec -rw-r----- 1 git git? 11K Dec? 4 00:30 rsync.spec 01:34:58 [load: 2.06 51.50% nproc: 4] root at 1822-cvs services/git# ``` yet can't find what updates ~/SPECS. looked into: - crontab - gitolite-scripts - git-core-slug-watcher there's some wiki docs, maybe these describe - https://www.pld-linux.org/pld-gitolite - https://www.pld-linux.org/howto-git From qboosh at pld-linux.org Sat Dec 8 11:12:28 2018 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 8 Dec 2018 11:12:28 +0100 Subject: [packages/rsync] - downgrade to 3.1.2 due to server segfault In-Reply-To: <5C05B360.9040104@pld-linux.org> References: <615041e096bf687532c390c51043f93d15f4801e_refs_heads_master@pld-linux.org> <0658b5a8-9e89-cbdf-c786-a5c1899d52aa@delfi.ee> <5C05B360.9040104@pld-linux.org> Message-ID: <20181208101228.GA6113@mail> On Mon, Dec 03, 2018 at 11:51:12PM +0100, Marcin Krol wrote: > >>diff --git a/rsync.spec b/rsync.spec > >>index d663909..a257e2d 100644 > >>--- a/rsync.spec > >>+++ b/rsync.spec > >>@@ -1,3 +1,4 @@ > >>+# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode > >>(both inetd and standalone) > > > FYI... > > https://www.mail-archive.com/rsync at lists.samba.org/msg32342.html Try with popt 1.17-3. -- Jakub Bogusz http://qboosh.pl/ From glen at delfi.ee Tue Dec 11 11:53:08 2018 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 11 Dec 2018 12:53:08 +0200 Subject: openssl again makes php5.3 crash Message-ID: <5eed7172-31e9-5829-a9d4-68a5e2856170@delfi.ee> $ docker run --privileged --rm -it registry.gitlab.com/pld-linux/pld sh [@42300ff78c63 /]# poldek -u --noask composer gdb --ignore=*php4* --ignore=*php52* [@42300ff78c63 /]# poldek -n th-debuginfo -u php53-debuginfo openssl-debuginfo [@42300ff78c63 /]# cd /tmp [@42300ff78c63 /tmp]# echo '{}' > composer.json [@42300ff78c63 /tmp]# composer install Do not run Composer as root/super user! See https://getcomposer.org/root for details Loading composer repositories with package information Segmentation fault [@42300ff78c63 /tmp]# composer config -g -- disable-tls true Do not run Composer as root/super user! See https://getcomposer.org/root for details [@42300ff78c63 /tmp]# composer install You are running Composer with SSL/TLS protection disabled. Do not run Composer as root/super user! See https://getcomposer.org/root for details Loading composer repositories with package information Updating dependencies (including require-dev) Nothing to install or update Generating autoload files [@42300ff78c63 /tmp]# [@236200a329d5 r]# rpm -q php53-common openssl php53-common-5.3.29-43.x86_64 openssl-1.1.1a-1.x86_64 [@236200a329d5 r]# [@42300ff78c63 /tmp]# composer config -g -- disable-tls false You are running Composer with SSL/TLS protection disabled. Do not run Composer as root/super user! See https://getcomposer.org/root for details [@42300ff78c63 /tmp]# gdb --args php /usr/bin/composer install GNU gdb (GDB) 8.2-2 (PLD Linux) Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pld-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: ??? . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from php...Reading symbols from /usr/lib/debug/usr/bin/php53.debug...done. done. (gdb) r Starting program: /usr/bin/php /usr/bin/composer install [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [Detaching after fork from child process 333] [Detaching after fork from child process 334] [Detaching after fork from child process 335] [Detaching after fork from child process 336] [Detaching after fork from child process 337] [Detaching after fork from child process 338] [Detaching after fork from child process 339] Do not run Composer as root/super user! See https://getcomposer.org/root for details [Detaching after fork from child process 340] Loading composer repositories with package information Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7e66731 in _zval_ptr_dtor (zval_ptr=0x7ffff6853f9000) at /usr/src/debug/php-5.3.29/Zend/zend_execute_API.c:434 434??? ??? zval *zv = *zval_ptr; (gdb) bt #0? 0x00007ffff7e66731 in _zval_ptr_dtor (zval_ptr=0x7ffff6853f9000) at /usr/src/debug/php-5.3.29/Zend/zend_execute_API.c:434 #1? 0x00007ffff7ec0f85 in zend_leave_helper_SPEC (execute_data=execute_data at entry=0x7ffff6853eb0) at /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:160 #2? 0x00007ffff7ec148a in ZEND_RETURN_SPEC_VAR_HANDLER (execute_data=0x7ffff6853eb0) at /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:8255 #3? 0x00007ffff7e99e61 in execute (op_array=0x131dec8) at /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:107 #4? 0x00007ffff7e76597 in zend_execute_scripts (type=type at entry=8, retval=retval at entry=0x0, file_count=file_count at entry=3) at /usr/src/debug/php-5.3.29/Zend/zend.c:1259 #5? 0x00007ffff7e23d38 in php_execute_script (primary_file=primary_file at entry=0x7fffffffd090) at /usr/src/debug/php-5.3.29/main/main.c:2316 #6? 0x0000000000404939 in main (argc=3, argv=0x7fffffffe458) at /usr/src/debug/php-5.3.29/sapi/cli/php_cli.c:1189 (gdb) From glen at pld-linux.org Tue Dec 11 14:53:33 2018 From: glen at pld-linux.org (glen) Date: Tue, 11 Dec 2018 15:53:33 +0200 Subject: [packages/nagios-plugin-check_raid] - rel 2; plugin doesn't monitor bbu by default, so provide separate template command and template fo In-Reply-To: <5fe36881db12eb4ba498c749cb310450ce57138d_refs_heads_master@pld-linux.org> References: <5fe36881db12eb4ba498c749cb310450ce57138d_refs_heads_master@pld-linux.org> Message-ID: On 12/11/18 2:13 PM, arekm wrote: > commit 5fe36881db12eb4ba498c749cb310450ce57138d > Author: Arkadiusz Mi?kiewicz > Date: Tue Dec 11 13:13:17 2018 +0100 > > - rel 2; plugin doesn't monitor bbu by default, so provide separate template command and template for that you can just use: check_command check_raid!--bbu-monitoring also, if you insist on new template, extend the previous one, not copy paste? -- glen From glen at pld-linux.org Tue Dec 11 14:55:04 2018 From: glen at pld-linux.org (glen) Date: Tue, 11 Dec 2018 15:55:04 +0200 Subject: [packages/nagios-plugin-check_raid] - rel 3; use separate config, so nagios_nrpe rpm macros can deal with it In-Reply-To: <46ad8dd8b531d61f3b62001d1880b4d452c7ea82_refs_heads_master@pld-linux.org> References: <5fe36881db12eb4ba498c749cb310450ce57138d_refs_heads_master@pld-linux.org> <46ad8dd8b531d61f3b62001d1880b4d452c7ea82_refs_heads_master@pld-linux.org> Message-ID: On 12/11/18 2:52 PM, arekm wrote: > - rel 3; use separate config, so nagios_nrpe rpm macros can deal with it why not just patch and enable bbu by default? -- glen From arekm at maven.pl Tue Dec 11 15:36:39 2018 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Tue, 11 Dec 2018 15:36:39 +0100 Subject: [packages/nagios-plugin-check_raid] - rel 3; use separate config, so nagios_nrpe rpm macros can deal with it In-Reply-To: References: <5fe36881db12eb4ba498c749cb310450ce57138d_refs_heads_master@pld-linux.org> <46ad8dd8b531d61f3b62001d1880b4d452c7ea82_refs_heads_master@pld-linux.org> Message-ID: On 11/12/2018 14:55, glen wrote: > On 12/11/18 2:52 PM, arekm wrote: > >> ???? - rel 3; use separate config, so nagios_nrpe rpm macros can deal >> with it > > why not just patch and enable bbu by default? > Fine with me (there is no option to disable it though, on per host basis). Kind of --bbu-monitoring=0 -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From jajcus at jajcus.net Tue Dec 11 15:37:40 2018 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 11 Dec 2018 15:37:40 +0100 Subject: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL Message-ID: <68c4a718-d18c-9c3a-e57a-aad691ff0c90@jajcus.net> Hi, I am preparing package for Mesa 18.3.0, switching the build system to Meson, as autoconf/automake is deprecated. I made it build, but without OpenCL. The problem is the Clover part of Mesa requires RTTI to build (uses dynamic_cast) and Mesa is build -fno-rtti when compiled with LLVM built without RTTI. LLVM builds without RTTI by default, but it should be possible to build it with RTTI, using 'REQUIRES_RTTI=1', which we have in our llvm.spec. It doesn't seem to work, though: [jajcus at jajo ~]$ llvm-config --has-rtti NO [jajcus at jajo ~]$ rpm -qf `which llvm-config` llvm-devel-7.0.0-1.x86_64 Should we fix it? It is disabled in LLVM for a reason, but it seems Mesa expects it rather enabled. Also, changing the setting now will change the ABI, which will force us to recompile everything compiled with current LLVM. And I am not sure how to fix it, anyway. Other than that, I would be glad if someone would try the new Mesa, to see if the build works for anything other than Intel GPU. Especially the Gallium drivers. Jacek From qboosh at pld-linux.org Wed Dec 12 16:06:02 2018 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 12 Dec 2018 16:06:02 +0100 Subject: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL In-Reply-To: <68c4a718-d18c-9c3a-e57a-aad691ff0c90@jajcus.net> References: <68c4a718-d18c-9c3a-e57a-aad691ff0c90@jajcus.net> Message-ID: <20181212150602.GA32143@mail> On Tue, Dec 11, 2018 at 03:37:40PM +0100, Jacek Konieczny wrote: > Hi, > > I am preparing package for Mesa 18.3.0, switching the build system to > Meson, as autoconf/automake is deprecated. > > I made it build, but without OpenCL. The problem is the Clover part of > Mesa requires RTTI to build (uses dynamic_cast) and Mesa is build > -fno-rtti when compiled with LLVM built without RTTI. > > LLVM builds without RTTI by default, but it should be possible to build > it with RTTI, using 'REQUIRES_RTTI=1', which we have in our llvm.spec. > It doesn't seem to work, though: > > [jajcus at jajo ~]$ llvm-config --has-rtti > NO > [jajcus at jajo ~]$ rpm -qf `which llvm-config` > llvm-devel-7.0.0-1.x86_64 > > Should we fix it? It is disabled in LLVM for a reason, but it seems Mesa > expects it rather enabled. Also, changing the setting now will change > the ABI, which will force us to recompile everything compiled with > current LLVM. And I am not sure how to fix it, anyway. THEY just changed the way of enabling rtti (from make variable to cmake define). As we had rtti in previous versions of llvm and it's needed by other packages (i.e. Mesa/pipe-*), IMO we should just keep it enabled (and rebuild packages already built with rtti-less llvm 7, if necessary). -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Wed Dec 12 23:39:47 2018 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Wed, 12 Dec 2018 23:39:47 +0100 Subject: PL money transfer Message-ID: Hi devs! I need quick money transfer in .pl for a ticket. And even transferwise takes days. Plz, mail me directly if you think you can help. From atler at pld-linux.org Thu Dec 13 12:30:58 2018 From: atler at pld-linux.org (Jan Palus) Date: Thu, 13 Dec 2018 12:30:58 +0100 Subject: DISTFILES: sqlite3: ERRORS: sqlite-src-3260000.zip In-Reply-To: <6164.1544700520@distfiles.pld-linux.org> References: <6164.1544700520@distfiles.pld-linux.org> Message-ID: <20181213113058.z2c5ebrwynwi4ujd@kalarepa> On 13.12.2018 12:28, atler wrote: > Request by: atler > > sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in string.gmatch(string.format("%08d", vn), "..") do v=v.."."..i:gsub("^0", "");end;v=v:gsub("^.",""):gsub("\.0$","");print(v) > > > > Files fetched: 0 > > ALREADY GOT: http://www.sqlite.org/2018/sqlite-src-3260000.zip > dfc2ae0e9b810e9e3db553f71ea832ad sqlite-src-3260000.zip Anyone knows why distfiles is unable to expand this lua macro? From arekm at maven.pl Thu Dec 13 12:37:18 2018 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Thu, 13 Dec 2018 12:37:18 +0100 Subject: DISTFILES: sqlite3: ERRORS: sqlite-src-3260000.zip In-Reply-To: <20181213113058.z2c5ebrwynwi4ujd@kalarepa> References: <6164.1544700520@distfiles.pld-linux.org> <20181213113058.z2c5ebrwynwi4ujd@kalarepa> Message-ID: <5d7937bf-03de-fd3b-9f3c-ff0f4fb316a2@maven.pl> On 13/12/2018 12:30, Jan Palus wrote: > On 13.12.2018 12:28, atler wrote: >> Request by: atler >> >> sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in string.gmatch(string.format("%08d", vn), "..") do v=v.."."..i:gsub("^0", "");end;v=v:gsub("^.",""):gsub("\.0$","");print(v) >> >> >> >> Files fetched: 0 >> >> ALREADY GOT: http://www.sqlite.org/2018/sqlite-src-3260000.zip >> dfc2ae0e9b810e9e3db553f71ea832ad sqlite-src-3260000.zip > > Anyone knows why distfiles is unable to expand this lua macro? It's a simple perl script that expands these macros and doesn't handle complicated cases. Is this macro expansion needed anyway for sqlite3.spec? It fetched source correctly, so likely it is not needed. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Thu Dec 13 12:42:26 2018 From: atler at pld-linux.org (Jan Palus) Date: Thu, 13 Dec 2018 12:42:26 +0100 Subject: DISTFILES: sqlite3: ERRORS: sqlite-src-3260000.zip In-Reply-To: <5d7937bf-03de-fd3b-9f3c-ff0f4fb316a2@maven.pl> References: <6164.1544700520@distfiles.pld-linux.org> <20181213113058.z2c5ebrwynwi4ujd@kalarepa> <5d7937bf-03de-fd3b-9f3c-ff0f4fb316a2@maven.pl> Message-ID: <20181213114226.nz6xs3gajpfux77f@kalarepa> On 13.12.2018 12:37, Arkadiusz Mi?kiewicz wrote: > On 13/12/2018 12:30, Jan Palus wrote: > > On 13.12.2018 12:28, atler wrote: > >> Request by: atler > >> > >> sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in string.gmatch(string.format("%08d", vn), "..") do v=v.."."..i:gsub("^0", "");end;v=v:gsub("^.",""):gsub("\.0$","");print(v) > >> > >> > >> > >> Files fetched: 0 > >> > >> ALREADY GOT: http://www.sqlite.org/2018/sqlite-src-3260000.zip > >> dfc2ae0e9b810e9e3db553f71ea832ad sqlite-src-3260000.zip > > > > Anyone knows why distfiles is unable to expand this lua macro? > > It's a simple perl script that expands these macros and doesn't handle > complicated cases. > > Is this macro expansion needed anyway for sqlite3.spec? It fetched > source correctly, so likely it is not needed. It's needed to fetch replication patch: %define ver %{lua:vn... ... Patch1: https://github.com/CanonicalLtd/sqlite/releases/download/version-%{ver}%%2Breplication3/sqlite-%{ver}.diff I wonder how it worked the first time. From arekm at maven.pl Thu Dec 13 15:05:43 2018 From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Thu, 13 Dec 2018 15:05:43 +0100 Subject: DISTFILES: sqlite3: ERRORS: sqlite-src-3260000.zip In-Reply-To: <20181213114226.nz6xs3gajpfux77f@kalarepa> References: <6164.1544700520@distfiles.pld-linux.org> <20181213113058.z2c5ebrwynwi4ujd@kalarepa> <5d7937bf-03de-fd3b-9f3c-ff0f4fb316a2@maven.pl> <20181213114226.nz6xs3gajpfux77f@kalarepa> Message-ID: On 13/12/2018 12:42, Jan Palus wrote: > On 13.12.2018 12:37, Arkadiusz Mi?kiewicz wrote: >> On 13/12/2018 12:30, Jan Palus wrote: >>> On 13.12.2018 12:28, atler wrote: >>>> Request by: atler >>>> >>>> sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in string.gmatch(string.format("%08d", vn), "..") do v=v.."."..i:gsub("^0", "");end;v=v:gsub("^.",""):gsub("\.0$","");print(v) >>>> >>>> >>>> >>>> Files fetched: 0 >>>> >>>> ALREADY GOT: http://www.sqlite.org/2018/sqlite-src-3260000.zip >>>> dfc2ae0e9b810e9e3db553f71ea832ad sqlite-src-3260000.zip >>> >>> Anyone knows why distfiles is unable to expand this lua macro? >> >> It's a simple perl script that expands these macros and doesn't handle >> complicated cases. >> >> Is this macro expansion needed anyway for sqlite3.spec? It fetched >> source correctly, so likely it is not needed. > > It's needed to fetch replication patch: > > %define ver %{lua:vn... > ... > Patch1: https://github.com/CanonicalLtd/sqlite/releases/download/version-%{ver}%%2Breplication3/sqlite-%{ver}.diff > > I wonder how it worked the first time. This is the script: https://git.pld-linux.org/gitweb.cgi?p=projects/distfiles.git;a=blob;f=specparser.pl;h=510fbc5e001d422f0e5d0657cd87b33da4260c6a;hb=HEAD or just store patch in our git and make small update.sh which fetches latest version and updates spec -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From jajcus at jajcus.net Fri Dec 14 11:26:24 2018 From: jajcus at jajcus.net (Jacek Konieczny) Date: Fri, 14 Dec 2018 11:26:24 +0100 Subject: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL In-Reply-To: <20181212150602.GA32143@mail> References: <68c4a718-d18c-9c3a-e57a-aad691ff0c90@jajcus.net> <20181212150602.GA32143@mail> Message-ID: <39e4791a-fe80-d362-1140-1fb6d719952f@jajcus.net> On 12/12/2018 16.06, Jakub Bogusz wrote: > > THEY just changed the way of enabling rtti (from make variable to cmake > define). > As we had rtti in previous versions of llvm and it's needed by other > packages (i.e. Mesa/pipe-*), IMO we should just keep it enabled (and > rebuild packages already built with rtti-less llvm 7, if necessary). I can see you have already fixed the spec, but how do we build it now? It seems the builders currently cannot handle it. Jacek From qboosh at pld-linux.org Fri Dec 14 16:02:20 2018 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 14 Dec 2018 16:02:20 +0100 Subject: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL In-Reply-To: <39e4791a-fe80-d362-1140-1fb6d719952f@jajcus.net> References: <68c4a718-d18c-9c3a-e57a-aad691ff0c90@jajcus.net> <20181212150602.GA32143@mail> <39e4791a-fe80-d362-1140-1fb6d719952f@jajcus.net> Message-ID: <20181214150220.GA8832@mail> On Fri, Dec 14, 2018 at 11:26:24AM +0100, Jacek Konieczny wrote: > On 12/12/2018 16.06, Jakub Bogusz wrote: > > > > THEY just changed the way of enabling rtti (from make variable to cmake > > define). > > As we had rtti in previous versions of llvm and it's needed by other > > packages (i.e. Mesa/pipe-*), IMO we should just keep it enabled (and > > rebuild packages already built with rtti-less llvm 7, if necessary). > > I can see you have already fixed the spec, but how do we build it now? > It seems the builders currently cannot handle it. I successfully built llvm on carme-x32 (with split-dwarf)... Maybe we should reduce debuginfo level for this package. -- Jakub Bogusz http://qboosh.pl/ From j.rekorajski at gmail.com Fri Dec 14 17:56:50 2018 From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=) Date: Fri, 14 Dec 2018 17:56:50 +0100 Subject: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL In-Reply-To: <20181214150220.GA8832@mail> References: <68c4a718-d18c-9c3a-e57a-aad691ff0c90@jajcus.net> <20181212150602.GA32143@mail> <39e4791a-fe80-d362-1140-1fb6d719952f@jajcus.net> <20181214150220.GA8832@mail> Message-ID: You need to revert this: http://git.pld-linux.org/?p=packages/llvm.git;a=commitdiff;h=f8b4baa198f262d3bff6af0ba38065ad386881a5;hp=fba35f645ed4c3ec1fd41765993175a580cd2c91 I've been testing if newly added builders disk capacity is enough for this beast ;) On Fri, Dec 14, 2018 at 4:02 PM Jakub Bogusz wrote: > > On Fri, Dec 14, 2018 at 11:26:24AM +0100, Jacek Konieczny wrote: > > On 12/12/2018 16.06, Jakub Bogusz wrote: > > > > > > THEY just changed the way of enabling rtti (from make variable to cmake > > > define). > > > As we had rtti in previous versions of llvm and it's needed by other > > > packages (i.e. Mesa/pipe-*), IMO we should just keep it enabled (and > > > rebuild packages already built with rtti-less llvm 7, if necessary). > > > > I can see you have already fixed the spec, but how do we build it now? > > It seems the builders currently cannot handle it. > > I successfully built llvm on carme-x32 (with split-dwarf)... > > Maybe we should reduce debuginfo level for this package. > > > -- > Jakub Bogusz http://qboosh.pl/ > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en -- Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ bagginspld-linux.org From qboosh at pld-linux.org Fri Dec 14 18:36:50 2018 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 14 Dec 2018 18:36:50 +0100 Subject: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL In-Reply-To: References: <68c4a718-d18c-9c3a-e57a-aad691ff0c90@jajcus.net> <20181212150602.GA32143@mail> <39e4791a-fe80-d362-1140-1fb6d719952f@jajcus.net> <20181214150220.GA8832@mail> Message-ID: <20181214173650.GA9151@mail> On Fri, Dec 14, 2018 at 05:56:50PM +0100, Jan R?korajski wrote: > You need to revert this: > > http://git.pld-linux.org/?p=packages/llvm.git;a=commitdiff;h=f8b4baa198f262d3bff6af0ba38065ad386881a5;hp=fba35f645ed4c3ec1fd41765993175a580cd2c91 > > I've been testing if newly added builders disk capacity is enough for > this beast ;) Argh. I did revert it (when building on carme), but it's been lost during rebase on my localhost. Redone now. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Sat Dec 15 13:40:38 2018 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 15 Dec 2018 13:40:38 +0100 Subject: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL In-Reply-To: <20181214173650.GA9151@mail> References: <68c4a718-d18c-9c3a-e57a-aad691ff0c90@jajcus.net> <20181212150602.GA32143@mail> <39e4791a-fe80-d362-1140-1fb6d719952f@jajcus.net> <20181214150220.GA8832@mail> <20181214173650.GA9151@mail> Message-ID: <20181215124038.GA11216@mail> llvm built successfully for all Th archs. BTW - ouch... 1889870589 llvm-debuginfo-7.0.0-3.x86_64.rpm -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Fri Dec 21 12:10:11 2018 From: glen at pld-linux.org (glen) Date: Fri, 21 Dec 2018 13:10:11 +0200 Subject: ruby unneeded versioning Message-ID: <2a737fb8-26b6-537a-eac3-1e8fe0f554e8@pld-linux.org> somewhy ruby deps provider puts versioning, even if the installed paths are unversioned: ``` ? rpm -qpl /home/users/glen/rpm/packages/RPMS/knife-backup-0.0.12-1.noarch.rpm /usr/share/ruby/vendor_ruby/chef/knife/backup_export.rb /usr/share/ruby/vendor_ruby/chef/knife/backup_restore.rb /usr/share/ruby/vendor_ruby/knife-backup /usr/share/ruby/vendor_ruby/knife-backup.rb /usr/share/ruby/vendor_ruby/knife-backup/version.rb ? rpm -qp --requires /home/users/glen/rpm/packages/RPMS/knife-backup-0.0.12-1.noarch.rpm|grep ruby ruby(abi) = 2.4 ? ``` i fixed this once, why it's back? -- glen From glen at pld-linux.org Thu Dec 27 12:29:51 2018 From: glen at pld-linux.org (glen) Date: Thu, 27 Dec 2018 13:29:51 +0200 Subject: mysql 5.0 openssl 1.1 request Message-ID: please someone (arekm?) add patch to build mysql 5.0 with openssl 1.1. also previous report that mysql 5.3 crashes: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2018-December/025680.html thanks! -- glen From zawadaa at gmail.com Thu Dec 27 17:17:32 2018 From: zawadaa at gmail.com (Andrzej Zawadzki) Date: Thu, 27 Dec 2018 17:17:32 +0100 Subject: [curl] /usr/lib64/libcurl.so.4: undefined symbol: BrotliDecoderVersion Message-ID: Hi, this is happening after upgrading curl to newest version. I had to upgraded libbrotli by myself. -- Andrzej Zawadzki