From aredridel at nbtsc.org Sun Dec 4 05:11:03 2011 From: aredridel at nbtsc.org (Aria Stewart) Date: Sat, 3 Dec 2011 21:11:03 -0700 Subject: Switch to systemd? In-Reply-To: <20111129120735.GC2121@jajo.eggsoft> References: <20111129120735.GC2121@jajo.eggsoft> Message-ID: <20111204041103.GA15742@mail.theinternetco.net> On Tue, Nov 29, 2011 at 01:07:35PM +0100, Jacek Konieczny wrote: > On the Polish mailing list there is discussion about systemd support. > SysVinit is evil and needs to be replaced ? its hard to argue about > that. Though, I have already done some work to replace SysVinit with > Upstart. > > The question is, should we now start maintaining the third init > subsystem? Or should we drop anything done for Upstart? Or even drop > legacy SysVinit support? I, for one, welcome our new systemd overlords. > What about current SysVinit scripts. Should we keep them and maintain > them or start switching everything (including whole rc-scripts) to > systemd? This can break backward compatibility a lot, but we could gain > much more consistent (which also means: more reliable and faster) system > in the end. +1 for this! From gotar at polanet.pl Mon Dec 5 03:49:17 2011 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 5 Dec 2011 03:49:17 +0100 Subject: Switch to systemd? In-Reply-To: <20111129120735.GC2121@jajo.eggsoft> References: <20111129120735.GC2121@jajo.eggsoft> Message-ID: <20111205024917.GA19785@polanet.pl> On Tue, Nov 29, 2011 at 13:07:35 +0100, Jacek Konieczny wrote: > The question is, should we now start maintaining the third init > subsystem? Or should we drop anything done for Upstart? Or even drop > legacy SysVinit support? Legacy SysV can't be dropped, as upstart won't be finished to the level when it could replace SysV, and systemd requires pretty new kernel. > Anybody relies on Upstart or can we assume it was a dead end road and we > can give it up? Do we need any transition facilities (I will take care > of my systems myself)? As upstart was never oficially supported, I don't see a need to make transition scripts or any tools. But I don't see a reason to drop it as well! We can't tell today what is going to be the final init. History of open source is full of dead ends and come backs (recently we dropped util-linux-NG, pwdutils obsoleting shadow is dead, there was libungif vs giflib issue, multiple Motif implementations, Image*Magick etc. - oh, and rpm of course). > What about current SysVinit scripts. Should we keep them and maintain > them or start switching everything (including whole rc-scripts) to > systemd? This can break backward compatibility a lot, but we could gain > much more consistent (which also means: more reliable and faster) system > in the end. IMHO we can't break SysV (and LSB). If rc-scripts can't be expanded (they should, as most of functions or rc.sysinit is actually pointless for systemd), it should be forked. > Anyway, LSB scripts in /etc/init.d should still be supported in some way > and probably wrapper scripts for services maintained by systemd should > be placed there too ??? some things still rely on that and this will allow LSB and SysV are both supported by systemd as long as COMPAT_MODE is compiled in. -- Tomasz Pala From glen at delfi.ee Fri Dec 9 17:30:19 2011 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Fri, 09 Dec 2011 18:30:19 +0200 Subject: packages: argyllcms/argyllcms.spec - changed my mind, package hargyllcms fo... In-Reply-To: References:

Message-ID: <4EE2379B.8080103@delfi.ee> On 08.12.2011 22:09, qboosh wrote: > -# we're not allowed to refer to acquisition devices as scanners > -./legal.sh you sure we're not bound to those restrictions? -- glen From qboosh at pld-linux.org Fri Dec 9 18:45:43 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 9 Dec 2011 18:45:43 +0100 Subject: packages: argyllcms/argyllcms.spec - changed my mind, package hargyllcms fo... In-Reply-To: <4EE2379B.8080103@delfi.ee> References:

<4EE2379B.8080103@delfi.ee> Message-ID: <20111209174543.GA10415@mail> On Fri, Dec 09, 2011 at 06:30:19PM +0200, Elan Ruusam?e wrote: > On 08.12.2011 22:09, qboosh wrote: > >-# we're not allowed to refer to acquisition devices as scanners > >-./legal.sh > you sure we're not bound to those restrictions? Their idea looks USA-centric. -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Fri Dec 23 07:28:36 2011 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Fri, 23 Dec 2011 07:28:36 +0100 Subject: INFO: PAE default on in our i686 kernel Message-ID: <201112230728.36559.arekm@maven.pl> Helo, just a note. "Upcoming PLD kernels (>= 3.0.13-2) will have PAE enabled on 32bit i686 kernels by default. Such kernel will run only on processors that support PAE (grep pae /proc/cpuinfo to verify). If your CPU doesn't support PAE then you have to switch to PLD i486 kernel." There is such kernel (3.0.14-1) now in th-ready. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From gotar at polanet.pl Fri Dec 23 12:16:21 2011 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 23 Dec 2011 12:16:21 +0100 Subject: INFO: PAE default on in our i686 kernel In-Reply-To: <201112230728.36559.arekm@maven.pl> References: <201112230728.36559.arekm@maven.pl> Message-ID: <20111223111621.GA21587@polanet.pl> On Fri, Dec 23, 2011 at 07:28:36 +0100, Arkadiusz Mi?kiewicz wrote: > "Upcoming PLD kernels (>= 3.0.13-2) will have PAE enabled on 32bit i686 We shall ship no-highmem-crap enabled kernel (possibly with 2G/2G memory split) for every 32-bit arch. The only possitive effect of PAE is NX bit, while HIGHMEM64G should be forbidden and punished. -- Tomasz Pala From qboosh at pld-linux.org Fri Dec 23 14:00:54 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 23 Dec 2011 14:00:54 +0100 Subject: packages: bird/bird.spec - use macro In-Reply-To: References:

Message-ID: <20111223130054.GA27042@mail> On Fri, Dec 23, 2011 at 12:36:27PM +0100, glen wrote: > --- packages/bird/bird.spec:1.65 Wed Dec 21 22:01:33 2011 > +++ packages/bird/bird.spec Fri Dec 23 12:36:22 2011 > @@ -191,7 +191,7 @@ > /sbin/chkconfig --del %{name}-ipv6 > fi > > -%triggerpostun ipv4 -- bird-ipv4 < 1.3.4-3 > +%triggerpostun ipv4 -- %{name}-ipv4 < 1.3.4-3 I don't think %{name} macro should be used here. It's the name of _old package_, which new versions of spec will never generate. Consider upgrade from bird-ipv4-1.3.3 to birdng-ipv4-9.6.6 after spec name change. Then trigger should still cover bird-ipv4 < 1.3.4-3, not birdng-ipv4 < 1.3.4-3. This is similar case to Obsoletes for old packages. -- Jakub Bogusz http://qboosh.pl/ From glen at delfi.ee Fri Dec 23 14:26:52 2011 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Fri, 23 Dec 2011 15:26:52 +0200 Subject: packages: bird/bird.spec - use macro In-Reply-To: <20111223130054.GA27042@mail> References:

<20111223130054.GA27042@mail> Message-ID: <4EF4819C.5050904@delfi.ee> On 23.12.2011 15:00, Jakub Bogusz wrote: > On Fri, Dec 23, 2011 at 12:36:27PM +0100, glen wrote: >> --- packages/bird/bird.spec:1.65 Wed Dec 21 22:01:33 2011 >> +++ packages/bird/bird.spec Fri Dec 23 12:36:22 2011 >> @@ -191,7 +191,7 @@ >> /sbin/chkconfig --del %{name}-ipv6 >> fi >> >> -%triggerpostun ipv4 -- bird-ipv4< 1.3.4-3 >> +%triggerpostun ipv4 -- %{name}-ipv4< 1.3.4-3 > I don't think %{name} macro should be used here. > It's the name of _old package_, which new versions of spec will never > generate. > Consider upgrade from bird-ipv4-1.3.3 to birdng-ipv4-9.6.6 after spec > name change. Then trigger should still cover bird-ipv4< 1.3.4-3, > not birdng-ipv4< 1.3.4-3. > > This is similar case to Obsoletes for old packages. yet then people copy same trigger line from one spec to another -- makes it simplier there -- glen From gotar at polanet.pl Fri Dec 23 15:42:22 2011 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 23 Dec 2011 15:42:22 +0100 Subject: packages: bird/bird.spec - use macro In-Reply-To: <4EF4819C.5050904@delfi.ee> References:

<20111223130054.GA27042@mail> <4EF4819C.5050904@delfi.ee> Message-ID: <20111223144222.GA13614@polanet.pl> On Fri, Dec 23, 2011 at 15:26:52 +0200, Elan Ruusam?e wrote: >>> -%triggerpostun ipv4 -- bird-ipv4< 1.3.4-3 >>> +%triggerpostun ipv4 -- %{name}-ipv4< 1.3.4-3 >> I don't think %{name} macro should be used here. >> It's the name of _old package_, which new versions of spec will never [...] > yet then people copy same trigger line from one spec to another -- makes > it simplier there Well, it's their problem. Not all specs have %configure; %{__make} too. -- Tomasz Pala From lisu87 at gmail.com Wed Dec 28 09:32:14 2011 From: lisu87 at gmail.com (Michal Lisowski) Date: Wed, 28 Dec 2011 09:32:14 +0100 Subject: packages: adapter.awk - use java(jaxp_parser_impl) virtual dep instead of d... In-Reply-To: References:

Message-ID: <4EFAD40E.30008@gmail.com> On 09.02.2011 18:32, glen wrote: > Author: glen Date: Wed Feb 9 17:32:18 2011 GMT > Module: packages Tag: HEAD > ---- Log message: > - use java(jaxp_parser_impl) virtual dep instead of direct java-xerces > so java-sun can satisfy too It seems that it does not work as it should. Example: $ ./builder -bb ant-contrib ... + umask 022 + cd /home/users/lisu/pldrpm/BUILD + cd ant-contrib + find-jar junit + junit_jar=/usr/share/java/junit.jar + find-jar xercesImpl /usr/bin/find-jar: error: Could not find xercesImpl Java extension for this JVM Could not find the requested jar or jar directory. Please check the correct JAVA_HOME is set. + xerces_jar= ... $ rpm -qa | grep java-sun rpm -qa | grep java-sun $ rpm -qa | grep java-xerces (empty) From lisu87 at gmail.com Wed Dec 28 10:15:46 2011 From: lisu87 at gmail.com (Michal Lisowski) Date: Wed, 28 Dec 2011 10:15:46 +0100 Subject: packages: adapter.awk - use java(jaxp_parser_impl) virtual dep instead of d... In-Reply-To: <4EFAD40E.30008@gmail.com> References:

<4EFAD40E.30008@gmail.com> Message-ID: <4EFADE42.6000007@gmail.com> On 28.12.2011 09:32, Michal Lisowski wrote: > On 09.02.2011 18:32, glen wrote: >> Author: glen Date: Wed Feb 9 17:32:18 2011 GMT >> Module: packages Tag: HEAD >> ---- Log message: >> - use java(jaxp_parser_impl) virtual dep instead of direct >> java-xerces so java-sun can satisfy too > > It seems that it does not work as it should. Example: > > $ ./builder -bb ant-contrib > ... > + umask 022 > + cd /home/users/lisu/pldrpm/BUILD > + cd ant-contrib > + find-jar junit > + junit_jar=/usr/share/java/junit.jar > + find-jar xercesImpl > /usr/bin/find-jar: error: Could not find xercesImpl Java extension for > this JVM > Could not find the requested jar or jar directory. > Please check the correct JAVA_HOME is set. > + xerces_jar= > ... > > $ rpm -qa | grep java-sun > rpm -qa | grep java-sun I was concerned about the java-sun-1.6.0.30-1.i686 > > $ rpm -qa | grep java-xerces > (empty) >