From adwol at zonk.pl Fri Apr 1 14:06:08 2016 From: adwol at zonk.pl (Adam Osuchowski) Date: Fri, 1 Apr 2016 14:06:08 +0200 Subject: kwin crashes when calibre is spawned Message-ID: <20160401120608.6b8b4567@zonk.pl> Under KDE4 on x86-64, when calibre is started, kwin crashes: Program received signal SIGSEGV, Segmentation fault. XVisualIDFromVisual (visual=0x0) at Misc.c:60 60 return visual->visualid; (gdb) bt #0 XVisualIDFromVisual (visual=0x0) at Misc.c:60 #1 0x00007faa274daca3 in KWin::Client::embedClient (this=this at entry=0x157aa40, w=w at entry=31457284, attr=...) at /usr/src/debug/kde-workspace-4.11.22/kwin/manage.cpp:647 #2 0x00007faa274db7c5 in KWin::Client::manage (this=this at entry=0x157aa40, w=w at entry=31457284, isMapped=isMapped at entry=false) at /usr/src/debug/kde-workspace-4.11.22/kwin/manage.cpp:67 #3 0x00007faa27499f0d in KWin::Workspace::createClient (this=this at entry=0x14c8070, w=31457284, is_mapped=is_mapped at entry=false) at /usr/src/debug/kde-workspace-4.11.22/kwin/workspace.cpp:475 #4 0x00007faa274cc847 in KWin::Workspace::workspaceEvent (this=0x14c8070, e=e at entry=0x7fffd01df0f0) at /usr/src/debug/kde-workspace-4.11.22/kwin/events.cpp:229 #5 0x00007faa274bfbb0 in KWin::Application::x11EventFilter (this=0x7fffd01df4d0, e=0x7fffd01df0f0) at /usr/src/debug/kde-workspace-4.11.22/kwin/main.cpp:422 #6 0x00007faa20627fa6 in ?? () from /usr/lib64/libQtGui.so.4 #7 0x00007faa206387a2 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib64/libQtGui.so.4 #8 0x00007faa20662a57 in ?? () from /usr/lib64/libQtGui.so.4 #9 0x00007faa21486ce1 in QEventLoop::processEvents(QFlags) () from /usr/lib64/libQtCore.so.4 #10 0x00007faa21487055 in QEventLoop::exec(QFlags) () from /usr/lib64/libQtCore.so.4 #11 0x00007faa2148ca1d in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #12 0x00007faa274c096f in kdemain (argc=3, argv=0x7fffd01df628) at /usr/src/debug/kde-workspace-4.11.22/kwin/main.cpp:597 #13 0x00007faa270bf800 in __libc_start_main () from /lib64/libc.so.6 #14 0x00000000004007a9 in _start () at ../sysdeps/x86_64/start.S:118 The issue is recurrent every time. Could anybody confirm it? Is it common PLD problem or is it connected with my environment? From ed at yen.ipipan.waw.pl Fri Apr 1 14:32:35 2016 From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=) Date: Fri, 01 Apr 2016 14:32:35 +0200 Subject: kwin crashes when calibre is spawned In-Reply-To: <20160401120608.6b8b4567@zonk.pl> References: <20160401120608.6b8b4567@zonk.pl> Message-ID: <2431566.Iud0BooQhg@laptok> Dnia pi?tek, 1 kwietnia 2016 14:06:08 Adam Osuchowski pisze: > Under KDE4 on x86-64, when calibre is started, kwin crashes: Seems to work fine for me: $ rpm -q calibre kde4-kdelibs kde4-kdebase-workspace-kwin calibre-2.52.0-1.x86_64 kde4-kdelibs-4.14.18-2.x86_64 kde4-kdebase-workspace-kwin-4.11.22-3.x86_64 -- ?ukasz Ma?ko _o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana" From qboosh at pld-linux.org Mon Apr 4 19:35:02 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 4 Apr 2016 19:35:02 +0200 Subject: pldnotify false-positive: ibus-pinyin? Message-ID: <20160404173502.GA13741@mail> ibus-pinyin [OLD] 1.5.0 [NEW] 1.5.13 I can't find ibus-pinyin later than 1.5.0 (upstream URL is https://github.com/ibus/ibus-pinyin). The "newer" version comes probably from ibus (https://github.com/ibus/ibus - latest version is 1.5.13 currently) Is it possible to fix matching this package? -- Jakub Bogusz http://qboosh.pl/ From glen at delfi.ee Mon Apr 4 22:12:09 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 4 Apr 2016 23:12:09 +0300 Subject: pldnotify false-positive: ibus-pinyin? In-Reply-To: <20160404173502.GA13741@mail> References: <20160404173502.GA13741@mail> Message-ID: <5702CA99.4040109@delfi.ee> On 04.04.2016 20:35, Jakub Bogusz wrote: > ibus-pinyin [OLD] 1.5.0 [NEW] 1.5.13 > > I can't find ibus-pinyin later than 1.5.0 > (upstream URL is https://github.com/ibus/ibus-pinyin). > The "newer" version comes probably from ibus > (https://github.com/ibus/ibus - latest version is 1.5.13 currently) > > Is it possible to fix matching this package? it was mapped incorrectly under 'ibus' https://release-monitoring.org/project/1352/ marked as bogus there, so now the cron will fallback to old awk parser [~/relup/ibus-pinyin(1.5.0) (master)] ? pldnotify.py ibus-pinyin.spec Checking 1 packages [1/1] checking ibus-pinyin.spec ibus-pinyin: 1.5.0 WARNING: skipping anitya: No package "ibus-pinyin" found in distro "pld-linux", Do you need to map "ibus" (https://github.com/ibus/ibus)? [ibus-pinyin.spec] No updates found [~/relup/ibus-pinyin(1.5.0) (master)] ? -- glen From glen at pld-linux.org Thu Apr 7 10:42:02 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 7 Apr 2016 11:42:02 +0300 Subject: [packages/git-lfs] do not get affected from env from rpmbuild runs In-Reply-To: <61923bef92b21e296791467a6257cc41c4d1cfc7_refs_heads_master@pld-linux.org> References: <5b986cd46a17e1b1e39081b41753502a83e116bd_refs_heads_master@pld-linux.org> <61923bef92b21e296791467a6257cc41c4d1cfc7_refs_heads_master@pld-linux.org> Message-ID: <57061D5A.2050409@pld-linux.org> On 07.04.2016 11:23, glen wrote: > commit 61923bef92b21e296791467a6257cc41c4d1cfc7 > Author: Elan Ruusam?e > Date: Thu Apr 7 11:22:49 2016 +0300 > > do not get affected from env from rpmbuild runs > > git-lfs.spec | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > --- > diff --git a/git-lfs.spec b/git-lfs.spec > index 394af7a..0a4493b 100644 > --- a/git-lfs.spec > +++ b/git-lfs.spec > @@ -33,6 +33,7 @@ mkdir -p src/github.com/github > ln -s $(pwd) src/github.com/github/%{name} > > %build > +unset GOROOT where did that support go that all env is cleared except PATH and some whitelisted env vars? the earlier GIT_DIR and GIT_WORK_TREE hacks would not also be needed if that rpmbuild cleanenv thing actually worked. -- glen From groups at sq9mev.info Mon Apr 11 11:14:49 2016 From: groups at sq9mev.info (Bartek Radwan) Date: Mon, 11 Apr 2016 11:14:49 +0200 Subject: bird-1.5.0-1.x86_64 crasches quite often on reconfiguration including renaming BGP protocols due to bad set of CFLAGS passed on compilation In-Reply-To: <56FB7FAC.6070509@sq9mev.info> References: <56EFF5B1.5020007@sq9mev.info> <56F25500.2090303@pld-linux.org> <56F675E5.1050105@sq9mev.info> <56F67656.8000607@sq9mev.info> <20160326120038.GA21432@polanet.pl> <56F684A8.2000000@sq9mev.info> <20160328102144.GA22675@polanet.pl> <56FB7FAC.6070509@sq9mev.info> Message-ID: <570B6B09.3020805@sq9mev.info> On 30.03.2016 09:26, Bartek Radwan wrote: > On 28.03.2016 12:21, Tomasz Pala wrote: > I'll post the group when i find out more. > I'll try to remove -fwrapv. Loadavg is still varied with: - binary 1.5.0 from upstream (ftp://bird.network.cz/pub/bird/redhatbird- 1.5.0-1.x86_64.rpm) - 1.5.0-2 (PLD cflags with addition of -fno-strict-aliasing -fno-strict-overflow) - 1.5.0-3 (just PLD cflags with cherry-picked commits resolving primary segfault issue ) - vanilla 1.5.0 (ftp://bird.network.cz/pub/bird/bird-1.5.0.tar.gz) compiled with upstream cflags) I've tried above aproaches with gcc 4.9.2 (current PLD's 1.5.0-1 is compiled with gcc 4.9.2) and with gcc-5.3.0-2 as well - gcc still varies. Next thing i've found is that level of loadavg peaks is higly realted to scan time bird's kernel protocol. We'were using quite small value of 10s, after increasing to 300s loadavg looks OK. Since bird receives async netlink notifications about new alien routes i'm just wondering if 10 seconds scan time was not too small (however default is 20s, and with 20s peaks are still observable). Next thing i've checkd was comparison of perf samples with perf sample for for some of bird versions with varying loadavg during high and low loadavg periods: http://www.sq9mev.info/unstable_near1_near0_perf.diff.txt I cant recognize any big difference. Then I've compared perf data with PLD 1.5.0-1 (stable loadavg) with 1.5.0-1 provided by upstream: http://www.sq9mev.info/stable_unstable.diff.txt First thing that i've noticed thet there's noticable if_find_by_index (+20%) amount of if_find_by_index ocurrances in "unstable" perf data, while it's not in "stable" perf data. I've got not enough knowledge to investigate any further, but seems to me that the "peaks" may be just normal with lower kernel sync time values. I'll go with this to bird list again. Tomasz or anybody else - do you have any hints or ideas? What about increasing kernel scan time to higher values? -- Regards Bartek From groups at sq9mev.info Mon Apr 11 12:53:29 2016 From: groups at sq9mev.info (Bartek Radwan) Date: Mon, 11 Apr 2016 12:53:29 +0200 Subject: bird-1.5.0-1.x86_64 crasches quite often on reconfiguration including renaming BGP protocols due to bad set of CFLAGS passed on compilation In-Reply-To: <570B6B09.3020805@sq9mev.info> References: <56EFF5B1.5020007@sq9mev.info> <56F25500.2090303@pld-linux.org> <56F675E5.1050105@sq9mev.info> <56F67656.8000607@sq9mev.info> <20160326120038.GA21432@polanet.pl> <56F684A8.2000000@sq9mev.info> <20160328102144.GA22675@polanet.pl> <56FB7FAC.6070509@sq9mev.info> <570B6B09.3020805@sq9mev.info> Message-ID: <570B8229.8090703@sq9mev.info> On 11.04.2016 11:14, Bartek Radwan wrote: > I'll go with this to bird list again. http://trubka.network.cz/pipermail/bird-users/2016-April/010302.html -- Regards Bartek From glen at pld-linux.org Tue Apr 12 07:50:05 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 12 Apr 2016 08:50:05 +0300 Subject: CGRE[1369]: Warning: invalid file format of /proc/12546/status Message-ID: <570C8C8D.4040908@pld-linux.org> any one getting these? Apr 12 08:39:32 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/12546/status Apr 12 08:40:44 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/14369/status Apr 12 08:41:21 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/15352/status Apr 12 08:41:34 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/15689/status Apr 12 08:41:36 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/15755/status Apr 12 08:41:40 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/15842/status Apr 12 08:42:17 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/16827/status Apr 12 08:42:39 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/17460/status Apr 12 08:42:39 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/17465/status Apr 12 08:43:49 rotten-fruit CGRE[1369]: Warning: invalid file format of /proc/19321/status USER PID LXC PGRP STARTED TT VSZ RSS STAT CMD root 1369 - 1369 Sun Apr 3 23:07:20 2016 ? 15768 3592 Ss /sbin/cgrulesengd -s -g cgred -v # rpm -qf /sbin/cgrulesengd libcgroup-0.41-4.x86_64 and by the time i go check these pids do not even exist it complains about. -- glen From glen at pld-linux.org Tue Apr 12 15:32:20 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 12 Apr 2016 16:32:20 +0300 Subject: git notes In-Reply-To: <56F1AFDE.4090603@pld-linux.org> References: <56F06B8D.10206@pld-linux.org> <20160322164257.GA4856@mail> <56F1AFDE.4090603@pld-linux.org> Message-ID: <570CF8E4.1070802@pld-linux.org> On 22.03.2016 22:49, Elan Ruusam?e wrote: > On 22.03.2016 18:42, Jakub Bogusz wrote: >> On Mon, Mar 21, 2016 at 11:45:49PM +0200, Elan Ruusam?e wrote: >>> i added git note to some commit >>> but it appears not to be pushed out with just 'git push'. should it? >> Notes are not pushed by default, one can do >> $ git push origin refs/notes/commits >> (or so) >> > > so, as builder -a will setup fetch refs, why not setup similarily push > refs? > > in the blog they say refs aren't very good when multiple authorities > maintain them > https://git-scm.com/blog/2010/08/25/notes.html > > or the push note refs aren't just setup because it's just not done? so i tried to add: git config --local --add "remote.$REMOTE_PLD.push" 'refs/notes/*:refs/notes/*' which results: [remote "origin"] url = git://git.pld-linux.org/packages/owncloudclient.git fetch = +refs/heads/*:refs/remotes/origin/* fetch = refs/notes/*:refs/notes/* push = refs/notes/*:refs/notes/* pushurl = ssh://git at git.pld-linux.org/packages/owncloudclient but now `git push` does nothing, as it's configured to push only notes, how to make it behave like before? push = +refs/heads/*:refs/remotes/origin/* or: push = refs/heads/*:refs/remotes/origin/* as i'm afraid this config would make it push all branches, not just current branch... -- glen From glen at pld-linux.org Thu Apr 14 14:50:27 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 14 Apr 2016 15:50:27 +0300 Subject: rescue Message-ID: <570F9213.6050604@pld-linux.org> https://github.com/Jajcus/pld-new-rescue/releases can we get rescue images for 2015 and 2016 snaps? -- glen From jajcus at jajcus.net Thu Apr 14 15:15:04 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Thu, 14 Apr 2016 15:15:04 +0200 Subject: rescue In-Reply-To: <570F9213.6050604@pld-linux.org> References: <570F9213.6050604@pld-linux.org> Message-ID: <570F97D8.3080409@jajcus.net> On 2016-04-14 14:50, Elan Ruusam?e wrote: > https://github.com/Jajcus/pld-new-rescue/releases > > can we get rescue images for 2015 and 2016 snaps? Yes, when I finally manage to do that. Maybe this weekend? Jacek From qboosh at pld-linux.org Thu Apr 14 18:33:13 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 14 Apr 2016 18:33:13 +0200 Subject: [packages/usbutils] - updated to 008 In-Reply-To: <0a4a3ec8dd35920f1f307310ca1a47c8079ee84b_refs_heads_master@pld-linux.org> References: <0a4a3ec8dd35920f1f307310ca1a47c8079ee84b_refs_heads_master@pld-linux.org> Message-ID: <20160414163313.GA14397@mail> It was on "udev" branch - please note, that in this version C implementation of lsusb no longer supports usb.ids and requires udev for device detection/recognition (it's useless without udev-core installed and run). Only Python implementation (lsusb.py) uses uds.ids. On Thu, Apr 14, 2016 at 02:17:21PM +0200, hawk wrote: > commit 0a4a3ec8dd35920f1f307310ca1a47c8079ee84b > Author: Marcin Krol > Date: Thu Apr 14 12:16:34 2016 +0000 > > - updated to 008 > > usbutils.spec | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > --- > diff --git a/usbutils.spec b/usbutils.spec > index 21a1885..a552705 100644 > --- a/usbutils.spec > +++ b/usbutils.spec > @@ -6,12 +6,12 @@ Summary: Linux USB utilities > Summary(pl.UTF-8): Linuksowe narz?dzia do USB > Summary(pt_BR.UTF-8): Utilit?rios Linux USB > Name: usbutils > -Version: 007 > -Release: 2 > +Version: 008 > +Release: 1 > License: GPL v2+ > Group: Applications/System > Source0: http://www.kernel.org/pub/linux/utils/usb/usbutils/%{name}-%{version}.tar.xz > -# Source0-md5: c9df5107ae9d26b10a1736a261250139 > +# Source0-md5: 2780b6ae21264c888f8f30fb2aab1259 > Patch0: hwdata.patch > URL: http://www.linux-usb.org/ > BuildRequires: autoconf >= 2.60 > @@ -55,7 +55,6 @@ if [ usb.ids -nt %{hwdatadir}/usb.ids ]; then > exit 1 > fi > %endif > -%{__rm} usb.ids > > %build > %{__libtoolize} -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Fri Apr 15 22:26:57 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 15 Apr 2016 23:26:57 +0300 Subject: cron no logrotate! Message-ID: <57114E91.8030408@pld-linux.org> ... 13:libusbmuxd ########################################### [ 29%] 14:cups-image-lib ########################################### [ 31%] 15:cups-clients ########################################### [ 33%] 16:cronie ########################################### [ 36%] 17:curl-libs ########################################### [ 38%] 18:c-ares-devel ########################################### [ 40%] 19:syslog-ng warning: /etc/syslog-ng/syslog-ng.conf created as /etc/syslog-ng/syslog-ng.conf.rpmnew ########################################### [ 42%] 20:cyrus-sasl ########################################### [ 44%] 21:cloog-ppl ########################################### [ 47%] 22:libimobiledevice ########################################### [ 49%] 23:cups warning: /etc/cups/cupsd.conf created as /etc/cups/cupsd.conf.rpmnew ########################################### [ 51%] warning: /etc/logrotate.d/cron saved as /etc/logrotate.d/cron.rpmsave 24:cmake ########################################### [ 53%] 25:curl ########################################### [ 56%] ... and as a result, no cron logs rotation! [root at blodnatt mail]# l /etc/logrotate.d/cron /etc/logrotate.d/cron.rpmsave ls: cannot access '/etc/logrotate.d/cron': No such file or directory -rw-r----- 1 root root 158 mai 5 2010 /etc/logrotate.d/cron.rpmsave [root at blodnatt mail]# [root at blodnatt mail]# cat /etc/logrotate.d/cron.rpmsave /var/log/cron { create 660 root crontab postrotate /sbin/service crond flush-logs >/dev/null /sbin/service syslog-ng flush-logs >/dev/null endscript } [root at blodnatt mail]# rpm -qf /etc/logrotate.d/cron file /etc/logrotate.d/cron: No such file or directory [root at blodnatt mail]# it was addressed directly to bartek, and via mailing list http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2015-November/024534.html but seems still not resolved? -- glen From jajcus at jajcus.net Sat Apr 16 14:14:12 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sat, 16 Apr 2016 14:14:12 +0200 Subject: PLD New Rescue th2015-1.5 Message-ID: <57122C94.4000301@jajcus.net> I have just built PLD New Rescue based on the th-2015 snapshot: https://github.com/Jajcus/pld-new-rescue/releases/tag/th2015-1.5 Please do test it in any way you need to use this. I have done only some very basic testing. Jacek From baggins at pld-linux.org Sun Apr 17 13:23:07 2016 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 17 Apr 2016 13:23:07 +0200 Subject: ftp updates (Xen 4.6, ruby 2.1, packages removals) Message-ID: <20160417112307.GC8556@home> Hi, I just moved ~700 packages from test to ready, among them: - Xen 4.6.1 - please test, this version removes xend - ruby 2.1 - ffmpeg 3.0 and almost all dependant packages On a related note, the following packages will be removed soon: - cinelerra-cv - CV is dead, unmaintained project - mpeg4ip - dead project, no upstream updates for 9 years If you really want to keep those, be prepared to maintain them, as every time their deps change fixing them is a RPITA. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From baggins at pld-linux.org Sun Apr 17 15:44:09 2016 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 17 Apr 2016 15:44:09 +0200 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> Message-ID: <20160417134409.GF8556@home> I removed it from ftp and downgraded on builders, building gnome-initial-setup or jbig2dec causes rpm to hang indefinitely on "processing files" step. On Sun, 17 Apr 2016, baggins wrote: > commit 0659b65444a1849eef8a951b4083d3e148712499 > Author: Jan R?korajski > Date: Sun Apr 17 15:39:10 2016 +0200 > > - this version breaks rpmbuild, good testcase is gnome-initial-setup package > - rel 1.1 > > file.spec | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > --- > diff --git a/file.spec b/file.spec > index fd2a19f..2caa5d2 100644 > --- a/file.spec > +++ b/file.spec > @@ -30,7 +30,7 @@ Summary(zh_CN.UTF-8): ?????????? > Summary(zh_TW.UTF-8): ???????????????? > Name: file > Version: 5.26 > -Release: 1 > +Release: 1.1 > License: distributable > Group: Applications/File > Source0: ftp://ftp.astron.com/pub/file/%{name}-%{version}.tar.gz > ================================================================ > > ---- gitweb: > > http://git.pld-linux.org/gitweb.cgi/packages/file.git/commitdiff/0659b65444a1849eef8a951b4083d3e148712499 > > _______________________________________________ > pld-cvs-commit mailing list > pld-cvs-commit at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From gotar at polanet.pl Sun Apr 17 15:57:13 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 17 Apr 2016 15:57:13 +0200 Subject: ftp updates (Xen 4.6, ruby 2.1, packages removals) In-Reply-To: <20160417112307.GC8556@home> References: <20160417112307.GC8556@home> Message-ID: <20160417135713.GA3757@polanet.pl> On Sun, Apr 17, 2016 at 13:23:07 +0200, Jan R?korajski wrote: > On a related note, the following packages will be removed soon: > > - cinelerra-cv - CV is dead, unmaintained project https://cinelerra-cv.org/ https://cinelerra-cv.org/about.php January 19, 2016 New Cinelerra-HV release by Adam Williams September 5, 2015 Cinelerra-CV release 2.3 So there is some decent mess around, but if anyone is interested there ARE maintainers of several versions... > - mpeg4ip - dead project, no upstream updates for 9 years https://sourceforge.net/projects/mpeg4ip-ng/ -- Tomasz Pala From bszx-pld at bszx.eu Sun Apr 17 20:40:45 2016 From: bszx-pld at bszx.eu (Bartek Szady) Date: Sun, 17 Apr 2016 20:40:45 +0200 Subject: cron no logrotate! In-Reply-To: <57114E91.8030408@pld-linux.org> References: <57114E91.8030408@pld-linux.org> Message-ID: <5713D8AD.6050600@bszx.eu> On 04/15/16 22:26, Elan Ruusam?e wrote: > > > > ... > 13:libusbmuxd ########################################### [ 29%] > 14:cups-image-lib ########################################### [ 31%] > 15:cups-clients ########################################### [ 33%] > 16:cronie ########################################### [ 36%] > 17:curl-libs ########################################### [ 38%] > 18:c-ares-devel ########################################### [ 40%] > 19:syslog-ng warning: /etc/syslog-ng/syslog-ng.conf > created as /etc/syslog-ng/syslog-ng.conf.rpmnew > ########################################### [ 42%] > 20:cyrus-sasl ########################################### [ 44%] > 21:cloog-ppl ########################################### [ 47%] > 22:libimobiledevice ########################################### [ 49%] > 23:cups warning: /etc/cups/cupsd.conf created as > /etc/cups/cupsd.conf.rpmnew > ########################################### [ 51%] > warning: /etc/logrotate.d/cron saved as /etc/logrotate.d/cron.rpmsave > 24:cmake ########################################### [ 53%] > 25:curl ########################################### [ 56%] > ... > > > and as a result, no cron logs rotation! Please, show the result of cat /etc/logrotate.d/syslog-ng Bartek From glen at pld-linux.org Sun Apr 17 23:07:09 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 00:07:09 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <20160417134409.GF8556@home> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> Message-ID: <5713FAFD.7030004@pld-linux.org> seems it's not related to specific packages, all packages fail packaging and just aborts with unclear error message. On 17.04.2016 16:44, Jan R?korajski wrote: > I removed it from ftp and downgraded on builders, building > gnome-initial-setup or jbig2dec causes rpm to hang indefinitely on > "processing files" step. > > On Sun, 17 Apr 2016, baggins wrote: > >> commit 0659b65444a1849eef8a951b4083d3e148712499 >> Author: Jan R?korajski >> Date: Sun Apr 17 15:39:10 2016 +0200 >> >> - this version breaks rpmbuild, good testcase is gnome-initial-setup package >> - rel 1.1 >> >> file.spec | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> --- >> diff --git a/file.spec b/file.spec >> index fd2a19f..2caa5d2 100644 >> --- a/file.spec >> +++ b/file.spec >> @@ -30,7 +30,7 @@ Summary(zh_CN.UTF-8): ?????????? >> Summary(zh_TW.UTF-8): ???????????????? >> Name: file >> Version: 5.26 >> -Release: 1 >> +Release: 1.1 -- glen From glen at delfi.ee Sun Apr 17 23:08:56 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 00:08:56 +0300 Subject: cron no logrotate! In-Reply-To: <5713D8AD.6050600@bszx.eu> References: <57114E91.8030408@pld-linux.org> <5713D8AD.6050600@bszx.eu> Message-ID: <5713FB68.6010903@delfi.ee> On 17.04.2016 21:40, Bartek Szady wrote: > > Please, show the result of cat /etc/logrotate.d/syslog-ng oh, it's there. no worries! [root at blodnatt apache]# grep cron /etc/logrotate.d/syslog-ng /var/log/cron [root at blodnatt apache]# -- glen From n3npq at mac.com Mon Apr 18 10:06:32 2016 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Apr 2016 04:06:32 -0400 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <20160417134409.GF8556@home> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> Message-ID: <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> On Apr 17, 2016, at 9:44 AM, Jan R?korajski wrote: > I removed it from ftp and downgraded on builders, building > gnome-initial-setup or jbig2dec causes rpm to hang indefinitely on > "processing files" step. > The coupling between rpmbuild <-> file is through /etc/magic rules (whatever path is used these days) and libmagic. One way to break the coupling is to put a minimalistic/deterministic copy of magic in /usr/lib/rpm/magic and reconfigure the macro used to find the magic file path. Since identifier strings from /etc/magic end up in *.rpm headers, and invokes helper scripts based on magic keywords, there are other "reproducible build" reasons to internalize a minimalistic/deterministic portable version of /etc/magic. Should rpm catty a copy of magic in /usr/lib/rpm/magic? 73 de Jeff From glen at pld-linux.org Mon Apr 18 10:52:48 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 11:52:48 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> Message-ID: <5714A060.8050902@pld-linux.org> On 18.04.2016 11:06, Jeff Johnson wrote: > On Apr 17, 2016, at 9:44 AM, Jan R?korajski wrote: > >> I removed it from ftp and downgraded on builders, building >> gnome-initial-setup or jbig2dec causes rpm to hang indefinitely on >> "processing files" step. >> > The coupling between rpmbuild <-> file is through /etc/magic rules > (whatever path is used these days) and libmagic. > > One way to break the coupling is to put a minimalistic/deterministic > copy of magic in /usr/lib/rpm/magic and reconfigure the macro used > to find the magic file path. > > Since identifier strings from /etc/magic end up in *.rpm headers, > and invokes helper scripts based on magic keywords, > there are other "reproducible build" reasons to internalize a > minimalistic/deterministic portable version of /etc/magic. > > Should rpm catty a copy of magic in /usr/lib/rpm/magic? pld rpm links with system libmagic, not using bundled version. i think this is something broken on library level. should try build file 5.26 and rebuild rpm with that version, it could help. -- glen From n3npq at mac.com Mon Apr 18 11:04:17 2016 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Apr 2016 05:04:17 -0400 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <5714A060.8050902@pld-linux.org> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> <5714A060.8050902@pld-linux.org> Message-ID: <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> On Apr 18, 2016, at 4:52 AM, Elan Ruusam?e wrote: > > pld rpm links with system libmagic, not using bundled version. i think this is something broken on library level. > Perhaps the libmagic code is broken, yes. Usually the issue is new definitions, which are increasingly using *RE patterns. If so, then using a known good version of /usr/share/misc/../file/magic might help. Meanwhile, rpm has the undocumented --rpmmgdebug which should display how rpm rpmbuild is using libmagic. hth 73 de Jeff From glen at pld-linux.org Mon Apr 18 12:04:47 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 13:04:47 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <5714A060.8050902@pld-linux.org> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> <5714A060.8050902@pld-linux.org> Message-ID: <5714B13F.6050108@pld-linux.org> On 18.04.2016 11:52, Elan Ruusam?e wrote: > > should try build file 5.26 and rebuild rpm with that version, it could > help. eh. this is rather impossible task, as having file 5.26 installed and producing rpm package will also fail -- glen From glen at pld-linux.org Mon Apr 18 18:10:57 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 19:10:57 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> <5714A060.8050902@pld-linux.org> <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> Message-ID: <57150711.4070905@pld-linux.org> On 18.04.2016 12:04, Jeff Johnson wrote: > Perhaps the libmagic code is broken, yes. here's process "stopped" with following output (will post complete outputs in separate post): build-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmbuild.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmbuild.so) symbolic link to librpmbuild-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmconstant-5.4.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmconstant-5.4.so) symbolic link to /lib64/librpmconstant-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmconstant.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmconstant.so) symbolic link to librpmconstant-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmdb-5.4.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmdb-5.4.so) symbolic link to /lib64/librpmdb-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmdb.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmdb.so) symbolic link to librpmdb-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmio-5.4.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmio-5.4.so) symbolic link to /lib64/librpmio-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmio.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmio.so) symbolic link to librpmio-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmmisc-5.4.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmmisc-5.4.so) symbolic link to /lib64/librpmmisc-5.4.so --> rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmmisc.so) <-- rpmmgFile(0x25e7000, /home/users/glen/tmp/rpm-5.4.15-root-glen/usr/lib64/librpmmisc.so) symbolic link to librpmmisc-5.4.so --> mg 0x25e7000 -- 1 rpmfcClassify at rpmfc.c:1510 from different terminal stracing the rpmbuild process: select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}) = 0 (Timeout) read(4, 0x7ffd47808c00, 8192) = -1 EAGAIN (Resource temporarily unavailable) select(4, [], [], NULL, {0, 10000}^Cstrace: Process 224753 detached lsof shows fd4 being: rpmbuild 224753 glen 4r FIFO 0,10 0t0 79112236 pipe which leads to believe it's subprocess pipe? from ps shows it goes to libtooldeps.sh: glen 224753 0.7 0.0 200520 13828 pts/1 S+ 19:06 0:01 \_ /usr/bin/rpmbuild --target x86_64 --short-circuit --define _specdir /home/users/glen/rpm/packages/rpm --define _sourcedir /home/users/glen/rpm/packages/rpm --define clean %%%{!?__ldconfig:clean}%{?__ldconfig:check} \ ??exit 0%{nil} --define check %%check \ ??exit 0%{nil} --define _source_payload w5.gzdio --define _binary_payload w5.gzdio --define __spec_install_pre %___build_pre --define __spec_clean_body %{nil} --define _enable_debug_packages 0 -bb rpm.spec --without doc --without apidocs --rpmmgdebug glen 224811 98.2 0.0 4452 768 pts/1 R+ 19:06 2:32 \_ /bin/sh /usr/lib/rpm/libtooldeps.sh --provides /home/users/glen/tmp/rpm-5.4.15-root-glen rpm-devel from strace of libtooldeps process, i see: read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad file descriptor) read(0, 0x808808, 1) = -1 EBADF (Bad fi^C0x808808, 1) = -1 EBADF (Bad file descriptor) strace: Process 224811 detached -- glen From glen at pld-linux.org Mon Apr 18 18:16:30 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 19:16:30 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <57150711.4070905@pld-linux.org> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> <5714A060.8050902@pld-linux.org> <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> <57150711.4070905@pld-linux.org> Message-ID: <5715085E.7060203@pld-linux.org> On 18.04.2016 19:10, Elan Ruusam?e wrote: > On 18.04.2016 12:04, Jeff Johnson wrote: >> Perhaps the libmagic code is broken, yes. > here's process "stopped" with following output (will post complete > outputs in separate post): weird if i run rpmbuild --short-circuit -bi then it stalls: http://carme.pld-linux.org/~glen/file-5.26-bi.log but if i run with --short-circuit -bb, it is able to finish: http://carme.pld-linux.org/~glen/file-5.26-bb.log but from previous post, seems the "lockup" problem being that libtooldeps expect input from stdin, but rpm side it was already closed? -- glen From glen at pld-linux.org Mon Apr 18 18:25:49 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 19:25:49 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> <5714A060.8050902@pld-linux.org> <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> Message-ID: <57150A8D.5050103@pld-linux.org> On 18.04.2016 12:04, Jeff Johnson wrote: > Perhaps the libmagic code is broken, yes. Usually the issue is new definitions, which > are increasingly using *RE patterns. If so, then using a known good version of > /usr/share/misc/../file/magic > might help. i installed file 5.26 replacing magic files from 5.25, it's still broken, so i don't think magic definitions are at fault. -- glen From glen at pld-linux.org Mon Apr 18 18:35:11 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 19:35:11 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <5715085E.7060203@pld-linux.org> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> <5714A060.8050902@pld-linux.org> <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> <57150711.4070905@pld-linux.org> <5715085E.7060203@pld-linux.org> Message-ID: <57150CBF.7070000@pld-linux.org> On 18.04.2016 19:16, Elan Ruusam?e wrote: > but from previous post, seems the "lockup" problem being that > libtooldeps expect input from stdin, but rpm side it was already closed? added "set -x" to libtooldeps script: --- Processing files: libmagic-devel-5.26-1.2.x86_64 + '[' 3 -ge 2 ']' + pkgname=libmagic-devel + shift + RPM_BUILD_ROOT=/home/users/glen/tmp/file-5.26-root-glen + read possible --- so, rpm invokes the helper but prints nothing there i replaced libtool scripts interpreter /bin/sh -> /bin/bash, seems bash handles io error better and reports error: Processing files: libmagic-devel-5.26-1.2.x86_64 + '[' 3 -ge 2 ']' + pkgname=libmagic-devel + case $1 in + shift + RPM_BUILD_ROOT=/home/users/glen/tmp/file-5.26-root-glen + read possible /home/users/glen/libtooldeps.sh: line 16: read: read error: 0: Bad file descriptor + exit 0 + '[' 3 -ge 2 ']' + pkgname=libmagic-devel + case $1 in + case $pkgname in + read possible /home/users/glen/libtooldeps.sh: line 31: read: read error: 0: Bad file descriptor + exit 0 Processing files: libmagic-static-5.26-1.2.x86_64 file(1) itself seems to process okay: [~/rpm/packages/file(5.26) (master)?] ? file /home/users/glen/tmp/file-5.26-root-glen/usr/lib64/libmagic.la; echo $? /home/users/glen/tmp/file-5.26-root-glen/usr/lib64/libmagic.la: libtool library file, ASCII text 0 [~/rpm/packages/file(5.26) (master)?] ? the io error happens for python deps as well: Processing files: python-magic-5.26-1.2.x86_64 skipping /usr/share/doc/python-magic-5.26 requires detection Traceback (most recent call last): File "/usr/lib/rpm/pythoneggs.py", line 84, in files = stdin.readlines() IOError: [Errno 9] Bad file descriptor Traceback (most recent call last): File "/usr/lib/rpm/pythoneggs.py", line 84, in files = stdin.readlines() IOError: [Errno 9] Bad file descriptor Traceback (most recent call last): File "/usr/lib/rpm/pythoneggs.py", line 84, in files = stdin.readlines() IOError: [Errno 9] Bad file descriptor Traceback (most recent call last): File "/usr/lib/rpm/pythoneggs.py", line 84, in files = stdin.readlines() IOError: [Errno 9] Bad file descriptor Processing files: python3-magic-5.26-1.2.x86_64 skipping /usr/share/doc/python3-magic-5.26 requires detection Traceback (most recent call last): File "/usr/lib/rpm/pythoneggs.py", line 84, in files = stdin.readlines() IOError: [Errno 9] Bad file descriptor Traceback (most recent call last): File "/usr/lib/rpm/pythoneggs.py", line 84, in files = stdin.readlines() IOError: [Errno 9] Bad file descriptor ^CTraceback (most recent call last): File "/usr/lib/rpm/pythoneggs.py", line 15, in from pkg_resources import Distribution, FileMetadata, PathMetadata -- glen From glen at pld-linux.org Mon Apr 18 18:48:01 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 19:48:01 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <57150CBF.7070000@pld-linux.org> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> <5714A060.8050902@pld-linux.org> <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> <57150711.4070905@pld-linux.org> <5715085E.7060203@pld-linux.org> <57150CBF.7070000@pld-linux.org> Message-ID: <57150FC1.80309@pld-linux.org> On 18.04.2016 19:35, Elan Ruusam?e wrote: > i replaced libtool scripts interpreter /bin/sh -> /bin/bash, seems > bash handles io error better and reports error: > > > Processing files: libmagic-devel-5.26-1.2.x86_64 > + '[' 3 -ge 2 ']' > + pkgname=libmagic-devel > + case $1 in > + shift > + RPM_BUILD_ROOT=/home/users/glen/tmp/file-5.26-root-glen > + read possible > /home/users/glen/libtooldeps.sh: line 16: read: read error: 0: Bad > file descriptor > + exit 0 > + '[' 3 -ge 2 ']' found the faulty commit, seems file closes STDIN, doh from commit message, he seems to think file opened the STDIN! https://github.com/file/file/commit/c8581da4c79cfc3fe52bb6c398497ff3a9986abd however that is not the only problem, next problem is the magic file definition problem, which is very typical for file releases: [~/rpm/packages/file(5.26) (master)?] ? file /home/users/glen/tmp/file-5.26-root-glen/usr/share/python3.5/site-packages/file_magic-0.3.0-py3.5.egg-info/top_level.txt /home/users/glen/tmp/file-5.26-root-glen/usr/share/python3.5/site-packages/file_magic-0.3.0-py3.5.egg-info/top_level.txt: ERROR: Offset out of range [~/rpm/packages/file(5.26) (master)?] ? echo $? 1 -- glen From glen at pld-linux.org Mon Apr 18 20:05:18 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 18 Apr 2016 21:05:18 +0300 Subject: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1 In-Reply-To: <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> References: <55e86be4e478a55e7113686c2275fa8a9fe611ed_refs_heads_master@pld-linux.org> <0659b65444a1849eef8a951b4083d3e148712499_refs_heads_master@pld-linux.org> <20160417134409.GF8556@home> <3BE65DAE-8A1D-4162-BE95-7D214C525C3D@mac.com> <5714A060.8050902@pld-linux.org> <261BD5C0-0B57-47F6-A68D-716878331929@mac.com> Message-ID: <571521DE.8040607@pld-linux.org> On 18.04.2016 12:04, Jeff Johnson wrote: > On Apr 18, 2016, at 4:52 AM, Elan Ruusam?e wrote: > >> pld rpm links with system libmagic, not using bundled version. i think this is something broken on library level. >> > Perhaps the libmagic code is broken, yes. Usually the issue is new definitions, which > are increasingly using *RE patterns. If so, then using a known good version of > /usr/share/misc/../file/magic > might help. > > Meanwhile, rpm has the undocumented --rpmmgdebug which should > display how rpm rpmbuild is using libmagic. > jeff, are you willing to describe or provide him testcase? http://mx.gw.com/pipermail/file/2016/001960.html -- glen From gzohop at gmail.com Tue Apr 19 15:59:01 2016 From: gzohop at gmail.com (Grzesiek Pycia) Date: Tue, 19 Apr 2016 15:59:01 +0200 Subject: PLD New Rescue th2015-1.5 In-Reply-To: <57122C94.4000301@jajcus.net> References: <57122C94.4000301@jajcus.net> Message-ID: Works fine for me, both 32&64bit. Under qemu/kvm it does not power off machine, but version th-2014 stops on "System halted" to. 2016-04-16 14:14 GMT+02:00 Jacek Konieczny : > I have just built PLD New Rescue based on the th-2015 snapshot: > > https://github.com/Jajcus/pld-new-rescue/releases/tag/th2015-1.5 > > Please do test it in any way you need to use this. I have done only some > very basic testing. > > Jacek > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > From glen at pld-linux.org Tue Apr 19 22:59:43 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 19 Apr 2016 23:59:43 +0300 Subject: rpm loses %configs Message-ID: <57169C3F.2070403@pld-linux.org> i'm pretty sure this has happened before, just did not payed attention so, if i use --nodeps rpm forgets it has to put .rpmnew? and instead no config files left on the original path (mv -i would had said that file is there) there are no %file %config changes between the versions in the transaction don't want to re-test this, but seems like it wintersunset / # poldek -s /home/glen/rpm/pld/packages/RPMS/ -u eventum Loading [dir]/home/glen/rpm/RPMS/pld/... 14 packages read Processing dependencies... eventum-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-3.0.12-1.noarch greedy upgrade eventum-irc-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-irc-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-irc-3.0.12-1.noarch greedy upgrade eventum-mail-download-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-mail-download-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-mail-download-3.0.12-1.noarch greedy upgrade eventum-mail-queue-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-mail-queue-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-mail-queue-3.0.12-1.noarch greedy upgrade eventum-monitor-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-monitor-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-monitor-3.0.12-1.noarch greedy upgrade eventum-reminder-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-reminder-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-reminder-3.0.12-1.noarch greedy upgrade eventum-router-postfix-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-router-postfix-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-router-postfix-3.0.12-1.noarch greedy upgrade eventum-setup-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-setup-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-setup-3.0.12-1.noarch There are 8 packages to install (7 marked by dependencies), 8 to remove: I eventum-3.0.12-1.noarch D eventum-irc-3.0.12-1.noarch eventum-mail-download-3.0.12-1.noarch eventum-mail-queue-3.0.12-1.noarch D eventum-monitor-3.0.12-1.noarch eventum-reminder-3.0.12-1.noarch eventum-router-postfix-3.0.12-1.noarch D eventum-setup-3.0.12-1.noarch R eventum-3.0.10-1.88.g58096f4.1.9.noarch eventum-irc-3.0.10-1.88.g58096f4.1.9.noarch R eventum-mail-download-3.0.10-1.88.g58096f4.1.9.noarch eventum-mail-queue-3.0.10-1.88.g58096f4.1.9.noarch R eventum-monitor-3.0.10-1.88.g58096f4.1.9.noarch eventum-reminder-3.0.10-1.88.g58096f4.1.9.noarch R eventum-router-postfix-3.0.10-1.88.g58096f4.1.9.noarch eventum-setup-3.0.10-1.88.g58096f4.1.9.noarch This operation will use 4.4KB of disk space. Need to get 1.3MB of archives. Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0... error: Failed dependencies: eventum >= 3.1 is needed by (installed) eventum-workflow-3.1-0.4.noarch wintersunset / # poldek -s /home/glen/rpm/pld/packages/RPMS/ -u eventum --nodeps Loading [dir]/home/glen/rpm/RPMS/pld/... 14 packages read Processing dependencies... eventum-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-3.0.12-1.noarch greedy upgrade eventum-irc-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-irc-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-irc-3.0.12-1.noarch greedy upgrade eventum-mail-download-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-mail-download-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-mail-download-3.0.12-1.noarch greedy upgrade eventum-mail-queue-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-mail-queue-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-mail-queue-3.0.12-1.noarch greedy upgrade eventum-monitor-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-monitor-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-monitor-3.0.12-1.noarch greedy upgrade eventum-reminder-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-reminder-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-reminder-3.0.12-1.noarch greedy upgrade eventum-router-postfix-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-router-postfix-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-router-postfix-3.0.12-1.noarch greedy upgrade eventum-setup-3.0.10-1.88.g58096f4.1.9.noarch to 3.0.12-1.noarch (unresolved eventum = 3.0.10-1.88.g58096f4.1.9) eventum-setup-3.0.10-1.88.g58096f4.1.9.noarch obsoleted by eventum-setup-3.0.12-1.noarch There are 8 packages to install (7 marked by dependencies), 8 to remove: I eventum-3.0.12-1.noarch D eventum-irc-3.0.12-1.noarch eventum-mail-download-3.0.12-1.noarch eventum-mail-queue-3.0.12-1.noarch D eventum-monitor-3.0.12-1.noarch eventum-reminder-3.0.12-1.noarch eventum-router-postfix-3.0.12-1.noarch D eventum-setup-3.0.12-1.noarch R eventum-3.0.10-1.88.g58096f4.1.9.noarch eventum-irc-3.0.10-1.88.g58096f4.1.9.noarch R eventum-mail-download-3.0.10-1.88.g58096f4.1.9.noarch eventum-mail-queue-3.0.10-1.88.g58096f4.1.9.noarch R eventum-monitor-3.0.10-1.88.g58096f4.1.9.noarch eventum-reminder-3.0.10-1.88.g58096f4.1.9.noarch R eventum-router-postfix-3.0.10-1.88.g58096f4.1.9.noarch eventum-setup-3.0.10-1.88.g58096f4.1.9.noarch This operation will use 4.4KB of disk space. Need to get 1.3MB of archives. Executing pm-command.sh --upgrade -vh --nodeps --root / --define _check_dirname_deps 0... Preparing... ########################################### [100%] Repackaging... 1:eventum-setup ########################################### [ 13%] 2:eventum-router-postfix ########################################### [ 25%] 3:eventum-reminder ########################################### [ 38%] 4:eventum-monitor ########################################### [ 50%] 5:eventum-mail-queue ########################################### [ 63%] 6:eventum-mail-download ########################################### [ 75%] 7:eventum-irc ########################################################################################### 7:eventum ########################################### [ 88%] Upgrading... 1:eventum ########################################### [ 13%] * Applying patch: 52 (52_support_to_null.sql) * Your database is now up-to-date. Version 52 Stopping Apache 1.3 Web Server service.............................[ DONE ] Stopping Apache Lingerd service....................................[ DONE ] Starting Apache Lingerd service....................................[ DONE ] Starting Apache 1.3 Web Server service.............................[ DONE ] Reloading Apache 1.3 Web Server service............................[ DONE ] Checking Lighttpd Web Server configuration.........................[ DONE ] WARNING: found deprecated 'url.rewrite-final', convert to 'url.rewrite-final' recommented, See http://redmine.lighttpd.net/issues/2379 Syntax OK Reloading Lighttpd Web Server service..............................[ DONE ] warning: /etc/cron.d/eventum-reminder saved as /etc/cron.d/eventum-reminder.rpmsave warning: /etc/cron.d/eventum-monitor saved as /etc/cron.d/eventum-monitor.rpmsave warning: /etc/cron.d/eventum-mail-queue saved as /etc/cron.d/eventum-mail-queue.rpmsave Stopping Eventum IRC Bot service...................................No process in pidfile `/var/run/eventum/irc_bot.pid' found running; none killed. [ DONE ] warning: /etc/webapps/eventum/irc_config.php saved as /etc/webapps/eventum/irc_config.php.rpmsave 2:eventum-irc ########################################### [ 25%] Run "/sbin/service eventum-irc start" to start Eventum IRC Bot. 3:eventum-mail-download ########################################### [ 38%] 4:eventum-mail-queue ########################################### [ 50%] 5:eventum-monitor ########################################### [ 63%] 6:eventum-reminder ########################################### [ 75%] 7:eventum-router-postfix ########################################### [ 88%] 8:eventum-setup ########################################### [100%] [master 2048fd1] committing changes in /etc after poldek run 5 files changed, 120 deletions(-) delete mode 100644 cron.d/eventum-mail-queue delete mode 100644 cron.d/eventum-monitor delete mode 100644 cron.d/eventum-reminder delete mode 100644 webapps/eventum/irc_config.php wintersunset / # rpm -qf /etc/cron.d/eventum-reminder eventum-reminder-3.0.12-1.noarch wintersunset / # mv -bi /etc/cron.d/eventum-reminder.rpmsave /etc/cron.d/eventum-reminder wintersunset / # mv -bi /etc/cron.d/eventum-monitor.rpmsave /etc/cron.d/eventum-monitor wintersunset / # mv -bi /etc/cron.d/eventum-mail-queue.rpmsave /etc/cron.d/eventum-mail-queue wintersunset / # rpm -qf /etc/webapps/eventum/irc_config.php eventum-irc-3.0.12-1.noarch wintersunset / # mv -bi /etc/webapps/eventum/irc_config.php.rpmsave /etc/webapps/eventum/irc_config.php -- glen From n3npq at mac.com Wed Apr 20 10:09:03 2016 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 20 Apr 2016 04:09:03 -0400 Subject: rpm loses %configs In-Reply-To: <57169C3F.2070403@pld-linux.org> References: <57169C3F.2070403@pld-linux.org> Message-ID: <4A1089D7-3FF5-442E-B4CF-9AC0BCACB828@mac.com> On Apr 19, 2016, at 4:59 PM, Elan Ruusam?e wrote: > i'm pretty sure this has happened before, just did not payed attention > I believe you. Meanwhile ... > so, if i use --nodeps rpm forgets it has to put .rpmnew? > and instead no config files left on the original path (mv -i would had said that file is there) > RPM verifies dependency assertions and then installs files from packages. Adding --nodeps disables dependency assertion verification, while %config file resolution (like renaming to *.rpmnew) is computed while installing. These actions are largely indpendent of each other, based on different package data. Something else is going on imho. > there are no %file %config changes between the versions in the transaction > And the %config file resolution in rpm has not changed in many years, like all of this century. > don't want to re-test this, but seems like it > I cannot do engineering based on anecdotal inattention to details. The minimum necessary information necessary for a rpm bug report about %config needs a reproducer with rpm, not poldek, using -vv to output the %config file renaming computed by rpmlib and a clear statement of what specific behavior you are claiming that is broken. hth 73 de Jeff From glen at pld-linux.org Wed Apr 20 12:19:18 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 20 Apr 2016 13:19:18 +0300 Subject: bacula versions Message-ID: <571757A6.4040608@pld-linux.org> so, we have 5.2.13 -> 7.0.5 upgrade in th https://github.com/pld-linux/bacula/blob/auto/th/bacula-7.0.5-1/bacula.spec#L494-L499 # install the updatedb scripts for older versions that last full release # 2.0 -> 3.0 : 10_to_11 # 5.0 -> 5.2 : 12_to_14 install -p updatedb/update_*_tables_10_to_11 $RPM_BUILD_ROOT%{_libexecdir}/%{name} install -p updatedb/update_*_tables_11_to_12 $RPM_BUILD_ROOT%{_libexecdir}/%{name} install -p updatedb/update_*_tables_12_to_14 $RPM_BUILD_ROOT%{_libexecdir}/%{name} i looked bacula website and found 7.2.0 and 7.4.0 there so i tried to build 7.2.0 and it would have such files (12->13->14, not 12-14) install -p updatedb/update_*_tables_10_to_11 $RPM_BUILD_ROOT%{_libexecdir}/%{name} install -p updatedb/update_*_tables_11_to_12 $RPM_BUILD_ROOT%{_libexecdir}/%{name} install -p updatedb/update_*_tables_12_to_13 $RPM_BUILD_ROOT%{_libexecdir}/%{name} install -p updatedb/update_*_tables_13_to_14 $RPM_BUILD_ROOT%{_libexecdir}/%{name} looks like 7.2.0 is older than 7.0.5? like 7.2 is development branch for 7.0? huh? and they both result v14 database? so i'm a bit confused of their releases, and what version series we should stick in pld? the problem i have is that i have bacula5 director, and having upraded clients to bacula7 results authentication failures yet if i read 7.4.0 release notes http://blog.bacula.org/release-7-4-0/ it claims: " Upgrading should be easy since there is no database change and all older File Daemons should remain compatible with Bacula 7.4.0." of course i don't know do they claim if 5.2 clients can connect there or not -- glen From n3npq at mac.com Wed Apr 20 14:38:59 2016 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 20 Apr 2016 08:38:59 -0400 Subject: rpm-5.4.16 snapshot In-Reply-To: <7E23C44F-7F3E-4F2F-B289-09F98425C869@mac.com> References: <7E23C44F-7F3E-4F2F-B289-09F98425C869@mac.com> Message-ID: There is a final snapshot release of rpm-5.4.16 now available at http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160420.src.rpm Unless I screwed something at the last minute, this SRPM will be released as rpm-5.4.16 later this week. Since the last snapshot, there are several important changes 1) colorized rpm error messages. 2) *.rpm package reading has been hardened using american fuzzy lop on the command rpm -qp --nomanifest minimal*.rpm and all issues have been fixed. The current run has survived 400M forks. 3) configure options to enable link time optimization (-flto) and run-time checking (-fsanitize=address et al) have been added. 73 de Jeff On Mar 15, 2016, at 4:50 PM, Jeff Johnson wrote: > There is a snapshot release of rpm-5.4.16 now available at > > http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160315.src.rpm > > This is the first SRPM built by itself that is headed for release > in the next few weeks that is being provided as a public reference > point for integration and portability testing. > > See the included INSTALL document for the build pre-requisite versions used. > > From a distro POV, please note the following changes that are included > in the snapshot that will (at least) need to be considered when upgrading: > > 1) (recommended) rpm-5.4.16 uses BLAKE2bp for file digests. > BLAKe2bp is a 256bit digest that is faster than SHA256 (and MD5) > that will improve installation speeds. > > Details are here: > https://blake2.net > > 2) (recommended) rpm-5.4.16 uses libtomcrypt (rather than BeeCrypt). > LibTomCrypt has support for ECDSA and is used by recent python and > the linux kernel (iirc). > > Details are here: > https://github.com/libtom/libtomcrypt > > 3) (recommended) rpm-5.4.16 uses db-6.1.23 (not 6.1.26) with > DB_MULTIVERSION and DB_TXN_SNAPSHOT. > DB_TXN_SNAPSHOT avoids deadlocks with copy-on-write rather than > locking semantics. > > The change is necessary to support nested transactional commits > in rpm like > command transaction > package transaction > install transaction > erase transaction > without deadlocking on trigger lookups. > > Details about DB_MULTIVERSION and DB_TXN_SNAPSHOT can be found > in the Oracle Berkeley DB documentation here: > http://docs.oracle.com/cd/E17076_04/html/index.html > > As always, rpm can be configured to use any of ~120 digests, any of > BeeCrypt > NSS > Openssl > Libgcrypt > LibTomCrypt > and (most likely, unchecked) any version of Berkeley DB back to db-4.6.x. > > Bug reports are requested at > https://launchpad.net/rpm > > Patches and discussion are requested at > > > Enjoy! > > 73 de Jeff > From glen at pld-linux.org Wed Apr 20 17:01:09 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 20 Apr 2016 18:01:09 +0300 Subject: rpm-5.4.16 snapshot In-Reply-To: References: <7E23C44F-7F3E-4F2F-B289-09F98425C869@mac.com> Message-ID: <571799B5.5070300@pld-linux.org> On 20.04.2016 15:38, Jeff Johnson wrote: > There is a final snapshot release of rpm-5.4.16 now available at > > http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160420.src.rpm so this did got finally addressed? http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2015-November/thread.html#24537 -- glen From glen at pld-linux.org Wed Apr 20 17:05:58 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 20 Apr 2016 18:05:58 +0300 Subject: rpm-5.4.16 snapshot In-Reply-To: <571799B5.5070300@pld-linux.org> References: <7E23C44F-7F3E-4F2F-B289-09F98425C869@mac.com> <571799B5.5070300@pld-linux.org> Message-ID: <57179AD6.4060806@pld-linux.org> On 20.04.2016 18:01, Elan Ruusam?e wrote: > On 20.04.2016 15:38, Jeff Johnson wrote: >> There is a final snapshot release of rpm-5.4.16 now available at >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160420.src.rpm >> > > so this did got finally addressed? > > http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2015-November/thread.html#24537 > > sorry, the patch that pld has applied now is here: https://github.com/pld-linux/rpm/blob/ff1a99fc4/do_not_write_before_macro_buffer.patch -- glen From glen at delfi.ee Wed Apr 20 18:07:04 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 20 Apr 2016 19:07:04 +0300 Subject: PLD New Rescue th2015-1.5 In-Reply-To: <57122C94.4000301@jajcus.net> References: <57122C94.4000301@jajcus.net> Message-ID: <5717A928.4030104@delfi.ee> reported okay with: proxmox-ve 4.1-41, pve-qemu-kvm 2.5-9 amd64 image On 16.04.2016 15:14, Jacek Konieczny wrote: > I have just built PLD New Rescue based on the th-2015 snapshot: > > https://github.com/Jajcus/pld-new-rescue/releases/tag/th2015-1.5 > > Please do test it in any way you need to use this. I have done only some > very basic testing. > > Jacek -- glen From n3npq at mac.com Wed Apr 20 18:23:13 2016 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 20 Apr 2016 12:23:13 -0400 Subject: rpm-5.4.16 snapshot In-Reply-To: <57179AD6.4060806@pld-linux.org> References: <7E23C44F-7F3E-4F2F-B289-09F98425C869@mac.com> <571799B5.5070300@pld-linux.org> <57179AD6.4060806@pld-linux.org> Message-ID: On Apr 20, 2016, at 11:05 AM, Elan Ruusam?e wrote: > On 20.04.2016 18:01, Elan Ruusam?e wrote: >> On 20.04.2016 15:38, Jeff Johnson wrote: >>> There is a final snapshot release of rpm-5.4.16 now available at >>> >>> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160420.src.rpm >> >> so this did got finally addressed? >> >> http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2015-November/thread.html#24537 >> > sorry, the patch that pld has applied now is here: > > https://github.com/pld-linux/rpm/blob/ff1a99fc4/do_not_write_before_macro_buffer.patch > Yes fixed. 73 de jeff From hawk at pld-linux.org Thu Apr 21 08:45:29 2016 From: hawk at pld-linux.org (Marcin Krol) Date: Thu, 21 Apr 2016 08:45:29 +0200 Subject: bacula versions In-Reply-To: <571757A6.4040608@pld-linux.org> References: <571757A6.4040608@pld-linux.org> Message-ID: <57187709.8030502@pld-linux.org> > looks like 7.2.0 is older than 7.0.5? like 7.2 is development branch for > 7.0? huh? and they both result v14 database? > > so i'm a bit confused of their releases, and what version series we > should stick in pld? Its not older. Bacula isn't always providing all SQL migration paths and scripts in their tarballs, you have to obtain proper ones from older tarballs if doing bigger version jump. Its not the first time its that way. AFAIR there was no DB update after 5.x to 7.x series switch or it was mere cosmetics. I may be wrong however, I've switched to 7.x series back in 2014. > the problem i have is that i have bacula5 director, and having upraded > clients to bacula7 results authentication failures > yet if i read 7.4.0 release notes http://blog.bacula.org/release-7-4-0/ > > it claims: " Upgrading should be easy since there is no database change > and all older File Daemons should remain compatible with Bacula 7.4.0." > of course i don't know do they claim if 5.2 clients can connect there or > not Director will work with all older clients, but will not work with any newer clients. If client is newer than director it will be rejected. It is explained in bacula documentation. You either have to upgrade your director or downgrade the clients. There is no other way to make it work due to changes made in client-director communication protocol. FYI there is bacula 7.4.0 in TLD git. Feel free to merge it if you want. M. From hawk at pld-linux.org Thu Apr 21 08:50:57 2016 From: hawk at pld-linux.org (Marcin Krol) Date: Thu, 21 Apr 2016 08:50:57 +0200 Subject: bacula versions In-Reply-To: <571757A6.4040608@pld-linux.org> References: <571757A6.4040608@pld-linux.org> Message-ID: <57187851.1040105@pld-linux.org> > looks like 7.2.0 is older than 7.0.5? like 7.2 is development branch for > 7.0? huh? and they both result v14 database? > > so i'm a bit confused of their releases, and what version series we > should stick in pld? Its not older. Bacula isn't always providing all SQL migration paths and scripts in their tarballs, you have to obtain proper ones from older tarballs if doing bigger version jump. Its not the first time its that way. AFAIR there was no DB update after 5.x to 7.x series switch or it was mere cosmetics. I may be wrong however, I've switched to 7.x series back in 2014. > the problem i have is that i have bacula5 director, and having upraded > clients to bacula7 results authentication failures > yet if i read 7.4.0 release notes http://blog.bacula.org/release-7-4-0/ > > it claims: " Upgrading should be easy since there is no database change > and all older File Daemons should remain compatible with Bacula 7.4.0." > of course i don't know do they claim if 5.2 clients can connect there or > not Director will work with all older clients, but will not work with any newer clients. If client is newer than director it will be rejected. It is explained in bacula documentation. You either have to upgrade your director or downgrade the clients. There is no other way to make it work due to changes made in client-director communication protocol. FYI there is bacula 7.4.0 in TLD git. Feel free to merge it if you want. M. From jajcus at jajcus.net Thu Apr 21 09:23:17 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Thu, 21 Apr 2016 09:23:17 +0200 Subject: PLD New Rescue th2015-1.5 In-Reply-To: <5717A928.4030104@delfi.ee> References: <57122C94.4000301@jajcus.net> <5717A928.4030104@delfi.ee> Message-ID: <6fbdc30d-a656-8bc7-a085-36e0da500177@jajcus.net> On 2016-04-19 15:59, Grzesiek Pycia wrote: > Works fine for me, both 32&64bit. > Under qemu/kvm it does not power off machine, but version th-2014 > stops on "System halted" to. On 2016-04-20 18:07, Elan Ruusam?e wrote: > reported okay with: > > proxmox-ve 4.1-41, pve-qemu-kvm 2.5-9 Thanks! I'll remove the 'pre-release' flag on GitHub. Jacek From atler at pld-linux.org Thu Apr 21 22:55:07 2016 From: atler at pld-linux.org (Jan Palus) Date: Thu, 21 Apr 2016 22:55:07 +0200 Subject: building kernel modules Message-ID: <20160421205507.GA7788@cukinia> In latest VirtualBox release there was an issue with building kernel modules for LTS kernel 3.10 which was basically caused by missing KERNELRELEASE definition. Since for one module build depends on target kernel version, the decision was made incorrectly in the absence of above var. Now from top level Makefile in kernel-headers: KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null) kernel.release file is fine and contains correct value, however the implicit requirement is to have $PWD pointing to kernel headers top dir. That's not the case for our %build_kernel_modules macro which uses O=$PWD/o in turn causing `cd $O` before evaluating KERNELRELEASE. As a result KERNELRELEASE ends up empty. As I'm not really proficient with build process of kernel modules, can someone advise if O= is really necessary or is there some other way to fix the issue? From glen at pld-linux.org Sun Apr 24 11:51:58 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 24 Apr 2016 12:51:58 +0300 Subject: rpm-5.4.16 snapshot In-Reply-To: References: <7E23C44F-7F3E-4F2F-B289-09F98425C869@mac.com> Message-ID: <571C973E.8030001@pld-linux.org> On 20.04.2016 15:38, Jeff Johnson wrote: > There is a final snapshot release of rpm-5.4.16 now available at > > http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160420.src.rpm baggins, could you take care of the last remaining patches on dev-5.4.16. those are both yours and i don't know how to test are those still needed. anyway, i finally installed the built version. the sasl2 error is probably from somewhere else. 12:48:25 root[load: 0.00]@new-server /# rpm -q rpm rpm-5.4.16-0.1.i686 something logs to syslog at this time: Apr 24 12:48:27 new-server rpm: looking for plugins in '/usr/lib/sasl2', failed to open directory, error: No such file or directory 12:50:56 root[load: 0.00]@new-server /# pkgbytime sasl Wed Aug 26 14:31:10 2015 cyrus-sasl-libs-2.1.26-4.i686 -- glen From glen at pld-linux.org Sun Apr 24 12:03:20 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 24 Apr 2016 13:03:20 +0300 Subject: rpm-5.4.16 snapshot In-Reply-To: <571C973E.8030001@pld-linux.org> References: <7E23C44F-7F3E-4F2F-B289-09F98425C869@mac.com> <571C973E.8030001@pld-linux.org> Message-ID: <571C99E8.7020401@pld-linux.org> On 24.04.2016 12:51, Elan Ruusam?e wrote: > > anyway, i finally installed the built version. the sasl2 error is > probably from somewhere else. > > 12:48:25 root[load: 0.00]@new-server /# rpm -q rpm > rpm-5.4.16-0.1.i686 There are 1 package to install, 1 to remove: I filesystem-4.0-46.i686 R filesystem-4.0-42.i686 Need to get 19.7KB of archives (19.7KB to download). Retrieving th::filesystem-4.0-46.i686.rpm... .............................. 100.0% [19.7K (19.7K/s)] warn: tag Name(1000) type(0x4) != expected type(0x10006) warn: tag Summary(1004) type(0x7) != expected type(0x10006) warn: tag Buildhost(1007) type(0x4) != expected type(0x10006) Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 1... Preparing... ########################################### [100%] Repackaging... 1:filesystem ########################################### [100%] Upgrading... 1:filesystem ########################################### [100%] Installing set #2 probably related to RPM_I18NSTRING_TYPE what jbj talked and i don't understand. -- glen From baggins at pld-linux.org Sun Apr 24 12:29:40 2016 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 24 Apr 2016 12:29:40 +0200 Subject: rpm-5.4.16-0.20160321.src.rpm, take 3 In-Reply-To: <7DE4F56A-3BA3-4DE6-9DCA-F3545CD8722F@mac.com> References: <7DE4F56A-3BA3-4DE6-9DCA-F3545CD8722F@mac.com> Message-ID: <20160424102939.GA4333@home> On Mon, 21 Mar 2016, Jeff Johnson wrote: > There is a 3rd snapshot release of rpm-5.4.16 now available at > > http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT//rpm-5.4.16-0.20160321.src.rpm > > This addresses the following issues: > 1) mongoc.h needed #include to rebuild with PLD configuration > 2) build with or without in "system.h" > #define SUPPORT_I18NSTRING_TYPE 1 > > The tarball has > #undef SUPPORT_I18NSTRING > which will display the Summary/Description/Group tags ifrom the header n the C locale aways, > and otherwise eliminates the RPM_I18NSTRING_TYPE interface. Digging this one up. Why are you so set on eliminating RPM_I18NSTRING_TYPE? I don't see any explanation anywhere and it will kill a lot of work we put in translating spec Summary/Descriptions. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From n3npq at mac.com Sun Apr 24 16:25:50 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 10:25:50 -0400 Subject: rpm-5.4.16-0.20160321.src.rpm, take 3 In-Reply-To: <20160424102939.GA4333@home> References: <7DE4F56A-3BA3-4DE6-9DCA-F3545CD8722F@mac.com> <20160424102939.GA4333@home> Message-ID: On Apr 24, 2016, at 6:29 AM, Jan R?korajski wrote: > On Mon, 21 Mar 2016, Jeff Johnson wrote: > >> There is a 3rd snapshot release of rpm-5.4.16 now available at >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT//rpm-5.4.16-0.20160321.src.rpm >> >> This addresses the following issues: >> 1) mongoc.h needed #include to rebuild with PLD configuration >> 2) build with or without in "system.h" >> #define SUPPORT_I18NSTRING_TYPE 1 >> >> The tarball has >> #undef SUPPORT_I18NSTRING >> which will display the Summary/Description/Group tags ifrom the header n the C locale aways, >> and otherwise eliminates the RPM_I18NSTRING_TYPE interface. > > Digging this one up. > > Why are you so set on eliminating RPM_I18NSTRING_TYPE? I don't see any > explanation anywhere and it will kill a lot of work we put in > translating spec Summary/Descriptions. > Short answer: Patch the define and be happy. Everything "works" as before, none of your "work" in *.spec files needs to be changed or is lost. Longer answer: I'm interested in removing (by abandoning) a problematic (sometimes RPM_I18NSTRING_TYPE is a string, sometimes its an array, dependent on context) data type in RPM headers. There are deeper/harder issues with specifying an encoding for RPM_I18NSTRING_TYPE in a spec file as well. Already there are some deep hacks in RPM to translate what is usually (PLD is the only distro I know of that specifies encoding explicitly) implicitly dependent on a LANG/LC_ALL envvar. The processes of "building" and "translating" are rather different as well. Most distros (unlike PLD) have some awkward "string freezes" and "string merges" as part of their release cycle that synchronize the steps needed to hand data to translation teams, and to put translated strings into packages. I am interested in making these processes more independent of each other, with an alternative means of distribution and associating Group/Summary/Description with packages. That includes handling RPMTAG_FILELANGS differently as well. I think that I18N could (and should) be done better in RPM. Meanwhile devising a transparent "legacy compatible" retrofit for RPM_I18NSTRING_TYPE is/was the necessary first step to attempting a better implementation. 73 de Jeff > Jan R?korajski | PLD/Linux > SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From n3npq at mac.com Sun Apr 24 16:41:06 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 10:41:06 -0400 Subject: Fwd: rpm-5.4.16 snapshot References: <571C973E.8030001@pld-linux.org> Message-ID: Begin forwarded message: > From: Elan Ruusam?e > Subject: Re: rpm-5.4.16 snapshot > Date: April 24, 2016 5:51:58 AM EDT > To: "PLD: Developers list (English)" > Reply-To: "PLD: Developers list (English)" > > On 20.04.2016 15:38, Jeff Johnson wrote: >> There is a final snapshot release of rpm-5.4.16 now available at >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160420.src.rpm > > baggins, could you take care of the last remaining patches on dev-5.4.16. those are both yours and i don't know how to test are those still needed. > > > anyway, i finally installed the built version. the sasl2 error is probably from somewhere else. > The SASL error is coming from integration with the mongo-c-driver. Adding --without-sasl SHOULD just work (from a patch coming from Poky/Yocto, only lightly tested by me). > 12:48:25 root[load: 0.00]@new-server /# rpm -q rpm > rpm-5.4.16-0.1.i686 > > something logs to syslog at this time: > Apr 24 12:48:27 new-server rpm: looking for plugins in '/usr/lib/sasl2', failed to open directory, error: No such file or directory > That message isn't coming from RPM afaik. 73 de Jeff From n3npq at mac.com Sun Apr 24 16:53:05 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 10:53:05 -0400 Subject: rpm-5.4.16 snapshot In-Reply-To: <571C99E8.7020401@pld-linux.org> References: <7E23C44F-7F3E-4F2F-B289-09F98425C869@mac.com> <571C973E.8030001@pld-linux.org> <571C99E8.7020401@pld-linux.org> Message-ID: On Apr 24, 2016, at 6:03 AM, Elan Ruusam?e wrote: > On 24.04.2016 12:51, Elan Ruusam?e wrote: >> >> anyway, i finally installed the built version. the sasl2 error is probably from somewhere else. >> >> 12:48:25 root[load: 0.00]@new-server /# rpm -q rpm >> rpm-5.4.16-0.1.i686 > There are 1 package to install, 1 to remove: > I filesystem-4.0-46.i686 > R filesystem-4.0-42.i686 > Need to get 19.7KB of archives (19.7KB to download). > > Retrieving th::filesystem-4.0-46.i686.rpm... > .............................. 100.0% [19.7K (19.7K/s)] > warn: tag Name(1000) type(0x4) != expected type(0x10006) > warn: tag Summary(1004) type(0x7) != expected type(0x10006) > warn: tag Buildhost(1007) type(0x4) != expected type(0x10006) No, the above has nothing to do with I18N. rpm-5.4.16 explicitly checks the data type on all metdata header tags. Unfortunately, there are ancient tag number collisions between signature and metadata headers between RPMSIGTAG_SIZE RPMTAG_NAME RPMSIGTAG_MD5 RPMTAG_SUMMARY RPMSIGTAG_PAYLOADSIZE RPMTAG_BUILDHOST that need to be handled by marking the headerGet()/headerNext() access with the flag HEADERGET_SIGHEADER. The warning is there to ensure that the HEADERGET_SIGHEADER has been specified. Presumably those messages are triggered by poldek access, not rpm. You can also patch tagValidate() in rpmdb/tagname.c to avoid the warning message (which is what recent RPM versions was doing) if you cannot find the place where HEADERGET_SIGHEADER needs to be added. > Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 1... > Preparing... ########################################### [100%] > Repackaging... > 1:filesystem ########################################### [100%] > Upgrading... > 1:filesystem ########################################### [100%] > Installing set #2 > > probably related to RPM_I18NSTRING_TYPE what jbj talked and i don't understand. > Again, nothing to do with I18N, but rather disambiguating signature from metadata header tagno's. hth 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From n3npq at mac.com Sun Apr 24 17:28:24 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 11:28:24 -0400 Subject: rpm-5.4.16 snapshot In-Reply-To: References: <571C973E.8030001@pld-linux.org> Message-ID: <243CFC4D-6874-4BDE-B5CC-FAB3F48E8841@mac.com> On Apr 24, 2016, at 10:41 AM, Jeff Johnson wrote: >> >> something logs to syslog at this time: >> Apr 24 12:48:27 new-server rpm: looking for plugins in '/usr/lib/sasl2', failed to open directory, error: No such file or directory >> > > That message isn't coming from RPM afaik. > The message is likely coming from the .init section in libsasl.so.3.0.0 $ readelf -a /usr/lib64/libsasl2.so.3.0.0 ... [ 9] .init PROGBITS 0000000000004268 00004268 000000000000001a 0000000000000000 AX 0 0 4 [10] .plt PROGBITS 0000000000004290 00004290 00000000000008d0 0000000000000010 AX 0 0 16 [11] .text PROGBITS 0000000000004b60 00004b60 0000000000011193 0000000000000000 AX 0 0 16 So specifiying --without-sasl when building is the only (well you could configure/install sasl correctly before executing rpm too) way to remove the syslog'd message. Note that adding --with-java when building RPM links to a library with .init/.fini sections. hth 73 de Jeff From glen at pld-linux.org Sun Apr 24 18:32:00 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 24 Apr 2016 19:32:00 +0300 Subject: rpm-5.4.16 snapshot In-Reply-To: <243CFC4D-6874-4BDE-B5CC-FAB3F48E8841@mac.com> References: <571C973E.8030001@pld-linux.org> <243CFC4D-6874-4BDE-B5CC-FAB3F48E8841@mac.com> Message-ID: <571CF500.8090600@pld-linux.org> On 24.04.2016 18:28, Jeff Johnson wrote: > So specifiying --without-sasl when building is the only (well you could configure/install sasl > correctly before executing rpm too) way to remove the syslog'd message. added, did not help. did not investigate further, but build log is available: http://carme.pld-linux.org/~glen/rpm-5.4.16-0.2.i686-linux.2016-04-24_17-50-47.log -- glen From n3npq at mac.com Sun Apr 24 18:49:48 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 12:49:48 -0400 Subject: rpm-5.4.16 snapshot In-Reply-To: <571CF500.8090600@pld-linux.org> References: <571C973E.8030001@pld-linux.org> <243CFC4D-6874-4BDE-B5CC-FAB3F48E8841@mac.com> <571CF500.8090600@pld-linux.org> Message-ID: On Apr 24, 2016, at 12:32 PM, Elan Ruusam?e wrote: > On 24.04.2016 18:28, Jeff Johnson wrote: >> So specifiying --without-sasl when building is the only (well you could configure/install sasl >> correctly before executing rpm too) way to remove the syslog'd message. > > added, did not help. did not investigate further, but build log is available: > > > http://carme.pld-linux.org/~glen/rpm-5.4.16-0.2.i686-linux.2016-04-24_17-50-47.log > I'll have a fix shortly. The syslog messages from linking SASL2 are very annoying. There's another msg that happens on exit: Apr 24 12:31:21 hi.jbj.org rpm[5634]: DIGEST-MD5 common mech free I'll either find a way to get rid of the messages or make --with-sasl "opt-in" rather than "opt-out". (aside) BTW, there is one other 1-line patch to rpmio/pkgio.c needed to plug a 16b memory leak in rdSignature(). The final code should look like ... /* All packages should have RPMSIGTAG_MD5. */ he->tag = (rpmTag) RPMSIGTAG_MD5; xx = headerGet(sigh, he, HEADERGET_SIGHEADER); he->p.ptr = _free(he->p.ptr); /* <== THIS LINE */ if (!xx) { ... 73 de Jeff. From n3npq at mac.com Sun Apr 24 19:14:07 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 13:14:07 -0400 Subject: rpm-5.4.16 snapshot In-Reply-To: References: <571C973E.8030001@pld-linux.org> <243CFC4D-6874-4BDE-B5CC-FAB3F48E8841@mac.com> <571CF500.8090600@pld-linux.org> Message-ID: On Apr 24, 2016, at 12:49 PM, Jeff Johnson wrote: > > (aside) > BTW, there is one other 1-line patch to rpmio/pkgio.c needed to plug a 16b memory leak > in rdSignature(). The final code should look like > > ... > /* All packages should have RPMSIGTAG_MD5. */ > he->tag = (rpmTag) RPMSIGTAG_MD5; > xx = headerGet(sigh, he, HEADERGET_SIGHEADER); > he->p.ptr = _free(he->p.ptr); /* <== THIS LINE */ > if (!xx) { > ... > And there is another 1 liner found by fuzzing with american fuzzy-lop after 1.1B execs that I just checked in: Summary stats ============= Fuzzers alive : 6 Total run time : 37 days, 14 hours Total execs : 1135 million Cumulative speed : 2097 execs/sec Pending paths : 0 faves, 1 total Pending per fuzzer : 0 faves, 0 total (on average) Crashes found : 38 locally unique FWIW, I don't consider either the 16b memory leak or the header read hardening (that affects 3 unique "hangs" found in 1.1B execs) to be worth re-rolling (and re-testing) rpm-5.4.16. RPM is about installing *.rpm packages, not in reading randomized inputs. hth 73 de Jeff From baggins at pld-linux.org Sun Apr 24 20:03:46 2016 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 24 Apr 2016 20:03:46 +0200 Subject: Update on kernel packages in Th Message-ID: <20160424180346.GA4036@home> Hi, With the addition of new longterm kernel (4.4) we would have six (6) package lines to keep up. Because of this I'm removing 3.10 and 3.14 from Th to keep the number maintainable. There will be no more releases for those lines and I will move existing packages to .archive within a month. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From n3npq at mac.com Sun Apr 24 20:08:35 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 14:08:35 -0400 Subject: rpm-5.4.16 snapshot In-Reply-To: References: <571C973E.8030001@pld-linux.org> <243CFC4D-6874-4BDE-B5CC-FAB3F48E8841@mac.com> <571CF500.8090600@pld-linux.org> Message-ID: <6028EF90-92FF-4F78-92A4-D92A8EA39CC7@mac.com> On Apr 24, 2016, at 12:49 PM, Jeff Johnson wrote: > > On Apr 24, 2016, at 12:32 PM, Elan Ruusam?e wrote: > >> On 24.04.2016 18:28, Jeff Johnson wrote: >>> So specifiying --without-sasl when building is the only (well you could configure/install sasl >>> correctly before executing rpm too) way to remove the syslog'd message. >> >> added, did not help. did not investigate further, but build log is available: >> >> >> http://carme.pld-linux.org/~glen/rpm-5.4.16-0.2.i686-linux.2016-04-24_17-50-47.log >> > > I'll have a fix shortly. > The fix is --without-sasl2 (not --without-sasl). My brain fart, now verified. I'll also change configure.ac to be "opt-in" rather than "opt-out" in rpm-5.4.17. Two syslog msgs for every rpm exec (or library load) is too much info for my taste. ymmv. 73 de Jeff From glen at pld-linux.org Sun Apr 24 21:20:04 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 24 Apr 2016 22:20:04 +0300 Subject: rpm-5.4.16 snapshot In-Reply-To: <6028EF90-92FF-4F78-92A4-D92A8EA39CC7@mac.com> References: <571C973E.8030001@pld-linux.org> <243CFC4D-6874-4BDE-B5CC-FAB3F48E8841@mac.com> <571CF500.8090600@pld-linux.org> <6028EF90-92FF-4F78-92A4-D92A8EA39CC7@mac.com> Message-ID: <571D1C64.3060005@pld-linux.org> On 24.04.2016 21:08, Jeff Johnson wrote: > The fix is --without-sasl2 (not --without-sasl). My brain fart, now verified. thanks. indeed that's the option. seems libacl is also new library dependency. is there appropriate functionality or it also slipped in somehow? [~/rpm/packages/rpm(5.4.16) (dev-5.4.16)?] ? dif rpm5.4.1* -w --- rpm5.4.15 2016-04-24 22:17:31.377687443 +0300 +++ rpm5.4.16 2016-04-24 22:17:07.000000000 +0300 @@ -3,6 +3,8 @@ beecrypt >= 2:4.2.0 db5.2 >= 5.2.36.0-4 db5.2-sql >= 5.2.36.0-4 +libacl.so.1 +libacl.so.1(ACL_1.0) libbeecrypt.so.7 libbz2.so.1 libc.so.6 @@ -38,6 +40,7 @@ liblzma.so.5(XZ_5.0) libm.so.6 libm.so.6(GLIBC_2.0) +libm.so.6(GLIBC_2.1) libmagic >= 1.15-2 libmagic.so.1 libossp-uuid.so.16 (END) more complete listing, if interesting: $ rpm -q rpm-lib --requires /sbin/ldconfig /sbin/ldconfig beecrypt >= 2:4.2.0 db5.2 >= 5.2.36.0-4 db5.2-sql >= 5.2.36.0-4 libacl.so.1 libacl.so.1(ACL_1.0) libbeecrypt.so.7 libbz2.so.1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.11) libc.so.6(GLIBC_2.15) libc.so.6(GLIBC_2.17) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.2.3) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.3.3) libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) libc.so.6(GLIBC_2.7) libc.so.6(GLIBC_2.8) libdb-5.2.so libdb_sql-5.2.so libdl.so.2 libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libelf.so.1 libelf.so.1(ELFUTILS_1.0) libelf.so.1(ELFUTILS_1.3) libgcc_s.so.1 libgcc_s.so.1(GLIBC_2.0) libgomp.so.1 libgomp.so.1(GOMP_4.0) libgomp.so.1(OMP_1.0) liblzma.so.5 liblzma.so.5(XZ_5.0) libm.so.6 libm.so.6(GLIBC_2.0) libm.so.6(GLIBC_2.1) libmagic >= 1.15-2 libmagic.so.1 libossp-uuid.so.16 libpcre.so.1 libpcreposix.so.0 libpopt.so.0 libpopt.so.0(LIBPOPT_0) libpthread.so.0 libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.1) libpthread.so.0(GLIBC_2.2) libpthread.so.0(GLIBC_2.3.2) libpthread.so.0(GLIBC_2.3.3) librt.so.1 librt.so.1(GLIBC_2.2) libselinux >= 2.1.0 libselinux.so.1 libsemanage.so.1 libsemanage.so.1(LIBSEMANAGE_1.0) libsepol.so.1 libz.so.1 libz.so.1(ZLIB_1.2.3.3) popt >= 1.15 rtld(GNU_HASH) -- glen From n3npq at mac.com Sun Apr 24 21:23:29 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 15:23:29 -0400 Subject: rpm-5.4.16-0.20160321.src.rpm, take 3 In-Reply-To: References: <7DE4F56A-3BA3-4DE6-9DCA-F3545CD8722F@mac.com> <20160424102939.GA4333@home> Message-ID: <9B037FF3-4CC8-4D9D-AEA2-0CDD30FE66B1@mac.com> On Apr 24, 2016, at 10:25 AM, Jeff Johnson wrote: ... > > I think that I18N could (and should) be done better in RPM. Meanwhile devising a transparent > "legacy compatible" retrofit for RPM_I18NSTRING_TYPE is/was the necessary first step to attempting > a better implementation. > I perhaps should describe some modest extensions that improve on the storage of I18N in headers. RPM has something called "arbitrary tags" that are essentially an associative array. The tag name string is digested with SHA1 and the least significant 30bits of the digest have 0x4000000 (i.e. the 2 most significant bits are 01......), so there are potentially 1G of tagno's in the arbitrary tag space that can be used as an associative array. E.g. any tag name string can be used as an arbitrary tag like Foo: can be added to package headers by adding to a macro in configuration, and just adding to *.spec files. One header tag storage improvement would be to permit tag names like (literally) Description(en_US.utf8) which the *.spec parser can easily generate and implicitly predefine tags of that form (instead of the rather clunky %_arbitrary_tags macro configuration). The retrieval of Summary/Group/Description would have to sequentially try Description($LANG) and then (if that tag doesn't exist) Description exactly mimic'ing existing behavior, where the locale is stored in RPMTAG_HEADERI18NTABLE and a sequential comparison is undertaken before using the C locale. (aside) There are other compatibility issues with specspo (and a lookaside cache) that most distros are using most of this century that can be retrofitted as necessary. I personally believe that automatic translation through yandex.com, storing the returned string in a local cache database, with provisions to prime the lookaside cache by installing a package, or by doing a git checkout, or by using the embedded sqlite, or mongo, or ... are also needed for "building" and "translation" processes to become indpendent. The current means of distributing all possible locales directly in header metadata simply does not scale. When was the last time a distro rebuilt a package to correct a spelling error typo in, say, the Swahili translation? Getting rid of RPM_I18NSTRING_TYPE is (imho) a necessary first step in attempting a better implementation. YMMV. 73 de Jeff From n3npq at mac.com Sun Apr 24 21:27:35 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 15:27:35 -0400 Subject: rpm-5.4.16 snapshot In-Reply-To: <571D1C64.3060005@pld-linux.org> References: <571C973E.8030001@pld-linux.org> <243CFC4D-6874-4BDE-B5CC-FAB3F48E8841@mac.com> <571CF500.8090600@pld-linux.org> <6028EF90-92FF-4F78-92A4-D92A8EA39CC7@mac.com> <571D1C64.3060005@pld-linux.org> Message-ID: <1C360F4D-FCA2-4AB7-A346-A1492C51054B@mac.com> On Apr 24, 2016, at 3:20 PM, Elan Ruusam?e wrote: > On 24.04.2016 21:08, Jeff Johnson wrote: >> The fix is --without-sasl2 (not --without-sasl). My brain fart, now verified. > > thanks. indeed that's the option. > > seems libacl is also new library dependency. is there appropriate functionality or it also slipped in somehow? > There is a --without-acl build option that should do what you wish. The lossage will be in in tools/mtree (swiped from F*BSD). RPM itself doesn't give a hoot about ACL's. Meanwhile there are already RFE's to handle ACL's and capabilities and xattr's and worser through *.rpm packaging which are the reason to link -lacl. 73 de Jeff From glen at pld-linux.org Sun Apr 24 21:29:11 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 24 Apr 2016 22:29:11 +0300 Subject: rpm-5.4.16-0.20160321.src.rpm, take 3 In-Reply-To: <9B037FF3-4CC8-4D9D-AEA2-0CDD30FE66B1@mac.com> References: <7DE4F56A-3BA3-4DE6-9DCA-F3545CD8722F@mac.com> <20160424102939.GA4333@home> <9B037FF3-4CC8-4D9D-AEA2-0CDD30FE66B1@mac.com> Message-ID: <571D1E87.8000207@pld-linux.org> On 24.04.2016 22:23, Jeff Johnson wrote: > When was the last time a distro rebuilt a package to correct a spelling error typo in, say, > the Swahili translation? fedora rebuilds *all* packages for each release, so each release will have whatever translations were added to .spec. altho i don't even know do they translate or where they store the translations. in pld, there's only -pl translation that can be considered near complete. -- glen From n3npq at mac.com Sun Apr 24 21:42:59 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 24 Apr 2016 15:42:59 -0400 Subject: rpm-5.4.16-0.20160321.src.rpm, take 3 In-Reply-To: <571D1E87.8000207@pld-linux.org> References: <7DE4F56A-3BA3-4DE6-9DCA-F3545CD8722F@mac.com> <20160424102939.GA4333@home> <9B037FF3-4CC8-4D9D-AEA2-0CDD30FE66B1@mac.com> <571D1E87.8000207@pld-linux.org> Message-ID: <21E872CB-C82B-49B9-98A7-46F48228C7D2@mac.com> On Apr 24, 2016, at 3:29 PM, Elan Ruusam?e wrote: > On 24.04.2016 22:23, Jeff Johnson wrote: >> When was the last time a distro rebuilt a package to correct a spelling error typo in, say, >> the Swahili translation? > > fedora rebuilds *all* packages for each release, so each release will have whatever translations were added to .spec. altho i don't even know do they translate or where they store the translations. > Fedora (and RHEL) are likely not bothering with anything but the C locale for package description/summary/group, largely because of the comp-lexity of the task, and perhaps because of (from PLD years ago) Kurwa, durni ameryka?ce sobe zawsze my?l?, ?e ca?y ?wiat m?wi po angielsku... > in pld, there's only -pl translation that can be considered near complete. > Well there is the C locale so actually there are two copies of I18N tags if pl is "near complete". For a national distro with a dominant locale, its also possible to reconfigure to eliminate the C locale, and put the pl translation into header content (as if it were the "C" locale) See RPMBUILD_DEFAULT_LANG (currently "C", but trivial to turn into a macro). hth 73 de Jeff From jajcus at jajcus.net Mon Apr 25 10:26:11 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 25 Apr 2016 10:26:11 +0200 Subject: [packages/python3] - use 'share' not 'lib' for platform independent files - rel 3 In-Reply-To: References: Message-ID: <7f19cbf4-2af8-e0ad-1053-383287b757da@jajcus.net> On 2016-04-23 22:45, baggins wrote: > commit f69d21534e5f5805751fca202e9e2ae82cb10d35 > Author: Jan R?korajski > Date: Sat Apr 23 22:44:51 2016 +0200 > > - use 'share' not 'lib' for platform independent files > - rel 3 > > python3-multilib.patch | 6 ++---- > python3.spec | 2 +- > 2 files changed, 3 insertions(+), 5 deletions(-) > --- > diff --git a/python3.spec b/python3.spec > index e89ded1..694d20f 100644 > --- a/python3.spec > +++ b/python3.spec > @@ -34,7 +34,7 @@ Summary(tr.UTF-8): X aray?zl?, y?ksek d?zeyli, kabuk yorumlay?c? dili > Summary(uk.UTF-8): ???? ????????????? ???? ???????? ????? ? X-??????????? > Name: python3 > Version: %{py_ver}.1 > -Release: 2 > +Release: 3 > Epoch: 1 > License: PSF > Group: Development/Languages/Python > diff --git a/python3-multilib.patch b/python3-multilib.patch > index 30e0e94..f5a49b0 100644 > --- a/python3-multilib.patch > +++ b/python3-multilib.patch > @@ -52,7 +52,7 @@ diff -dur Python-3.5.0.orig/Lib/distutils/sysconfig.py Python-3.5.0/Lib/distutil > + if plat_specific: > + lib = sys.lib > + else: > -+ lib = 'lib' > ++ lib = 'share' > libpython = os.path.join(prefix, > - "lib", "python" + get_python_version()) > + lib, "python" + get_python_version()) You are probably breaking pypi and /usr/local installs again! Proper directories for RPM packages are set with setup.py options via %py_build/%py_install macros. Packages not using distutils/setuptools may need patching, but that is better than breaking Python for non-RPM usage. Jacek From glen at pld-linux.org Mon Apr 25 10:54:00 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 25 Apr 2016 11:54:00 +0300 Subject: rpm-5.4.16-0.20160321.src.rpm, take 3 In-Reply-To: <21E872CB-C82B-49B9-98A7-46F48228C7D2@mac.com> References: <7DE4F56A-3BA3-4DE6-9DCA-F3545CD8722F@mac.com> <20160424102939.GA4333@home> <9B037FF3-4CC8-4D9D-AEA2-0CDD30FE66B1@mac.com> <571D1E87.8000207@pld-linux.org> <21E872CB-C82B-49B9-98A7-46F48228C7D2@mac.com> Message-ID: <571DDB28.1040607@pld-linux.org> On 24.04.2016 22:42, Jeff Johnson wrote: > For a national distro with a dominant locale, its also possible to > reconfigure to eliminate the C locale, and put the pl translation > into header content (as if it were the "C" locale) pld is not polish linux distribution no more, it's pld linux distribution! thus completely international! afaik the name changed after 2003 fork (pld.org.pl -> pld-linux.org) https://www.pld-linux.org/faq#what_does_the_acronym_pld_stand_for -- glen From j.rekorajski at gmail.com Tue Apr 26 09:14:34 2016 From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=) Date: Tue, 26 Apr 2016 09:14:34 +0200 Subject: [packages/python3] - use 'share' not 'lib' for platform independent files - rel 3 In-Reply-To: <7f19cbf4-2af8-e0ad-1053-383287b757da@jajcus.net> References: <7f19cbf4-2af8-e0ad-1053-383287b757da@jajcus.net> Message-ID: On Mon, Apr 25, 2016 at 10:26 AM, Jacek Konieczny wrote: > On 2016-04-23 22:45, baggins wrote: > >> commit f69d21534e5f5805751fca202e9e2ae82cb10d35 >> Author: Jan R?korajski >> Date: Sat Apr 23 22:44:51 2016 +0200 >> >> - use 'share' not 'lib' for platform independent files >> - rel 3 >> >> python3-multilib.patch | 6 ++---- >> python3.spec | 2 +- >> 2 files changed, 3 insertions(+), 5 deletions(-) >> --- >> diff --git a/python3.spec b/python3.spec >> index e89ded1..694d20f 100644 >> --- a/python3.spec >> +++ b/python3.spec >> @@ -34,7 +34,7 @@ Summary(tr.UTF-8): X aray?zl?, y?ksek d?zeyli, kabuk >> yorumlay?c? dili >> Summary(uk.UTF-8): ???? ????????????? ???? ???????? ????? ? >> X-??????????? >> Name: python3 >> Version: %{py_ver}.1 >> -Release: 2 >> +Release: 3 >> Epoch: 1 >> License: PSF >> Group: Development/Languages/Python >> diff --git a/python3-multilib.patch b/python3-multilib.patch >> index 30e0e94..f5a49b0 100644 >> --- a/python3-multilib.patch >> +++ b/python3-multilib.patch >> @@ -52,7 +52,7 @@ diff -dur Python-3.5.0.orig/Lib/distutils/sysconfig.py >> Python-3.5.0/Lib/distutil >> + if plat_specific: >> + lib = sys.lib >> + else: >> -+ lib = 'lib' >> ++ lib = 'share' >> libpython = os.path.join(prefix, >> - "lib", "python" + get_python_version()) >> + lib, "python" + get_python_version()) >> > > You are probably breaking pypi and /usr/local installs again! > > Proper directories for RPM packages are set with setup.py options via > %py_build/%py_install macros. Packages not using distutils/setuptools may > need patching, but that is better than breaking Python for non-RPM usage. > It caused distutils.sysconfig.get_python_lib() to return /usr/lib for platform independent modules location which is not what we want and breaks automake's python.m4. -- Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ bagginspld-linux.org From jajcus at jajcus.net Tue Apr 26 09:37:57 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 26 Apr 2016 09:37:57 +0200 Subject: [packages/python3] - use 'share' not 'lib' for platform independent files - rel 3 In-Reply-To: References: <7f19cbf4-2af8-e0ad-1053-383287b757da@jajcus.net> Message-ID: <01d3014b-1a62-7080-bbc7-e9673d18a11a@jajcus.net> On 2016-04-26 09:14, Jan R?korajski wrote: >> You are probably breaking pypi and /usr/local installs again! >> >> Proper directories for RPM packages are set with setup.py options via >> %py_build/%py_install macros. Packages not using distutils/setuptools may >> need patching, but that is better than breaking Python for non-RPM usage. >> > > It caused distutils.sysconfig.get_python_lib() to return /usr/lib for > platform independent modules location which is not what we want and breaks > automake's python.m4. I am sure I have left this for purpose. Many python packages, including 'core' ones, like setuptools/pip/virtualenv assume that python_lib is ${prefix}/lib. Things were quite broken when we patched Python to do things 'the right way'. We only need to force platform independent modules installed in /usr/share when building RPM packages and that is mostly solved by our %py_build/%py_install macros. The few packages left can always be patched. That said? I have tested the python3 package after your change to find what has been broken? and failed to get the expected results. Either I cannot recall the exact thing broken (I have tested various pip and virtualenv usage, using upstream packages) or this one change doesn't break anything (the 'lib' is hardcoded in a similar way in a few places, IIRC). So it is possible that nothing have been broken in this case, but we should be very careful about this. virtualenv and pip _must_ work properly with unpatched upstream code for /usr/local and $HOME installs ? that is how lots of Python packages is expected to be installed and we are not able to package everything ourselves. Jacek From glen at pld-linux.org Wed Apr 27 09:13:40 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 27 Apr 2016 10:13:40 +0300 Subject: how rpm destroyed my private key Message-ID: <572066A4.8090502@pld-linux.org> and it did it again! scenario: package version1 installed, i have file secret_key.php in filesystem, which is not (yet) packaged. i create package version2, which has: %attr(640,root,http) %config(noreplace) %verify(not md5 mtime size) %{_webappdir}/secret_key.php secret_key.php is 0 byte file in package. now i upgrade package version1->version2, the file is just replaced with empty file. no .rpmsave, no .rpmnew, no nothing. it just nuked the damn file. i have repackage enabled, and the secret_key.php is not present even repackage file. i have to go to extract the file from bacula backup! -- glen From glen at delfi.ee Wed Apr 27 11:50:52 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 27 Apr 2016 12:50:52 +0300 Subject: dracut Message-ID: <57208B7C.5010808@delfi.ee> anyone tried dracut lately? does the output below indicate failure? root at silenoz /tmp# rpm -ihv kernel-4.4.6-1.x86_64.rpm kernel-virtualbox-host-5.0.16-1 at 4.4.6_1.x86_64.rpm Preparing... ########################################### [100%] 1:kernel ########################################### [ 50%] WARNING: Vserver support is DISABLED in this kernel build! 2:kernel-virtualbox-host ########################################### [100%] /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. dracut: systemd-initrd needs systemd in the initramfs dracut: dracut-systemd needs systemd-initrd in the initramfs /usr/lib/dracut/modules.d/99base/module-setup.sh: line 15: /var/tmp/dracut.vkZlVJ/initramfs/usr/lib/initrd-release: No such file or directory ln: failed to create symbolic link '/var/tmp/dracut.vkZlVJ/initramfs/usr/lib/os-release': No such file or directory dracut-install: ERROR: installing 'losetup' dracut: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.vkZlVJ/initramfs -a umount poweroff reboot halt losetup dracut-install: ERROR: installing 'open' dracut: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.vkZlVJ/initramfs -a vi /etc/vim/vimrc ps grep cat rm open File descriptor 3 (/dev/null) leaked on vgs invocation. Parent PID 2693: /sbin/grub-probe /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. File descriptor 3 (/dev/null) leaked on vgs invocation. Parent PID 2693: /sbin/grub-probe /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. File descriptor 3 (/dev/null) leaked on vgs invocation. Parent PID 2894: /sbin/grub-probe /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. File descriptor 3 (/dev/null) leaked on vgs invocation. Parent PID 2894: /sbin/grub-probe /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. 12:49:34 [load: 0.85 10,62% nproc: 8] root at silenoz /tmp# rpm -qf /etc/os-release pld-release-3.0-7.noarch 12:49:40 [load: 0.78 9,75% nproc: 8] root at silenoz /tmp# q dracut dracut-044-1.x86_64 -- glen From n3npq at mac.com Wed Apr 27 15:55:01 2016 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 27 Apr 2016 09:55:01 -0400 Subject: how rpm destroyed my private key In-Reply-To: <572066A4.8090502@pld-linux.org> References: <572066A4.8090502@pld-linux.org> Message-ID: <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> On Apr 27, 2016, at 3:13 AM, Elan Ruusam?e wrote: > and it did it again! > You are smart enough to identify a better solution for your problems than blaming RPM for destroying your files ... again ... and again. 73 de Jeff From glen at pld-linux.org Wed Apr 27 16:12:52 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 27 Apr 2016 17:12:52 +0300 Subject: how rpm destroyed my private key In-Reply-To: <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> References: <572066A4.8090502@pld-linux.org> <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> Message-ID: <5720C8E4.3020209@pld-linux.org> On 27.04.2016 16:55, Jeff Johnson wrote: > On Apr 27, 2016, at 3:13 AM, Elan Ruusam?e wrote: > >> and it did it again! >> > You are smart enough to identify a better solution for your problems than blaming RPM > for destroying your files ... again ... and again. meh? i described scenario that is complete for interested party to be able to reproduce and witness the destruction. please explain how is that my problem that rpm replaced file marked as %config(noreplace) on package installation not rpm's? i'm not convinced. -- glen From n3npq at mac.com Wed Apr 27 19:08:44 2016 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 27 Apr 2016 13:08:44 -0400 Subject: how rpm destroyed my private key In-Reply-To: <5720C8E4.3020209@pld-linux.org> References: <572066A4.8090502@pld-linux.org> <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> <5720C8E4.3020209@pld-linux.org> Message-ID: On Apr 27, 2016, at 10:12 AM, Elan Ruusam?e wrote: > On 27.04.2016 16:55, Jeff Johnson wrote: >> On Apr 27, 2016, at 3:13 AM, Elan Ruusam?e wrote: >> >>> and it did it again! >>> >> You are smart enough to identify a better solution for your problems than blaming RPM >> for destroying your files ... again ... and again. > > meh? > > i described scenario that is complete for interested party to be able to reproduce and witness the destruction. > > please explain how is that my problem that rpm replaced file marked as %config(noreplace) on package installation not rpm's? i'm not convinced. > Sorry to be snarky ... we have gone through %config handling many many times. In the v1 package, secret_key.php is _NOT_ in a package. Which means: 1) there is no way to tell if the file is modified, owned, timestamped, should be present, etc. In the v2 package, secret_key.php is present and marked with %config(noreplace). You are expecting rpm to rename secret_key.php before installing the v2 file to preserve the contents because you have marked the file with %config(noreplace) The %config(noreplace) handling in RPM is a decision tree based on being able to detect whether a file is "modified". RPM will happily replace unmodified config files with altered content even when the previous file differs. This is exactly the behavior one expects when the newer config file has been changed, and that other executables (like daemons) which will be restarted, are implicitly dependent on the new configuration. RPM also goes to lengths to save "modified" %config files when they are included in packages, as we all know. The unmanaged version of secret_key.php that is installed does not have a record in the rpmdb that permits detecting whether a file is "modified". So RPM replaces (not "destroys") the file just like any archiver would do. This is exactly the behavior one expects in the following circumstances 1) converting an unmanaged -> managed package where "modified" can be computed 2) replacing a misconfigured manually installed set of files with a package Your expectations have confused the existing %config(noreplace) behavior with other archiver behaviors. E.g. tar(1) has a number of "overwrite controi" options --keep-old-files --keep-newer-files --overwrite-dir --preserve-permissions I doubt you would be surprised if you extracted a tar archive that "destroyed" secret_key.php, particularly if you had forgotten to add options that might have prevented overwriting. Similarly, if you added tar options wrongly and then found that, say, a daemon would not restart because some config file was _NOT_ replaced as expected, I doubt that you would be surprised. So why are you claiming RPM "destroyed" your secret_key.php file when you are misusing %config(noreplace) with expectations of behavior that have never been implemented, and cannot be implemented because there is no reference copy of metadata information needed to compute "modified", and are in general confusing %config handling with --nooverwrite behavior? 73 de Jeff From n3npq at mac.com Wed Apr 27 20:09:58 2016 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 27 Apr 2016 14:09:58 -0400 Subject: how rpm destroyed my private key In-Reply-To: References: <572066A4.8090502@pld-linux.org> <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> <5720C8E4.3020209@pld-linux.org> Message-ID: <4118F47A-3ADF-406A-9576-3F2A24F5F792@mac.com> On Apr 27, 2016, at 1:08 PM, Jeff Johnson wrote: > > So why are you claiming RPM "destroyed" your secret_key.php file when you are misusing > %config(noreplace) > with expectations of behavior that have never been implemented, and cannot be implemented > because there is no reference copy of metadata information needed to compute "modified", and > are in general confusing %config handling with --nooverwrite behavior? > Let's try and make this positive, shall we? I suspect that if you registered a closer (including secret_key.php) approximation to the existing installed (but unmanaged) files, that some of your expectations with %config(noreplace) renaming might Just Work. What I am suggesting is using --justdb --noscripts --notriggers on the v2 package before attempting an upgrade. That might (entirely untested) provide a reference point to compute "modified" that will trigger %config renaming when you reinstall (or erasing with --repackage) the v2 package. Expecting --repackage of the v1 package to somehow preserve secret_key.php (which isn't included in the v1 package) to preserve the file does not make any sense whatsoever. It would not be too hard to add a %nooverwrite (or %noclobber) attribute to spec files and packages (but I suspect that there is a vanishingly small usage case). hth 73 de Jeff From glen at pld-linux.org Thu Apr 28 10:32:38 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 28 Apr 2016 11:32:38 +0300 Subject: how rpm destroyed my private key In-Reply-To: References: <572066A4.8090502@pld-linux.org> <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> <5720C8E4.3020209@pld-linux.org> Message-ID: <5721CAA6.1000304@pld-linux.org> On 27.04.2016 20:08, Jeff Johnson wrote: > In the v1 package, secret_key.php is_NOT_ in a package. > Which means: > 1) there is no way to tell if the file is modified, owned, timestamped, should be present, etc. i will make it very short of my expectation on rpm behaviour: as there's no way to tell. i'd expect rpm assume the file is modified. -- glen From glen at pld-linux.org Thu Apr 28 10:41:19 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 28 Apr 2016 11:41:19 +0300 Subject: how rpm destroyed my private key In-Reply-To: References: <572066A4.8090502@pld-linux.org> <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> <5720C8E4.3020209@pld-linux.org> Message-ID: <5721CCAF.7070703@pld-linux.org> On 27.04.2016 20:08, Jeff Johnson wrote: > I doubt you would be surprised if you extracted a tar archive that "destroyed" secret_key.php, > particularly if you had forgotten to add options that might have prevented overwriting. Similarly, > if you added tar options wrongly and then found that, say, a daemon would not restart because > some config file was_NOT_ replaced as expected, I doubt that you would be surprised. please don't compare rpm with tar. i would never expect tar to skip extracting files. i always extract it to empty dir. but rpm i use to manage configuration and expect %noreplace to mean "do not replace the file". that one technical detail makes it behave differently on high level does not change my expectation. i'd rather consider it flaw in implementation. and that it has been so in last two decades, doesn't mean it has to stay so. there are VENDOR_PLD conditions if that rpm5.org maintainers do not consider usable for everybody. you explained why it overwrote. good, at least you accept that it really does that now. but i'm not interested preserving that behaviour, i don't think anybody in pld (or rpm users) like to expect such behaviour. i can likely WORKAROUND that with rpm pretrans triggers to move away the file that rpm would otherwise overwrite. but it's hack, highly unmaintainable: i should do that only when the specific transaaction is done (nofile->packaged file), because if i do that always, i will lose the benefits of %config at all. such workarounds have been implemented on critical files in the past, because there doesn't seem to be solution from rpm-side. (and don't see anybody willing to code it) -- glen From glen at pld-linux.org Thu Apr 28 10:43:39 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 28 Apr 2016 11:43:39 +0300 Subject: how rpm destroyed my private key In-Reply-To: <4118F47A-3ADF-406A-9576-3F2A24F5F792@mac.com> References: <572066A4.8090502@pld-linux.org> <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> <5720C8E4.3020209@pld-linux.org> <4118F47A-3ADF-406A-9576-3F2A24F5F792@mac.com> Message-ID: <5721CD3B.6070500@pld-linux.org> On 27.04.2016 21:09, Jeff Johnson wrote: > What I am suggesting is using --justdb --noscripts --notriggers on the v2 package before attempting an upgrade. you're solving the problem in wrong order. suggesting to use --justdb --notriggers --notriggers means i already know that specific package upgrade path is broken. but the time i found that out it's already late, file is destroyed and there's no recovery path from rpm (even repackage did not "save" me a copy). and the solution should be independant who runs the upgrade. should behave similarily to all users who upgrade the package. -- glen From glen at delfi.ee Thu Apr 28 15:18:57 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 28 Apr 2016 16:18:57 +0300 Subject: rcd down Message-ID: <57220DC1.5070107@delfi.ee> wget http://rescuecd.pld-linux.org/beta/RCDx86_13_03_10.iso --2016-04-28 16:18:31-- http://rescuecd.pld-linux.org/beta/RCDx86_13_03_10.iso Resolving rescuecd.pld-linux.org (rescuecd.pld-linux.org)... 91.193.144.110 Connecting to rescuecd.pld-linux.org (rescuecd.pld-linux.org)|91.193.144.110|:80... failed: Connection refused. -- glen From qboosh at pld-linux.org Thu Apr 28 16:15:36 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 28 Apr 2016 16:15:36 +0200 Subject: [packages/gcc] move packages around to have epoch correct In-Reply-To: References: Message-ID: <20160428141536.GA4511@mail> On Thu, Apr 28, 2016 at 09:32:57AM +0200, glen wrote: > commit a4c51f7ce5c5bc00c0406c1b62c370ab5aeecb4c > Author: Elan Ruusam?e > Date: Thu Apr 28 10:32:51 2016 +0300 > > move packages around to have epoch correct IMO it's not worth the effort. And it adds additional information to remember/check (which gcc packages have epoch 0 and which the main value). -- Jakub Bogusz http://qboosh.pl/ From n3npq at mac.com Thu Apr 28 19:38:49 2016 From: n3npq at mac.com (Jeff Johnson) Date: Thu, 28 Apr 2016 13:38:49 -0400 Subject: how rpm destroyed my private key In-Reply-To: <5721CCAF.7070703@pld-linux.org> References: <572066A4.8090502@pld-linux.org> <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> <5720C8E4.3020209@pld-linux.org> <5721CCAF.7070703@pld-linux.org> Message-ID: <19414C71-ABE2-4DEF-BFE2-3F81F744C16A@mac.com> On Apr 28, 2016, at 4:41 AM, Elan Ruusam?e wrote: > > but rpm i use to manage configuration and expect %noreplace to mean "do not replace the file". that one technical detail makes it behave differently on high level does not change my expectation. i'd rather consider it flaw in implementation. and that it has been so in last two decades, doesn't mean it has to stay so. there are VENDOR_PLD conditions if that rpm5.org maintainers do not consider usable for everybody. > Yes, "noreplace" has an ambiguous meaning that is non-intuitive. The intuitive meaning of "noreplace" is Never replace Meanwhile -- as I have pointed out -- %config(noreplace) was designed to replace unmodified existing config files with different content, and -- as you have pointed out -- will replace pre-existing files. Both behaviors are intentional in %config handling when implemented and cannot easily be changed without triggering a couple years of confusion. Meanwhile, the whole %config renaming needs to be abandoned in favor of an etckeeper approach to do checkins instead of renaming. RPM has embedded libgit2 sufficiently well enough to do simple checkins. A more complete solution awaits some distro willing to work through the remaining details for an entire distribution. 73 de Jeff From n3npq at mac.com Thu Apr 28 19:42:01 2016 From: n3npq at mac.com (Jeff Johnson) Date: Thu, 28 Apr 2016 13:42:01 -0400 Subject: how rpm destroyed my private key In-Reply-To: <5721CD3B.6070500@pld-linux.org> References: <572066A4.8090502@pld-linux.org> <1EE2C5E5-80DB-4071-AC60-774A7883C532@mac.com> <5720C8E4.3020209@pld-linux.org> <4118F47A-3ADF-406A-9576-3F2A24F5F792@mac.com> <5721CD3B.6070500@pld-linux.org> Message-ID: <7AA10EC5-CE94-4155-8F07-DF7A3DC562EA@mac.com> On Apr 28, 2016, at 4:43 AM, Elan Ruusam?e wrote: > On 27.04.2016 21:09, Jeff Johnson wrote: >> What I am suggesting is using --justdb --noscripts --notriggers on the v2 package before attempting an upgrade. > > you're solving the problem in wrong order. suggesting to use --justdb --notriggers --notriggers means i already know that specific package upgrade path is broken. > but the time i found that out it's already late, file is destroyed and there's no recovery path from rpm (even repackage did not "save" me a copy). > I'm not solving any problem whatsoever. I was asking Does preinstalling with --justdb "work" as you expected? > and the solution should be independant who runs the upgrade. should behave similarily to all users who upgrade the package. > Again, no "solution" with %config(noreplace) was suggested or intended. I did suggest a %noclobber attribute which you have chosen to ignore. 73 de Jeff