From jajcus at jajcus.net Mon Sep 5 12:48:41 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 5 Sep 2016 12:48:41 +0200 Subject: distfiles misbehaving Message-ID: Distfiles truncated an archive I have just uploaded there: [jajcus at jajo tmp]$ wget http://distfiles.pld-linux.org/distfiles/by-md5/6/6/66f3cfc0f6c3963a6c6c41e741b1518a/compton-20160811.tar.xz --2016-09-05 12:45:20-- http://distfiles.pld-linux.org/distfiles/by-md5/6/6/66f3cfc0f6c3963a6c6c41e741b1518a/compton-20160811.tar.xz Resolving distfiles.pld-linux.org (distfiles.pld-linux.org)... 193.239.45.41 Connecting to distfiles.pld-linux.org (distfiles.pld-linux.org)|193.239.45.41|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 65536 (64K) [application/octet-stream] Saving to: ?compton-20160811.tar.xz? compton-20160811.ta 100%[=====================>] 64.00K --.-KB/s in 0.04s 2016-09-05 12:45:21 (1.46 MB/s) - ?compton-20160811.tar.xz? saved [65536/65536] [jajcus at jajo tmp]$ file compton-20160811.tar.xz compton-20160811.tar.xz: XZ compressed data [jajcus at jajo tmp]$ ls -l compton-20160811.tar.xz ~/rpm/packages/compton/compton-20160811.tar.xz -rw-r--r-- 1 jajcus users 65536 Sep 5 11:27 compton-20160811.tar.xz -rw-r--r-- 1 jajcus users 130628 Sep 5 11:04 /home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz [jajcus at jajo tmp]$ md5sum compton-20160811.tar.xz /home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz 1ae2151dce0460c57c53410ce198067e compton-20160811.tar.xz 66f3cfc0f6c3963a6c6c41e741b1518a /home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz Jacek From glen at pld-linux.org Mon Sep 5 18:12:07 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 5 Sep 2016 19:12:07 +0300 Subject: distfiles misbehaving In-Reply-To: References: Message-ID: <57CD9957.2000406@pld-linux.org> if you had fixed your @pld-linux mail alias, you would probably had received error message of the first upload: On 05.09.2016 12:38, jajcus wrote: > Request by: jajcus > > scp problems: scp -pr -B -q ./tmp/349960f1-6fb2-4ed7-bbfc-c95b969ae301/66f3cfc0f6c3963a6c6c41e741b1518a/ plddist at distfiles.pld-linux.org:ftp//by-md5/6/6: > lost connection > > The command has exited with a non-zero status. > > Files fetched: 0 > altho i do agree here that distfiles should use temp files when copying and move to final name if all was correct. On 05.09.2016 13:48, Jacek Konieczny wrote: > > Distfiles truncated an archive I have just uploaded there: > > [jajcus at jajo tmp]$ wget > http://distfiles.pld-linux.org/distfiles/by-md5/6/6/66f3cfc0f6c3963a6c6c41e741b1518a/compton-20160811.tar.xz > --2016-09-05 12:45:20-- > http://distfiles.pld-linux.org/distfiles/by-md5/6/6/66f3cfc0f6c3963a6c6c41e741b1518a/compton-20160811.tar.xz > Resolving distfiles.pld-linux.org (distfiles.pld-linux.org)... > 193.239.45.41 > Connecting to distfiles.pld-linux.org > (distfiles.pld-linux.org)|193.239.45.41|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 65536 (64K) [application/octet-stream] > Saving to: ?compton-20160811.tar.xz? > > compton-20160811.ta 100%[=====================>] 64.00K --.-KB/s in > 0.04s > > 2016-09-05 12:45:21 (1.46 MB/s) - ?compton-20160811.tar.xz? saved > [65536/65536] > > [jajcus at jajo tmp]$ file compton-20160811.tar.xz > compton-20160811.tar.xz: XZ compressed data > [jajcus at jajo tmp]$ ls -l compton-20160811.tar.xz > ~/rpm/packages/compton/compton-20160811.tar.xz > -rw-r--r-- 1 jajcus users 65536 Sep 5 11:27 compton-20160811.tar.xz > -rw-r--r-- 1 jajcus users 130628 Sep 5 11:04 > /home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz > > [jajcus at jajo tmp]$ md5sum compton-20160811.tar.xz > /home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz > 1ae2151dce0460c57c53410ce198067e compton-20160811.tar.xz > 66f3cfc0f6c3963a6c6c41e741b1518a > /home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz > > Jacek -- glen From jajcus at jajcus.net Mon Sep 5 22:28:03 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 05 Sep 2016 22:28:03 +0200 Subject: distfiles misbehaving In-Reply-To: <57CD9957.2000406@pld-linux.org> References: <57CD9957.2000406@pld-linux.org> Message-ID: <57CDD553.1060204@jajcus.net> On 2016-09-05 18:12, Elan Ruusam?e wrote: > if you had fixed your @pld-linux mail alias, you would probably had > received error message of the first upload: How would it help? I already know it didn't work. And I got the error message from distfiles after pushing the spec commit. > altho i do agree here that distfiles should use temp files when copying > and move to final name if all was correct. That is why I am reporting this here. I hoped someone here can fix this manually or show me the way to force reupdate. Jacek From glen at pld-linux.org Tue Sep 6 13:03:26 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 6 Sep 2016 14:03:26 +0300 Subject: systemd macros In-Reply-To: <20160906101128.GA22080@polanet.pl> References: <57CDDCAD.8010508@pld-linux.org> <20160906101128.GA22080@polanet.pl> Message-ID: <57CEA27E.5050300@pld-linux.org> (cc: devel-en list) On 06.09.2016 13:11, gotar wrote: > On Mon, Sep 05, 2016 at 23:59:25 +0300, Elan Ruusam?e wrote: > >> plz recheck your macros >> >> this looks suspicious: >> >> foo || >/dev/null > And it was wrong. There might be some other bogus code paths I didn't > reached... > > I don't like our approach with hardcoding these macros as scripts in rpm > packages, I'd be better (to update, test and maintain) to have them sit > directly in filesystem, externally to rpm package. yeap. i had this problem in 2005 already (%useradd, %service macros) > Currently we have to > rebuild package to carry in some changes, e.g. my last change disabling > fsync() on update-mime-database. If it happens that we want to reenable > it, second run of rebuild is required (in such case I have had prepared > sysconfig/rpm to handle fsync() switch variable). we have some macros handled in filesystem, but owned by rpm.spec not rpm-build-macros.spec $ rpm -ql rpm-base /etc/rpm /etc/sysconfig/rpm /usr/bin/banner.sh /usr/lib/rpm /usr/lib/rpm/user_group.sh /var/lib/banner thus, %banner and %userremove macros only i guess simplest would be to move them (with file history) to rpm-build-macros package, and build rpm-base from rpm-build-macro.spec package -- glen From glen at delfi.ee Thu Sep 8 09:39:42 2016 From: glen at delfi.ee (=?utf-8?Q?Elan_Ruusam=C3=A4e?=) Date: Thu, 8 Sep 2016 10:39:42 +0300 Subject: poldek 64k Message-ID: the problem is back, or it wasn?t never solved? poldek-0.32.2-1.x86_64: equal version installed, skipped # poldek --sn th-archive Loading [pndir]th-archive... Loading [pndir]th-archive... Something wrong, something not quite right with 0.32.2 (stable) Assertion '*v < UINT16_MAX - 1' failed, ./trurlib/include/trurl/n_obj_ref.h:19 Please report this bug to: http://bugs.launchpad.net/poldek Aborted From glen at pld-linux.org Fri Sep 9 23:14:17 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sat, 10 Sep 2016 00:14:17 +0300 Subject: daemon --makepid --fork Message-ID: <57D32629.5010401@pld-linux.org> to cut to the chase, looks like there's problem with using both of those flags together: 1. if RC_LOGGING=yes the the pid written to pidfile is correct but process started has fd=1 and fd=2 pipe which is disconnected after initlog exits. no process likes this, some abort when they receive SIGPIPE 2. if RC_LOGGING=no the pid written to file is incorrect, it's sone actual_pid+N, where N is 1-2 stdin,stdout are /dev/null, so that is fine for most of the processes where we want to do "daemonize" for themselves. for first problem, could solve this by >/dev/null 2>/dev/null in our makepid script this means that initlog will not "capture" or "see" anything from those processes for second problem, probably could use our makepid wrapper instead of using --makepid from start-stop-daemon. i've committed 43f8f34 to rc-scripts repo where such behaviour could be analyzed ps: know any good framework to use to write such tests for shell scripts? ps2: usually i'd say lets rip out the RC_LOGGING=yes code, but seems RC_LOGGING=no isn't much used by other pld devs than me, so it's not probably most compatible and has unexpected results (like this bugreport about wring pid written). most horrible experience was causing lighttpd terminated with SIGKILL every time logrotate ran at night, fixed by this commit: commit 6154a5cecca4c7cf7252a230f81d2fa913c0bfab Author: Elan Ruusam?e Date: Wed Dec 5 20:54:15 2012 +0000 killproc: improve experimental start-stop-daemon based killing. do not send --retry, in case we specify a signal to kill (usually HUP) as processes do not usually exit (remove their pid from pidfile) if they receive HUP svn-id: @12603 ps3: don't bother replying something poisonous about why don't i go use systemd. -- glen From glen at pld-linux.org Fri Sep 9 23:25:41 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sat, 10 Sep 2016 00:25:41 +0300 Subject: daemon --makepid --fork In-Reply-To: <57D32629.5010401@pld-linux.org> References: <57D32629.5010401@pld-linux.org> Message-ID: <57D328D5.9020308@pld-linux.org> On 10.09.2016 00:14, Elan Ruusam?e wrote: > > 2. if RC_LOGGING=no > the pid written to file is incorrect, it's sone actual_pid+N, where N > is 1-2 glad i wrote the email, solved this problem. the other one still remains fix is in this commit: b402dd3f91a54c34d9eaf99bee8e4a129286c749 -- glen From gotar at polanet.pl Sat Sep 10 06:23:58 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 10 Sep 2016 06:23:58 +0200 Subject: rpm --nosignature reversed meaning In-Reply-To: <20160830110325.GK18894@polanet.pl> References: <20160829225349.GA12506@polanet.pl> <20160830091701.GC18894@polanet.pl> <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> Message-ID: <20160910042358.GA8602@polanet.pl> On Tue, Aug 30, 2016 at 13:03:25 +0200, Tomasz Pala wrote: > Since we got the answer for this issue - th-admin, please publish separate GPG files. Are we announcing PLD being dead? Current DSA+RSA GPG key is unusable for rpm, the one from FTP is being packaged, so it's also unusable. Nobody cares? -- Tomasz Pala From glen at pld-linux.org Sat Sep 10 10:41:46 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sat, 10 Sep 2016 11:41:46 +0300 Subject: rpm --nosignature reversed meaning In-Reply-To: <20160910042358.GA8602@polanet.pl> References: <20160829225349.GA12506@polanet.pl> <20160830091701.GC18894@polanet.pl> <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> Message-ID: <57D3C74A.2000607@pld-linux.org> On 10.09.2016 07:23, Tomasz Pala wrote: > On Tue, Aug 30, 2016 at 13:03:25 +0200, Tomasz Pala wrote: > >> Since we got the answer for this issue - th-admin, please publish separate GPG files. > Are we announcing PLD being dead? Current DSA+RSA GPG key is unusable > for rpm, the one from FTP is being packaged, so it's also unusable. > Nobody cares? and you really expecting th-admin picking up a task middle of huge thread? you should had asked it from th-admin at pld-linux.org (or at least cc:). i don't bother understanding what this topic is about -- packages install for me. but, i could upload the files if you make concrete request with details what needs to be done, and do that in in separate mailing thread (new thread), or even better open new ticket at bugs.pld-linux.org -- glen From gotar at polanet.pl Sat Sep 10 12:53:25 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 10 Sep 2016 12:53:25 +0200 Subject: rpm --nosignature reversed meaning In-Reply-To: <57D3C74A.2000607@pld-linux.org> References: <20160829225349.GA12506@polanet.pl> <20160830091701.GC18894@polanet.pl> <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> Message-ID: <20160910105325.GA22565@polanet.pl> On Sat, Sep 10, 2016 at 11:41:46 +0300, Elan Ruusam?e wrote: >>> Since we got the answer for this issue - th-admin, please publish separate GPG files. >> Are we announcing PLD being dead? Current DSA+RSA GPG key is unusable >> for rpm, the one from FTP is being packaged, so it's also unusable. >> Nobody cares? > > and you really expecting th-admin picking up a task middle of huge > thread? you should had asked it from th-admin at pld-linux.org (or at least > cc:). Indeed, forgot to do so. > i don't bother understanding what this topic is about -- packages > install for me. RPM doesn't support subkeys, but we do not provide separate DSA key. Easy to test: 1. disable using keyserver: %_hkp_keyserver %{nil} 2. import joined key we do provide: rpm --import /etc/pki/rpm-gpg/PLD-3.0-Th-GPG-key.asc 3. try to verify any PLD package. > but, i could upload the files if you make concrete request with details > what needs to be done, GPG key that is being used for package signing needs to published (the public part of course). Note the singular 'key', NOT plural 'keyS'. One per file, if there are multiple keys used. Currently ftp://ftp.pld-linux.org/dists/3.0/PLD-3.0-Th-GPG-key.asc provides two (however I haven't seen any package signed by RSA one, AFAIR.) > and do that in in separate mailing thread (new thread), or even better > open new ticket at bugs.pld-linux.org I already did my job. If nobody notices nor cares this, well, we might safely assure that PLD is dead. There was also second part of this thread, the one that concludes with 'PLD-provided rpm is broken'. If somebody messed with rpm signature verification bits in PLD, he REALLY SHOULD read this thread. Otherwise we might as well assume that PLD is dead (since nobody cares about the most crucial part of infrastructure). Moreover, I don't see any reason to break this thread into separate one - the subject is appropriate from the very beginning, and this (in rpm-part at least, not th-admin request) is not some middle point of discussion, but END OF THREAD. Everything that was to be discussed is settled now, the only thing left to do is finding the patch that breaks our rpm and reverting it. Since nobody playing with rpm did this, my GUESS is, that: rpm-5.4.9-support-signatures-and-digest-disablers.patch is not enough/complete. And I've just found this (some 'triple negation' issues), as recently noted in http://rpm5.org/community/rpm-devel/5655.html Jeff, this seems to BE the case - verification is reverted only for --query mode, --verify mode works as expected. We might simply test this: https://patchwork.openembedded.org/patch/126825/raw/ -- Tomasz Pala From gotar at polanet.pl Sat Sep 10 13:48:42 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 10 Sep 2016 13:48:42 +0200 Subject: rpm --nosignature reversed meaning In-Reply-To: <20160910105325.GA22565@polanet.pl> References: <20160830091701.GC18894@polanet.pl> <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> <20160910105325.GA22565@polanet.pl> Message-ID: <20160910114842.GA25129@polanet.pl> On Sat, Sep 10, 2016 at 12:53:25 +0200, Tomasz Pala wrote: > our rpm and reverting it. Since nobody playing with rpm did this, my > GUESS is, that: > > rpm-5.4.9-support-signatures-and-digest-disablers.patch > > is not enough/complete. And I've just found this (some 'triple negation' issues), as recently noted in > http://rpm5.org/community/rpm-devel/5655.html > > Jeff, this seems to BE the case - verification is reverted only for > --query mode, --verify mode works as expected. > > We might simply test this: > > https://patchwork.openembedded.org/patch/126825/raw/ Now it works as expected: ftp://ftp.th.pld-linux.org/dists/th/.test-builds/x86_64/rpm-5.4.15-35.x86_64.rpm ftp://ftp.th.pld-linux.org/dists/th/.test-builds/x86_64/rpm-lib-5.4.15-35.x86_64.rpm ftp://ftp.th.pld-linux.org/dists/th/.test-builds/x86_64/rpm-utils-5.4.15-35.x86_64.rpm -- Tomasz Pala From n3npq at me.com Sat Sep 10 15:46:17 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Sat, 10 Sep 2016 09:46:17 -0400 Subject: rpm --nosignature reversed meaning In-Reply-To: <20160910114842.GA25129@polanet.pl> References: <20160830091701.GC18894@polanet.pl> <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> <20160910105325.GA22565@polanet.pl> <20160910114842.GA25129@polanet.pl> Message-ID: > On Sep 10, 2016, at 7:48 AM, Tomasz Pala wrote: > > On Sat, Sep 10, 2016 at 12:53:25 +0200, Tomasz Pala wrote: > >> our rpm and reverting it. Since nobody playing with rpm did this, my >> GUESS is, that: >> >> rpm-5.4.9-support-signatures-and-digest-disablers.patch >> >> is not enough/complete. And I've just found this (some 'triple negation' issues), as recently noted in >> http://rpm5.org/community/rpm-devel/5655.html >> >> Jeff, this seems to BE the case - verification is reverted only for >> --query mode, --verify mode works as expected. >> >> We might simply test this: >> >> https://patchwork.openembedded.org/patch/126825/raw/ > > Now it works as expected: > > ftp://ftp.th.pld-linux.org/dists/th/.test-builds/x86_64/rpm-5.4.15-35.x86_64.rpm > ftp://ftp.th.pld-linux.org/dists/th/.test-builds/x86_64/rpm-lib-5.4.15-35.x86_64.rpm > ftp://ftp.th.pld-linux.org/dists/th/.test-builds/x86_64/rpm-utils-5.4.15-35.x86_64.rpm > What was the fix? AFAIK, the problem was concatenating both an armored RSA and a DSA pubkey in the same file. Separate files (or separate "rpm ?import 0x?? by keyid using hkp://) are ?fixes?. 73 de Jeff From gotar at polanet.pl Sat Sep 10 20:32:43 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 10 Sep 2016 20:32:43 +0200 Subject: rpm --nosignature reversed meaning In-Reply-To: References: <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> <20160910105325.GA22565@polanet.pl> <20160910114842.GA25129@polanet.pl> Message-ID: <20160910183243.GA5585@polanet.pl> On Sat, Sep 10, 2016 at 09:46:17 -0400, Jeffrey Johnson wrote: >>> is not enough/complete. And I've just found this (some 'triple negation' issues), as recently noted in >>> http://rpm5.org/community/rpm-devel/5655.html >>> >>> Jeff, this seems to BE the case - verification is reverted only for >>> --query mode, --verify mode works as expected. [...] > What was the fix? > > AFAIK, the problem was concatenating both an armored RSA and a DSA pubkey in the same file. > > Separate files (or separate "rpm ???import 0x?????? by keyid using hkp://) are ???fixes???. The patch from the rpm-devel maillist above fixed --nosignature working the opposite way as expected, i.e. veryfying signature with --nosignature option given and NOT veryfying it by default in --query mode. And it does not break proper behaviour in --verify mode. -- Tomasz Pala From mis at pld-linux.org Sat Sep 10 23:46:24 2016 From: mis at pld-linux.org (=?UTF-8?B?UGF3ZcWCIEEuIEdhamRh?=) Date: Sat, 10 Sep 2016 23:46:24 +0200 Subject: npm and bundled modules Message-ID: Our npm is packaged wihtout bundled npm modules, what is generally good and maybe elegant, but it's just hard to maintain as there is over 70 node modules (npm 3.x) it depends on. That is probably the reason, why npm has not been upgraded from 1.x. npm itself bundle its dependencies,so, what I like to do is just to bundle them into package as well. It just works and would make upgrades much, much easier. Any objections? From aredridel at nbtsc.org Sun Sep 11 00:01:28 2016 From: aredridel at nbtsc.org (aredridel at nbtsc.org) Date: Sat, 10 Sep 2016 18:01:28 -0400 Subject: npm and bundled modules In-Reply-To: References: Message-ID: <15637747-906D-4CC1-A8C6-0AE6C177F6BE@nbtsc.org> > On 10 Sep 2016, at 17:46, Pawe? A. Gajda wrote: > > Our npm is packaged wihtout bundled npm modules, what is generally good and > maybe elegant, but it's just hard to maintain as there is over 70 node > modules (npm 3.x) it depends on. That is probably the reason, why npm has > not been upgraded from 1.x. > > npm itself bundle its dependencies,so, what I like to do is just to bundle > them into package as well. It just works and would make upgrades much, much > easier. Any objections? This is how node apps work in community practice, and doing this would make me very, very happy. It's basically meant that I don't use the system versions of node and npm at all because they actively fight how node works. So not just +1 but +100. (PS. I now work at npm.) Aria From n3npq at me.com Sun Sep 11 05:22:39 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Sat, 10 Sep 2016 23:22:39 -0400 Subject: rpm --nosignature reversed meaning In-Reply-To: <20160910183243.GA5585@polanet.pl> References: <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> <20160910105325.GA22565@polanet.pl> <20160910114842.GA25129@polanet.pl> <20160910183243.GA5585@polanet.pl> Message-ID: > On Sep 10, 2016, at 2:32 PM, Tomasz Pala wrote: > > On Sat, Sep 10, 2016 at 09:46:17 -0400, Jeffrey Johnson wrote: > >>>> is not enough/complete. And I've just found this (some 'triple negation' issues), as recently noted in >>>> http://rpm5.org/community/rpm-devel/5655.html >>>> >>>> Jeff, this seems to BE the case - verification is reverted only for >>>> --query mode, --verify mode works as expected. > [...] >> What was the fix? >> >> AFAIK, the problem was concatenating both an armored RSA and a DSA pubkey in the same file. >> >> Separate files (or separate "rpm ???import 0x?????? by keyid using hkp://) are ???fixes???. > > The patch from the rpm-devel maillist above fixed --nosignature working > the opposite way as expected, i.e. veryfying signature with > --nosignature option given and NOT veryfying it by default in --query > mode. And it does not break proper behaviour in --verify mode. > Thanks for the pointer. Yes, the behavior is (likely, not personally verified, just from memory) reversed. I?f still claim that reversing the sense of the tests isn?t the right patch: the root cause is a change in the default setting of the bit(s) that control signature checking. The better patch (headed toward elimination of ?no signature disablers) is to wrap the tests on the ?query path with #if defined(SUPPORT_NOSIGNATURES) ? #endif and then rip out the ?nosignature option entirely. Feel free to patch rpm to do whatever you wish when I rip out ?nosignature/?nodigest disablers. KISS determinism (if that can be applied to *.rpm signature verification) is far easier to maintain/support. 73 de Jeff > -- > Tomasz Pala > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From gotar at polanet.pl Sun Sep 11 07:31:01 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 11 Sep 2016 07:31:01 +0200 Subject: rpm --nosignature reversed meaning In-Reply-To: References: <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> <20160910105325.GA22565@polanet.pl> <20160910114842.GA25129@polanet.pl> <20160910183243.GA5585@polanet.pl> Message-ID: <20160911053101.GA30829@polanet.pl> On Sat, Sep 10, 2016 at 23:22:39 -0400, Jeffrey Johnson wrote: > The better patch (headed toward elimination of ???no signature disablers) > is to wrap the tests on the ???query path with > > #if defined(SUPPORT_NOSIGNATURES) > ??? > #endif > > and then rip out the ???nosignature option entirely. Well, consider I got some unknown.rpm. I do want it to be verified by default during query, however if it happens that signatures do not match I need an option to analyze (potentially malicious) content. For the very beginning, I would check the first possibility - that I simply do not have imported appropriate key. That unknown.rpm might be some 3rd party software downloaded from vendor I do trust in sense of not being malicious, but I do not trust on proper packaging or compatibility (%pre/%post scripts quality, file locations, UIDs/GIDs etc.). So, BEFORE importing the key, I need to inspect this package. As rpm2cpio won't extract the scripts nor show me the site URL pointer, I can't imagine dropping --nosignature option from the --query mode. Then, while installing this particular package, you can't force me to trust GPG key used, as *IN GENERAL* I might NOT TRUST this vendor. The fact, that I'm forced to use some of their software, doesn't meen I ever want to install anything else they've signed. Without --nosignature, I would have to import the key, install package and remove the key. Or, as you've mentioned before, resign the package with my own key, provided there are some REALLY EASY ways of doing it (i.e. single command that generates temporary key and applies it to the package). However, BEFORE resign such package, I need the tool to query the contents and analyze it. Thus, as long as ripping off --nosignature seems to be the right way for Linux distribution, it seems to ignore the existence of 3rd party software that is being used in real world. The usage scenario rpm has to allow: 1. rpm -qp unknown.rpm -> signature verification failed, 2. rpm -qpilv --scripts --nosignature unknown.rpm -> analyze 3. rpm2cpio ... -> content analyze IF required (trusting the vendor) 3. rpm --resign unknown.rpm (not with MY key, but some generated) 4. rpm -i unknown.rpm Consider web browsers - with Let's Encrypt initiative I can imagine, that in several years some would start to disable various functions over non-secure channels (e.g. cookies and POST over HTTP). As this is gradual process with huge userbase behind, it can crawl towards HTTPS-only forcing web service providers to adjust. However, with relatively small rpm userbase (as a part of relatively small Linux users), with even less users of 3rd party software, you can't expect providers would adapt. And that's apart from the trust issue I've mentioned above (that I do NOT trust them in general, just have to use SOME of their sw). -- Tomasz Pala From glen at pld-linux.org Sun Sep 11 10:28:37 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 11 Sep 2016 11:28:37 +0300 Subject: npm and bundled modules In-Reply-To: References: Message-ID: <57D515B5.9040201@pld-linux.org> On 11.09.2016 00:46, Pawe? A. Gajda wrote: > Our npm is packaged wihtout bundled npm modules, what is generally good and > maybe elegant, but it's just hard to maintain as there is over 70 node > modules (npm 3.x) it depends on. That is probably the reason, why npm has > not been upgraded from 1.x. > > npm itself bundle its dependencies,so, what I like to do is just to bundle > them into package as well. It just works and would make upgrades much, much > easier. Any objections? that's the most reasonable thing to do now considering how much efforts it takes to match the npm package versions that actually are able to resolve to single set of packages. i.e foo 1.0 is satisified by all depenendcies, as usually pkg2 requires foo < 1.0 and pkg3 > 1.0 so you need to have two versions of foo package. but, it must be subpackage, not part of nodejs package. %package -n npm as it's highly optional for running nodejs apps. -- glen From baggins at pld-linux.org Sun Sep 11 12:38:00 2016 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 11 Sep 2016 12:38:00 +0200 Subject: rpm --nosignature reversed meaning In-Reply-To: <20160910105325.GA22565@polanet.pl> References: <20160830091701.GC18894@polanet.pl> <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> <20160910105325.GA22565@polanet.pl> Message-ID: <20160911103800.GA4069@home> On Sat, 10 Sep 2016, Tomasz Pala wrote: > On Sat, Sep 10, 2016 at 11:41:46 +0300, Elan Ruusam?e wrote: > > >>> Since we got the answer for this issue - th-admin, please publish separate GPG files. > >> Are we announcing PLD being dead? Current DSA+RSA GPG key is unusable > >> for rpm, the one from FTP is being packaged, so it's also unusable. > >> Nobody cares? > > > > and you really expecting th-admin picking up a task middle of huge > > thread? you should had asked it from th-admin at pld-linux.org (or at least > > cc:). > > Indeed, forgot to do so. > > > i don't bother understanding what this topic is about -- packages > > install for me. > > RPM doesn't support subkeys, but we do not provide separate DSA key. Easy to test: > > 1. disable using keyserver: %_hkp_keyserver %{nil} > 2. import joined key we do provide: > rpm --import /etc/pki/rpm-gpg/PLD-3.0-Th-GPG-key.asc > 3. try to verify any PLD package. > > > but, i could upload the files if you make concrete request with details > > what needs to be done, > > GPG key that is being used for package signing needs to published (the > public part of course). Note the singular 'key', NOT plural 'keyS'. One > per file, if there are multiple keys used. Currently > ftp://ftp.pld-linux.org/dists/3.0/PLD-3.0-Th-GPG-key.asc provides two > (however I haven't seen any package signed by RSA one, AFAIR.) Done. I removed RSA key from the ftp://ftp.pld-linux.org/dists/3.0/PLD-3.0-Th-GPG-key.asc file, as we indeed sign only with DSA key. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at delfi.ee Sun Sep 11 13:02:00 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 11 Sep 2016 14:02:00 +0300 Subject: opening gvfs+ssh files from python Message-ID: <57D539A8.70505@delfi.ee> any ideas? i.e how come truncate from bash works and not from python, and how to make it work ? python3 -c 'open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", "rb+")' Traceback (most recent call last): File "", line 1, in OSError: [Errno 95] Operation not supported: '/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt' ? python2 -c 'open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", "rb+")' Traceback (most recent call last): File "", line 1, in IOError: [Errno 95] Operation not supported: '/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt' ? ls -l /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt -rw-r--r-- 1 glen glen 0 sept 11 13:56 /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt ? df /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt Filesystem Type Size Used Avail Use% Mounted on gvfsd-fuse fuse.gvfsd-fuse 1,8T 1,8T 40G 98% /home/glen/.gvfs ? date> /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt ? cat /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt P sept 11 13:57:21 EEST 2016 strace shows just C level error: open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", O_RDWR) = -1 EOPNOTSUPP (Operation not supported) some more examples: ? strace -eopen truncate --size=0 /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", O_WRONLY|O_CREAT|O_NONBLOCK, 0666) = -1 EOPNOTSUPP (Operation not supported) -- glen From glen at delfi.ee Sun Sep 11 13:04:11 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 11 Sep 2016 14:04:11 +0300 Subject: opening gvfs+ssh files from python In-Reply-To: <57D539A8.70505@delfi.ee> References: <57D539A8.70505@delfi.ee> Message-ID: <57D53A2B.3040708@delfi.ee> On 11.09.2016 14:02, Elan Ruusam?e wrote: > > strace shows just C level error: > open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", > O_RDWR) = -1 EOPNOTSUPP (Operation not supported) > > some more examples: > ? strace -eopen truncate --size=0 > /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt > open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", > O_WRONLY|O_CREAT|O_NONBLOCK, 0666) = -1 EOPNOTSUPP (Operation not > supported) two bash straces as well: ? sh -c 'date> /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt' open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 ? strace -ff -efile sh -c 'date >> /home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt' open("/home/glen/.gvfs/sftp:host=ewok.local/media/NEKO/pytest.txt", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3 -- glen From glen at pld-linux.org Sun Sep 11 15:14:10 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 11 Sep 2016 16:14:10 +0300 Subject: merge udev-* addon packages to base Message-ID: <57D558A2.5040603@pld-linux.org> proposition: - drop udev-* addon packages for distro packages because: ? rpm -qf /lib/udev/rules.d/ filesystem-4.1-1.x86_64 they are harmless if udev is not installed, no extra deps than base package and the packages are also tiny and sometimes you lack some behavior and then find out that there was extra udev subpackage that you did not install (libmtp for example) also: we already package systemd unit files, unconditionally. and seems only 10 packages need to be merged to base package: /srv/pld/th/PLD/x86_64/RPMS/udev-libgpod-0.8.3-4.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-libmtp-1.1.12-1.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-pcsc-driver-ccid-1.4.24-1.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-gpsd-3.10-5.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-OpenNI-sensor-PrimeSense-5.1.6.6-1.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-libfprint-0.6.0-1.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-openct-0.6.20-4.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-libunicap-0.9.12-3.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-pulseaudio-alsa-9.0-1.x86_64.rpm /srv/pld/th/PLD/x86_64/RPMS/udev-libgphoto2-2.5.10-1.x86_64.rpm -- glen From baggins at pld-linux.org Sun Sep 11 15:36:48 2016 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 11 Sep 2016 15:36:48 +0200 Subject: merge udev-* addon packages to base In-Reply-To: <57D558A2.5040603@pld-linux.org> References: <57D558A2.5040603@pld-linux.org> Message-ID: <20160911133648.GB4069@home> On Sun, 11 Sep 2016, Elan Ruusam?e wrote: > proposition: > > - drop udev-* addon packages for distro packages > > because: > ? rpm -qf /lib/udev/rules.d/ > filesystem-4.1-1.x86_64 > > they are harmless if udev is not installed, no extra deps than base > package and the packages are also tiny > > and sometimes you lack some behavior and then find out that there was > extra udev subpackage that you did not install (libmtp for example) > > also: we already package systemd unit files, unconditionally. > > and seems only 10 packages need to be merged to base package: > /srv/pld/th/PLD/x86_64/RPMS/udev-libgpod-0.8.3-4.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-libmtp-1.1.12-1.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-pcsc-driver-ccid-1.4.24-1.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-gpsd-3.10-5.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-OpenNI-sensor-PrimeSense-5.1.6.6-1.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-libfprint-0.6.0-1.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-openct-0.6.20-4.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-libunicap-0.9.12-3.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-pulseaudio-alsa-9.0-1.x86_64.rpm > /srv/pld/th/PLD/x86_64/RPMS/udev-libgphoto2-2.5.10-1.x86_64.rpm Makes sense. Ok with me. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Sun Sep 11 18:37:24 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 11 Sep 2016 19:37:24 +0300 Subject: Vulnerability scanner based on vulners.com audit API In-Reply-To: <201608290702.04216.arekm@maven.pl> References: <201608290702.04216.arekm@maven.pl> Message-ID: <57D58844.8010202@pld-linux.org> On 29.08.2016 08:02, Arkadiusz Mi?kiewicz wrote: > Interesting > > https://github.com/videns/vulners-scanner > > TODO: incorporate that (API) into our infrastructure to check ftp contents > also: https://coreos.com/blog/vulnerability-analysis-for-containers/ https://github.com/coreos/clair but that also seems to use package list for the analysis -- glen From glen at pld-linux.org Sun Sep 11 18:51:19 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 11 Sep 2016 19:51:19 +0300 Subject: [packages/kde4-kdebase-runtime] - completed l10n -> lang() translation (based on entry Languages= fields with some manual correction In-Reply-To: References: Message-ID: <57D58B87.7050108@pld-linux.org> On 11.09.2016 19:40, qboosh wrote: > commit d660672224a021e7a8be9bb12baa586d77102783 > Author: Jakub Bogusz > Date: Sun Sep 11 18:42:03 2016 +0200 > > - completed l10n -> lang() translation (based on entry Languages= fields with some manual corrections) ... > @@ -1,231 +1,241 @@ > # COUNTRY CODE # LANGUAGE CODE # DESCRIPTION > -ad ca Andorra (Catalan language) > -ae ar United Arab Emirates (Arabic language) > -af ps Afghanistan (Dari (Persian) and Pashto languages) > +ad ca,es,fr Andorra (Catalan, Spanish, French) > +ae ar United Arab Emirates (Arabic) > +af ps Afghanistan (Dari (Persian) and Pashto) so, %lang(ca,es,fr) actually works? it will install the file if any of the lang tags is matched rpm %_install_langs? -- glen From gotar at polanet.pl Sun Sep 11 19:13:25 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 11 Sep 2016 19:13:25 +0200 Subject: merge udev-* addon packages to base In-Reply-To: <20160911133648.GB4069@home> References: <57D558A2.5040603@pld-linux.org> <20160911133648.GB4069@home> Message-ID: <20160911171325.GA5930@polanet.pl> On Sun, Sep 11, 2016 at 15:36:48 +0200, Jan R?korajski wrote: > On Sun, 11 Sep 2016, Elan Ruusam?e wrote: > >> - drop udev-* addon packages for distro packages [...] > Makes sense. Ok with me. The same applies to bash-completion and zsh-completion subpackages. -- Tomasz Pala From glen at pld-linux.org Sun Sep 11 19:22:53 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 11 Sep 2016 20:22:53 +0300 Subject: merge udev-* addon packages to base In-Reply-To: <20160911171325.GA5930@polanet.pl> References: <57D558A2.5040603@pld-linux.org> <20160911133648.GB4069@home> <20160911171325.GA5930@polanet.pl> Message-ID: <57D592ED.6050903@pld-linux.org> On 11.09.2016 20:13, Tomasz Pala wrote: > The same applies to bash-completion and zsh-completion subpackages. "same" does not: ? rpm -qf /usr/share/bash-completion /usr/share/zsh/site-functions bash-completion-2.1-5.noarch zsh-5.0.2-3.x86_64 -- glen From qboosh at pld-linux.org Sun Sep 11 21:16:55 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 11 Sep 2016 21:16:55 +0200 Subject: [packages/kde4-kdebase-runtime] - completed l10n -> lang() translation (based on entry Languages= fields with some manual correction In-Reply-To: <57D58B87.7050108@pld-linux.org> References: <57D58B87.7050108@pld-linux.org> Message-ID: <20160911191655.GA8244@mail> On Sun, Sep 11, 2016 at 07:51:19PM +0300, Elan Ruusam?e wrote: > On 11.09.2016 19:40, qboosh wrote: > >commit d660672224a021e7a8be9bb12baa586d77102783 > >Author: Jakub Bogusz > >Date: Sun Sep 11 18:42:03 2016 +0200 > > > > - completed l10n -> lang() translation (based on entry Languages= > > fields with some manual corrections) > ... > >@@ -1,231 +1,241 @@ > > # COUNTRY CODE # LANGUAGE CODE # DESCRIPTION > >-ad ca Andorra (Catalan language) > >-ae ar United Arab Emirates (Arabic language) > >-af ps Afghanistan (Dari (Persian) and Pashto languages) > >+ad ca,es,fr Andorra (Catalan, Spanish, French) > >+ae ar United Arab Emirates (Arabic) > >+af ps Afghanistan (Dari (Persian) and Pashto) > > so, %lang(ca,es,fr) actually works? > > it will install the file if any of the lang tags is matched rpm > %_install_langs? AFAIK yes (not checked now, but I'm convinced it worked some years ago). -- Jakub Bogusz http://qboosh.pl/ From n3npq at me.com Sun Sep 11 21:41:02 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Sun, 11 Sep 2016 15:41:02 -0400 Subject: rpm --nosignature reversed meaning In-Reply-To: <20160911053101.GA30829@polanet.pl> References: <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> <20160910105325.GA22565@polanet.pl> <20160910114842.GA25129@polanet.pl> <20160910183243.GA5585@polanet.pl> <20160911053101.GA30829@polanet.pl> Message-ID: > > The usage scenario rpm has to allow: > > 1. rpm -qp unknown.rpm -> signature verification failed, > 2. rpm -qpilv --scripts --nosignature unknown.rpm -> analyze > 3. rpm2cpio ... -> content analyze IF required (trusting the vendor) > 3. rpm --resign unknown.rpm (not with MY key, but some generated) > 4. rpm -i unknown.rpm > There is nothing stopping the above commands (in exactly that order) if you add 0. rpm ?addsign somekeyid unknown.rpm when necessary. In practice, all packages built by rpm5 will already be signed, and all packages not built by rpm5 are usually signed by some key, which can be distributed, retrieved and imported however one wishes. If hkp:// retrieval is enabled, and the key has been uploaded will be automatically retrieved and used. 73 de Jeff From n3npq at me.com Sun Sep 11 21:51:49 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Sun, 11 Sep 2016 15:51:49 -0400 Subject: rpm --nosignature reversed meaning In-Reply-To: <20160911103800.GA4069@home> References: <20160830091701.GC18894@polanet.pl> <9B92BB88-EE74-47A2-BDA5-4C2D5FB17C8F@me.com> <20160830104425.GH18894@polanet.pl> <3F9D79BB-7382-494F-87FC-579BAC24849F@me.com> <20160830110325.GK18894@polanet.pl> <20160910042358.GA8602@polanet.pl> <57D3C74A.2000607@pld-linux.org> <20160910105325.GA22565@polanet.pl> <20160911103800.GA4069@home> Message-ID: > On Sep 11, 2016, at 6:38 AM, Jan R?korajski wrote: > > Done. > I removed RSA key from the ftp://ftp.pld-linux.org/dists/3.0/PLD-3.0-Th-GPG-key.asc > file, as we indeed sign only with DSA key. > There is also a patch to rpm ?verify to disable header signature checks that can now be removed afaik. The original report had related symptoms (the RSA pubkey was used to verify a DSA signature) here: http://pld-devel-en.pld-linux.narkive.com/ZssnN7t4/rpm-va-bad-key-id hth 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 jajcus at jajcus.net Mon Sep 12 11:20:57 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 12 Sep 2016 11:20:57 +0200 Subject: npm and bundled modules In-Reply-To: References: Message-ID: On 2016-09-10 23:46, Pawe? A. Gajda wrote: > npm itself bundle its dependencies,so, what I like to do is just to bundle > them into package as well. It just works and would make upgrades much, much > easier. Any objections? +1, no objections. Node dependencies and packaging is totally crazy and mantaining it right with RPM (making RPM package for each node package, which may contain a single .js file with a single function) would require 100x bigger team of developers than we have. So, instead of fighting that, lets just package together as much as it is convenient. Jacek From glen at pld-linux.org Mon Sep 12 18:17:49 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 12 Sep 2016 19:17:49 +0300 Subject: npm and bundled modules In-Reply-To: References: Message-ID: <57D6D52D.5070505@pld-linux.org> On 12.09.2016 12:20, Jacek Konieczny wrote: > On 2016-09-10 23:46, Pawe? A. Gajda wrote: >> npm itself bundle its dependencies,so, what I like to do is just to >> bundle >> them into package as well. It just works and would make upgrades >> much, much >> easier. Any objections? > > +1, no objections. > > Node dependencies and packaging is totally crazy and mantaining it > right with RPM (making RPM package for each node package, which may > contain a single .js file with a single function) would require 100x > bigger team of developers than we have. So, instead of fighting that, > lets just package together as much as it is convenient. the exception may be binary packages. would be reasonable to build binary packages as standalone packages. but so far none of npm packages were binary, last time i tried to update npm -- glen From glen at pld-linux.org Wed Sep 14 21:39:45 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 14 Sep 2016 22:39:45 +0300 Subject: libvterm Message-ID: <57D9A781.5050608@pld-linux.org> hi, would like to package this for neovim: http://www.leonerd.org.uk/code/libvterm/ or rather version that is continued here: https://github.com/neovim/libvterm but we already have such package: https://github.com/pld-linux/libvterm added in feb 2012: http://libvterm.sourceforge.net/ that project was last updated in 2013 should i just overwrite it? as seems nothing uses it (no build tags, package doesn't build) and overwrite with trashing (git ssh rm) it first? -- glen From qboosh at pld-linux.org Thu Sep 15 05:58:03 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 15 Sep 2016 05:58:03 +0200 Subject: libvterm In-Reply-To: <57D9A781.5050608@pld-linux.org> References: <57D9A781.5050608@pld-linux.org> Message-ID: <20160915035803.GA28275@mail> On Wed, Sep 14, 2016 at 10:39:45PM +0300, Elan Ruusam?e wrote: > hi, > > would like to package this for neovim: > http://www.leonerd.org.uk/code/libvterm/ > or rather version that is continued here: > https://github.com/neovim/libvterm > > but we already have such package: > https://github.com/pld-linux/libvterm > added in feb 2012: > http://libvterm.sourceforge.net/ > that project was last updated in 2013 > > should i just overwrite it? as seems nothing uses it (no build tags, > package doesn't build) > and overwrite with trashing (git ssh rm) it first? Either use some other name (libvterm-neovim?) for new package, or (as it was never published as RPM) copy existing libvterm to some other name and overwrite libvterm with this one. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Thu Sep 15 22:11:03 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 15 Sep 2016 23:11:03 +0300 Subject: libvterm In-Reply-To: <20160915035803.GA28275@mail> References: <57D9A781.5050608@pld-linux.org> <20160915035803.GA28275@mail> Message-ID: <57DB0057.4040600@pld-linux.org> On 15.09.2016 06:58, Jakub Bogusz wrote: > Either use some other name (libvterm-neovim?) for new package, or > (as it was never published as RPM) copy existing libvterm to some other > name and overwrite libvterm with this one. old one is from https://sourceforge.net/projects/libvterm/ rename it as libvterm-rote? altho i would just drop it, it's 8 releases made in 2009-10 https://sourceforge.net/projects/libvterm/files/ -- glen From qboosh at pld-linux.org Sat Sep 17 07:58:13 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 17 Sep 2016 07:58:13 +0200 Subject: libvterm In-Reply-To: <57DB0057.4040600@pld-linux.org> References: <57D9A781.5050608@pld-linux.org> <20160915035803.GA28275@mail> <57DB0057.4040600@pld-linux.org> Message-ID: <20160917055813.GA12186@mail> On Thu, Sep 15, 2016 at 11:11:03PM +0300, Elan Ruusam?e wrote: > On 15.09.2016 06:58, Jakub Bogusz wrote: > >Either use some other name (libvterm-neovim?) for new package, or > >(as it was never published as RPM) copy existing libvterm to some other > >name and overwrite libvterm with this one. > old one is from https://sourceforge.net/projects/libvterm/ > > rename it as libvterm-rote? Seems fine. -- Jakub Bogusz http://qboosh.pl/ From jajcus at jajcus.net Wed Sep 21 12:51:55 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 21 Sep 2016 12:51:55 +0200 Subject: Going back to IcedTea, openjdk8 is obsolete Message-ID: <103d1323-0c91-8366-af74-b53ca923ed67@jajcus.net> Hi, For long time IcedTea was not available for building OpenJDK8, so I packaged OpenJDK directly. It seemed good idea anyway ? why using some intermediate system when OpenJDK can be directly compiled on Linux. It even worked when I packaged it. I was not sure if it is 'stable' or 'current' release, but it was better than Java 7 we had before. Problems started when I tried to upgrade. I still have no idea what the OpenJDK release process is, how the versioning works and what are important changes between the version. Anyway, I have tried two newer 'releases'? and those wouldn't work on x32. I was not able to fix it (x32 patches from Debian didn't help), no one else in PLD seemed interested in fixing that either. Then, I have discovered something even worse: our OpenJDK 8 build cryptography was limited to the 'export' strength, at least for some functions on AES cipher. This should not be the case in OpenJDK (as is in Oracle JDK), but in PLD it was. And I was not able to find any information how to fix that. Fortunately, IcedTea for Java 8 has been finally released earlier this year. It has regular versioning, changelog and will probably be maintained like previous IcedTea versions were. I gave it a try and managed to build PLD packages with it. Those seem to work on x32 properly and have no limit on crypto keys length. Much better than the openjdk8-* packages. I suggest that openjdk8 packages should be obsoleted and icedtea8 should be used as our JDK from now on, unless someone finds some problems with it. And a reminder: Oracle Java has really evil license, which does not allow us to redistribute it with the distribution. OpenJDK/IcedTea is the only way for us. Jacek From glen at pld-linux.org Sun Sep 25 10:59:32 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 25 Sep 2016 11:59:32 +0300 Subject: [packages/readline] - cleanup In-Reply-To: <816baf02502225a6c9a1d5128cdc9cce685f0755_refs_heads_master@pld-linux.org> References: <816baf02502225a6c9a1d5128cdc9cce685f0755_refs_heads_master@pld-linux.org> Message-ID: <57E791F4.9080407@pld-linux.org> you shouldn't cleanup these as you well know, they will soon have patch 001, etc and nobody will know from top of the head how to do it correctly. On 25.09.2016 11:52, qboosh wrote: > --- a/readline.spec > +++ b/readline.spec > @@ -1,4 +1,3 @@ > -# NOTE: when updating patchlevel, do not forget to update 'sources' file! > %define ver 7.0 > %define patchlevel 0 > Summary: Library for reading lines from a terminal ... > diff --git a/sources b/sources > deleted file mode 100644 > index 41549b3..0000000 > --- a/sources > +++ /dev/null > @@ -1,8 +0,0 @@ > -4343f5ea9b0f42447f102fb61576b398 readline63-001 > -700295212f7e2978577feaee584afddb readline63-002 > -af4963862f5156fbf9111c2c6fa86ed7 readline63-003 > -11f9def89803a5052db3ba72394ce14f readline63-004 > -93721c31cd225393f80cb3aadb165544 readline63-005 > -71dc6ecce66d1489b96595f55d142a52 readline63-006 > -062a08ed60679d3c4878710b3d595b65 readline63-007 > -ee1c04072154826870848d8b218d7b04 readline63-008 > ================================================================ -- glen From qboosh at pld-linux.org Sun Sep 25 20:35:09 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 25 Sep 2016 20:35:09 +0200 Subject: [packages/readline] - cleanup In-Reply-To: <57E791F4.9080407@pld-linux.org> References: <816baf02502225a6c9a1d5128cdc9cce685f0755_refs_heads_master@pld-linux.org> <57E791F4.9080407@pld-linux.org> Message-ID: <20160925183509.GA21512@mail> On Sun, Sep 25, 2016 at 11:59:32AM +0300, Elan Ruusam?e wrote: > you shouldn't cleanup these > > as you well know, they will soon have patch 001, etc and nobody will > know from top of the head how to do it correctly. Uhhh, obsolete content was misleading; also, "sources" is not documented in %patchset_* comments in macros.build (without -s option)... -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Tue Sep 27 22:05:38 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 27 Sep 2016 23:05:38 +0300 Subject: qemu sysprefix Message-ID: <57EAD112.1050906@pld-linux.org> anything against changing --interp-prefix=%{_libdir}/qemu/lib-%%M to: --interp-prefix=%{_prefix}/qemu-%%M reason: qemu-user(-static) would expect target system libraries from there. qemu-user(-static) does not require qemu-common, in which current %{_libdir}/qemu is contained in. -- glen From qboosh at pld-linux.org Tue Sep 27 22:20:34 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 27 Sep 2016 22:20:34 +0200 Subject: qemu sysprefix In-Reply-To: <57EAD112.1050906@pld-linux.org> References: <57EAD112.1050906@pld-linux.org> Message-ID: <20160927202034.GA31764@mail> On Tue, Sep 27, 2016 at 11:05:38PM +0300, Elan Ruusam?e wrote: > anything against changing > > --interp-prefix=%{_libdir}/qemu/lib-%%M > to: > --interp-prefix=%{_prefix}/qemu-%%M What is _prefix in qemu? If /usr, then /usr/qemu-* is not FHS compliant. > reason: > > qemu-user(-static) would expect target system libraries from there. > qemu-user(-static) does not require qemu-common, in which current > %{_libdir}/qemu is contained in. Is %{_libdir}/qemu dir ownership the only reason? If so, you can even add it to every qemu-user* package. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Tue Sep 27 23:15:16 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 28 Sep 2016 00:15:16 +0300 Subject: qemu sysprefix In-Reply-To: <20160927202034.GA31764@mail> References: <57EAD112.1050906@pld-linux.org> <20160927202034.GA31764@mail> Message-ID: <57EAE164.8030803@pld-linux.org> On 27.09.2016 23:20, Jakub Bogusz wrote: > On Tue, Sep 27, 2016 at 11:05:38PM +0300, Elan Ruusam?e wrote: >> anything against changing >> >> --interp-prefix=%{_libdir}/qemu/lib-%%M >> to: >> --interp-prefix=%{_prefix}/qemu-%%M > What is _prefix in qemu? > If /usr, then /usr/qemu-* is not FHS compliant. yes, /usr i thought FHS allowed /usr/ paths for such purpose ? ls /usr/ aarch64-linux-gnu/ c6x-linux-gnu/ ia64-linux-gnu/ microblaze-linux-gnu/ score-elf/ x86_64-linux-gnu/ alpha-linux-gnu/ c6x-uclinux/ include/ mips64-linux-gnu/ score-linux-gnu/ x86_64-linux-uclibc/ am33_2.0-linux/ cris-linux-gnu/ lib/ mn10300-linux-gnu/ sh-linux-gnu/ x86_64-nacl/ arm-linux-gnu/ frv-linux-gnu/ lib64/ nios2-linux-gnu/ sh64-linux/ x86_64-pc-mingw32/ arm-linux-gnueabi/ games/ libx32/ openrisc-linux-gnu/ sh64-linux-gnu/ x86_64-w64-mingw32/ avr-linux/ h8300-elf/ local/ or1k-linux-gnu/ share/ x86_64-w64-mingw64/ avr32-linux-gnu/ h8300-linux-gnu/ m32r-elf/ powerpc64-linux-gnu/ sparc64-linux-gnu/ xtensa-linux-gnu/ bfin-linux-gnu/ hppa-linux-gnu/ m32r-linux-gnu/ ppc64-linux-gnu/ src/ bfin-uclinux/ hppa64-linux-gnu/ m68k-linux-gnu/ s390x-linux-gnu/ tile-linux-gnu/ bin/ i386-mingw32/ metag-linux-gnu/ sbin/ tilegx-linux/ > >> reason: >> >> qemu-user(-static) would expect target system libraries from there. >> qemu-user(-static) does not require qemu-common, in which current >> %{_libdir}/qemu is contained in. > Is %{_libdir}/qemu dir ownership the only reason? 1. dir ownership 2. inconsistent path (it's different on all th arches due %{_libdir} prefix) btw, upstream default is: ? ./configure --help|grep %M use %M for cpu name [/usr/gnemul/qemu-%M] > If so, you can even add it to every qemu-user* package. /usr/lib/binfmt.d also bothers, but that can be moved to filesystem.spec -- glen