From pawelz at pld-linux.org Thu Sep 2 14:55:20 2010 From: pawelz at pld-linux.org (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Thu, 2 Sep 2010 14:55:20 +0200 Subject: kernel.spec, %ifarch overdoze Message-ID: <20100902125520.GA4517@pzz.touk.pl> packages/kernel/kernel.spec @HEAD, line 1157: %ifarch alpha sparc sparc64 %{__gzip} -cfv %{objdir}/vmlinux > %{objdir}/vmlinuz cp -a %{objdir}/vmlinuz $RPM_BUILD_ROOT/boot/vmlinuz-%{kernel_release} install %{objdir}/vmlinux $RPM_BUILD_ROOT/boot/vmlinuz-%{kernel_release} %ifarch sparc elftoaout %{objdir}/arch/sparc/boot/image -o %{objdir}/vmlinux.aout install %{objdir}/vmlinux.aout $RPM_BUILD_ROOT/boot/vmlinux.aout-%{kernel_release} %endif %ifarch sparc64 elftoaout %{objdir}/arch/sparc64/boot/image -o %{objdir}/vmlinux.aout install %{objdir}/vmlinux.aout $RPM_BUILD_ROOT/boot/vmlinux.aout-%{kernel_release} %endif %ifarch arm install %{objdir}/arch/arm/boot/zImage $RPM_BUILD_ROOT/boot/vmlinuz-%{kernel_release} %endif %endif Last %ifarch seems to be noop. Is last %endif is misplaced, or 'arm' should be appended to the first %ifarch? -- Regards, Pawe? From przemo at firszt.eu Sat Sep 4 21:43:33 2010 From: przemo at firszt.eu (Przemo Firszt) Date: Sat, 04 Sep 2010 20:43:33 +0100 Subject: [PATCH] lensfun-0.2.5 + ufraw-0.17 bug Message-ID: <1283629413.7902.26.camel@pldmachine> Hi, There is a bug that causes SIGSEGV in ufraw-0.17 when used with lensfun-0.2.5. Turning off vectorisation in lensfun is a known workaround for this bug. See attached patch. -- Reagrds, Przemo Firszt -------------- next part -------------- A non-text attachment was scrubbed... Name: lensfun.spec.patch Type: text/x-patch Size: 601 bytes Desc: not available URL: From kornet at gatekeeper.camk.edu.pl Sun Sep 5 11:24:18 2010 From: kornet at gatekeeper.camk.edu.pl (Kacper Kornet) Date: Sun, 5 Sep 2010 11:24:18 +0200 Subject: [PATCH] lensfun-0.2.5 + ufraw-0.17 bug In-Reply-To: <1283629413.7902.26.camel@pldmachine> References: <1283629413.7902.26.camel@pldmachine> Message-ID: <20100905092418.GA6708@gatekeeper.camk.edu.pl> On Sat, Sep 04, 2010 at 08:43:33PM +0100, Przemo Firszt wrote: > There is a bug that causes SIGSEGV in ufraw-0.17 when used with > lensfun-0.2.5. Turning off vectorisation in lensfun is a known > workaround for this bug. See attached patch. Could you check lensfun-0.2.5-2 from our CVS? I have just added patch which is supposed to fix the bug. -- Kacper From przemo at firszt.eu Sun Sep 5 17:54:13 2010 From: przemo at firszt.eu (Przemo Firszt) Date: Sun, 05 Sep 2010 16:54:13 +0100 Subject: [PATCH] lensfun-0.2.5 + ufraw-0.17 bug In-Reply-To: <20100905092418.GA6708@gatekeeper.camk.edu.pl> References: <1283629413.7902.26.camel@pldmachine> <20100905092418.GA6708@gatekeeper.camk.edu.pl> Message-ID: <1283702053.2926.0.camel@pldmachine> Dnia 2010-09-05, nie o godzinie 11:24 +0200, Kacper Kornet pisze: > On Sat, Sep 04, 2010 at 08:43:33PM +0100, Przemo Firszt wrote: > > There is a bug that causes SIGSEGV in ufraw-0.17 when used with > > lensfun-0.2.5. Turning off vectorisation in lensfun is a known > > workaround for this bug. See attached patch. > > Could you check lensfun-0.2.5-2 from our CVS? I have just added patch > which is supposed to fix the bug. Tested & works fine, so ma patch is no longer required. Thanks, -- Przemo Firszt From qboosh at pld-linux.org Mon Sep 6 20:18:32 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 6 Sep 2010 20:18:32 +0200 Subject: packages: filesystem/filesystem.spec - /usr/share/vala/vapi directory added... In-Reply-To: References:

Message-ID: <20100906181832.GD24059@stranger.qboosh.pl> On Mon, Sep 06, 2010 at 01:49:44PM +0200, jajcus wrote: > Author: jajcus Date: Mon Sep 6 11:49:44 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - /usr/share/vala/vapi directory added (vala package provides only the > versioned one and packeges providing vapi files do not always require Vala) My proposal is to separate vala-* (or vala-vapi-*) packages - they provide optional API for rarely used (mostly gnomish) vala language... -- Jakub Bogusz http://qboosh.pl/ From jajcus at jajcus.net Tue Sep 7 08:04:18 2010 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 7 Sep 2010 08:04:18 +0200 Subject: packages: filesystem/filesystem.spec - /usr/share/vala/vapi directory added... In-Reply-To: <20100906181832.GD24059@stranger.qboosh.pl> References:

<20100906181832.GD24059@stranger.qboosh.pl> Message-ID: <20100907060417.GA18547@jajo.eggsoft> On Mon, Sep 06, 2010 at 08:18:32PM +0200, Jakub Bogusz wrote: > On Mon, Sep 06, 2010 at 01:49:44PM +0200, jajcus wrote: > > Author: jajcus Date: Mon Sep 6 11:49:44 2010 GMT > > Module: packages Tag: HEAD > > ---- Log message: > > - /usr/share/vala/vapi directory added (vala package provides only the > > versioned one and packeges providing vapi files do not always require Vala) > > My proposal is to separate vala-* (or vala-vapi-*) packages - they > provide optional API for rarely used (mostly gnomish) vala language... The files are not big, the only dependency they add is the single directory. I see no reason in splitting those in separate subpackages, placing them in -devel should be enough, I guess. Greets, Jacek From qboosh at pld-linux.org Tue Sep 7 19:55:25 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 7 Sep 2010 19:55:25 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: References:

Message-ID: <20100907175525.GE24059@stranger.qboosh.pl> On Tue, Sep 07, 2010 at 12:45:15PM +0200, patrys wrote: > %files static > %defattr(644,root,root,755) > %{_libdir}/libcairo.a > +%{_libdir}/libcairo-gobject.a > +%{_libdir}/libcairo-gobject.la Too baaad... this causes that *.la of libs/modules using libcairo-gobject would have different dependencies (-lcairo-gobject or libcairo-gobject.la) depending on presence of cairo-static. This is not acceptable. Either move this .la to -devel, or remove at all. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Tue Sep 7 20:00:26 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 7 Sep 2010 20:00:26 +0200 Subject: packages: filesystem/filesystem.spec - /usr/share/vala/vapi directory added... In-Reply-To: <20100907060417.GA18547@jajo.eggsoft> References:

<20100906181832.GD24059@stranger.qboosh.pl> <20100907060417.GA18547@jajo.eggsoft> Message-ID: <20100907180026.GA5518@stranger.qboosh.pl> On Tue, Sep 07, 2010 at 08:04:18AM +0200, Jacek Konieczny wrote: > On Mon, Sep 06, 2010 at 08:18:32PM +0200, Jakub Bogusz wrote: > > On Mon, Sep 06, 2010 at 01:49:44PM +0200, jajcus wrote: > > > Author: jajcus Date: Mon Sep 6 11:49:44 2010 GMT > > > Module: packages Tag: HEAD > > > ---- Log message: > > > - /usr/share/vala/vapi directory added (vala package provides only the > > > versioned one and packeges providing vapi files do not always require Vala) > > > > My proposal is to separate vala-* (or vala-vapi-*) packages - they > > provide optional API for rarely used (mostly gnomish) vala language... > > The files are not big, the only dependency they add is the single > directory. I see no reason in splitting those in separate subpackages, > placing them in -devel should be enough, I guess. But (AFAIK) they have no use without vala compiler. And IMO it would be logical that programs written in vala BR appropriate vala-* packages. -- Jakub Bogusz http://qboosh.pl/ From patrys at pld-linux.org Tue Sep 7 20:59:39 2010 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 7 Sep 2010 20:59:39 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100907175525.GE24059@stranger.qboosh.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> Message-ID: On Tue, Sep 7, 2010 at 7:55 PM, Jakub Bogusz wrote: > On Tue, Sep 07, 2010 at 12:45:15PM +0200, patrys wrote: >> ?%files static >> ?%defattr(644,root,root,755) >> ?%{_libdir}/libcairo.a >> +%{_libdir}/libcairo-gobject.a >> +%{_libdir}/libcairo-gobject.la > > Too baaad... this causes that *.la of libs/modules using > libcairo-gobject would have different dependencies (-lcairo-gobject or > libcairo-gobject.la) depending on presence of cairo-static. > This is not acceptable. > > Either move this .la to -devel, or remove at all. Last time I checked libtool complained when you asked it to link statically without a .la file present. If it stays quiet now, I'll more than gladly drop the .la file. -- Patryk Zawadzki From patrys at pld-linux.org Tue Sep 7 21:00:58 2010 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 7 Sep 2010 21:00:58 +0200 Subject: packages: filesystem/filesystem.spec - /usr/share/vala/vapi directory added... In-Reply-To: <20100907180026.GA5518@stranger.qboosh.pl> References:

<20100906181832.GD24059@stranger.qboosh.pl> <20100907060417.GA18547@jajo.eggsoft> <20100907180026.GA5518@stranger.qboosh.pl> Message-ID: On Tue, Sep 7, 2010 at 8:00 PM, Jakub Bogusz wrote: > But (AFAIK) they have no use without vala compiler. > And IMO it would be logical that programs written in vala BR appropriate > vala-* packages. +1 even though the files are only needed at compilation time. -- Patryk Zawadzki From gotar at polanet.pl Wed Sep 8 09:23:49 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 8 Sep 2010 09:23:49 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100907175525.GE24059@stranger.qboosh.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> Message-ID: <20100908072348.GA31149@polanet.pl> On Tue, Sep 07, 2010 at 19:55:25 +0200, Jakub Bogusz wrote: >> %files static >> %defattr(644,root,root,755) >> %{_libdir}/libcairo.a >> +%{_libdir}/libcairo-gobject.a >> +%{_libdir}/libcairo-gobject.la > > Too baaad... this causes that *.la of libs/modules using > libcairo-gobject would have different dependencies (-lcairo-gobject or > libcairo-gobject.la) depending on presence of cairo-static. All those .la files should be moved to their -static as well. As for generated dependencies builders don't have *-static installed, so pkgconfig would be used and in resoult -lcairo-gobject should be put. Or maybe building *-static _should_ require -static and not only -devel? > Either move this .la to -devel, or remove at all. Regular .la are part of _static_ building, so there's no place in -devel for them. It only causes troubles. There was a discussion (well, not too many of 'discussion' were there) recently, please read this and continue there. Also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581352 In short: instead removing I've suggested repackaging into *-static, just because in contrary to other distros we support this kind of build. Without .la files there we might remove all the *-static too, as in general they would be useless. -- Tomasz Pala From mike at osdn.org.ua Wed Sep 8 10:05:43 2010 From: mike at osdn.org.ua (Michael Shigorin) Date: Wed, 8 Sep 2010 11:05:43 +0300 Subject: *-static (was: packages: cairo/cairo-link.patch ...) In-Reply-To: <20100908072348.GA31149@polanet.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> Message-ID: <20100908080543.GU14287@osdn.org.ua> On Wed, Sep 08, 2010 at 09:23:49AM +0200, Tomasz Pala wrote: > Or maybe building *-static _should_ require -static and not only -devel? Yup. > In short: instead removing I've suggested repackaging into *-static, > just because in contrary to other distros we support this kind of build. In ALT Linux ( :)) ), we do have some *-devel-static packages and they do buildrequire corresponding static subpackages for what they use to build (or more precisely, to statically link against). buildreq is a nice tool: http://git.altlinux.org/people/ldv/packages/?p=rpm-utils.git;a=blob;f=rpm-utils/buildreq;hb=HEAD -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From qboosh at pld-linux.org Thu Sep 9 21:08:36 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 9 Sep 2010 21:08:36 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100908072348.GA31149@polanet.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> Message-ID: <20100909190836.GB5518@stranger.qboosh.pl> On Wed, Sep 08, 2010 at 09:23:49AM +0200, Tomasz Pala wrote: > On Tue, Sep 07, 2010 at 19:55:25 +0200, Jakub Bogusz wrote: > > >> %files static > >> %defattr(644,root,root,755) > >> %{_libdir}/libcairo.a > >> +%{_libdir}/libcairo-gobject.a > >> +%{_libdir}/libcairo-gobject.la > > > > Too baaad... this causes that *.la of libs/modules using > > libcairo-gobject would have different dependencies (-lcairo-gobject or > > libcairo-gobject.la) depending on presence of cairo-static. > > All those .la files should be moved to their -static as well. As for > generated dependencies builders don't have *-static installed, so > pkgconfig would be used and in resoult -lcairo-gobject should be put. > > Or maybe building *-static _should_ require -static and not only -devel? Presence of *.a doesn't serve anything for -static building (just occuping disk space and hiding some errors in package configure scripts/makefiles). > > Either move this .la to -devel, or remove at all. > > Regular .la are part of _static_ building, so there's no place in -devel > for them. It only causes troubles. Well, unfortunately libtool didn't change its mind and uses dependency_libs during shared linking too. Maybe this is the only thing that should be changed... > There was a discussion (well, not too many of 'discussion' were there) > recently, please read this and continue there. Also: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581352 > > In short: instead removing I've suggested repackaging into *-static, > just because in contrary to other distros we support this kind of build. > Without .la files there we might remove all the *-static too, as in > general they would be useless. Packaging *.la in -static has several faults: - content of new .la file depends on presence of *.la files from dependent libraries, so the rule on their precence on builders must be strict. - we can't forbid installing _any_ static library on builders - in some rare cases they are used. - we don't want to install all *-static on builders from the reasons mentioned above. Plus: keeping all *-static containing *.la files on builders is in no way better than preevailing situation: *.la files are still "poisoned" by obsolete libraries (and thus rebuilding would be still required in case of transition like libpng12 -> libpng14 or dropping some dependency), and they affect on shared library building (-as-needed still needs to be enforced). -- Jakub Bogusz http://qboosh.pl/ From patrys at pld-linux.org Thu Sep 9 21:22:52 2010 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Thu, 9 Sep 2010 21:22:52 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100909190836.GB5518@stranger.qboosh.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> Message-ID: On Thu, Sep 9, 2010 at 9:08 PM, Jakub Bogusz wrote: > Plus: keeping all *-static containing *.la files on builders is in no > way better than preevailing situation: *.la files are still "poisoned" > by obsolete libraries (and thus rebuilding would be still required > in case of transition like libpng12 -> libpng14 or dropping some > dependency), and they affect on shared library building (-as-needed > still needs to be enforced). So two options: make libtool ignore the .la or replace all .la file contents with a pre-built template that pulls no dependencies (we want configure/autotools to take care of that anyway). -- Patryk Zawadzki From gotar at polanet.pl Thu Sep 9 21:57:39 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Thu, 9 Sep 2010 21:57:39 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100909190836.GB5518@stranger.qboosh.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> Message-ID: <20100909195739.GA32718@polanet.pl> On Thu, Sep 09, 2010 at 21:08:36 +0200, Jakub Bogusz wrote: >> Or maybe building *-static _should_ require -static and not only -devel? > > Presence of *.a doesn't serve anything for -static building But .la does. In fact if we didn't support static building we could simply remove .la, ...so maybe drop -static? > Well, unfortunately libtool didn't change its mind and uses > dependency_libs during shared linking too. > Maybe this is the only thing that should be changed... Only if pushed upstream - we shouldn't create another world-incompatibility as we already did a few times. > Packaging *.la in -static has several faults: > > - content of new .la file depends on presence of *.la files from > dependent libraries, so the rule on their precence on builders must be > strict. > > - we can't forbid installing _any_ static library on builders - in some > rare cases they are used. > > - we don't want to install all *-static on builders from the reasons > mentioned above. Well, seems .la files are just some temporary non-deterministic crap. There's no place for such files in any subpackage. > Plus: keeping all *-static containing *.la files on builders is in no > way better than preevailing situation: *.la files are still "poisoned" > by obsolete libraries (and thus rebuilding would be still required > in case of transition like libpng12 -> libpng14 or dropping some > dependency), and they affect on shared library building (-as-needed > still needs to be enforced). Yep. So we should: 1. remove .la entirely, 2. except for those required by our *-static, 3. unless we drop static subpackages, 4. or fix our libtool (last resort scenario). -- Tomasz Pala From mike at osdn.org.ua Fri Sep 10 18:32:34 2010 From: mike at osdn.org.ua (Michael Shigorin) Date: Fri, 10 Sep 2010 19:32:34 +0300 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100909195739.GA32718@polanet.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> <20100909195739.GA32718@polanet.pl> Message-ID: <20100910163234.GB14287@osdn.org.ua> On Thu, Sep 09, 2010 at 09:57:39PM +0200, Tomasz Pala wrote: > Yep. So we should: > 1. remove .la entirely, > 2. except for those required by our *-static, > 3. unless we drop static subpackages, > 4. or fix our libtool (last resort scenario). And in Soviet Russia, we've been removing *.la from *-devel for years! (at least in ALT Linux :) -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From qboosh at pld-linux.org Fri Sep 10 19:59:08 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 10 Sep 2010 19:59:08 +0200 Subject: packages: ffmpeg/ffmpeg.spec - link with faad at compile time; rel 4 In-Reply-To: References:

Message-ID: <20100910175908.GF24059@stranger.qboosh.pl> On Fri, Sep 10, 2010 at 08:59:51AM +0200, glen wrote: > Author: glen Date: Fri Sep 10 06:59:51 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - link with faad at compile time; rel 4 Why? Linking all with everything is not desired... -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Fri Sep 10 21:46:04 2010 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Fri, 10 Sep 2010 22:46:04 +0300 Subject: packages: ffmpeg/ffmpeg.spec - link with faad at compile time; rel 4 In-Reply-To: <20100910175908.GF24059@stranger.qboosh.pl> References:

<20100910175908.GF24059@stranger.qboosh.pl> Message-ID: <4C8A8AFC.4090003@pld-linux.org> On 10/09/10 20:59, Jakub Bogusz wrote: > On Fri, Sep 10, 2010 at 08:59:51AM +0200, glen wrote: >> Author: glen Date: Fri Sep 10 06:59:51 2010 GMT >> Module: packages Tag: HEAD >> ---- Log message: >> - link with faad at compile time; rel 4 > > Why? > > Linking all with everything is not desired... lacking capatability is not desired either, it links with everything else, why should faad be exception? and there is no suggests present either to know that some features can be extended with installing extra libs. -- glen From qboosh at pld-linux.org Sat Sep 11 12:37:23 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 11 Sep 2010 12:37:23 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> Message-ID: <20100911103723.GC5518@stranger.qboosh.pl> On Thu, Sep 09, 2010 at 09:22:52PM +0200, Patryk Zawadzki wrote: > On Thu, Sep 9, 2010 at 9:08 PM, Jakub Bogusz wrote: > > Plus: keeping all *-static containing *.la files on builders is in no > > way better than preevailing situation: *.la files are still "poisoned" > > by obsolete libraries (and thus rebuilding would be still required > > in case of transition like libpng12 -> libpng14 or dropping some > > dependency), and they affect on shared library building (-as-needed > > still needs to be enforced). > > So two options: make libtool ignore the .la or replace all .la file > contents with a pre-built template that pulls no dependencies Keeping stub .la doesn't make any sense; if there is no other method to pull all dependencies (like correct pkgconfig files chain), static library can be considered useless. > (we want configure/autotools to take care of that anyway). ? I don't see how autoconf/automake (without pkgconfig stuff) could take care of dependencies of already built library. -- Jakub Bogusz http://qboosh.pl/ From kornet at gatekeeper.camk.edu.pl Mon Sep 13 16:31:45 2010 From: kornet at gatekeeper.camk.edu.pl (Kacper Kornet) Date: Mon, 13 Sep 2010 16:31:45 +0200 Subject: Ktore wxWidgets Message-ID: <20100913143145.GA21155@gatekeeper.camk.edu.pl> Kt?ra z bibliotek dostarczaj?cych wxWidgets jest zalecana do linkowania z dystrybucyjnym pakietem? Z tego co widz? mam do wyboru: wxGTK2, wxGTK2-unicode, wxX11 i wxX11-unicode. -- Kacper From qboosh at pld-linux.org Wed Sep 15 09:02:50 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 15 Sep 2010 09:02:50 +0200 Subject: packages: ffmpeg/ffmpeg.spec - link with faad at compile time; rel 4 In-Reply-To: <4C8A8AFC.4090003@pld-linux.org> References:

<20100910175908.GF24059@stranger.qboosh.pl> <4C8A8AFC.4090003@pld-linux.org> Message-ID: <20100915070249.GE5518@stranger.qboosh.pl> On Fri, Sep 10, 2010 at 10:46:04PM +0300, Elan Ruusam?e wrote: > On 10/09/10 20:59, Jakub Bogusz wrote: > > On Fri, Sep 10, 2010 at 08:59:51AM +0200, glen wrote: > >> Author: glen Date: Fri Sep 10 06:59:51 2010 GMT > >> Module: packages Tag: HEAD > >> ---- Log message: > >> - link with faad at compile time; rel 4 > > > > Why? > > > > Linking all with everything is not desired... > > lacking capatability is not desired either, it links with everything > else, why should faad be exception? Every possibility to reduce "hard" dependencies of optional features is good. There is no general plugins support in ffmpeg/mplayer (comparing to most of generic decoders/players), but at least faad can be made dynamic - so let's do it. > and there is no suggests present > either to know that some features can be extended with installing extra > libs. So just add Suggests. E.g. in gstreamer every plugin with external dependency is packaged separately, not forcing codec library dependency for main package. -- Jakub Bogusz http://qboosh.pl/ From sparky at pld-linux.org Fri Sep 17 23:43:15 2010 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Fri, 17 Sep 2010 23:43:15 +0200 Subject: packages: libx264/libx264.spec, libx264/altivec-no-vand.patch (NEW) - ac gc... In-Reply-To: References:

Message-ID: <20100917214315.GA1114@pld-linux.org> On Thu, Aug 26, 2010 at 12:59:26PM +0200, glen wrote: > Author: glen Date: Thu Aug 26 10:59:26 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - ac gcc 3.3.6 on ppc has no "vand" instructions, drop altivec detect; rel 3 This is wrong. Compilation error goes straight from assembler, gcc doesn't even know there is some altivec instruction in there. To enable altivec instructions in gcc and assembler use -maltivec cflag. NOTE: never use -mabi=altivec because such code won't work on cpus without Altivec extension. -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ......... LANG...Pl,Ca,Es,En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW...ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : WWW2..............rsget.pl (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail..sparky at pld-linux.org From qboosh at pld-linux.org Sat Sep 18 10:26:35 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 18 Sep 2010 10:26:35 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100911103723.GC5518@stranger.qboosh.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> <20100911103723.GC5518@stranger.qboosh.pl> Message-ID: <20100918082635.GF5518@stranger.qboosh.pl> So finally - what is the future policy? Randomly removing some files or moving to -static makes only mess, which is worse than current situation. We have some options: - preserve status quo, keeping *.la in -devel - modify libtool not to use *.la for dynamic linking and keep them in -devel - remove *.la only for libraries with proper pkgconfig support, keep the rest in -devel - remove all library *.la and -static packages -- Jakub Bogusz http://qboosh.pl/ From blues at pld-linux.org Sat Sep 18 11:57:01 2010 From: blues at pld-linux.org (Pawel Golaszewski) Date: Sat, 18 Sep 2010 11:57:01 +0200 (CEST) Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100918082635.GF5518@stranger.qboosh.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> <20100911103723.GC5518@stranger.qboosh.pl> <20100918082635.GF5518@stranger.qboosh.pl> Message-ID: On Sat, 18 Sep 2010, Jakub Bogusz wrote: > - modify libtool not to use *.la for dynamic linking and keep them in > -devel Lets suppose we will have modification like that. Will mainstream accept it? If "yes" - lets do it. -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From patrys at pld-linux.org Sat Sep 18 12:00:50 2010 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Sat, 18 Sep 2010 12:00:50 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100918082635.GF5518@stranger.qboosh.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> <20100911103723.GC5518@stranger.qboosh.pl> <20100918082635.GF5518@stranger.qboosh.pl> Message-ID: On Sat, Sep 18, 2010 at 10:26 AM, Jakub Bogusz wrote: > So finally - what is the future policy? > Randomly removing some files or moving to -static makes only mess, > which is worse than current situation. Did anyone check what is the policy for other distros? > We have some options: > > - preserve status quo, keeping *.la in -devel It results in trash being passed to linker and sometimes hides missing deps. > - modify libtool not to use *.la for dynamic linking and keep them in > ?-devel I'd like to have this but it would be a patch for us to maintain. > - remove *.la only for libraries with proper pkgconfig support, keep the > ?rest in -devel That's just a partial workaround. > - remove all library *.la and -static packages I'd like to drop -static from all the desktop packages. We only build it for the sake of having it. -- Patryk Zawadzki From qboosh at pld-linux.org Sat Sep 18 12:21:41 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 18 Sep 2010 12:21:41 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> <20100911103723.GC5518@stranger.qboosh.pl> <20100918082635.GF5518@stranger.qboosh.pl> Message-ID: <20100918102141.GG5518@stranger.qboosh.pl> On Sat, Sep 18, 2010 at 11:57:01AM +0200, Pawel Golaszewski wrote: > On Sat, 18 Sep 2010, Jakub Bogusz wrote: > > - modify libtool not to use *.la for dynamic linking and keep them in > > -devel > > Lets suppose we will have modification like that. > > Will mainstream accept it? > If "yes" - lets do it. I don't think so, it's not portable. libtool (almost) doesn't support dynamic linking without *.la on e.g. MinGW32. Also, after rethinking - it doesn't change anything from current state wrt. the need of package rebuilding (to keep .la usable for static linking). So I think we can forget about this option. -- Jakub Bogusz http://qboosh.pl/ From baggins at sith.mimuw.edu.pl Sat Sep 18 12:26:39 2010 From: baggins at sith.mimuw.edu.pl (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sat, 18 Sep 2010 12:26:39 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> <20100911103723.GC5518@stranger.qboosh.pl> <20100918082635.GF5518@stranger.qboosh.pl> Message-ID: <20100918102639.GB23958@sith.mimuw.edu.pl> On Sat, 18 Sep 2010, Patryk Zawadzki wrote: > On Sat, Sep 18, 2010 at 10:26 AM, Jakub Bogusz wrote: > > > - remove all library *.la and -static packages > > I'd like to drop -static from all the desktop packages. We only build > it for the sake of having it. KISS? What about just drop *.la and leave -static? There are some programs that need static libs (ex. vim, initrd stuff), but as the number is low we can take care of theirs deps in respective specs, and we still have static libs for those people that may need it. -- Jan R?korajski | ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio From qboosh at pld-linux.org Sat Sep 18 12:32:13 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 18 Sep 2010 12:32:13 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> <20100911103723.GC5518@stranger.qboosh.pl> <20100918082635.GF5518@stranger.qboosh.pl> Message-ID: <20100918103213.GH5518@stranger.qboosh.pl> On Sat, Sep 18, 2010 at 12:00:50PM +0200, Patryk Zawadzki wrote: > On Sat, Sep 18, 2010 at 10:26 AM, Jakub Bogusz wrote: > > So finally - what is the future policy? > > Randomly removing some files or moving to -static makes only mess, > > which is worse than current situation. > > Did anyone check what is the policy for other distros? Fedora - no .la, no static. Debian - still discussing(?) Arch - "libtool slaying" but I don't know anything about static > > We have some options: > > > > - preserve status quo, keeping *.la in -devel > > It results in trash being passed to linker and sometimes hides missing deps. > > > - remove *.la only for libraries with proper pkgconfig support, keep the > > ?rest in -devel > > That's just a partial workaround. Well, pkgconfig support for dependency tracking (better than libtool's, in fact) was the most important argument for removing .la (except for dropping static linking support at all). > > - remove all library *.la and -static packages > > I'd like to drop -static from all the desktop packages. We only build > it for the sake of having it. What is the definition of "desktop package"? -- Jakub Bogusz http://qboosh.pl/ From patrys at pld-linux.org Sat Sep 18 12:40:44 2010 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Sat, 18 Sep 2010 12:40:44 +0200 Subject: packages: cairo/cairo-link.patch, cairo/cairo.spec - 1.10.0 - merged from d... In-Reply-To: <20100918103213.GH5518@stranger.qboosh.pl> References:

<20100907175525.GE24059@stranger.qboosh.pl> <20100908072348.GA31149@polanet.pl> <20100909190836.GB5518@stranger.qboosh.pl> <20100911103723.GC5518@stranger.qboosh.pl> <20100918082635.GF5518@stranger.qboosh.pl> <20100918115624.GA26932@polanet.pl> Message-ID: <20100919095628.GA25229@polanet.pl> On Sat, Sep 18, 2010 at 18:39:40 +0200, Pawel Golaszewski wrote: >> +1 - this also simplifies builds and releases storage. Do we have any >> FTP stats on *-static downloads? If noone uses them there's no >> point in wasting resources. > > Wrong. > I've used few times static libs to build some binaries and I'm using it > for years... Libs? Or binaries. > Some may download it only once to do the build (like I did). FTP stats are > not good indicator here... They are if it happens that noone ever downloaded a file. It keep popping up that some classification needs to be made. For now we could safely remove all the .la files, but ONLY IF (libtool) can do static build without them. So we are exactly where we were week ago: 1. no place for .la in -devel 2. useless -static without .la 3. no place for .la in -static And we could either: 1. 'fix' libtool to disregard .la for dynamic builds, or 2. improve libtool to link statically without .la files (IMHO impossible, that's what pkgconfig should be used), 3. BR: *-static for static builds. Well, we could also do some weird things like separate *-la subpackages required for building *-static ...but BC for *-devel (means two pass building). It's insane. Summarizing: - we want to package .la files of non-pc libs (to keep their -static usable), - we don't want .la to be used in building process (i.e. compile&link), - we do want .la to be used to create successive .la (the one to be packaged). I can't see any valid and reasonable solution without any loss here. So my final statement - assuming: - we can't 'fix' libtool, - we can't package .la into -devel (as it breaks regular builds, which are definitely more important) if we want to keep -static I'd sacrifice quality of .la files (as it's nondeterministic now TOO). So going back to the beginning of this thread (qboosh): > Too baaad... this causes that *.la of libs/modules using > libcairo-gobject would have different dependencies (-lcairo-gobject or > libcairo-gobject.la) depending on presence of cairo-static. > This is not acceptable. This is no difference to current situation (see my png12) - so it's not a bit worse. Usually there's no *-static on builders, so there would be -lsomelib: wouldn't it be sufficient to do some postprocessing like s/-l(.*)/\1.la/ > Either move this .la to -devel, or remove at all. ...and move .la to static? -- Tomasz Pala From jan.palus at gmail.com Tue Sep 21 15:04:30 2010 From: jan.palus at gmail.com (Jan Palus) Date: Tue, 21 Sep 2010 15:04:30 +0200 Subject: texlive-jadetex fmt files Message-ID: <20100921130430.GA12728@pomidor.echostar.pl> I'm not familiar with texlive.spec and fetching 1gb of texlive distribution just to test if a small commit works is not an option, so I'll ask here (uzsolt?). Our texlive-jadetex is missing fmt files (branch TEXLIVE_20080816, I don't care about HEAD as it's even bigger mess with jadetex files section commented out). I'd like to add them to generation list but the question is, where does fmtutil takes input files from? Is it source distribution or should I add BR: texlive-jadetex? From jan.palus at gmail.com Tue Sep 21 17:37:24 2010 From: jan.palus at gmail.com (Jan Palus) Date: Tue, 21 Sep 2010 17:37:24 +0200 Subject: texlive-jadetex fmt files In-Reply-To: <20100921130430.GA12728@pomidor.echostar.pl> References: <20100921130430.GA12728@pomidor.echostar.pl> Message-ID: <20100921153724.GA11484@pomidor.echostar.pl> On 21.09.2010 15:04, Jan Palus wrote: > I'm not familiar with texlive.spec and fetching 1gb of texlive > distribution just to test if a small commit works is not an option, so > I'll ask here (uzsolt?). Our texlive-jadetex is missing fmt files > (branch TEXLIVE_20080816, I don't care about HEAD as it's even bigger > mess with jadetex files section commented out). I'd like to add them to > generation list but the question is, where does fmtutil takes input > files from? Is it source distribution or should I add BR: texlive-jadetex? I was enlightened by good people on #pld and missing fmt file was added to texlive-texmf.spec. From udvzsolt at gmail.com Tue Sep 21 18:18:35 2010 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Tue, 21 Sep 2010 18:18:35 +0200 Subject: texlive-jadetex fmt files In-Reply-To: <20100921153724.GA11484@pomidor.echostar.pl> References: <20100921130430.GA12728@pomidor.echostar.pl> <20100921153724.GA11484@pomidor.echostar.pl> Message-ID: Yes, I'm working mostly on texlive*, but I have no time :( I'm using texlive-2009 and works well for me. So if you want to use "my" version: http://carme.pld-linux.org/~uzsolt/other-rpms/ Sorry for this :) Zsolt 2010/9/21 Jan Palus : > On 21.09.2010 15:04, Jan Palus wrote: >> I'm not familiar with texlive.spec and fetching 1gb of texlive >> distribution just to test if a small commit works is not an option, so >> I'll ask here (uzsolt?). Our texlive-jadetex is missing fmt files >> (branch TEXLIVE_20080816, I don't care about HEAD as it's even bigger >> mess with jadetex files section commented out). I'd like to add them to >> generation list but the question is, where does fmtutil takes input >> files from? Is it source distribution or should I add BR: texlive-jadetex? > > I was enlightened by good people on #pld and missing fmt file was added > to texlive-texmf.spec. > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > From mmazur at kernel.pl Sat Sep 25 18:21:30 2010 From: mmazur at kernel.pl (Mariusz Mazur) Date: Sat, 25 Sep 2010 18:21:30 +0200 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: References: <1281444989.5439.8.camel@pldmachine> Message-ID: <201009251821.30263.mmazur@kernel.pl> On Friday 13 of August 2010, Pawel Golaszewski wrote: > I think we should give you chance to work on your own account. > > me: +1 +1 Anyone else? :) --mmazur From caleb at pld-linux.org Sat Sep 25 20:15:23 2010 From: caleb at pld-linux.org (Caleb Maclennan) Date: Sat, 25 Sep 2010 21:15:23 +0300 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: <201009251821.30263.mmazur@kernel.pl> References: <1281444989.5439.8.camel@pldmachine> <201009251821.30263.mmazur@kernel.pl> Message-ID: On Sat, Sep 25, 2010 at 19:21, Mariusz Mazur wrote: > On Friday 13 of August 2010, Pawel Golaszewski wrote: >> I think we should give you chance to work on your own account. >> >> me: +1 > > +1 > > Anyone else? :) +1 From mmazur at kernel.pl Sun Sep 26 22:56:20 2010 From: mmazur at kernel.pl (Mariusz Mazur) Date: Sun, 26 Sep 2010 22:56:20 +0200 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: References: <1281444989.5439.8.camel@pldmachine> <201009251821.30263.mmazur@kernel.pl> Message-ID: <201009262256.21055.mmazur@kernel.pl> On Saturday 25 of September 2010, Caleb Maclennan wrote: > > On Sat, Sep 25, 2010 at 19:21, Mariusz Mazur wrote: > > On Friday 13 of August 2010, Pawel Golaszewski wrote: > >> I think we should give you chance to work on your own account. > >> > >> me: +1 > > > > +1 > > > > Anyone else? :) > > +1 Send your desired login and a password hash to cvsadmin at pld-linux.org Fill out the perl form below :) perl -e 'print "login:" . crypt("haslo", join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64, rand 64]) . "\n"' --mmazur From glen at pld-linux.org Mon Sep 27 09:17:08 2010 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 27 Sep 2010 10:17:08 +0300 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: <201009251821.30263.mmazur@kernel.pl> References: <1281444989.5439.8.camel@pldmachine> <201009251821.30263.mmazur@kernel.pl> Message-ID: <4CA044F4.5060708@pld-linux.org> On 25.09.2010 19:21, Mariusz Mazur wrote: > On Friday 13 of August 2010, Pawel Golaszewski wrote: > >> I think we should give you chance to work on your own account. >> >> me: +1 > +1 > > Anyone else? :) > > do you know, that if you say +1, you must mentor his commits, i.e correct him and explain things, not just say "yes" -- glen From gotar at polanet.pl Mon Sep 27 11:04:04 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 27 Sep 2010 11:04:04 +0200 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: <201009262256.21055.mmazur@kernel.pl> References: <1281444989.5439.8.camel@pldmachine> <201009251821.30263.mmazur@kernel.pl> <201009262256.21055.mmazur@kernel.pl> Message-ID: <20100927090404.GA8917@polanet.pl> On Sun, Sep 26, 2010 at 22:56:20 +0200, Mariusz Mazur wrote: > On Saturday 25 of September 2010, Caleb Maclennan wrote: > >> > On Sat, Sep 25, 2010 at 19:21, Mariusz Mazur wrote: >> > On Friday 13 of August 2010, Pawel Golaszewski wrote: >> >> I think we should give you chance to work on your own account. >> >> >> >> me: +1 >> > >> > +1 >> > >> > Anyone else? :) >> >> +1 > > Send your desired login and a password hash to cvsadmin at pld-linux.org Who? This voting is too stripped to know who about it is. > Fill out the perl form below :) ...and say goodbye to your $HOME ;> -- Tomasz Pala From caleb at pld-linux.org Mon Sep 27 11:12:12 2010 From: caleb at pld-linux.org (Caleb Maclennan) Date: Mon, 27 Sep 2010 12:12:12 +0300 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: <20100927090404.GA8917@polanet.pl> References: <1281444989.5439.8.camel@pldmachine> <201009251821.30263.mmazur@kernel.pl> <201009262256.21055.mmazur@kernel.pl> <20100927090404.GA8917@polanet.pl> Message-ID: On Mon, Sep 27, 2010 at 12:04, Tomasz Pala wrote: > Who? This voting is too stripped to know who about it is. If you follow the whole email thread this came up after Przemo Firszt sent in a bunch of stuff to be committed for NetworkManager. 2010/9/27 Elan Ruusam?e : > do you know, that if you say +1, you must mentor his commits, i.e > correct him and explain things, not just say "yes" And yes, Elan, I'm willing to help him out with the basic ropes. I don't know all the ins and outs but having just been through the process myself I'm willing to help pass on what I've learned. Caleb From gotar at polanet.pl Mon Sep 27 11:17:22 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 27 Sep 2010 11:17:22 +0200 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: References: <1281444989.5439.8.camel@pldmachine> <201009251821.30263.mmazur@kernel.pl> <201009262256.21055.mmazur@kernel.pl> <20100927090404.GA8917@polanet.pl> Message-ID: <20100927091722.GB8917@polanet.pl> On Mon, Sep 27, 2010 at 12:12:12 +0300, Caleb Maclennan wrote: >> Who? This voting is too stripped to know who about it is. > > If you follow the whole email thread this came up after Przemo Firszt > sent in a bunch of stuff to be committed for > NetworkManager. I didn't get this mail so I can't follow the thread. And it doesn't matter - every voting needs unambiguous subject. Not that I have anything against przemo rw, just for the lame voting. -- Tomasz Pala From arekm at maven.pl Mon Sep 27 11:23:13 2010 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 27 Sep 2010 11:23:13 +0200 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: References: <1281444989.5439.8.camel@pldmachine> <20100927090404.GA8917@polanet.pl> Message-ID: <201009271123.13639.arekm@maven.pl> On Monday 27 of September 2010, Caleb Maclennan wrote: > 2010/9/27 Elan Ruusam?e : > > do you know, that if you say +1, you must mentor his commits, i.e > > correct him and explain things, not just say "yes" AFAIK the above rule applies only to the first person proposing +1 (blues in this case). > And yes, Elan, I'm willing to help him out with the basic ropes. I > don't know all the ins and outs but having just been through the > process myself I'm willing to help pass on what I've learned. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From wolf.pld at gmail.com Mon Sep 27 12:31:36 2010 From: wolf.pld at gmail.com (Bartosz Taudul) Date: Mon, 27 Sep 2010 12:31:36 +0200 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: <201009271123.13639.arekm@maven.pl> References: <1281444989.5439.8.camel@pldmachine> <20100927090404.GA8917@polanet.pl> <201009271123.13639.arekm@maven.pl> Message-ID: On Mon, Sep 27, 2010 at 11:23 AM, Arkadiusz Miskiewicz wrote: >> 2010/9/27 Elan Ruusam?e : >> > do you know, that if you say +1, you must mentor his commits, i.e >> > correct him and explain things, not just say "yes" > AFAIK the above rule applies only to the first person proposing +1 (blues in > this case). I believe glen is correct here. wolf From blues at pld-linux.org Mon Sep 27 21:04:38 2010 From: blues at pld-linux.org (Pawel Golaszewski) Date: Mon, 27 Sep 2010 21:04:38 +0200 (CEST) Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: <4CA044F4.5060708@pld-linux.org> References: <1281444989.5439.8.camel@pldmachine> <201009251821.30263.mmazur@kernel.pl> <4CA044F4.5060708@pld-linux.org> Message-ID: On Mon, 27 Sep 2010, Elan Ruusam?e wrote: > >> I think we should give you chance to work on your own account. > >> me: +1 > > +1 > > > > Anyone else? :) > do you know, that if you say +1, you must mentor his commits, i.e > correct him and explain things, not just say "yes" Is it so hard to make search the list for patches sent by "subject" of that voting? IMO these are ok. What should I say more? I will watch for his commits, if you wish. We don't have many people as active developers, why shouldn't we look for new ones? -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From patrys at pld-linux.org Tue Sep 28 17:11:01 2010 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 28 Sep 2010 17:11:01 +0200 Subject: python 2.7 & sem_open Message-ID: Multiprocessing seems to be broken in our python packages: $ python -c 'from multiprocessing.queues import SimpleQueue' Traceback (most recent call last): File "", line 1, in File "/usr/share/python2.7/multiprocessing/queues.py", line 22, in File "/usr/share/python2.7/multiprocessing/synchronize.py", line 33, in ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770. Mentioned bug 3770? claims that sem_open support is checked for at build time. The test case is this: $ cat test.c #include #include #include #include #include int main(void) { sem_t *a = sem_open("/autoconf", O_CREAT, S_IRUSR|S_IWUSR, 0); if (a == SEM_FAILED) { perror("sem_open"); return 1; } sem_close(a); sem_unlink("/autoconf"); return 0; } $ gcc test.c -lrt $ ./a.out ; echo $? 0 It seems our builders don't have semaphore support in their kernels (or the syscalls are being filtered by some security mechanism). This results in partially broken python (and renders me unable to use celery). ? http://bugs.python.org/issue3770 -- Patryk Zawadzki From qboosh at pld-linux.org Tue Sep 28 19:58:05 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 28 Sep 2010 19:58:05 +0200 Subject: python 2.7 & sem_open In-Reply-To: References: Message-ID: <20100928175804.GL5518@stranger.qboosh.pl> On Tue, Sep 28, 2010 at 05:11:01PM +0200, Patryk Zawadzki wrote: > Multiprocessing seems to be broken in our python packages: > > $ python -c 'from multiprocessing.queues import SimpleQueue' > Traceback (most recent call last): > File "", line 1, in > File "/usr/share/python2.7/multiprocessing/queues.py", line 22, in > File "/usr/share/python2.7/multiprocessing/synchronize.py", line 33, > in > ImportError: This platform lacks a functioning sem_open > implementation, therefore, the required synchronization primitives > needed will not function, see issue 3770. > > Mentioned bug 3770? claims that sem_open support is checked for at > build time. The test case is this: IMO API check should be enough on builders (when build host is not the destination machine). > It seems our builders don't have semaphore support in their kernels > (or the syscalls are being filtered by some security mechanism). > > This results in partially broken python (and renders me unable to use celery). /dev/shm mounted? -- Jakub Bogusz http://qboosh.pl/ From patrys at pld-linux.org Tue Sep 28 20:33:27 2010 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 28 Sep 2010 20:33:27 +0200 Subject: python 2.7 & sem_open In-Reply-To: <20100928175804.GL5518@stranger.qboosh.pl> References: <20100928175804.GL5518@stranger.qboosh.pl> Message-ID: On Tue, Sep 28, 2010 at 7:58 PM, Jakub Bogusz wrote: > On Tue, Sep 28, 2010 at 05:11:01PM +0200, Patryk Zawadzki wrote: >> Multiprocessing seems to be broken in our python packages: >> >> $ python -c 'from multiprocessing.queues import SimpleQueue' >> Traceback (most recent call last): >> ? File "", line 1, in >> ? File "/usr/share/python2.7/multiprocessing/queues.py", line 22, in >> ? File "/usr/share/python2.7/multiprocessing/synchronize.py", line 33, >> in >> ImportError: This platform lacks a functioning sem_open >> implementation, therefore, the required synchronization primitives >> needed will not function, see issue 3770. >> >> Mentioned bug 3770? claims that sem_open support is checked for at >> build time. The test case is this: > IMO API check should be enough on builders (when build host is not > the destination machine). Python devs say it has to do a syscall check at build time as there is no way to modify the behavior at runtime (the whole module has to be disabled). >> It seems our builders don't have semaphore support in their kernels >> (or the syscalls are being filtered by some security mechanism). >> >> This results in partially broken python (and renders me unable to use celery). > /dev/shm mounted? Yup. -- Patryk Zawadzki From przemo at firszt.eu Tue Sep 28 21:16:37 2010 From: przemo at firszt.eu (Przemo Firszt) Date: Tue, 28 Sep 2010 20:16:37 +0100 Subject: [PATCH] NetworkManager & ModemManager In-Reply-To: References: <1281444989.5439.8.camel@pldmachine> <201009251821.30263.mmazur@kernel.pl> <4CA044F4.5060708@pld-linux.org> Message-ID: <1285701397.7661.14.camel@pldmachine> Dnia 2010-09-27, pon o godzinie 21:04 +0200, Pawel Golaszewski pisze: > On Mon, 27 Sep 2010, Elan Ruusam?e wrote: > > >> I think we should give you chance to work on your own account. > > >> me: +1 > > > +1 > > > > > > Anyone else? :) > > do you know, that if you say +1, you must mentor his commits, i.e > > correct him and explain things, not just say "yes" > > Is it so hard to make search the list for patches sent by "subject" of > that voting? IMO these are ok. What should I say more? > I will watch for his commits, if you wish. > > We don't have many people as active developers, why shouldn't we look for > new ones? Hi lads, Thanks for the votes and for offering help. I'll need it :-) -- Przemo Firszt From przemo at firszt.eu Tue Sep 28 22:09:29 2010 From: przemo at firszt.eu (Przemo Firszt) Date: Tue, 28 Sep 2010 21:09:29 +0100 Subject: CVS -> something else. Message-ID: <1285704569.7661.67.camel@pldmachine> For those not following pld-linux-pl: there was a discussion about migrating CVS repo to something else. Discussion seems to be (almost) dead by now. One of the options was to convert whole SPECS to one repo, but someone said that it's too big to be usable. Another option was to make one repo per package - I think it's an overkill. What about making a few repos (lets say one per the first letter of package name)? 20 odd repos could be fast enough and in the same time easy to handle. -- Regards, Przemo Firszt