From glen at delfi.ee Mon Nov 2 19:06:32 2015 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 02 Nov 2015 20:06:32 +0200 Subject: consolekit Message-ID: <5637A628.4080608@delfi.ee> Nov 2 20:05:20 rotten-fruit console-kit-daemon[5590]: WARNING: Couldn't read /proc/24047936/environ: Failed to open file '/proc/24047936/environ': No such file or directory anyone seeing this with non-systemd desktop? i'm using lightdm for xinit manager started to have this after applying bunch of updates -- glen From adwol at zonk.pl Tue Nov 3 08:36:31 2015 From: adwol at zonk.pl (Adam Osuchowski) Date: Tue, 3 Nov 2015 08:36:31 +0100 Subject: consolekit In-Reply-To: <5637A628.4080608@delfi.ee> References: <5637A628.4080608@delfi.ee> Message-ID: <20151103073631.6b8b4567@zonk.pl> Elan Ruusam?e wrote: > Nov 2 20:05:20 rotten-fruit console-kit-daemon[5590]: WARNING: Couldn't > read /proc/24047936/environ: Failed to open file '/proc/24047936/environ': > No such file or directory > > anyone seeing this with non-systemd desktop? > i'm using lightdm for xinit manager Yes, I've seen something similar few weeks ago. Check if last polkit commit (0.113-2, git only, not in repo) with my patch, helps. From glen at delfi.ee Tue Nov 3 10:22:37 2015 From: glen at delfi.ee (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=) Date: Tue, 03 Nov 2015 11:22:37 +0200 Subject: consolekit In-Reply-To: <20151103073631.6b8b4567@zonk.pl> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> Message-ID: <56387CDD.7010105@delfi.ee> On 03.11.2015 09:36, Adam Osuchowski wrote: > Elan Ruusam?e wrote: >> Nov 2 20:05:20 rotten-fruit console-kit-daemon[5590]: WARNING: Couldn't >> read /proc/24047936/environ: Failed to open file '/proc/24047936/environ': >> No such file or directory >> >> anyone seeing this with non-systemd desktop? >> i'm using lightdm for xinit manager > Yes, I've seen something similar few weeks ago. Check if last polkit > commit (0.113-2, git only, not in repo) with my patch, helps. did you have the same number? as first i guessed it somehow found two pids instead of one (2404, 7936), but neither pids existed in system second thought of mine was that somehow some pointer is used not the actual value. but my system is 64bit, it should had been bigger number for that. will check the polkit later, so far i downgraded lightdm and consolekit to previous versions. couldn't link the problem to polkit yet. well, my actual problem is that i can no longer suspend laptop from mate. have to type "poweroff" command, very annoying! -- glen From atler at pld-linux.org Tue Nov 3 10:30:24 2015 From: atler at pld-linux.org (Jan Palus) Date: Tue, 3 Nov 2015 10:30:24 +0100 Subject: consolekit In-Reply-To: <56387CDD.7010105@delfi.ee> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> <56387CDD.7010105@delfi.ee> Message-ID: <20151103093024.GA3053@cukinia.lan> On 03.11.2015 11:22, Elan Ruusam?e wrote: > well, my actual problem is that i can no longer suspend laptop from > mate. have to type "poweroff" command, very annoying! Just note from my side -- no issues with suspend/shutdown from mate here, though it looks I don't even have consolekit installed: > $ rpm -q ConsoleKit polkit lightdm systemd package ConsoleKit is not installed polkit-0.113-1.x86_64 lightdm-1.16.4-1.x86_64 systemd-221-7.x86_64 From glen at delfi.ee Tue Nov 3 10:35:15 2015 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 03 Nov 2015 11:35:15 +0200 Subject: consolekit In-Reply-To: <20151103093024.GA3053@cukinia.lan> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> <56387CDD.7010105@delfi.ee> <20151103093024.GA3053@cukinia.lan> Message-ID: <56387FD3.5080105@delfi.ee> On 03.11.2015 11:30, Jan Palus wrote: > Just note from my side -- no issues with suspend/shutdown from mate > here, though it looks I don't even have consolekit installed: after polkit problem gets solved, i was struggling to with upower package should i use: upower-libs-0.99.3-2 or upower-pm-utils-libs-0.9.23-1 btw, upower-pm-utils-libs-0.9.23-1 fakes .so.3 symlink, but i don't get why it kind of breaks things deliberately. i even saw some symbol error from mate-power-manager tool (don't have log right now) so... why? https://github.com/pld-linux/upower-pm-utils/commit/b00fa485f93d7b71a252c1c81517456b19e3b968 -- glen From adwol at zonk.pl Tue Nov 3 10:58:58 2015 From: adwol at zonk.pl (Adam Osuchowski) Date: Tue, 3 Nov 2015 10:58:58 +0100 Subject: consolekit In-Reply-To: <56387FD3.5080105@delfi.ee> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> <56387CDD.7010105@delfi.ee> <20151103093024.GA3053@cukinia.lan> <56387FD3.5080105@delfi.ee> Message-ID: <20151103095858.6b8b4567@zonk.pl> Elan Ruusam?e wrote: > after polkit problem gets solved, i was struggling to with upower package > should i use: > > upower-libs-0.99.3-2 or upower-pm-utils-libs-0.9.23-1 I fork upower-pm-utils package from upower over a year ago because of problems with suspending/hibernating. Dbus methods Suspend(), Hibernate(), CanSuspend() and CanHibernate() have been removed, so org.freedesktop.PowerManagement dbus service, which use them, stops working. The last version of upower which works well with non-systemd environments is 0.9.23. > btw, upower-pm-utils-libs-0.9.23-1 fakes .so.3 symlink, but i don't get why > it kind of breaks things deliberately. i even saw some symbol error from > mate-power-manager tool (don't have log right now) > > so... why? I don't remember why. It was made a year ago. I don't insist that this symlink has to stay. If you consider it needless and will be working as before, remove it. From glen at delfi.ee Tue Nov 3 11:10:55 2015 From: glen at delfi.ee (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=) Date: Tue, 03 Nov 2015 12:10:55 +0200 Subject: consolekit In-Reply-To: <20151103095858.6b8b4567@zonk.pl> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> <56387CDD.7010105@delfi.ee> <20151103093024.GA3053@cukinia.lan> <56387FD3.5080105@delfi.ee> <20151103095858.6b8b4567@zonk.pl> Message-ID: <5638882F.4060701@delfi.ee> On 03.11.2015 11:58, Adam Osuchowski wrote: >> >btw, upower-pm-utils-libs-0.9.23-1 fakes .so.3 symlink, but i don't get why >> >it kind of breaks things deliberately. i even saw some symbol error from >> >mate-power-manager tool (don't have log right now) >> > >> >so... why? > I don't remember why. It was made a year ago. I don't insist that this > symlink has to stay. If you consider it needless and will be working as > before, remove it. apps, libraries linked with .so.3 have now missing symbols, because you replace .so.3 link with .so.1 one and provide SONAME deps in rpm package, so poldek doesn't even try to install both libraries (.so.3 and .so.1) i would remove that hack, but i don't have anything to test with. don't know why you couldn't just provide .so.1 for legacy package, as new one uses .so.3 anyway and can be parallel installed? -- glen From adwol at zonk.pl Tue Nov 3 11:29:54 2015 From: adwol at zonk.pl (Adam Osuchowski) Date: Tue, 3 Nov 2015 11:29:54 +0100 Subject: consolekit In-Reply-To: <5638882F.4060701@delfi.ee> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> <56387CDD.7010105@delfi.ee> <20151103093024.GA3053@cukinia.lan> <56387FD3.5080105@delfi.ee> <20151103095858.6b8b4567@zonk.pl> <5638882F.4060701@delfi.ee> Message-ID: <20151103102954.6b8b4567@zonk.pl> Elan Ruusam?e wrote: > i would remove that hack, but i don't have anything to test with. don't > know why you couldn't just provide .so.1 for legacy package, as new one > uses .so.3 anyway and can be parallel installed? Ok, I will check 0.9.23-2 release on my box and will return report. From qboosh at pld-linux.org Tue Nov 3 17:29:52 2015 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 3 Nov 2015 17:29:52 +0100 Subject: perl-modules vs perl-Encode [Re: [packages/xorg-lib-libX11] update BR] In-Reply-To: References: <7488d398396e86c9c10a8629f4d690d585898015_refs_heads_master@pld-linux.org> Message-ID: <20151103162952.GA15939@mail> On Tue, Nov 03, 2015 at 03:51:45PM +0100, glen wrote: > commit fc1b336b66fa458ec83c54db990067e1cc603dae > Author: Elan Ruusam?e > Date: Sun Nov 1 23:26:05 2015 +0200 > > update BR > > - docbook-dtd43-xml -- /usr/src/BUILD/libX11-1.6.3/specs/libX11/libX11.xml:6: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" > - perl-Encode -- Can't locate Encode.pm in @INC (you may need to install the Encode module) (@INC contains: /usr/local/lib/perl5/5.20.0/x86_64-pld-linux-thread-multi /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl/5.20.0/x86_64-pld-linux-thread-multi /usr/share/perl5/vendor_perl /usr/lib64/perl5/5.20.3/x86_64-pld-linux-thread-multi /usr/share/perl5/5.20.3 .) at /usr/share/perl5/5.20.3/Pod/Text.pm line 32. In fact, most of Pod:: modules (from perl-modules) require Encode module to work. Also, some others perl-modules require Encode too. So, either perl-modules should require perl-Encode, or Encode modules (in version distributed with core perl) should be included in perl-modules. Or maybe more perl-modules should be made external... -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Tue Nov 3 18:10:12 2015 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 3 Nov 2015 18:10:12 +0100 Subject: MATE issues [was Re: consolekit] In-Reply-To: <56387CDD.7010105@delfi.ee> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> <56387CDD.7010105@delfi.ee> Message-ID: <20151103171012.GB15939@mail> On Tue, Nov 03, 2015 at 11:22:37AM +0200, Elan Ruusam?e wrote: > On 03.11.2015 09:36, Adam Osuchowski wrote: > >Elan Ruusam?e wrote: > >>Nov 2 20:05:20 rotten-fruit console-kit-daemon[5590]: WARNING: Couldn't > >>read /proc/24047936/environ: Failed to open file '/proc/24047936/environ': > >>No such file or directory > >> > >>anyone seeing this with non-systemd desktop? > >>i'm using lightdm for xinit manager > >Yes, I've seen something similar few weeks ago. Check if last polkit > >commit (0.113-2, git only, not in repo) with my patch, helps. > > did you have the same number? > > as first i guessed it somehow found two pids instead of one (2404, > 7936), but neither pids existed in system > second thought of mine was that somehow some pointer is used not the > actual value. but my system is 64bit, it should had been bigger number > for that. > > will check the polkit later, so far i downgraded lightdm and consolekit > to previous versions. couldn't link the problem to polkit yet. Pid numbers seem to be random junk from stack. The issue was caused by mismerge when I updated systemd-fallback patch, should be fixed by Adam in 0.113-2 (sent to builders right now). > well, my actual problem is that i can no longer suspend laptop from > mate. have to type "poweroff" command, very annoying! As for MATE - when I tried to use 1.10.x I couldn't get applications menu (clicking on top bar didn't work). What might be missing? -- Jakub Bogusz http://qboosh.pl/ From glen at delfi.ee Tue Nov 3 22:21:30 2015 From: glen at delfi.ee (=?windows-1252?Q?Elan_Ruusam=E4e?=) Date: Tue, 03 Nov 2015 23:21:30 +0200 Subject: MATE issues [was Re: consolekit] In-Reply-To: <20151103171012.GB15939@mail> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> <56387CDD.7010105@delfi.ee> <20151103171012.GB15939@mail> Message-ID: <5639255A.1090406@delfi.ee> On 03.11.2015 19:10, Jakub Bogusz wrote: > As for MATE - when I tried to use 1.10.x I couldn't get applications menu > (clicking on top bar didn't work). > What might be missing? i upgraded from 1.8 (had long pending update due known upower issues, upower 0.99 broke suspend last time (1y ago?) before upower-pm-utils was introduced to pld) and seems to work fine. the menu opens. -- glen From glen at delfi.ee Tue Nov 3 23:22:42 2015 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Wed, 04 Nov 2015 00:22:42 +0200 Subject: disabling rpm fetch Message-ID: <563933B2.3060405@delfi.ee> how do you disable rpm from fetching sources? from build/parsePrep.c i see such macros, but defining them to %{nil} had no effect. if (sp->flags & RPMFILE_SOURCE) { Rmacro = "%{?_Rsourcedir}/"; } else if (sp->flags & RPMFILE_PATCH) { Rmacro = "%{?_Rpatchdir}/"; } else if (sp->flags & RPMFILE_ICON) { Rmacro = "%{?_Ricondir}/"; } else continue; -- glen From glen at pld-linux.org Wed Nov 4 23:06:37 2015 From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=) Date: Thu, 05 Nov 2015 00:06:37 +0200 Subject: disabling rpm fetch In-Reply-To: <563933B2.3060405@delfi.ee> References: <563933B2.3060405@delfi.ee> Message-ID: <563A816D.5060505@pld-linux.org> On 04.11.2015 00:22, Elan Ruusam?e wrote: > how do you disable rpm from fetching sources? > from build/parsePrep.c i see such macros, but defining them to %{nil} > had no effect. disabled like this for now: https://github.com/pld-linux/rpm/commit/d397adc8e576680239e4201a21015921c8566bf1 -- glen From adwol at zonk.pl Wed Nov 4 23:23:05 2015 From: adwol at zonk.pl (Adam Osuchowski) Date: Wed, 4 Nov 2015 23:23:05 +0100 Subject: consolekit In-Reply-To: <5638882F.4060701@delfi.ee> References: <5637A628.4080608@delfi.ee> <20151103073631.6b8b4567@zonk.pl> <56387CDD.7010105@delfi.ee> <20151103093024.GA3053@cukinia.lan> <56387FD3.5080105@delfi.ee> <20151103095858.6b8b4567@zonk.pl> <5638882F.4060701@delfi.ee> Message-ID: <20151104222305.6b8b4567@zonk.pl> Elan Ruusam?e wrote: > i would remove that hack, but i don't have anything to test with. don't > know why you couldn't just provide .so.1 for legacy package, as new one > uses .so.3 anyway and can be parallel installed? Ok, I fiexd upower-pm-utils to allow coexistence of upower-libs and upower-pm-utils-libs. It is probably clean, now. There is one issue left: /usr/lib*/girepository-1.0/UPowerGlib-1.0.typelib file. I have no idea if this file is wanted and in what package it should be placed. From n3npq at me.com Thu Nov 5 01:21:22 2015 From: n3npq at me.com (Jeffrey Johnson) Date: Wed, 04 Nov 2015 19:21:22 -0500 Subject: disabling rpm fetch In-Reply-To: <563A816D.5060505@pld-linux.org> References: <563933B2.3060405@delfi.ee> <563A816D.5060505@pld-linux.org> Message-ID: <7885B3FE-DE56-490A-964F-B71E51B9508E@me.com> Sent from my iPad > On Nov 4, 2015, at 5:06 PM, Elan Ruusam?e wrote: > >> On 04.11.2015 00:22, Elan Ruusam?e wrote: >> how do you disable rpm from fetching sources? >> from build/parsePrep.c i see such macros, but defining them to %{nil} had no effect. > > disabled like this for now: > > https://github.com/pld-linux/rpm/commit/d397adc8e576680239e4201a21015921c8566bf1 > Ick but whatever floats your boat ... ... a final solution would involve choosing one (of at least three) solutions implemented in rpm to "download" and committing to a testing & support infrastructure. There is nothing too surprising about an attempt to download missing build elements that n 2015: look at any other installer application on the planet. And disabling -- even configurable -- is just brain dead avoidance and denial instead of a properly engineered solution. Just my $0.02 YMMV. PLD is still my favorite Linux distro because there are still many signs of intelligence in PLD, unlike other Linux carcasses. 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 glen at pld-linux.org Thu Nov 5 12:40:23 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Thu, 05 Nov 2015 13:40:23 +0200 Subject: disabling rpm fetch In-Reply-To: <7885B3FE-DE56-490A-964F-B71E51B9508E@me.com> References: <563933B2.3060405@delfi.ee> <563A816D.5060505@pld-linux.org> <7885B3FE-DE56-490A-964F-B71E51B9508E@me.com> Message-ID: <563B4027.3050604@pld-linux.org> On 05.11.2015 02:21, Jeffrey Johnson wrote: > There is nothing too surprising about an attempt to download > missing build elements that n 2015: look at any other installer > application on the planet. read the patch heading why would i want to download files if i want just to get parsed spec. -- glen From arekm at maven.pl Fri Nov 6 15:53:46 2015 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Fri, 6 Nov 2015 15:53:46 +0100 Subject: [packages/syslog-ng] - cron daemons log through syslog - syslog packages own cron log file and rotate it In-Reply-To: <56200034.8000409@bszx.eu> References: <3718169383b5759349c86af1b1f671203aad979d_refs_heads_master@pld-linux.org> <561FF5DC.7050403@pld-linux.org> <56200034.8000409@bszx.eu> Message-ID: <201511061553.46281.arekm@maven.pl> On Thursday 15 of October 2015, Bartek Szady wrote: > On 10/15/15 20:52, Elan Ruusam?e wrote: [...] > Default owner, group and permissions are set earlier in options: > > options { > ... > owner(root); > group(logs); > perm(0640); > .... > }; > > Bartek Could you finish cron related changes? rel up things, add proper deps (if needed); rebuild packages? Thanks, -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Fri Nov 6 16:13:02 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Fri, 06 Nov 2015 17:13:02 +0200 Subject: [packages/syslog-ng] - cron daemons log through syslog - syslog packages own cron log file and rotate it In-Reply-To: <201511061553.46281.arekm@maven.pl> References: <3718169383b5759349c86af1b1f671203aad979d_refs_heads_master@pld-linux.org> <561FF5DC.7050403@pld-linux.org> <56200034.8000409@bszx.eu> <201511061553.46281.arekm@maven.pl> Message-ID: <563CC37E.3020902@pld-linux.org> On 06.11.2015 16:53, Arkadiusz Mi?kiewicz wrote: > On Thursday 15 of October 2015, Bartek Szady wrote: >> On 10/15/15 20:52, Elan Ruusam?e wrote: > [...] >> Default owner, group and permissions are set earlier in options: >> >> options { >> ... >> owner(root); >> group(logs); >> perm(0640); >> .... >> }; >> >> Bartek > Could you finish cron related changes? rel up things, add proper deps (if > needed); rebuild packages? yep. i wrote him privately that he needs Conflicts/Requires, so people don't end up with no rotation for specific file. -- glen From bszx-pld at bszx.eu Fri Nov 6 22:47:24 2015 From: bszx-pld at bszx.eu (Bartek Szady) Date: Fri, 06 Nov 2015 22:47:24 +0100 Subject: [packages/syslog-ng] - cron daemons log through syslog - syslog packages own cron log file and rotate it In-Reply-To: <563CC37E.3020902@pld-linux.org> References: <3718169383b5759349c86af1b1f671203aad979d_refs_heads_master@pld-linux.org> <561FF5DC.7050403@pld-linux.org> <56200034.8000409@bszx.eu> <201511061553.46281.arekm@maven.pl> <563CC37E.3020902@pld-linux.org> Message-ID: <563D1FEC.80505@bszx.eu> On 11/06/15 16:13, Elan Ruusam?e wrote: > On 06.11.2015 16:53, Arkadiusz Mi?kiewicz wrote: >> On Thursday 15 of October 2015, Bartek Szady wrote: >>> On 10/15/15 20:52, Elan Ruusam?e wrote: >> [...] >>> Default owner, group and permissions are set earlier in options: >>> >>> options { >>> ... >>> owner(root); >>> group(logs); >>> perm(0640); >>> .... >>> }; >>> >>> Bartek >> Could you finish cron related changes? rel up things, add proper deps >> (if >> needed); rebuild packages? > yep. i wrote him privately that he needs Conflicts/Requires, so people > don't end up with no rotation for specific file. > Finished I hope. I've noticed that there could be similar problem with news servers. Syslogs configuration files contain information about /var/log/news/* but logrotate configuration files do not. I haven't touched this part. I don't have news server. Bartek From atler at pld-linux.org Sat Nov 7 13:41:36 2015 From: atler at pld-linux.org (Jan Palus) Date: Sat, 7 Nov 2015 13:41:36 +0100 Subject: ERRORS: libmateweather.spec OK: libmatekbd.spec libmatemixer.spec mate-menus.spec In-Reply-To: References: Message-ID: <20151107124136.GA20597@cukinia.lan> On 07.11.2015 12:28, PLD th-i686 builder wrote: > Conflicts: mate-applet-gweather < 1.6.1 > Processing files: libmateweather-devel-1.12.0-1.i686 > Segmentation fault ^^^^^^^^^^^^^^^^^^^^ > ended at: Sat Nov 7 13:27:32 2015, done in 0:04:49.335941 > error: No files produced. Can someone have a look what is failing on i686 builder? Seems to be reproducible -- two attempts failed the same way. From qboosh at pld-linux.org Sat Nov 7 14:13:11 2015 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 7 Nov 2015 14:13:11 +0100 Subject: ERRORS: libmateweather.spec OK: libmatekbd.spec libmatemixer.spec mate-menus.spec In-Reply-To: <20151107124136.GA20597@cukinia.lan> References: <20151107124136.GA20597@cukinia.lan> Message-ID: <20151107131311.GA21026@mail> On Sat, Nov 07, 2015 at 01:41:36PM +0100, Jan Palus wrote: > On 07.11.2015 12:28, PLD th-i686 builder wrote: > > Conflicts: mate-applet-gweather < 1.6.1 > > Processing files: libmateweather-devel-1.12.0-1.i686 > > Segmentation fault > ^^^^^^^^^^^^^^^^^^^^ > > ended at: Sat Nov 7 13:27:32 2015, done in 0:04:49.335941 > > error: No files produced. > > Can someone have a look what is failing on i686 builder? Seems to be > reproducible -- two attempts failed the same way. i686 rpmbuild seems to fail randomly during libmagic calls (reproductible also on my machine, so it's not th-i686 builder issue). I tried to debug it, but it's nothing obvious and hard to reproduce - so I gave up due to the lack of enough time resources. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Sun Nov 8 15:22:41 2015 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 8 Nov 2015 15:22:41 +0100 Subject: PLD-update-TODO false positives In-Reply-To: References: Message-ID: <20151108142240.GA31636@mail> Found a few (probably not all): > +SDL_net [OLD] 1.2.8 [NEW] 2.0.0 2.0.0 refers only to "SDL2_net" files in sources directory (SDL2_net is different package) > +belle-sip [OLD] 1.4.1 [NEW] 3.9.0 3.9.0 seems to be latest linphone version (in http://download-mirror.savannah.gnu.org/releases/linphone/3.9.x/sources/) belle-sip resides in http://download-mirror.savannah.gnu.org/releases/linphone/belle-sip/ and latest version is 1.4.2 (as for today) > +crossmingw32-SDL_image [OLD] 1.2.12 [NEW] 2.0.0 case similar to SDL_net > libidn2 [OLD] 0.10 [NEW] 1.32 1.32 is the latest version of libidn on ftp.gnu.org -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Sun Nov 8 15:39:51 2015 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Sun, 8 Nov 2015 15:39:51 +0100 Subject: PLD-update-TODO false positives In-Reply-To: <20151108142240.GA31636@mail> References: <20151108142240.GA31636@mail> Message-ID: <201511081539.51779.arekm@maven.pl> On Sunday 08 of November 2015, Jakub Bogusz wrote: > Found a few (probably not all): > > +SDL_net [OLD] 1.2.8 [NEW] 2.0.0 > > 2.0.0 refers only to "SDL2_net" files in sources directory (SDL2_net is > different package) [...] It uses pldnotify only, so if these are new false positive then that's (most likely) regression in pldnotify. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Mon Nov 9 11:07:04 2015 From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=) Date: Mon, 09 Nov 2015 12:07:04 +0200 Subject: PLD-update-TODO false positives In-Reply-To: <20151108142240.GA31636@mail> References: <20151108142240.GA31636@mail> Message-ID: <56407048.5040104@pld-linux.org> fixed them all On 08.11.2015 16:22, Jakub Bogusz wrote: > Found a few (probably not all): > >> +SDL_net [OLD] 1.2.8 [NEW] 2.0.0 > 2.0.0 refers only to "SDL2_net" files in sources directory (SDL2_net is > different package) added new sdl_net project and distro mapping https://release-monitoring.org/project/7983/ > >> +belle-sip [OLD] 1.4.1 [NEW] 3.9.0 > 3.9.0 seems to be latest linphone version > (in http://download-mirror.savannah.gnu.org/releases/linphone/3.9.x/sources/) > > belle-sip resides in http://download-mirror.savannah.gnu.org/releases/linphone/belle-sip/ > and latest version is 1.4.2 (as for today) somewhy linphone pld-package name was filled as belle-sip. corrected https://release-monitoring.org/project/1823/ i guess when i originally filled via api, url matching caused false positive > >> +crossmingw32-SDL_image [OLD] 1.2.12 [NEW] 2.0.0 > case similar to SDL_net similar fix as SDL_net https://release-monitoring.org/project/7985/ > >> libidn2 [OLD] 0.10 [NEW] 1.32 > 1.32 is the latest version of libidn on ftp.gnu.org somehow libidn vs libidn2 were messed up in r-m.o (2 pointed to 1 and so on) fixed mapping. -- glen From glen at pld-linux.org Mon Nov 9 16:46:43 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 09 Nov 2015 17:46:43 +0200 Subject: php 5.3 mysqlnd Message-ID: <5640BFE3.4070505@pld-linux.org> any objection to turning mysqlnd "on" on 5.3 branch? it fixed some segfaults on ac mysqli prepared statements. so if objections, i will do so only for ac. -- glen From arekm at maven.pl Mon Nov 9 17:46:31 2015 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 9 Nov 2015 17:46:31 +0100 Subject: php 5.3 mysqlnd In-Reply-To: <5640BFE3.4070505@pld-linux.org> References: <5640BFE3.4070505@pld-linux.org> Message-ID: <201511091746.31388.arekm@maven.pl> On Monday 09 of November 2015, Elan Ruusam?e wrote: > any objection to turning mysqlnd "on" on 5.3 branch? > > it fixed some segfaults on ac mysqli prepared statements. > so if objections, i will do so only for ac. Only one. It's totally untested in our 5.3 and high risk for existing environments. For example major problem is SSL handling which was broken in php mysqlnd up to (upcoming upstream) 5.6.16. So I'm strongly against changing defaults for 5.3 (still using it). -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From atler at pld-linux.org Wed Nov 11 17:16:04 2015 From: atler at pld-linux.org (Jan Palus) Date: Wed, 11 Nov 2015 17:16:04 +0100 Subject: [all] builder queue problem In-Reply-To: References: Message-ID: <20151111161604.GA32716@cukinia.lan> On 11.11.2015 16:06, PLD all builder wrote: > there were problems sending files from queue /home/pld/builderth/pld-builder.new/spool/notify: > problems: > [src: /home/pld/builderth/pld-builder.new/spool/notify/897a4ea6-eea2-4ae7-9cdc-8b83a5f02230] > > > [src: /home/pld/builderth/pld-builder.new/spool/notify/26618bd6-7ede-4d59-a629-c1ec3e8ce199] > > > [src: /home/pld/builderth/pld-builder.new/spool/notify/5b33c564-6b37-4f58-be8c-96237f011088] > > > Can someone have a look or at least disable cron job until issue is resolved so above message is not resent every 5min? From arekm at maven.pl Wed Nov 11 17:24:07 2015 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 11 Nov 2015 17:24:07 +0100 Subject: [all] builder queue problem In-Reply-To: <20151111161604.GA32716@cukinia.lan> References: <20151111161604.GA32716@cukinia.lan> Message-ID: <201511111724.07895.arekm@maven.pl> On Wednesday 11 of November 2015, Jan Palus wrote: > > > (_ssl.c:581)> > > Can someone have a look or at least disable cron job until issue is > resolved so above message is not resent every 5min? Certificate expired on srcbuilder.pld-linux.org causing that problem. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From baggins at pld-linux.org Wed Nov 11 20:43:34 2015 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Wed, 11 Nov 2015 20:43:34 +0100 Subject: [all] builder queue problem In-Reply-To: <201511111724.07895.arekm@maven.pl> References: <20151111161604.GA32716@cukinia.lan> <201511111724.07895.arekm@maven.pl> Message-ID: <20151111194334.GA3947@home.lan> On Wed, 11 Nov 2015, Arkadiusz Mi?kiewicz wrote: > On Wednesday 11 of November 2015, Jan Palus wrote: > > > > > > (_ssl.c:581)> > > > > Can someone have a look or at least disable cron job until issue is > > resolved so above message is not resent every 5min? > > Certificate expired on srcbuilder.pld-linux.org causing that problem. Who can generate new cert there? RMF? For now I hacked builder code (only on builders, not in git) to disable cert verification. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From arekm at maven.pl Wed Nov 11 20:49:29 2015 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 11 Nov 2015 20:49:29 +0100 Subject: [all] builder queue problem In-Reply-To: <20151111194334.GA3947@home.lan> References: <201511111724.07895.arekm@maven.pl> <20151111194334.GA3947@home.lan> Message-ID: <201511112049.29817.arekm@maven.pl> On Wednesday 11 of November 2015, Jan R?korajski wrote: > On Wed, 11 Nov 2015, Arkadiusz Mi?kiewicz wrote: > > On Wednesday 11 of November 2015, Jan Palus wrote: > > > > > > > failed (_ssl.c:581)> > > > > > > Can someone have a look or at least disable cron job until issue is > > > resolved so above message is not resent every 5min? > > > > Certificate expired on srcbuilder.pld-linux.org causing that problem. > > Who can generate new cert there? RMF? Anyone having hostmaster@/feedback@ access can do it on startssl.com. Started procedure, waiting for their staff confirmation of certificate. > For now I hacked builder code (only on builders, not in git) > to disable cert verification. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From arekm at maven.pl Wed Nov 11 21:55:30 2015 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 11 Nov 2015 21:55:30 +0100 Subject: [all] builder queue problem In-Reply-To: <201511112049.29817.arekm@maven.pl> References: <20151111194334.GA3947@home.lan> <201511112049.29817.arekm@maven.pl> Message-ID: <201511112155.30889.arekm@maven.pl> On Wednesday 11 of November 2015, Arkadiusz Mi?kiewicz wrote: > On Wednesday 11 of November 2015, Jan R?korajski wrote: > > On Wed, 11 Nov 2015, Arkadiusz Mi?kiewicz wrote: > > > On Wednesday 11 of November 2015, Jan Palus wrote: > > > > > > > > > failed (_ssl.c:581)> > > > > > > > > Can someone have a look or at least disable cron job until issue is > > > > resolved so above message is not resent every 5min? > > > > > > Certificate expired on srcbuilder.pld-linux.org causing that problem. > > > > Who can generate new cert there? RMF? > > Anyone having hostmaster@/feedback@ access can do it on startssl.com. > > Started procedure, waiting for their staff confirmation of certificate. srcbuilder.pld got new certificate now. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From baggins at pld-linux.org Thu Nov 12 22:46:58 2015 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 12 Nov 2015 22:46:58 +0100 Subject: wpa_supplicant 2.5 not talking to NetworkManager Message-ID: <20151112214658.GA4820@tachikoma.lan> Is wpa_supplicant 2.5 working for anyone with NM? All I get is below logs and no networks detected. For now I removed that package from ftp (we still have 2.3 in main). NetworkManager[4134]: wpa_supplicant die count reset NetworkManager[4134]: wpa_supplicant running NetworkManager[4134]: [1447364054.904323] [supplicant-manager/nm-supplicant-interface.c:734] interface_add_cb(): (wlan0): error adding interface: Timeout was reached NetworkManager[4134]: (wlan0): supplicant interface state: starting -> down -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Fri Nov 13 16:01:55 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Fri, 13 Nov 2015 17:01:55 +0200 Subject: xfs v5 Message-ID: <5645FB63.8030108@pld-linux.org> can we go back to v4 or at least detect running kernel first? XFS Version v5 superblock VS old kernels ( < v3.15) issues Using recent Th provided xfsprogs|mkfs.xfs|results in created filesystem with v5 superblock which is not fully supported in 3.14 and lower kernels. Below message is produced in kernel log while trying to mount such filesystem on old kernel (3.14): [3180866.360834] XFS (dm-13): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled! Use of these features in this kernel is at your own risk! [3180866.360848] XFS (dm-13): Superblock has unknown read-only compatible features (0x1) enabled. [3180866.360853] XFS (dm-13): Attempted to mount read-only compatible filesystem read-write. Filesystem can only be safely mounted read only. [3180866.360868] XFS (dm-13): SB validate failed with error 22. To overcome it and create v4 superblock, one need to provide specific|mkfs.xfs|options to disable v5 features: mkfs.xfs -m crc=0,finobt=0 /dev/sys/apus-vserver See related issue discussion:http://oss.sgi.com/archives/xfs/2015-08/msg00548.html -- glen From glen at pld-linux.org Fri Nov 13 16:02:57 2015 From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=) Date: Fri, 13 Nov 2015 17:02:57 +0200 Subject: xfs v5 In-Reply-To: <5645FB63.8030108@pld-linux.org> References: <5645FB63.8030108@pld-linux.org> Message-ID: <5645FBA1.4080706@pld-linux.org> On 13.11.2015 17:01, Elan Ruusam?e wrote: > can we go back to v4 or at least detect running kernel first? > > > XFS Version v5 superblock VS old kernels ( < v3.15) issues > > Using recent Th provided xfsprogs|mkfs.xfs|results in created > filesystem with v5 superblock which is not fully supported in 3.14 and > lower kernels. Below message is produced in kernel log while trying to > mount such filesystem on old kernel (3.14): > > [3180866.360834] XFS (dm-13): Version 5 superblock detected. This > kernel has EXPERIMENTAL support enabled! > Use of these features in this kernel is at your own > risk! > [3180866.360848] XFS (dm-13): Superblock has unknown read-only > compatible features (0x1) enabled. > [3180866.360853] XFS (dm-13): Attempted to mount read-only compatible > filesystem read-write. > Filesystem can only be safely mounted read only. > [3180866.360868] XFS (dm-13): SB validate failed with error 22. > > To overcome it and create v4 superblock, one need to provide > specific|mkfs.xfs|options to disable v5 features: > > mkfs.xfs -m crc=0,finobt=0 /dev/sys/apus-vserver > > See related issue > discussion:http://oss.sgi.com/archives/xfs/2015-08/msg00548.html and more specifically: http://oss.sgi.com/archives/xfs/2015-08/msg00554.html -- glen From arekm at maven.pl Fri Nov 13 16:17:16 2015 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Fri, 13 Nov 2015 16:17:16 +0100 Subject: xfs v5 In-Reply-To: <5645FB63.8030108@pld-linux.org> References: <5645FB63.8030108@pld-linux.org> Message-ID: <201511131617.16753.arekm@maven.pl> On Friday 13 of November 2015, Elan Ruusam?e wrote: > can we go back to v4 or at least detect running kernel first? Back to v4 - no. We don't want to be different from upstream and we should have defaults for fresh kernels and not ancient ones. Detect - sure. Detect and warn if creating v5 fs on old kernel (but don't change default). -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From lukaszgl at post.pl Sun Nov 15 18:53:27 2015 From: lukaszgl at post.pl (Lukasz Glebicki) Date: Sun, 15 Nov 2015 18:53:27 +0100 Subject: wpa_supplicant 2.5 not talking to NetworkManager In-Reply-To: <20151112214658.GA4820@tachikoma.lan> References: <20151112214658.GA4820@tachikoma.lan> Message-ID: <1516265.W4RL28W1vl@inhell> On Thursday 12 of November 2015 22:46:58 Jan R?korajski wrote: > Is wpa_supplicant 2.5 working for anyone with NM? > All I get is below logs and no networks detected. > > For now I removed that package from ftp (we still have 2.3 in main). > > NetworkManager[4134]: wpa_supplicant die count reset > NetworkManager[4134]: wpa_supplicant running > NetworkManager[4134]: [1447364054.904323] > [supplicant-manager/nm-supplicant-interface.c:734] interface_add_cb(): > (wlan0): error adding interface: Timeout was reached NetworkManager[4134]: > (wlan0): supplicant interface state: starting -> down I got exactly the same issue. Downgrade wpa_sipplicant to the previous version rapidly enable WiFi connection, Regards, -- ?ukasz G??bicki mail/rot13:yhxnfmty at cbfg.cy PLD/Linux Team gg:246267 Linux Registered User #318551 blekot:{irc,skype} From glen at delfi.ee Tue Nov 17 15:13:44 2015 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 17 Nov 2015 16:13:44 +0200 Subject: sshd not functioning on new installs Message-ID: <564B3618.9090605@delfi.ee> sshd from current th-main not usable on new installations: Script started on Tue Nov 17 16:11:41 2015 [root at pld64 ~]# service sshd start Generating public/private rsa1 key pair. Saving key "/etc/ssh/ssh_host_key" failed: unknown or unsupported key type chmod: cannot access '/etc/ssh/ssh_host_key': No such file or directory OpenSSH service is not running. No SSH host key found! You must run "/etc/rc.d/init.d/sshd init" first. [root at pld64 ~]# rpm -q openssh-server openssh-server-7.1p1-4.x86_64 [root at pld64 ~]# service sshd init Now the SSH host key will be generated. Please note, that if you will use password for the key, you will need to type it on each reboot. Generating public/private rsa1 key pair. Saving key "/etc/ssh/ssh_host_key" failed: unknown or unsupported key type chmod: cannot access '/etc/ssh/ssh_host_key': No such file or directory [root at pld64 ~]# ^D Script done on Tue Nov 17 16:11:59 2015 -- glen From jajcus at jajcus.net Sun Nov 22 13:25:16 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 22 Nov 2015 13:25:16 +0100 Subject: RFC: default python installlation directories Message-ID: <5651B42C.4030209@jajcus.net> Hi, Most Python HOWTOs and similar resources suggest using 'pip', 'easy_install' or other tools to install python modules or python-based programs. The problem is, that in PLD those tools would install modules in /usr/{lib{64},share}/pythonX.Y/site-packages ? the same place, where python modules from our RPM packages go. This is a mess and may destroy already installed packages ? using pip to install a single innocent program may cause chain reaction of installing dependency modules and overwitting old versions of those already in the system. virtualenv can help, but only if one chooses to use it. I suggest patching python, python3 and, if neccessary, other packages, so distutils/setuptools/pip would install Python modules to /usr/local by default ? like autoconf configure scripts do. Python would look for modues in /usr/local first and then in /usr. Effects: 1. easy_install/pip/etc would not overwrite distribution packages ? that is what we want. 2. modules installed with easy_install/pip/etc would override those installed from RPM ? that is what the user would expect installing something manually. 3. No existing python-*.spec would build any more. All python specs would need to be updated to force proper instalation directories. I would prepare %setup_py2 and %setup_py3. Those would use proper python interpreter and compiler flags too. I guess a 'sed' job on all the python-*.spec would do the trick for most packages. 4. Existing packages (except, maybe, a few exceptions, like pip itself would not have to be rebuilt immediately ? the paths used by the packages would still be ok What do you think? Jacek From gotar at polanet.pl Sun Nov 22 16:57:10 2015 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 22 Nov 2015 16:57:10 +0100 Subject: RFC: default python installlation directories In-Reply-To: <5651B42C.4030209@jajcus.net> References: <5651B42C.4030209@jajcus.net> Message-ID: <20151122155710.GA16656@polanet.pl> On Sun, Nov 22, 2015 at 13:25:16 +0100, Jacek Konieczny wrote: > I suggest patching python, python3 and, if neccessary, other packages, > so distutils/setuptools/pip would install Python modules to /usr/local > by default ??? like autoconf configure scripts do. Python would look for > modues in /usr/local first and then in /usr. If any tool installs anything with /usr prefix, not /usr/local, this should be considered as a bug and reported upstream. FHS clearly states that /usr/local should be used, so go ahead with this approach. > 3. No existing python-*.spec would build any more. > > All python specs would need to be updated to force proper instalation > directories. I would prepare %setup_py2 and %setup_py3. Those would use > proper python interpreter and compiler flags too. Can't this be accomplished by detecting some environment variables? > What do you think? I'm really tired of not having the ability to run some code just because there is no PLD package (and no point in creating one, there are dozens of perl/python/ruby modules) and I already have some other installed from rpms. -- Tomasz Pala From baggins at pld-linux.org Sun Nov 22 18:52:08 2015 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 22 Nov 2015 18:52:08 +0100 Subject: RFC: default python installlation directories In-Reply-To: <5651B42C.4030209@jajcus.net> References: <5651B42C.4030209@jajcus.net> Message-ID: <20151122175208.GA4472@home.lan> On Sun, 22 Nov 2015, Jacek Konieczny wrote: > Hi, > > Most Python HOWTOs and similar resources suggest using 'pip', > 'easy_install' or other tools to install python modules or python-based > programs. The problem is, that in PLD those tools would install modules > in /usr/{lib{64},share}/pythonX.Y/site-packages ? the same place, where > python modules from our RPM packages go. > > This is a mess and may destroy already installed packages ? using pip to > install a single innocent program may cause chain reaction of installing > dependency modules and overwitting old versions of those already in the > system. > > virtualenv can help, but only if one chooses to use it. > > I suggest patching python, python3 and, if neccessary, other packages, > so distutils/setuptools/pip would install Python modules to /usr/local > by default ? like autoconf configure scripts do. Python would look for > modues in /usr/local first and then in /usr. Makes sense. Go ahead and do it. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From jajcus at jajcus.net Sun Nov 22 20:20:16 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 22 Nov 2015 20:20:16 +0100 Subject: RFC: default python installlation directories In-Reply-To: <20151122155710.GA16656@polanet.pl> References: <5651B42C.4030209@jajcus.net> <20151122155710.GA16656@polanet.pl> Message-ID: <56521570.2070707@jajcus.net> On 2015-11-22 16:57, Tomasz Pala wrote: > On Sun, Nov 22, 2015 at 13:25:16 +0100, Jacek Konieczny wrote: > >> I suggest patching python, python3 and, if neccessary, other packages, >> so distutils/setuptools/pip would install Python modules to /usr/local >> by default ??? like autoconf configure scripts do. Python would look for >> modues in /usr/local first and then in /usr. > > If any tool installs anything with /usr prefix, not /usr/local, this > should be considered as a bug and reported upstream. FHS clearly states > that /usr/local should be used, so go ahead with this approach. Python's default prefix is /usr/local, but that is, obviously, changed for our python package. Most python software use the paths provided by python standard library and that is the prefix Python was configured with. Please note that Python software is built for Python, not for Linux, so python specifications (official Python documentation and various PEPs) are follwed first. If that could be solved upstream Debian would already forced that, but they use patches similar to what I suggest. >> 3. No existing python-*.spec would build any more. >> >> All python specs would need to be updated to force proper instalation >> directories. I would prepare %setup_py2 and %setup_py3. Those would use >> proper python interpreter and compiler flags too. > > Can't this be accomplished by detecting some environment variables? Probably, but I don't think this is the most elegant solution. We usually don't use rpm-build-specific variables and rather use '%configure', '%cmake' and similar macros or pass the parameters to the build process directly. Another set of macros for Python software seems consistent with that. >> What do you think? > > I'm really tired of not having the ability to run some code just because > there is no PLD package (and no point in creating one, there are dozens > of perl/python/ruby modules) and I already have some other installed > from rpms. So you understand the problem well :) Jacek From jajcus at jajcus.net Sun Nov 22 21:39:58 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 22 Nov 2015 21:39:58 +0100 Subject: Terrible performance of Python dependency generator Message-ID: <5652281E.2040604@jajcus.net> Hi, We will probably need to rebuild the python-* packages again and I already hate that. Such python-django takes 45 minutes to build and most of that is in the auto-dependency generator. That is insane! It should not take that long! /usr/lib/rpm/pythoneggs.py is used to find the dependencies and it is not that slow by itself? but it is called twice (Provides + Requires) for each file in /usr/share/pythonX.Y. And big Python packages have lots of files there. Most of them not adding any extra dependency information. That is strange, as the dependency helpers accept list of file names on their stdout? and RPM (in lib/rpmfc.c) always feeds them with one filename only. Why is that? I can even see a buffer for a file list in the code (iob_python in the rpmfc_s struct), but it seems not used. I tried to invent some smart hack to limit number of files examined ? usually checking a single *.py file and the *.egg-info/PKG-INFO should be enough, but I was not able to inject this in the weird rpmfc logic. And I do not quite understand what it is supposed to do (what are those 'colors' and what files should be python-colored). Can this be fixed somehow? How have we ended with this? Jacek From n3npq at me.com Sun Nov 22 22:03:14 2015 From: n3npq at me.com (Jeffrey Johnson) Date: Sun, 22 Nov 2015 16:03:14 -0500 Subject: Terrible performance of Python dependency generator In-Reply-To: <5652281E.2040604@jajcus.net> References: <5652281E.2040604@jajcus.net> Message-ID: <96EBE532-5445-45D1-8B77-7D1A99420163@me.com> > On Nov 22, 2015, at 3:39 PM, Jacek Konieczny wrote: > > Hi, > > We will probably need to rebuild the python-* packages again and I > already hate that. Such python-django takes 45 minutes to build and most > of that is in the auto-dependency generator. That is insane! It should > not take that long! > > /usr/lib/rpm/pythoneggs.py is used to find the dependencies and it is > not that slow by itself? but it is called twice (Provides + Requires) > for each file in /usr/share/pythonX.Y. And big Python packages have lots > of files there. Most of them not adding any extra dependency > information. > > That is strange, as the dependency helpers accept list of file names on > their stdout? and RPM (in lib/rpmfc.c) always feeds them with one > filename only. Why is that? > Short answer: rpmfc is dynamically building multiple cross referenced arrays dynamically in a single pass through the file list, so each file typed to an external helper is called. > I can even see a buffer for a file list in the code (iob_python in the > rpmfc_s struct), but it seems not used. > Yes: either ancient history (when all dependencies were generated externally) or being used in rpmdeps (which can be used as an external dependency generator replacement). > I tried to invent some smart hack to limit number of files examined ? > usually checking a single *.py file and the *.egg-info/PKG-INFO should > be enough, but I was not able to inject this in the weird rpmfc logic. > And I do not quite understand what it is supposed to do (what are those > 'colors' and what files should be python-colored). > Colors (as exposed externally in rpm headers) are logic bits to distinguish between ELF32 and ELF64 (and the oddball MIPS little endian). Colors (as used internally in rpmfc) are used for classification based on lib magic strings and used to associate helpers with file types, basically to avoid having to repeatedly do string compares. > Can this be fixed somehow? How have we ended with this? > There?s some quick fixes and then there are some better fixes. Dependencies are automatically generated only for executable files. So using %files -f manifest, one can make a pass in %install to generate the manifest, and doing both 1) add a %attr marker to set the execute bits 2) chmod -x on the file in %buildroot and then generate dependencies manually (using a two pass build to edit Requires: etc into the spec file. The better fix would be to use the embedded python interpreter yo avoid repeatedly involving a shell that invokes python. Bur the fundamental problem is with user overridable external helper scripts that conform to ancient expectations of the helper API and still must classify files and generate cross referenced tag data dynamically. hah 73 de Jeff > 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 baggins at pld-linux.org Sun Nov 22 22:20:36 2015 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 22 Nov 2015 22:20:36 +0100 Subject: [packages/gmock] don't need the macros in preamble In-Reply-To: <09d9b8b85792b8f61d5aca7fe7fcc30b6996cb44_refs_heads_master@pld-linux.org> References: <09d9b8b85792b8f61d5aca7fe7fcc30b6996cb44_refs_heads_master@pld-linux.org> Message-ID: <20151122212036.GB4472@home.lan> Think first before doing something. How do you expect an 'ifarch' to work _after_ setting arch to noarch? On Sun, 22 Nov 2015, glen wrote: > commit 09d9b8b85792b8f61d5aca7fe7fcc30b6996cb44 > Author: Elan Ruusam?e > Date: Sun Nov 22 23:08:21 2015 +0200 > > don't need the macros in preamble > > gmock.spec | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > --- > diff --git a/gmock.spec b/gmock.spec > index dde9d8c..5f6c500 100644 > --- a/gmock.spec > +++ b/gmock.spec > @@ -1,9 +1,3 @@ > -%ifarch x32 > -%define build_arch %{_target_platform} > -%else > -%define build_arch %{_host} > -%endif > - > Summary: Google C++ Mocking Framework > Summary(pl.UTF-8): Szkielet Google Mock dla C++ > Name: gmock > @@ -26,6 +20,12 @@ BuildRequires: sed >= 4.0 > BuildArch: noarch > BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) > > +%ifarch x32 > +%define build_arch %{_target_platform} > +%else > +%define build_arch %{_host} > +%endif > + > %description > Inspired by jMock, EasyMock, and Hamcrest, and designed with C++'s > specifics in mind, Google C++ Mocking Framework (or Google Mock for > ================================================================ > > ---- gitweb: > > http://git.pld-linux.org/gitweb.cgi/packages/gmock.git/commitdiff/09d9b8b85792b8f61d5aca7fe7fcc30b6996cb44 > > _______________________________________________ > 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 glen at pld-linux.org Mon Nov 23 09:45:05 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 23 Nov 2015 10:45:05 +0200 Subject: RFC: default python installlation directories In-Reply-To: <5651B42C.4030209@jajcus.net> References: <5651B42C.4030209@jajcus.net> Message-ID: <5652D211.6020806@pld-linux.org> On 22.11.2015 14:25, Jacek Konieczny wrote: > I suggest patching python, python3 and, if neccessary, other packages, > so distutils/setuptools/pip would install Python modules to /usr/local > by default ? like autoconf configure scripts do. Python would look for > modues in /usr/local first and then in /usr. +1 -- glen From glen at pld-linux.org Mon Nov 23 09:54:30 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 23 Nov 2015 10:54:30 +0200 Subject: Terrible performance of Python dependency generator In-Reply-To: <5652281E.2040604@jajcus.net> References: <5652281E.2040604@jajcus.net> Message-ID: <5652D446.4070105@pld-linux.org> On 22.11.2015 22:39, Jacek Konieczny wrote: > /usr/lib/rpm/pythoneggs.py is used to find the dependencies and it is > not that slow by itself? but it is called twice (Provides + Requires) > for each file in /usr/share/pythonX.Y. And big Python packages have lots > of files there. Most of them not adding any extra dependency > information. i tried once to make hack to that, when facing similar problem with php dependencies generator. the idea was simple: 1. first time dep generator is invoked, it becames daemon and starts listening to unix socket 2. further calls talk to socket instead dispatching the "requests" but i never finished it, don't know if i have some WIP saved somewhere. and with rpm4.5 the python dep genreator just compared pythonX.Y version to do print "python(abi) %s" print that was "optimized" by providing PY_VER as env var. -- glen From n3npq at me.com Mon Nov 23 10:09:15 2015 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 23 Nov 2015 04:09:15 -0500 Subject: Terrible performance of Python dependency generator In-Reply-To: <5652D446.4070105@pld-linux.org> References: <5652281E.2040604@jajcus.net> <5652D446.4070105@pld-linux.org> Message-ID: > On Nov 23, 2015, at 3:54 AM, Elan Ruusam?e wrote: > > On 22.11.2015 22:39, Jacek Konieczny wrote: >> /usr/lib/rpm/pythoneggs.py is used to find the dependencies and it is >> not that slow by itself? but it is called twice (Provides + Requires) >> for each file in /usr/share/pythonX.Y. And big Python packages have lots >> of files there. Most of them not adding any extra dependency >> information. > i tried once to make hack to that, when facing similar problem with php dependencies generator. > > the idea was simple: > 1. first time dep generator is invoked, it becames daemon and starts listening to unix socket > 2. further calls talk to socket instead dispatching the "requests" > > but i never finished it, don't know if i have some WIP saved somewhere. > The ?simple? idea is fine for optimizing I/O to an external helper. However, with an embedded python interpreter in rpm, one has all the persistence needed to generate python (or perl or tcl or java or ?) dependencies of each file without having to ?batch?. (aside) But any rpmdep optimization is mostly overkill, the per-interpreter dependencies (perl perhaps the one exception) are rather primitive and hardly need to be generated for every file every build with current packaging. Sure one can conceive of a single python build that generates modules and dependencies for every possibly deployed interpreter version in a single build, just that is a rather hard package to construct and maintain ? I?ve not personally seen a serious attempt to do that yet. > and with rpm4.5 the python dep genreator just compared pythonX.Y version to do print "python(abi) %s" print > that was "optimized" by providing PY_VER as env var. > IIRC, something like python(abi) is still mostly what is being distributed with rpm helper scripts (though perhaps some distro has extended the helpers to do something more useful). 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 jajcus at jajcus.net Mon Nov 23 10:16:55 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 23 Nov 2015 10:16:55 +0100 Subject: Terrible performance of Python dependency generator In-Reply-To: <96EBE532-5445-45D1-8B77-7D1A99420163@me.com> References: <5652281E.2040604@jajcus.net> <96EBE532-5445-45D1-8B77-7D1A99420163@me.com> Message-ID: <5652D987.9030107@jajcus.net> On 2015-11-22 22:03, Jeffrey Johnson wrote: > Dependencies are automatically generated only for executable files. That is not true for Python dependencies and this would not work for Python dependencies. There are two useful types of Python dependencies: 1. python(abi) ? this is extracted from .pyc or .pyo files. These are not the executable scripts, but non-executable library files in /usr/lib or /usr/share. Checking a single *.py[co] file would do for the whole package. On the other hand, this dependency is a bit redundant, because files for each python abi are going to a different directory and the directory dependency should be enough. 2. pythonegg(*) ? this are extracted from meta-data in *.egg-info directories. A package usually contains only one such directory. Currently it works as all /usr/{lib*,share}/pythonX.Y/* files are passed to pythoneggs.py. Among this file there would be some *.pyc and some file from the egg-info directory, so all the important dependencies would be extracted. Examining only the executables would return only the '/usr/bin/python', or even '/bin/sh' dependency. I guess I will hack rpmfc.c to run Python helper only for a single py[co] file and a single file in every egg-info directory. > So > using %files -f manifest, one can make a pass in %install to generate > the manifest, and doing both > 1) add a %attr marker to set the execute bits > 2) chmod -x on the file in %buildroot > > and then generate dependencies manually (using a two pass build to > edit Requires: etc into the spec file. Sounds like a very ugly hack. BTW we don't need a manifest to preserve proper file permissions as in PLD we _always_ provide permissions explicitly in %files. So we could just chmod -R a-x all the Python files. But that is not what file permissions are for! > The better fix would be to use the embedded python interpreter yo > avoid repeatedly involving a shell that invokes python. That wouldn't work much better than no repeat a stupid check for each file. > Bur the fundamental problem is with user overridable external > helper scripts that conform to ancient expectations of the helper API > and still must classify files and generate cross referenced tag data > dynamically. The 'ancient expectations of the helper API' actually made some sense in terms of performance (single process to handle a file list). Executing any external process for every file is plain stupid. And Python (and probably not only Python) dependencies are not per-file, but per python package. Linking dependencies checks to specific files is quite artificial. Jacek From n3npq at me.com Mon Nov 23 10:35:32 2015 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 23 Nov 2015 04:35:32 -0500 Subject: Terrible performance of Python dependency generator In-Reply-To: <5652D987.9030107@jajcus.net> References: <5652281E.2040604@jajcus.net> <96EBE532-5445-45D1-8B77-7D1A99420163@me.com> <5652D987.9030107@jajcus.net> Message-ID: > On Nov 23, 2015, at 4:16 AM, Jacek Konieczny wrote: > > On 2015-11-22 22:03, Jeffrey Johnson wrote: >> Dependencies are automatically generated only for executable files. > > That is not true for Python dependencies and this would not work for > Python dependencies. > (aside) ?Only executable files? SHOULD be true for all automated dependencies imho, as that is what rpm dependencies were originally designed for, to verify that executables had all necessary prerequisites. YMMV, everyone?s does. > There are two useful types of Python dependencies: > > 1. python(abi) ? this is extracted from .pyc or .pyo files. These are > not the executable scripts, but non-executable library files in /usr/lib > or /usr/share. Checking a single *.py[co] file would do for the whole > package. On the other hand, this dependency is a bit redundant, because > files for each python abi are going to a different directory and the > directory dependency should be enough. > > 2. pythonegg(*) ? this are extracted from meta-data in *.egg-info > directories. A package usually contains only one such directory. > > Currently it works as all /usr/{lib*,share}/pythonX.Y/* files are passed > to pythoneggs.py. Among this file there would be some *.pyc and some > file from the egg-info directory, so all the important dependencies > would be extracted. > > Examining only the executables would return only the '/usr/bin/python', > or even '/bin/sh' dependency. > > I guess I will hack rpmfc.c to run Python helper only for a single > py[co] file and a single file in every egg-info directory. > Whatever works for you ? >> So >> using %files -f manifest, one can make a pass in %install to generate >> the manifest, and doing both >> 1) add a %attr marker to set the execute bits >> 2) chmod -x on the file in %buildroot >> >> and then generate dependencies manually (using a two pass build to >> edit Requires: etc into the spec file. > > Sounds like a very ugly hack. > Yep. > BTW we don't need a manifest to preserve proper file permissions as in > PLD we _always_ provide permissions explicitly in %files. So we could > just chmod -R a-x all the Python files. But that is not what file > permissions are for! > (aside) There are other benefits to a manifest, particularly when filtering large trees of files (which you surely have with drupal) to split into sub packages. But you can package however you wish. >> The better fix would be to use the embedded python interpreter yo >> avoid repeatedly involving a shell that invokes python. > > That wouldn't work much better than no repeat a stupid check for each file. > Its not the check, but the overhead of invoking python for every file, that you are seeing. >> Bur the fundamental problem is with user overridable external >> helper scripts that conform to ancient expectations of the helper API >> and still must classify files and generate cross referenced tag data >> dynamically. > > The 'ancient expectations of the helper API' actually made some sense in > terms of performance (single process to handle a file list). Executing > any external process for every file is plain stupid. > Yes the ancient API was dirt simple and was preserved. The metadata has changed so that the dependencies are attached to each file in a package is what becomes problematic. The original API was a single shell script ? these days there are too many types of dependencies to handle in ne single shell script. > And Python (and probably not only Python) dependencies are not per-file, > but per python package. Linking dependencies checks to specific files is > quite artificial. > We disagree here. There is functionality within rpm that disables dependencies attached to a file when that file is excluded. Of course you can put every file in its own package and choose not to install that package to achieve the same effect. But automatic dependencies are a file attribute carried in package metadata, including pythonegg(?), not a package attribute imposed on the files within. 73 de Jeff > 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 jajcus at jajcus.net Wed Nov 25 21:19:21 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 25 Nov 2015 21:19:21 +0100 Subject: RFC: default python installlation directories In-Reply-To: <20151122175208.GA4472@home.lan> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> Message-ID: <565617C9.5010402@jajcus.net> On 2015-11-22 18:52, Jan R?korajski wrote: > On Sun, 22 Nov 2015, Jacek Konieczny wrote: >> >> I suggest patching python, python3 and, if neccessary, other packages, >> so distutils/setuptools/pip would install Python modules to /usr/local >> by default ? like autoconf configure scripts do. Python would look for >> modues in /usr/local first and then in /usr. > > Makes sense. Go ahead and do it. Done. New RPM build macros added: %py_build %py_install %py3_build %py3_install Just %setup_py and %setup_py3 wouldn't do as we cannot change options order: 'setup.py --prefix=/usr install' is wrong, 'setup.py install --prefix=/usr' is ok. I have updated the python template specs and a few packages. Things seems to work well. Including distutils, setuptools and pip. If there are no objections, I may try a mass-update of python-* specs tomorrow. Jacek From glen at pld-linux.org Fri Nov 27 10:28:21 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Fri, 27 Nov 2015 11:28:21 +0200 Subject: RFC: default python installlation directories In-Reply-To: <565617C9.5010402@jajcus.net> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> Message-ID: <56582235.8060501@pld-linux.org> On 25.11.2015 22:19, Jacek Konieczny wrote: > If there are no objections, I may try a mass-update of python-* specs > tomorrow. afaik not all packages supported --build-base thing. i don't know why. so i'm not objecting, just warning. you can find such packages with something like this: ? grep -r 'set --' ~/all-specs /home/users/glen/all-specs/python-httplib2.spec:set -- * not all matches really need it, some of them are just bad copy paste: python-pyquery.spec: %prep %setup -q -n %{module}-%{version} # setup copy of source in py3 dir set -- * install -d py3 cp -a "$@" py3 %build %if %{with python2} %{__python} setup.py build --build-base build-2 %{?with_tests:test} %endif %if %{with python3} %{__python3} setup.py build --build-base build-3 %{?with_tests:test} %endif -- glen From glen at pld-linux.org Fri Nov 27 10:32:20 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Fri, 27 Nov 2015 11:32:20 +0200 Subject: mysql-server vision Message-ID: <56582324.9030006@pld-linux.org> so what is the future of mysql packages now that arekm cloned mysql.spec to percona-server.spec and replaced mysql.spec master with original mysql code luckily nothing else was done so far. i don't think going from percona-server to mysql-server works without issues. in binary data wise and configuration wise and stability performance wise. there's also mariadb-server and drizzle-server which are some kind of mysql-server forks. also could consider supporting multiple server versions (i still run 5.0 for example) -- glen From jajcus at jajcus.net Fri Nov 27 12:06:51 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Fri, 27 Nov 2015 12:06:51 +0100 Subject: RFC: default python installlation directories In-Reply-To: <56582235.8060501@pld-linux.org> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <56582235.8060501@pld-linux.org> Message-ID: <5658394B.6090509@jajcus.net> On 2015-11-27 10:28, Elan Ruusam?e wrote: > On 25.11.2015 22:19, Jacek Konieczny wrote: >> If there are no objections, I may try a mass-update of python-* specs >> tomorrow. more like in the weekend ;) > afaik not all packages supported --build-base thing. i don't know why. Most current Python packages can use setup.py same way. There might be problem with outdated packages, but you can find such which wouldn't even use 'setup.py' at all. I think a very small minority of the packages would be broken by replacing setup.py with py_build/py_install. Most of our python specs that don't use '--build-base' are those which were never updated for Python 3 support or which were written before the '--build-base' trick was known to the spec author. > you can find such packages with something like this: > > ? grep -r 'set --' ~/all-specs > /home/users/glen/all-specs/python-httplib2.spec:set -- * Are you sure this is not some alternative to the '--build-base'? But thanks, I will look at those. Jacek From glen at pld-linux.org Fri Nov 27 23:12:14 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Sat, 28 Nov 2015 00:12:14 +0200 Subject: [packages/linux-firmware] - up to 20151030; include amd microcode files here In-Reply-To: <2aa22ec520713a4335e2104aa177c99be629fa7b_refs_heads_master@pld-linux.org> References: <2c543da4e80e5fa7b23a271af82024080534f3b0_refs_heads_master@pld-linux.org> <2aa22ec520713a4335e2104aa177c99be629fa7b_refs_heads_master@pld-linux.org> Message-ID: <5658D53E.3040004@pld-linux.org> On 28.11.2015 00:05, arekm wrote: > commit 2aa22ec520713a4335e2104aa177c99be629fa7b > Author: Arkadiusz Mi?kiewicz > Date: Fri Nov 27 23:05:47 2015 +0100 > > - up to 20151030; include amd microcode files here > > linux-firmware.spec | 27 +++++++++++++++------------ > 1 file changed, 15 insertions(+), 12 deletions(-) > --- > diff --git a/linux-firmware.spec b/linux-firmware.spec > index 8e776a8..8e8f4cb 100644 > --- a/linux-firmware.spec > +++ b/linux-firmware.spec > @@ -1,17 +1,17 @@ > # TODO > # - subpackages for various firmwares? > -# - build microcode-data-amd from this spec? > Summary: Firmware files used by the Linux kernel > Summary(pl.UTF-8): Pliki firmware'u u?ywane przez j?dro Linuksa > Name: linux-firmware > -Version: 20150715 > +Version: 20151030 > Release: 1 > License: GPL+ and GPL v2+ and MIT and Redistributable, no modification permitted > Group: Base/Kernel > -Source0: http://pkgs.fedoraproject.org/repo/pkgs/linux-firmware/%{name}-%{version}.tar.gz/5f829e860b1b9b5f6ea1a385eb368540/%{name}-%{version}.tar.gz > -# Source0-md5: 5f829e860b1b9b5f6ea1a385eb368540 > +Source0: http://pkgs.fedoraproject.org/repo/pkgs/linux-firmware/%{name}-%{version}.tar.gz/a3ed304228118353c5b26819cef10136/%{name}-%{version}.tar.gz > +# Source0-md5: a3ed304228118353c5b26819cef10136 > URL: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ > BuildArch: noarch > +Obsoletes: microcode-data-amd imho subpackage is better here. -- glen From jajcus at jajcus.net Sat Nov 28 16:36:07 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sat, 28 Nov 2015 16:36:07 +0100 Subject: [packages/python-setuptools] adapter, use realtive symlink In-Reply-To: References: <25fb9ea97f0c9cc2d0c6ddbf9ff65c610076d3be_refs_heads_master@pld-linux.org> Message-ID: <5659C9E7.1090605@jajcus.net> On 2015-11-28 15:16, glen wrote: > commit b6cbc91d94c8fad86e0ad1b271429f6772218700 > Author: Elan Ruusam?e > Date: Sat Nov 28 16:16:47 2015 +0200 > > adapter, use realtive symlink [...] > -ln -f $RPM_BUILD_ROOT/%{_bindir}/easy_install-%{py3_ver} $RPM_BUILD_ROOT/%{_bindir}/easy_install > +ln -sf easy_install-%{py3_ver} $RPM_BUILD_ROOT%{_bindir}/easy_install > %else > -ln -f $RPM_BUILD_ROOT/%{_bindir}/easy_install-%{py_ver} $RPM_BUILD_ROOT/%{_bindir}/easy_install > +ln -sf easy_install-%{py_ver} $RPM_BUILD_ROOT%{_bindir}/easy_install > %endif Why symlink? There was a hard-link for purpose. No need for extra redirection. And there are no relative hard links. Jacek From arekm at maven.pl Sat Nov 28 19:32:02 2015 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Sat, 28 Nov 2015 19:32:02 +0100 Subject: ERRORS: libmateweather.spec OK: libmatekbd.spec libmatemixer.spec mate-menus.spec In-Reply-To: <20151107131311.GA21026@mail> References: <20151107124136.GA20597@cukinia.lan> <20151107131311.GA21026@mail> Message-ID: <201511281932.02103.arekm@maven.pl> On Saturday 07 of November 2015, Jakub Bogusz wrote: > On Sat, Nov 07, 2015 at 01:41:36PM +0100, Jan Palus wrote: > > On 07.11.2015 12:28, PLD th-i686 builder wrote: > > > Conflicts: mate-applet-gweather < 1.6.1 > > > Processing files: libmateweather-devel-1.12.0-1.i686 > > > Segmentation fault > > > > ^^^^^^^^^^^^^^^^^^^^ > > > > > ended at: Sat Nov 7 13:27:32 2015, done in 0:04:49.335941 > > > error: No files produced. > > > > Can someone have a look what is failing on i686 builder? Seems to be > > reproducible -- two attempts failed the same way. > > i686 rpmbuild seems to fail randomly during libmagic calls > (reproductible also on my machine, so it's not th-i686 builder issue). > I tried to debug it, but it's nothing obvious and hard to reproduce - > so I gave up due to the lack of enough time resources. So different bugs? I got: (gdb) bt #0 0xf724d3fc in ?? () from /lib/libc.so.6 #1 0xf7481eb9 in strncpy (__len=, __src=0xffda95b0 "", __dest=) at /usr/include/bits/string3.h:126 #2 expandMacros (spec=spec at entry=0x0, mc=, mc at entry=0x0, sbuf=sbuf at entry=0xa0dae38 "", slen=slen at entry=131094) at macro.c:2776 #3 0xf7481feb in rpmExpand (arg=arg at entry=0xf7658373 "%{?__noautoprovfiles}") at macro.c:3277 #4 0xf7636018 in rpmfcExpandRegexps (str=str at entry=0xf7658373 "%{?__noautoprovfiles}", nmirep=nmirep at entry=0xa072fb8) at rpmfc.c:346 #5 0xf7638bdb in rpmfcApply (fc=fc at entry=0xa072f48) at rpmfc.c:1126 #6 0xf763a562 in rpmfcGenerateDepends (_spec=_spec at entry=0xa08d700, _pkg=_pkg at entry=0xa0a8a28) at rpmfc.c:2059 #7 0xf7685c31 in processBinaryFiles (spec=spec at entry=0xa08d700, installSpecialDoc=installSpecialDoc at entry=4, test=test at entry=0) at files.c:3211 #8 0xf767dd02 in buildSpec (ts=0xa0714b0, spec=spec at entry=0xa08d700, what=159, test=0) at build.c:392 #9 0x0804a65b in buildForTarget (ts=ts at entry=0xa0714b0, ba=ba at entry=0x804d200 ) at build.c:265 #10 0x0804adbe in build (ts=ts at entry=0xa0714b0, ba=0x804d200 , rcfile=rcfile at entry=0x0) at build.c:315 #11 0x08049b98 in main (argc=5, argv=0xffdcfd64) at ./rpmqv.cc:982 (gdb) frame 2 #2 expandMacros (spec=spec at entry=0x0, mc=, mc at entry=0x0, sbuf=sbuf at entry=0xa0dae38 "", slen=slen at entry=131094) at macro.c:2776 2776 strncpy(sbuf, tbuf, (slen - mb->nb + 1)); (gdb) print sbuf $22 = 0xa0dae38 "" (gdb) print tbuf $23 = 0xffda95b0 "" (gdb) print slen $24 = 131094 (gdb) print mb->nb value has been optimized out (gdb) frame 3 #3 0xf7481feb in rpmExpand (arg=arg at entry=0xf7658373 "%{?__noautoprovfiles}") at macro.c:3277 3277 (void) expandMacros(NULL, mc, t, tn + bufn + 1); (gdb) print mc $25 = (struct MacroContext_s *) 0x0 (gdb) print t $26 = 0xa0dae38 "" (gdb) print tn + bufn + 1 $27 = 131094 (gdb) frame 4 #4 0xf7636018 in rpmfcExpandRegexps (str=str at entry=0xf7658373 "%{?__noautoprovfiles}", nmirep=nmirep at entry=0xa072fb8) at rpmfc.c:346 346 s = rpmExpand(str, NULL); (gdb) print str $28 = 0xf7658373 "%{?__noautoprovfiles}" reproduced (3 times in the same place) on carme-i686 by doing ../builder -bi python-setuptools.spec while (rpmbuild --short-circuit -bi python-setuptools.spec); do echo x; done ~50 iterations, 10 minutes to reproduce -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From jajcus at jajcus.net Sat Nov 28 20:12:53 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sat, 28 Nov 2015 20:12:53 +0100 Subject: ERRORS: libmateweather.spec OK: libmatekbd.spec libmatemixer.spec mate-menus.spec In-Reply-To: <201511281932.02103.arekm@maven.pl> References: <20151107124136.GA20597@cukinia.lan> <20151107131311.GA21026@mail> <201511281932.02103.arekm@maven.pl> Message-ID: <5659FCB5.50306@jajcus.net> On 2015-11-28 19:32, Arkadiusz Mi?kiewicz wrote: > reproduced (3 times in the same place) on carme-i686 by doing > > ../builder -bi python-setuptools.spec > while (rpmbuild --short-circuit -bi python-setuptools.spec); do echo x; done > > ~50 iterations, 10 minutes to reproduce No need to build anything. valgrind rpm --eval '%{?__noautoprovfiles}' shows the problem: ==102752== Conditional jump or move depends on uninitialised value(s) ==102752== at 0x429E22B: doShellEscape (in /lib/librpmio-5.4.so) ==102752== by 0x429CACA: expandMacro (in /lib/librpmio-5.4.so) ==102752== by 0x429EA11: expandT (in /lib/librpmio-5.4.so) ==102752== by 0x429D1D6: expandMacro (in /lib/librpmio-5.4.so) ==102752== by 0x429DE86: expandMacros (in /lib/librpmio-5.4.so) ==102752== by 0x429DFEA: rpmExpand (in /lib/librpmio-5.4.so) ==102752== by 0x40D70B5: rpmcliAllArgCallback (in /lib/librpm-5.4.so) ==102752== by 0x4635F5BC: ??? (in /lib/libpopt.so.0.0.0) ==102752== by 0x4635F5F6: ??? (in /lib/libpopt.so.0.0.0) ==102752== by 0x46360EB5: poptGetNextOpt (in /lib/libpopt.so.0.0.0) ==102752== by 0x40D778C: rpmcliInit (in /lib/librpm-5.4.so) ==102752== by 0x8049CB7: main (in /bin/rpm) Having anything before the expanded macro will fix it: valgrind rpm --eval 'x%{?__noautoprovfiles}' Clearly some access before the buffer. Jacek From jajcus at jajcus.net Sat Nov 28 21:34:17 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sat, 28 Nov 2015 21:34:17 +0100 Subject: ERRORS: libmateweather.spec OK: libmatekbd.spec libmatemixer.spec mate-menus.spec In-Reply-To: <5659FCB5.50306@jajcus.net> References: <20151107124136.GA20597@cukinia.lan> <20151107131311.GA21026@mail> <201511281932.02103.arekm@maven.pl> <5659FCB5.50306@jajcus.net> Message-ID: <565A0FC9.4040309@jajcus.net> On 2015-11-28 20:12, Jacek Konieczny wrote: > Clearly some access before the buffer. Fixed, I think. Jacek From glen at pld-linux.org Sun Nov 29 10:48:45 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Sun, 29 Nov 2015 11:48:45 +0200 Subject: [packages/python-setuptools] adapter, use realtive symlink In-Reply-To: <5659C9E7.1090605@jajcus.net> References: <25fb9ea97f0c9cc2d0c6ddbf9ff65c610076d3be_refs_heads_master@pld-linux.org> <5659C9E7.1090605@jajcus.net> Message-ID: <565AC9FD.1010906@pld-linux.org> On 28.11.2015 17:36, Jacek Konieczny wrote: > On 2015-11-28 15:16, glen wrote: >> commit b6cbc91d94c8fad86e0ad1b271429f6772218700 >> Author: Elan Ruusam?e >> Date: Sat Nov 28 16:16:47 2015 +0200 >> >> adapter, use realtive symlink > [...] > >> -ln -f $RPM_BUILD_ROOT/%{_bindir}/easy_install-%{py3_ver} $RPM_BUILD_ROOT/%{_bindir}/easy_install >> +ln -sf easy_install-%{py3_ver} $RPM_BUILD_ROOT%{_bindir}/easy_install >> %else >> -ln -f $RPM_BUILD_ROOT/%{_bindir}/easy_install-%{py_ver} $RPM_BUILD_ROOT/%{_bindir}/easy_install >> +ln -sf easy_install-%{py_ver} $RPM_BUILD_ROOT%{_bindir}/easy_install >> %endif > Why symlink? There was a hard-link for purpose. No need for extra > redirection. And there are no relative hard links. symlink is easier to figure out what the file is, py2 or py3 version. similarily other stuff is symlinked as well when it comes for generic name vs versioned name. even python itself: ls -l /usr/bin/python* lrwxrwxrwx 1 root root 7 22. nov 09:39 /usr/bin/python -> python2* lrwxrwxrwx 1 root root 14 22. nov 09:39 /usr/bin/python-config -> python2-config* lrwxrwxrwx 1 root root 3 22. nov 09:39 /usr/bin/python-pip -> pip* lrwxrwxrwx 1 root root 9 22. nov 09:39 /usr/bin/python2 -> python2.7* lrwxrwxrwx 1 root root 16 22. nov 09:39 /usr/bin/python2-config -> python2.7-config* -rwxr-xr-x 1 root root 6.0K 31. okt 10:06 /usr/bin/python2.7* -rwxr-xr-x 1 root root 1.7K 31. okt 10:05 /usr/bin/python2.7-config* and what's the purpose? ps: rpm sucks when it comes to accounting free space using hardlinks (see some old thread i wrote about git-core) -- glen From glen at pld-linux.org Sun Nov 29 10:51:10 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Sun, 29 Nov 2015 11:51:10 +0200 Subject: RFC: default python installlation directories In-Reply-To: <5658394B.6090509@jajcus.net> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <56582235.8060501@pld-linux.org> <5658394B.6090509@jajcus.net> Message-ID: <565ACA8E.9000407@pld-linux.org> On 27.11.2015 13:06, Jacek Konieczny wrote: > On 2015-11-27 10:28, Elan Ruusam?e wrote: >> On 25.11.2015 22:19, Jacek Konieczny wrote: >>> If there are no objections, I may try a mass-update of python-* specs >>> tomorrow. > > more like in the weekend ;) looks like python egg dependency generator is broken, none provided: ? rpm -q --provides python-defusedxml python-defusedxml = 0.4.1-7 https://srcbuilder.pld-linux.org/~pldth/qa.php?q=main-ready-test currently 30 matches for missing "pythonegg", it will probably grow as the queue is big ps: should use bigger than default pri=2 when doing mass builds, so normal builds get built first. -- glen From glen at pld-linux.org Sun Nov 29 10:59:06 2015 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Sun, 29 Nov 2015 11:59:06 +0200 Subject: RFC: default python installlation directories In-Reply-To: <565ACA8E.9000407@pld-linux.org> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <56582235.8060501@pld-linux.org> <5658394B.6090509@jajcus.net> <565ACA8E.9000407@pld-linux.org> Message-ID: <565ACC6A.10501@pld-linux.org> On 29.11.2015 11:51, Elan Ruusam?e wrote: > On 27.11.2015 13:06, Jacek Konieczny wrote: >> On 2015-11-27 10:28, Elan Ruusam?e wrote: >>> On 25.11.2015 22:19, Jacek Konieczny wrote: >>>> If there are no objections, I may try a mass-update of python-* specs >>>> tomorrow. btw, why was mass rebuild necessary? binary wise nothing changes in already built packages? just mass fixing spec does not need to follow rebuild? -- glen From jajcus at jajcus.net Sun Nov 29 11:07:46 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 29 Nov 2015 11:07:46 +0100 Subject: RFC: default python installlation directories In-Reply-To: <565ACC6A.10501@pld-linux.org> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <56582235.8060501@pld-linux.org> <5658394B.6090509@jajcus.net> <565ACA8E.9000407@pld-linux.org> <565ACC6A.10501@pld-linux.org> Message-ID: <565ACE72.7070901@jajcus.net> On 2015-11-29 10:59, Elan Ruusam?e wrote: > On 29.11.2015 11:51, Elan Ruusam?e wrote: >> On 27.11.2015 13:06, Jacek Konieczny wrote: >>> On 2015-11-27 10:28, Elan Ruusam?e wrote: >>>> On 25.11.2015 22:19, Jacek Konieczny wrote: >>>>> If there are no objections, I may try a mass-update of python-* specs >>>>> tomorrow. > > btw, why was mass rebuild necessary? You are right, it was not. But there is a good side: we caught some problems introduced with recent python changes. Jacek From jajcus at jajcus.net Sun Nov 29 11:29:42 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 29 Nov 2015 11:29:42 +0100 Subject: RFC: default python installlation directories In-Reply-To: <565ACA8E.9000407@pld-linux.org> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <56582235.8060501@pld-linux.org> <5658394B.6090509@jajcus.net> <565ACA8E.9000407@pld-linux.org> Message-ID: <565AD396.5070602@jajcus.net> On 2015-11-29 10:51, Elan Ruusam?e wrote: > looks like python egg dependency generator is broken, none provided: > > ? rpm -q --provides python-defusedxml > python-defusedxml = 0.4.1-7 Already fixed in rpm. > https://srcbuilder.pld-linux.org/~pldth/qa.php?q=main-ready-test > currently 30 matches for missing "pythonegg", it will probably grow as > the queue is big I will rebuild the affected packages when this batch is done. > ps: should use bigger than default pri=2 when doing mass builds, so > normal builds get built first. I will remember the next time. Jacek From baggins at pld-linux.org Sun Nov 29 22:58:14 2015 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 29 Nov 2015 22:58:14 +0100 Subject: RFC: default python installlation directories In-Reply-To: <565617C9.5010402@jajcus.net> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> Message-ID: <20151129215813.GA4015@home.lan> On Wed, 25 Nov 2015, Jacek Konieczny wrote: > On 2015-11-22 18:52, Jan R?korajski wrote: > > On Sun, 22 Nov 2015, Jacek Konieczny wrote: > >> > >> I suggest patching python, python3 and, if neccessary, other packages, > >> so distutils/setuptools/pip would install Python modules to /usr/local > >> by default ? like autoconf configure scripts do. Python would look for > >> modues in /usr/local first and then in /usr. > > > > Makes sense. Go ahead and do it. > > Done. > > New RPM build macros added: > %py_build > %py_install > %py3_build > %py3_install > > Just %setup_py and %setup_py3 wouldn't do as we cannot change options > order: > 'setup.py --prefix=/usr install' is wrong, > 'setup.py install --prefix=/usr' is ok. > > I have updated the python template specs and a few packages. Things > seems to work well. Including distutils, setuptools and pip. > > If there are no objections, I may try a mass-update of python-* specs > tomorrow. The change broke icedove/iceweasel build, looks like some virtualenv paths confusion: http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=icedove&id=3c8b77d4-5fec-47a0-ae3d-dd2a575890c2&action=tail -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From baggins at pld-linux.org Sun Nov 29 23:30:40 2015 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 29 Nov 2015 23:30:40 +0100 Subject: RFC: default python installlation directories In-Reply-To: <20151129215813.GA4015@home.lan> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan> Message-ID: <20151129223039.GB4015@home.lan> On Sun, 29 Nov 2015, Jan R?korajski wrote: > On Wed, 25 Nov 2015, Jacek Konieczny wrote: > > > On 2015-11-22 18:52, Jan R?korajski wrote: > > > On Sun, 22 Nov 2015, Jacek Konieczny wrote: > > >> > > >> I suggest patching python, python3 and, if neccessary, other packages, > > >> so distutils/setuptools/pip would install Python modules to /usr/local > > >> by default ? like autoconf configure scripts do. Python would look for > > >> modues in /usr/local first and then in /usr. > > > > > > Makes sense. Go ahead and do it. > > > > Done. > > > > New RPM build macros added: > > %py_build > > %py_install > > %py3_build > > %py3_install > > > > Just %setup_py and %setup_py3 wouldn't do as we cannot change options > > order: > > 'setup.py --prefix=/usr install' is wrong, > > 'setup.py install --prefix=/usr' is ok. > > > > I have updated the python template specs and a few packages. Things > > seems to work well. Including distutils, setuptools and pip. > > > > If there are no objections, I may try a mass-update of python-* specs > > tomorrow. > > The change broke icedove/iceweasel build, looks like some virtualenv > paths confusion: > > http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=icedove&id=3c8b77d4-5fec-47a0-ae3d-dd2a575890c2&action=tail Actually it broke virtualenv/pip: $ virtualenv xxx New python executable in xxx/bin/python2 Not overwriting existing python script xxx/bin/python (you must use xxx/bin/python2) Installing setuptools, pip, wheel... Complete output from command /home/users/baggins/8/xxx/bin/python2 -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel: Ignoring indexes: https://pypi.python.org/simple Collecting setuptools Collecting pip Collecting wheel Installing collected packages: setuptools, pip, wheel Exception: Traceback (most recent call last): File "/usr/share/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/basecommand.py", line 211, in main status = self.run(options, args) File "/usr/share/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/commands/install.py", line 311, in run root=options.root_path, File "/usr/share/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/req/req_set.py", line 646, in install **kwargs File "/usr/share/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/req/req_install.py", line 803, in install self.move_wheel_files(self.source_dir, root=root) File "/usr/share/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/req/req_install.py", line 998, in move_wheel_files isolated=self.isolated, File "/usr/share/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/wheel.py", line 339, in move_wheel_files clobber(source, lib_dir, True) File "/usr/share/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/wheel.py", line 282, in clobber ensure_dir(dest) # common for the 'include' path File "/usr/share/python2.7/site-packages/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/utils/__init__.py", line 71, in ensure_dir os.makedirs(path) File "/home/users/baggins/8/xxx/share/python2.7/os.py", line 150, in makedirs makedirs(head, mode) File "/home/users/baggins/8/xxx/share/python2.7/os.py", line 157, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7' ---------------------------------------- ...Installing setuptools, pip, wheel...done. Traceback (most recent call last): File "/usr/bin/virtualenv", line 9, in load_entry_point('virtualenv==13.1.2', 'console_scripts', 'virtualenv')() File "/usr/share/python2.7/site-packages/virtualenv.py", line 896, in main symlink=options.symlink) File "/usr/share/python2.7/site-packages/virtualenv.py", line 1068, in create_environment install_wheel(to_install, py_executable, search_dirs) File "/usr/share/python2.7/site-packages/virtualenv.py", line 1033, in install_wheel 'PIP_NO_INDEX': '1' File "/usr/share/python2.7/site-packages/virtualenv.py", line 974, in call_subprocess % (cmd_desc, proc.returncode)) OSError: Command /home/users/baggins/8/xxx/bin/python2 -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel failed with error code 2 -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From jajcus at jajcus.net Mon Nov 30 08:07:58 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 30 Nov 2015 08:07:58 +0100 Subject: RFC: default python installlation directories In-Reply-To: <20151129223039.GB4015@home.lan> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan> <20151129223039.GB4015@home.lan> Message-ID: <565BF5CE.5010601@jajcus.net> On 2015-11-29 23:30, Jan R?korajski wrote: >> The change broke icedove/iceweasel build, looks like some virtualenv >> paths confusion: >> >> http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=icedove&id=3c8b77d4-5fec-47a0-ae3d-dd2a575890c2&action=tail Yes, I have seen that. > Actually it broke virtualenv/pip: > > $ virtualenv xxx > New python executable in xxx/bin/python2 > Not overwriting existing python script xxx/bin/python (you must use xxx/bin/python2) [...] > OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7' That is strange. Though, maybe virtualenv overrides sys.prefix and then uses that for installation. In such case I would have to change the python patch a bit. Does it work in Python 3 correctly? Things are a bit different there. I will investigate this further in the evening. Jacek From j.rekorajski at gmail.com Mon Nov 30 09:19:14 2015 From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=) Date: Mon, 30 Nov 2015 09:19:14 +0100 Subject: RFC: default python installlation directories In-Reply-To: <565BF5CE.5010601@jajcus.net> References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan> <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net> Message-ID: On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny wrote: > On 2015-11-29 23:30, Jan R?korajski wrote: >>> >>> The change broke icedove/iceweasel build, looks like some virtualenv >>> paths confusion: >>> >>> >>> http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=icedove&id=3c8b77d4-5fec-47a0-ae3d-dd2a575890c2&action=tail > > > Yes, I have seen that. > >> Actually it broke virtualenv/pip: >> >> $ virtualenv xxx >> New python executable in xxx/bin/python2 >> Not overwriting existing python script xxx/bin/python (you must use >> xxx/bin/python2) > > [...] >> >> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7' > > > That is strange. Though, maybe virtualenv overrides sys.prefix and then uses > that for installation. In such case I would have to change the python patch > a bit. Does it work in Python 3 correctly? Things are a bit different there. > > I will investigate this further in the evening. A food for thought - what about dropping PLD specific hack with with lib<->share split? It constantly gives us grief with virtualenv. -- Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ bagginspld-linux.org From jajcus at jajcus.net Mon Nov 30 10:23:52 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 30 Nov 2015 10:23:52 +0100 Subject: RFC: default python installlation directories In-Reply-To: References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan> <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net> Message-ID: <565C15A8.2030201@jajcus.net> On 2015-11-30 09:19, Jan R?korajski wrote: > A food for thought - what about dropping PLD specific hack with with > lib<->share split? What do you choose? ? binaries (*.so) in /usr/share and conflicts between x86_64 and i686 packages ? all python modules in %{_libdir} and no more 'noarch' Python packages (as %{_libdir} is different on x86_64 and i686) ? all python modules in /usr/lib ? pure python modules could stay 'noarch', but binary modules (*.so) would conflict between x86_64 and i686 packages However we handle dropping the the split, it will cause new problems. > It constantly gives us grief with virtualenv. Does it? The funny thing is that original Python sources have notion of different locations for platform-dependent and platform-independent modules. But those paths, on 'unix' differ by the prefix (--prefix vs --exec-prefix), not further path. I have no idea why they have chosen to ignore FHS. Other distributions have to patch this too, unless they ignore FHS or mult-lib installations too. Jacek From jajcus at jajcus.net Mon Nov 30 16:42:11 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 30 Nov 2015 16:42:11 +0100 Subject: RFC: default python installlation directories In-Reply-To: References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan> <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan> <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net> Message-ID: <565C6E53.5030007@jajcus.net> On 2015-11-30 09:19, Jan R?korajski wrote: > A food for thought - what about dropping PLD specific hack with with > lib<->share split? > It constantly gives us grief with virtualenv. Ok, now I can see what can be done. We need to keep the split between /usr/{lib64,share}/pythonX.Y/site-packages ? for noarch packages, but there is probably no reason to split the Python package itself into /usr/{lib64,share}/pythonX.Y. That should help virtualenv. But I first check if there is no easier way. Jacek From qboosh at pld-linux.org Mon Nov 30 21:07:04 2015 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 30 Nov 2015 21:07:04 +0100 Subject: [packages/sphinx-pdg] py_build/py_install macros, use python3 by default In-Reply-To: References: Message-ID: <20151130200704.GA25814@mail> On Sat, Nov 28, 2015 at 03:11:04PM +0100, jajcus wrote: > commit b9b9d28833bd29bd614464718b69ccd003ea238b > Author: Jacek Konieczny > Date: Sat Nov 28 15:10:30 2015 +0100 > > py_build/py_install macros, use python3 by default Maybe always create both -2 and -3 (with non-bconditional content) and base package with just symlinks to default version (bconditional)? -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Mon Nov 30 21:13:52 2015 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 30 Nov 2015 21:13:52 +0100 Subject: [packages/python-amqp] fix apidocs build In-Reply-To: <8df16ed9ea864060d2f64e4da41c5b7261d4f1ad_refs_heads_master@pld-linux.org> References: <8df16ed9ea864060d2f64e4da41c5b7261d4f1ad_refs_heads_master@pld-linux.org> Message-ID: <20151130201352.GB25814@mail> On Mon, Nov 30, 2015 at 07:17:21PM +0100, jajcus wrote: > commit 8df16ed9ea864060d2f64e4da41c5b7261d4f1ad > Author: Jacek Konieczny > Date: Mon Nov 30 19:16:45 2015 +0100 > > fix apidocs build > %if %{with doc} > BuildRequires: python-sphinxcontrib-issuetracker > -BuildRequires: sphinx-pdg > +BuildRequires: sphinx-pdg-2 > %endif > %endif > %if %{with python3} > @@ -40,6 +40,10 @@ BuildRequires: python3-mock > BuildRequires: python3-nose > BuildRequires: python3-nose-cover3 > %endif > +%if %{with doc} > +BuildRequires: python3-sphinxcontrib-issuetracker > +BuildRequires: sphinx-pdg-3 > +%endif > %endif > @@ -120,6 +145,12 @@ rm -rf $RPM_BUILD_ROOT > %dir %{py_sitescriptdir}/%{module}/tests > %{py_sitescriptdir}/%{module}/tests/*.py[co] > %{py_sitescriptdir}/%{module}-%{version}-py*.egg-info > + > +%if %{with doc} > +%files apidocs > +%defattr(644,root,root,755) > +%doc docs/.build2/html/* > +%endif > %endif > > %if %{with python3} > @@ -128,10 +159,10 @@ rm -rf $RPM_BUILD_ROOT > %doc Changelog README.rst > %{py3_sitescriptdir}/%{module} > %{py3_sitescriptdir}/%{module}-%{version}-py*.egg-info > -%endif > > %if %{with doc} > -%files apidocs > +%files -n python3-%{module}-apidocs > %defattr(644,root,root,755) > -%doc docs/.build/html/* > +%doc docs/.build3/html/* > +%endif > %endif Why -apidocs for both python versions? Does documentation differ? -- Jakub Bogusz http://qboosh.pl/ From jajcus at jajcus.net Mon Nov 30 21:26:10 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 30 Nov 2015 21:26:10 +0100 Subject: [packages/sphinx-pdg] py_build/py_install macros, use python3 by default In-Reply-To: <20151130200704.GA25814@mail> References: <20151130200704.GA25814@mail> Message-ID: <565CB0E2.9000701@jajcus.net> On 2015-11-30 21:07, Jakub Bogusz wrote: > On Sat, Nov 28, 2015 at 03:11:04PM +0100, jajcus wrote: >> commit b9b9d28833bd29bd614464718b69ccd003ea238b >> Author: Jacek Konieczny >> Date: Sat Nov 28 15:10:30 2015 +0100 >> >> py_build/py_install macros, use python3 by default > > Maybe always create both -2 and -3 (with non-bconditional content) > and base package with just symlinks to default version (bconditional)? I assumed that a package with symlinks only is a bad idea. Though I am not very attached to this assumption. Jacek From jajcus at jajcus.net Mon Nov 30 21:28:18 2015 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 30 Nov 2015 21:28:18 +0100 Subject: [packages/python-amqp] fix apidocs build In-Reply-To: <20151130201352.GB25814@mail> References: <8df16ed9ea864060d2f64e4da41c5b7261d4f1ad_refs_heads_master@pld-linux.org> <20151130201352.GB25814@mail> Message-ID: <565CB162.9040708@jajcus.net> On 2015-11-30 21:13, Jakub Bogusz wrote: > On Mon, Nov 30, 2015 at 07:17:21PM +0100, jajcus wrote: >> commit 8df16ed9ea864060d2f64e4da41c5b7261d4f1ad >> Author: Jacek Konieczny >> Date: Mon Nov 30 19:16:45 2015 +0100 >> >> fix apidocs build > >> %if %{with doc} >> BuildRequires: python-sphinxcontrib-issuetracker >> -BuildRequires: sphinx-pdg >> +BuildRequires: sphinx-pdg-2 >> %endif >> %endif >> %if %{with python3} >> @@ -40,6 +40,10 @@ BuildRequires: python3-mock >> BuildRequires: python3-nose >> BuildRequires: python3-nose-cover3 >> %endif >> +%if %{with doc} >> +BuildRequires: python3-sphinxcontrib-issuetracker >> +BuildRequires: sphinx-pdg-3 >> +%endif >> %endif > >> @@ -120,6 +145,12 @@ rm -rf $RPM_BUILD_ROOT >> %dir %{py_sitescriptdir}/%{module}/tests >> %{py_sitescriptdir}/%{module}/tests/*.py[co] >> %{py_sitescriptdir}/%{module}-%{version}-py*.egg-info >> + >> +%if %{with doc} >> +%files apidocs >> +%defattr(644,root,root,755) >> +%doc docs/.build2/html/* >> +%endif >> %endif >> >> %if %{with python3} >> @@ -128,10 +159,10 @@ rm -rf $RPM_BUILD_ROOT >> %doc Changelog README.rst >> %{py3_sitescriptdir}/%{module} >> %{py3_sitescriptdir}/%{module}-%{version}-py*.egg-info >> -%endif >> >> %if %{with doc} >> -%files apidocs >> +%files -n python3-%{module}-apidocs >> %defattr(644,root,root,755) >> -%doc docs/.build/html/* >> +%doc docs/.build3/html/* >> +%endif >> %endif > > Why -apidocs for both python versions? > Does documentation differ? It may differ. Python 3 version may have extended API (using the new features) or one of versions (Python 2 or Python 3) may be not feature-complete. Also, it was easier to handle the with_python2/with_python3 bconds. Jacek