From glen at pld-linux.org Sat May 2 11:25:14 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Sat, 2 May 2009 12:25:14 +0300 Subject: INFO: cvs downtime In-Reply-To: <20090430180714.GA8656@polanet.pl> References: <200904281641.n3SGfceC023150@green.mif.pg.gda.pl> <20090429172845.GA6765@polanet.pl> <20090430180714.GA8656@polanet.pl> Message-ID: <200905021225.15079.glen@pld-linux.org> On Thursday 30 April 2009 21:07, Tomasz Pala wrote: > On Wed, Apr 29, 2009 at 19:28:45 +0200, Tomasz Pala wrote: > > On Wed, Apr 29, 2009 at 16:13:06 +0300, Elan Ruusam?e wrote: > >>> Thnx (however this fetches all package contents, any way to get spec > >>> alone?) > >> > >> ./builder -g -ns icewm? > > > > Works as expected, thanks. > > Ermmm, no, it doesn't now... what might have changed? > > [gotar at fs ~/rpm/packages]$ ./builder -g -ns icewm > U icewm/icewm.spec > # $Revision: 1.207 $, $Date: 2008/09/18 15:51:29 $ > U icewm-broken-xrandr.patch > U icewm-helpbrowser.patch > U icewm-tray_hotfixes.patch > > I don't want any sources to be fetched. those are "patches" not "sources" indeed --fetch-only-spec option would be nice -- glen From n3npq at mac.com Sat May 2 17:03:06 2009 From: n3npq at mac.com (Jeff Johnson) Date: Sat, 02 May 2009 11:03:06 -0400 Subject: INFO: cvs downtime In-Reply-To: <200905021225.15079.glen@pld-linux.org> References: <200904281641.n3SGfceC023150@green.mif.pg.gda.pl> <20090429172845.GA6765@polanet.pl> <20090430180714.GA8656@polanet.pl> <200905021225.15079.glen@pld-linux.org> Message-ID: <7070DAEB-0FED-4056-A47D-2BE2ED667099@mac.com> On May 2, 2009, at 5:25 AM, Elan Ruusam?e wrote: >> >> I don't want any sources to be fetched. > > those are "patches" not "sources" > > indeed --fetch-only-spec option would be nice > Likely achievable with L and R macro overrides, and a popt alias to hide the --define. (3+ years since "fetch" being implemented dims my memory) 73 de Jeff From glen at pld-linux.org Sun May 3 12:26:06 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Sun, 3 May 2009 13:26:06 +0300 Subject: topdir macro Message-ID: <200905031326.06928.glen@pld-linux.org> why not have such default macros: %_topdir %{expand:%%global _topdir %(d=$([ -d ../../packages ] && (cd ../.. && pwd)); d=${d:-$([ -d ../packages ] && (cd ..; pwd))}; echo ${d:-$HOME/rpm})}%_topdir %_specdir %{_topdir}/packages/%{name} %_sourcedir %{_specdir} the %{name} seems to work too: $ /usr/bin/rpmbuild -bp jalbum.spec Executing(%prep): env -i PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/home/users/glen/bin:/usr/games:/home/users/glen/okas HOME=/home/users/glen TMP=/home/users/glen/tmp TMPDIR=/home/users/glen/tmp /bin/sh -e /home/users/glen/tmp/rpm-tmp.82586 + umask 022 + cd /home/users/glen/rpm/BUILD.i686-linux actually i'd see topdir = packages/ dir, i.e default ~/rpm/packages -- glen From arekm at maven.pl Sun May 3 12:31:15 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sun, 3 May 2009 12:31:15 +0200 Subject: topdir macro In-Reply-To: <200905031326.06928.glen@pld-linux.org> References: <200905031326.06928.glen@pld-linux.org> Message-ID: <200905031231.15573.arekm@maven.pl> On Sunday 03 of May 2009, Elan Ruusam?e wrote: > why not have such default macros: > > %_topdir %{expand:%%global _topdir %(d=$([ -d ../../packages ] && > (cd ../.. && pwd)); d=${d:-$([ -d ../packages ] && (cd ..; pwd))}; echo > ${d:-$HOME/rpm})}%_topdir %_specdir %{_topdir}/packages/%{name} > %_sourcedir %{_specdir} It's nice bit it will break in a case when you use some .src.rpm and install it. It should be installed in standard place - rpm/{SOURCES,SPECS} not in our packages. I actually did that _years_ ago, so it's not big deal for me but worth considering. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From baggins at sith.mimuw.edu.pl Sun May 3 13:02:43 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Sun, 3 May 2009 13:02:43 +0200 Subject: topdir macro In-Reply-To: <200905031326.06928.glen@pld-linux.org> References: <200905031326.06928.glen@pld-linux.org> Message-ID: <20090503110243.GA16369@sith.mimuw.edu.pl> On Sun, 03 May 2009, Elan Ruusam?e wrote: > why not have such default macros: > > %_topdir %{expand:%%global _topdir %(d=$([ -d ../../packages ] && (cd ../.. && pwd)); d=${d:-$([ -d ../packages ] && (cd ..; pwd))}; echo ${d:-$HOME/rpm})}%_topdir > %_specdir %{_topdir}/packages/%{name} > %_sourcedir %{_specdir} > > the %{name} seems to work too: It won't work in case of _alt_kernel and all other packages that have %{name} inconsistent with package name. -- Jan Rekorajski | ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio From n3npq at mac.com Sun May 3 17:19:19 2009 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 03 May 2009 11:19:19 -0400 Subject: topdir macro In-Reply-To: <200905031326.06928.glen@pld-linux.org> References: <200905031326.06928.glen@pld-linux.org> Message-ID: <836DB1F2-8CB1-464F-97F3-A415F3902DEB@mac.com> On May 3, 2009, at 6:26 AM, Elan Ruusam?e wrote: > why not have such default macros: > > %_topdir %{expand:%%global _topdir %(d=$([ -d ../../ > packages ] && (cd ../.. && pwd)); d=${d:-$([ -d ../packages ] && > (cd ..; pwd))}; echo ${d:-$HOME/rpm})}%_topdir > %_specdir %{_topdir}/packages/%{name} > %_sourcedir %{_specdir} > > the %{name} seems to work too: > > $ /usr/bin/rpmbuild -bp jalbum.spec > Executing(%prep): env -i PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/ > X11R6/bin:/usr/local/bin:/home/users/glen/bin:/usr/games:/home/users/ > glen/okas HOME=/home/users/glen > TMP=/home/users/glen/tmp TMPDIR=/home/users/glen/tmp /bin/sh -e / > home/users/glen/tmp/rpm-tmp.82586 > + umask 022 > + cd /home/users/glen/rpm/BUILD.i686-linux > > actually i'd see topdir = packages/ dir, i.e default ~/rpm/packages > The issue is gonna be side effects, like lazy mkdir's, when CWD is incorrect for some reason. Symlinks to directories can/will also break "../" lookups. If you want rpm to handle a remote build tree, or with a VPATH search, independent of CWD, then it should likely be done by fundamentally changing the 10 or so expansions where build paths are instantiated, not with clever and fragile hacks to %_topdir and CWD. It wouldn't be hard to add a VPATH hierarchy creating build paths to rpm. 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 gotar at polanet.pl Sun May 3 20:48:00 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 3 May 2009 20:48:00 +0200 Subject: flat SPECS available! In-Reply-To: <200904291255.40657.mmazur@kernel.pl> References: <200904271815.49920.arekm@maven.pl> <200904291255.40657.mmazur@kernel.pl> Message-ID: <20090503184800.GA14787@polanet.pl> On Wed, Apr 29, 2009 at 12:55:40 +0200, Mariusz Mazur wrote: > I just did a server-side read-only SPECS that's full of symlinks to > the ../packages spec files. I've also added a small monitoring script that > will rename/delete/ It would be nice if there were Attic subdirectory for deleted symlinks. Oh, and I've just realized I've sometimes used flat SOURCES to find some files matching pattern (like every logrotate) - any chances for this too? BTW how should I now add 'packages'? $ cvs add monit-rc-quagga ? monit-rc-quagga/.cvsignore ? monit-rc-quagga/monit-rc-quagga.spec ? monit-rc-quagga/quagga-bgpd.monitrc stat: invalid option -- '\' Usage: cvs status [-vlR] [files...] -v Verbose format; includes tag information for the file -l Process this directory only (not recursive). -R Process directories recursively. -q Display a quick summary of each file (send more increased terseness). -x cvsnt 2.x compatible output (default). -X cvs 1.x compatible output. (Specify the --help global option for a list of other help options) diff: invalid option -- '\' Usage: cvs diff [-lNR] [rcsdiff-options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files...] -l Local directory only, not recursive -R Process directories recursively. -D d1 Diff revision for date against working file. -D d2 Diff rev1/date1 against date2. -N include diffs for added and removed files. -r rev1 Diff revision for rev1 against working file. -r rev2 Diff rev1/date1 against rev2. --ifdef=arg Output diffs in ifdef format. (consult the documentation for your diff program for rcsdiff-options. The most popular is -c for context diffs but there are many more). (Specify the --help global option for a list of other help options) cvs status: nothing known about New\ cvs diff: I know nothing about New\ cvs status: nothing known about directory cvs diff: I know nothing about directory Directory /cvsroot/packages/monit-rc-quagga added to the repository -- Tomasz Pala From mmazur at kernel.pl Mon May 4 09:11:44 2009 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 4 May 2009 09:11:44 +0200 Subject: flat SPECS available! In-Reply-To: <20090503184800.GA14787@polanet.pl> References: <200904271815.49920.arekm@maven.pl> <200904291255.40657.mmazur@kernel.pl> <20090503184800.GA14787@polanet.pl> Message-ID: <200905040911.45190.mmazur@kernel.pl> Dnia niedziela, 3 maja 2009, Tomasz Pala napisa?: > It would be nice if there were Attic subdirectory for deleted symlinks. What for? It's not like they would be pointing to anything. > Oh, and I've just realized I've sometimes used flat SOURCES to find some > files matching pattern (like every logrotate) - any chances for this too? Nope. There are a lot of files with duplicate filenames. Plus SOURCES won't be doable with a VCS switch. > BTW how should I now add 'packages'? > > $ cvs add monit-rc-quagga > ? monit-rc-quagga/.cvsignore > ? monit-rc-quagga/monit-rc-quagga.spec > ? monit-rc-quagga/quagga-bgpd.monitrc > stat: invalid option -- '\' Yeah, there's a bug there, but adding dirs works. --mmazur From gotar at polanet.pl Mon May 4 11:42:44 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 4 May 2009 11:42:44 +0200 Subject: flat SPECS available! In-Reply-To: <200905040911.45190.mmazur@kernel.pl> References: <200904271815.49920.arekm@maven.pl> <200904291255.40657.mmazur@kernel.pl> <20090503184800.GA14787@polanet.pl> <200905040911.45190.mmazur@kernel.pl> Message-ID: <20090504094244.GA30398@polanet.pl> On Mon, May 04, 2009 at 09:11:44 +0200, Mariusz Mazur wrote: >> It would be nice if there were Attic subdirectory for deleted symlinks. > > What for? It's not like they would be pointing to anything. They could point to packages//Attic/. >> Oh, and I've just realized I've sometimes used flat SOURCES to find some >> files matching pattern (like every logrotate) - any chances for this too? > > Nope. There are a lot of files with duplicate filenames. Plus SOURCES won't be Actually duplicated names are not problem - it would be enough for me to have one simple file with 'ls -R packages' output, so that anyone could grep it for somethig. It doesn't have to be up to date, such index may be generated from cron once per day. -- Tomasz Pala From glen at pld-linux.org Mon May 4 11:48:11 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Mon, 4 May 2009 12:48:11 +0300 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... Message-ID: <200905041248.11625.glen@pld-linux.org> this config change hit the builders plz test and verify that you configuration does not depend on the broken configuration (foo.php.blah expected to be parsed by php engine) note: this affects only apache webserver. -- glen -------------- next part -------------- An embedded message was scrubbed... From: glen Subject: packages: php/php-mod_php.conf - match only *.php for added security by avo... Date: Mon, 04 May 2009 11:26:04 +0200 Size: 5964 URL: From gotar at polanet.pl Mon May 4 12:56:36 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 4 May 2009 12:56:36 +0200 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <200905041248.11625.glen@pld-linux.org> References: <200905041248.11625.glen@pld-linux.org> Message-ID: <20090504105636.GA26573@polanet.pl> On Mon, May 04, 2009 at 12:48:11 +0300, Elan Ruusam?e wrote: > this config change hit the builders > > plz test and verify that you configuration does not depend on the broken > configuration (foo.php.blah expected to be parsed by php engine) So now you've exposed *.php.rpmsave contents (with plain passwords possible) one might have after some webapp upgrade, nice security. Please revert this and do like the rest of the world does (unless you follow them now?). > ---- Log message: > - match only *.php for added security by avoiding multiple extensions match > http://isc.sans.org/diary.html?storyid=6139 -- Tomasz Pala From patrys at pld-linux.org Mon May 4 13:01:10 2009 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Mon, 4 May 2009 13:01:10 +0200 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <20090504105636.GA26573@polanet.pl> References: <200905041248.11625.glen@pld-linux.org> <20090504105636.GA26573@polanet.pl> Message-ID: <89b6ba3a0905040401y1f6ad19cwd659effa3d1fec77@mail.gmail.com> 2009/5/4 Tomasz Pala : > On Mon, May 04, 2009 at 12:48:11 +0300, Elan Ruusam?e wrote: > >> this config change hit the builders >> >> plz test and verify that you configuration does not depend on the broken >> configuration (foo.php.blah expected to be parsed by php engine) > So now you've exposed *.php.rpmsave contents (with plain passwords > possible) one might have after some webapp upgrade, nice security. Do we keep %config files in publicly accessible dirs? If we do, we should be shot. And then shot again. -- Patryk Zawadzki From gotar at polanet.pl Mon May 4 15:07:18 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 4 May 2009 15:07:18 +0200 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <89b6ba3a0905040401y1f6ad19cwd659effa3d1fec77@mail.gmail.com> References: <200905041248.11625.glen@pld-linux.org> <20090504105636.GA26573@polanet.pl> <89b6ba3a0905040401y1f6ad19cwd659effa3d1fec77@mail.gmail.com> Message-ID: <20090504130718.GA6888@polanet.pl> On Mon, May 04, 2009 at 13:01:10 +0200, Patryk Zawadzki wrote: > Do we keep %config files in publicly accessible dirs? If we do, we > should be shot. And then shot again. I don't know if we do now, but we might (remember that packages were kept entirely in /home/services/httpd some time ago, I doubt every single one get moved). Can you guarantee that noone has such leftovers? Moreover - situation as before is de facto standard, so there might be people having their own code which may be altered. So i see DEsecurity here[*] with no gain at all. Following this way we should take 01_mod_authz_host.conf and change: to: [*] security means filter as much as possible; in this case it's "'don't expose as much as possible" - so the change would be acceptable among with filtering access to every *.php*.* (maybe with *~ and *.rpm{save,new}). -- Tomasz Pala From patrys at pld-linux.org Mon May 4 15:43:54 2009 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Mon, 4 May 2009 15:43:54 +0200 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <20090504130718.GA6888@polanet.pl> References: <200905041248.11625.glen@pld-linux.org> <20090504105636.GA26573@polanet.pl> <89b6ba3a0905040401y1f6ad19cwd659effa3d1fec77@mail.gmail.com> <20090504130718.GA6888@polanet.pl> Message-ID: <89b6ba3a0905040643j616ca614le7b1b55661e96685@mail.gmail.com> On Mon, May 4, 2009 at 3:07 PM, Tomasz Pala wrote: > [*] security means filter as much as possible; in this case it's "'don't > expose as much as possible" - so the change would be acceptable among > with filtering access to every *.php*.* (maybe with *~ and *.rpm{save,new}). Actually here it seems to be more secure the other way around - not alowing parsing of uploaded foo.php.jpg files for example (at least some webapps only care about file extensions). To exploit .rpmsave, you need to a) know it's PLD, b) know the config copy is in the DocumentRoot (packaging bug). YMMV but most likely you won't get a chance to execute any code. To exploit .php.foo you can ask google for a list of sites using the same software (for example querying for "powered by foo") and do a mass scripted exploit. This allows people to run untrusted code on your webserver. -- Patryk Zawadzki From gotar at polanet.pl Mon May 4 20:31:13 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 4 May 2009 20:31:13 +0200 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <89b6ba3a0905040643j616ca614le7b1b55661e96685@mail.gmail.com> References: <200905041248.11625.glen@pld-linux.org> <20090504105636.GA26573@polanet.pl> <89b6ba3a0905040401y1f6ad19cwd659effa3d1fec77@mail.gmail.com> <20090504130718.GA6888@polanet.pl> <89b6ba3a0905040643j616ca614le7b1b55661e96685@mail.gmail.com> Message-ID: <20090504183112.GA15911@polanet.pl> On Mon, May 04, 2009 at 15:43:54 +0200, Patryk Zawadzki wrote: > Actually here it seems to be more secure the other way around - not > alowing parsing of uploaded foo.php.jpg files for example (at least > some webapps only care about file extensions). I know only one application having direct web access to uploaded data: coppermine-gallery (Alias /cpg/albums /var/lib/coppermine-gallery/albums) I've created index.php.jpg and the file was fetched (not parsed and executed) - that's probably due to registered mime-type. Conclusion #1: - if webapp cares about file extension, nothing bad should happen. OK, let's assume our webapp doesn't check anything: mv index.php.jp{g,} Now the Bad File indeed is executed. Let's try to fix our webapp: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/coppermine-gallery/coppermine-gallery-apache.conf?r1=1.4&r2=1.5 tadam. I think that's the way upload dirs should be protected. Maybe we should globally disable PHP for entire /tmp and /var? Is there any code that should be run from within these locations? > To exploit .rpmsave, you need to a) know it's PLD, b) know the config > copy is in the DocumentRoot (packaging bug). YMMV but most likely you > won't get a chance to execute any code. Someone gets a chance to made database passwords public (I do clean them). > To exploit .php.foo you can ask google for a list of sites using the > same software (for example querying for "powered by foo") and do a > mass scripted exploit. This allows people to run untrusted code on > your webserver. I'm aware of such threat, but I'm not sure this is the proper solution (without some filtering). -- Tomasz Pala From patrys at pld-linux.org Mon May 4 20:57:36 2009 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Mon, 4 May 2009 20:57:36 +0200 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <20090504183112.GA15911@polanet.pl> References: <200905041248.11625.glen@pld-linux.org> <20090504105636.GA26573@polanet.pl> <89b6ba3a0905040401y1f6ad19cwd659effa3d1fec77@mail.gmail.com> <20090504130718.GA6888@polanet.pl> <89b6ba3a0905040643j616ca614le7b1b55661e96685@mail.gmail.com> <20090504183112.GA15911@polanet.pl> Message-ID: <89b6ba3a0905041157p8e994a1h1fdc1419ebc18f0a@mail.gmail.com> On Mon, May 4, 2009 at 8:31 PM, Tomasz Pala wrote: > I know only one application having direct web access to uploaded data: > coppermine-gallery (Alias /cpg/albums /var/lib/coppermine-gallery/albums) > > I've created index.php.jpg and the file was fetched (not parsed and > executed) - that's probably due to registered mime-type. Conclusion #1: > - if webapp cares about file extension, nothing bad should happen. > > OK, let's assume our webapp doesn't check anything: mv index.php.jp{g,} > Now the Bad File indeed is executed. Let's try to fix our webapp: > > http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/coppermine-gallery/coppermine-gallery-apache.conf?r1=1.4&r2=1.5 > > tadam. I think that's the way upload dirs should be protected. I don't think that's a proper solution. It might be ok for php apps but putting php_* inside a Perl or Python tool is a no-no. glen suggested something like "SetHandler DoNothing" (that's what Drupal does - set handler to a non-existent action to disable all parsers). -- Patryk Zawadzki From gotar at polanet.pl Mon May 4 21:50:19 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 4 May 2009 21:50:19 +0200 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <89b6ba3a0905041157p8e994a1h1fdc1419ebc18f0a@mail.gmail.com> References: <200905041248.11625.glen@pld-linux.org> <20090504105636.GA26573@polanet.pl> <89b6ba3a0905040401y1f6ad19cwd659effa3d1fec77@mail.gmail.com> <20090504130718.GA6888@polanet.pl> <89b6ba3a0905040643j616ca614le7b1b55661e96685@mail.gmail.com> <20090504183112.GA15911@polanet.pl> <89b6ba3a0905041157p8e994a1h1fdc1419ebc18f0a@mail.gmail.com> Message-ID: <20090504195019.GA15081@polanet.pl> On Mon, May 04, 2009 at 20:57:36 +0200, Patryk Zawadzki wrote: > but putting php_* inside a Perl or Python tool is a no-no. glen I'd suggest using: RemoveType .php RemoveType .php3 [...] Options None AllowOverride None then (upload dirs of non-PHP apps, where IfModule mod_php5.c directive would be ugly). > suggested something like "SetHandler DoNothing" (that's what Drupal That would break handlers like watch-info or cband-status. -- Tomasz Pala From glen at pld-linux.org Mon May 4 22:53:36 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Mon, 4 May 2009 23:53:36 +0300 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <20090504195019.GA15081@polanet.pl> References: <200905041248.11625.glen@pld-linux.org> <89b6ba3a0905041157p8e994a1h1fdc1419ebc18f0a@mail.gmail.com> <20090504195019.GA15081@polanet.pl> Message-ID: <200905042353.36837.glen@pld-linux.org> On Monday 04 May 2009 22:50, Tomasz Pala wrote: > > suggested something like "SetHandler DoNothing" (that's what Drupal > > That would break handlers like watch-info or cband-status. reading the context, i think patrys did not mean it being global, but setup for public upload directory. -- glen From glen at pld-linux.org Mon May 4 22:55:01 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Mon, 4 May 2009 23:55:01 +0300 Subject: Fwd: packages: php/php-mod_php.conf - match only *.php for added security by avo... In-Reply-To: <20090504130718.GA6888@polanet.pl> References: <200905041248.11625.glen@pld-linux.org> <89b6ba3a0905040401y1f6ad19cwd659effa3d1fec77@mail.gmail.com> <20090504130718.GA6888@polanet.pl> Message-ID: <200905042355.02029.glen@pld-linux.org> On Monday 04 May 2009 16:07, Tomasz Pala wrote: > [*] security means filter as much as possible; in this case it's "'don't > expose as much as possible" - so the change would be acceptable among > with filtering access to every *.php*.* (maybe with *~ and > *.rpm{save,new}). so as by default block known backup files by "deny all" directive... -- glen From sparky at pld-linux.org Tue May 5 13:10:09 2009 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Tue, 5 May 2009 13:10:09 +0200 Subject: magic broken on builders !! (again ?) Message-ID: <20090505111009.GA2447@pld-linux.org> There is no use in sending anything to Th builders right now because Provides won't be generated properly. file.spec must be fixed - volunteers ? and reinstalled manually on builders ( -devel won't upgrade automatycally because of missing P: libtool() ) -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From ankry at green.mif.pg.gda.pl Tue May 5 14:55:21 2009 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Tue, 5 May 2009 14:55:21 +0200 (CEST) Subject: INFO: cvs downtime In-Reply-To: <200904291613.06904.glen@pld-linux.org> Message-ID: <200905051255.n45CtL9i000329@green.mif.pg.gda.pl> Jak w nowym repo budowac stare pakiety (takie, ktore wylecialy do Attic) ? $ ./builder -r auto-ac-opera-i18n-9_02-1 opera-i18n cvs server: cannot find module `packages/opera-i18n/opera-i18n.spec' - ignored Error: spec file not stored in CVS repo. Any hints? Buildery sobie z tym poradza? -- ======================================================================= Andrzej M. Krzysztofowicz ankry at mif.pg.gda.pl phone (48)(58) 347 19 36 Faculty of Applied Phys. & Math., Gdansk University of Technology From radek at pld-linux.org Wed May 6 12:29:49 2009 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Wed, 6 May 2009 12:29:49 +0200 Subject: gdb's debuglink support is broken Message-ID: <20090506102949.GA13857@bzium> This path is correct: $ objdump -s -j .gnu_debuglink /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so: file format elf32-i386 Contents of section .gnu_debuglink: 0000 2f757372 2f6c6962 2f646562 75672f75 /usr/lib/debug/u 0010 73722f6c 69622f70 65726c35 2f76656e sr/lib/perl5/ven 0020 646f725f 7065726c 2f352e31 302e302f dor_perl/5.10.0/ 0030 69363836 2d706c64 2d6c696e 75782d74 i686-pld-linux-t 0040 68726561 642d6d75 6c74692f 6175746f hread-multi/auto 0050 2f444244 2f50672f 50672e73 6f2e6465 /DBD/Pg/Pg.so.de 0060 62756700 96e2872f bug..../ ...but gdb doesn't use it properly; neither of these makes sense: $ echo "set args -MDBD::Pg -e 'warn42'\nr" > /tmp/foo $ strace -etrace=file gdb -batch -x /tmp/foo perl 2>&1 | grep Pg.so.debug open("/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg//usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/.debug//usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/debug//usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg//usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg//usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) According to [1], the paths should be: /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/.debug/Pg.so.debug /usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug I took a look at the 115 patches we have for gdb, but gave up. Anyone familiar with this code? [1] http://sources.redhat.com/gdb/current/onlinedocs/gdb_17.html#SEC166 -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From gotar at polanet.pl Thu May 7 11:40:42 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Thu, 7 May 2009 11:40:42 +0200 Subject: flat SPECS available! In-Reply-To: <20090504094244.GA30398@polanet.pl> References: <200904271815.49920.arekm@maven.pl> <200904291255.40657.mmazur@kernel.pl> <20090503184800.GA14787@polanet.pl> <200905040911.45190.mmazur@kernel.pl> <20090504094244.GA30398@polanet.pl> Message-ID: <20090507094042.GA32272@polanet.pl> On Mon, May 04, 2009 at 11:42:44 +0200, Tomasz Pala wrote: >>> It would be nice if there were Attic subdirectory for deleted symlinks. >> >> What for? It's not like they would be pointing to anything. > > They could point to packages//Attic/. > >>> Oh, and I've just realized I've sometimes used flat SOURCES to find some >>> files matching pattern (like every logrotate) - any chances for this too? >> >> Nope. There are a lot of files with duplicate filenames. Plus SOURCES won't be > > Actually duplicated names are not problem - it would be enough for me to > have one simple file with 'ls -R packages' output, so that anyone could > grep it for somethig. It doesn't have to be up to date, such index may > be generated from cron once per day. Anyone? BTW there's one more problem - there are http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/blabla links to patches floating around which point to nowhere now... -- Tomasz Pala From udvzsolt at gmail.com Thu May 7 17:52:39 2009 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Thu, 7 May 2009 17:52:39 +0200 Subject: texlive-xmltex vs. xmltex Message-ID: <760ece280905070852h65f924b7h3284baadfe133de1@mail.gmail.com> Hi all! A problem on build servers: poldek: warning: /root/.poldek-cache/ftp_ftp.pld.kernel.pl.dists.th.PLD.noarch.RPMS/xmltex-20020625-5.noarch.rpm: Header V3 DSA signature: NOKEY, key ID e4f1bc2d poldek: Preparing... ################################################## poldek: file /usr/bin/xmltex from install of xmltex-20020625-5.noarch conflicts with file from package texlive-xmltex-20080816-5.i686 See: http://buildlogs.pld-linux.org/index.php?dist=th&arch=i686&ok=0&name=awesome&id=3db58531-4e71-41dc-bd1d-91d3c514177a&action=text But on carme (and on my machine): poldek:/all-avail> desc -pc texlive-xmltex-20080816-5.i686 Package: texlive-xmltex-20080816-5.i686 Provides: xmltex Obsoletes: xmltex poldek:/all-avail> install texlive-xmltex-20080816-5.i686 Processing dependencies... xmltex-20020625-5.noarch obsoleted by texlive-xmltex-20080816-5.i686 There are 1 package to install, 1 to remove: I texlive-xmltex-20080816-5.i686 R xmltex-20020625-5.noarch Need to get 732.7KB of archives (732.7KB to download). After unpacking 5.7MB will be used. Zsolt From glen at pld-linux.org Fri May 8 11:22:03 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 8 May 2009 12:22:03 +0300 Subject: old links to patches In-Reply-To: <20090507094042.GA32272@polanet.pl> References: <200904271815.49920.arekm@maven.pl> <20090504094244.GA30398@polanet.pl> <20090507094042.GA32272@polanet.pl> Message-ID: <200905081222.03804.glen@pld-linux.org> On Thursday 07 May 2009 12:40:42 Tomasz Pala wrote: > BTW there's one more problem - there are > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/blabla > links to patches floating around which point to nowhere now... please give (at least) one sample, so i could write 404 handler in apache to solve this problem. -- glen From glen at pld-linux.org Fri May 8 11:25:37 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 8 May 2009 12:25:37 +0300 Subject: misc scripts in cvs In-Reply-To: <200904291408.37429.glen@pld-linux.org> References: <200904271815.49920.arekm@maven.pl> <200904291255.40657.mmazur@kernel.pl> <200904291408.37429.glen@pld-linux.org> Message-ID: <200905081225.37900.glen@pld-linux.org> On Wednesday 29 April 2009 14:08:36 Elan Ruusam?e wrote: > On Wednesday 29 April 2009 13:55:40 Mariusz Mazur wrote: > > I just did a server-side read-only SPECS that's full of symlinks to > > the ../packages spec files. > > doing cvs up revealed what other non-spec files were present, where they > are now? so, where should these go, also some misc scripts in SOURCES like: kdediff.sh, kde4diff.sh, where those should end up? /scripts? /packages? > glen at builder-ac pld/SPECS $ grep 'is no longer' /tmp/ss > cvs server: .cvsignore is no longer in the repository > cvs server: COPYING is no longer in the repository > cvs server: R-spec.sh is no longer in the repository > cvs server: adapter is no longer in the repository > cvs server: adapter.awk is no longer in the repository > cvs server: additional-md5sums is no longer in the repository > cvs server: apt-get-buildrequires is no longer in the repository > cvs server: bcond-list is no longer in the repository > cvs server: builder is no longer in the repository > cvs server: buildrpm_request is no longer in the repository > cvs server: check-cvs-sync is no longer in the repository > cvs server: check-ftp-sync is no longer in the repository > cvs server: check_fresh is no longer in the repository > cvs server: compile.sh is no longer in the repository > cvs server: fetchsrc_request is no longer in the repository > cvs server: find-spec is no longer in the repository > cvs server: ftplinks.sh is no longer in the repository > cvs server: getsrc is no longer in the repository > cvs server: getsrcurl is no longer in the repository > cvs server: hamcrest.spec is no longer in the repository > cvs server: hardcoded-pkgs is no longer in the repository > cvs server: makegen is no longer in the repository > cvs server: md5 is no longer in the repository > cvs server: mirrors is no longer in the repository > cvs server: mysql-connector-j.spec is no longer in the repository > cvs server: new-cpan.sh is no longer in the repository > cvs server: nps.spec is no longer in the repository > cvs server: old2newbconds.awk is no longer in the repository > cvs server: optflags-test is no longer in the repository > cvs server: package-opts is no longer in the repository > cvs server: patchtool.pl is no longer in the repository > cvs server: pearize.sh is no longer in the repository > cvs server: perl-autoup is no longer in the repository > cvs server: pldnotify.awk is no longer in the repository > cvs server: poldek-get-buildrequires is no longer in the repository > cvs server: relup.sh is no longer in the repository > cvs server: repackage.sh is no longer in the repository > cvs server: review.py is no longer in the repository > cvs server: rollback is no longer in the repository > cvs server: rpmdb-checkdir.sh is no longer in the repository > cvs server: rsget2.spec is no longer in the repository > cvs server: sb.sh is no longer in the repository > cvs server: sed_to_patch.pl is no longer in the repository > cvs server: spec_utf8 is no longer in the repository > cvs server: specparser.pl is no longer in the repository > cvs server: srcwrap is no longer in the repository > [template*.spec omited] > cvs server: updatelib.sh is no longer in the repository > cvs server: utf8_check.py is no longer in the repository > cvs server: verup.sh is no longer in the repository > cvs server: workcleanup.sh is no longer in the repository > cvs server: xemacs-adapter is no longer in the repository > cvs server: xemacs-adapter-template is no longer in the repository > cvs server: xemacs-adapter.awk is no longer in the repository > glen at builder-ac pld/SPECS $ -- glen From gotar at polanet.pl Fri May 8 11:28:13 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 8 May 2009 11:28:13 +0200 Subject: old links to patches In-Reply-To: <200905081222.03804.glen@pld-linux.org> References: <200904271815.49920.arekm@maven.pl> <20090504094244.GA30398@polanet.pl> <20090507094042.GA32272@polanet.pl> <200905081222.03804.glen@pld-linux.org> Message-ID: <20090508092813.GA5008@polanet.pl> On Fri, May 08, 2009 at 12:22:03 +0300, Elan Ruusam?e wrote: >> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/blabla >> links to patches floating around which point to nowhere now... > > please give (at least) one sample, so i could write 404 handler in apache to > solve this problem. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/quagga-view_commands.patch I've provided them always in this form. -- Tomasz Pala From glen at pld-linux.org Fri May 8 11:33:01 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Fri, 8 May 2009 12:33:01 +0300 Subject: topdir macro In-Reply-To: <200905031231.15573.arekm@maven.pl> References: <200905031326.06928.glen@pld-linux.org> <200905031231.15573.arekm@maven.pl> Message-ID: <200905081233.01903.glen@pld-linux.org> On Sunday 03 May 2009 13:31:15 Arkadiusz Miskiewicz wrote: > It's nice bit it will break in a case when you use some .src.rpm and > install it. It should be installed in standard place - rpm/{SOURCES,SPECS} > not in our packages. why is it so? i mean why you need it being installed in rpm/{SOURCES,SPECS}? you can't build such pkg anyway, if building requires sources/specs being in pld layout.... and otoh no path is hardcoded, the same macros are used in building as in installing src.rpm... -- glen From glen at pld-linux.org Fri May 8 11:33:46 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Fri, 8 May 2009 12:33:46 +0300 Subject: old links to patches In-Reply-To: <20090508092813.GA5008@polanet.pl> References: <200904271815.49920.arekm@maven.pl> <200905081222.03804.glen@pld-linux.org> <20090508092813.GA5008@polanet.pl> Message-ID: <200905081233.46711.glen@pld-linux.org> On Friday 08 May 2009 12:28:13 Tomasz Pala wrote: > On Fri, May 08, 2009 at 12:22:03 +0300, Elan Ruusam?e wrote: > >> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/blabla > >> links to patches floating around which point to nowhere now... > > > > please give (at least) one sample, so i could write 404 handler in apache > > to solve this problem. > > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/quagga-view_commands.patch > > I've provided them always in this form. i mean, a url to resource which contains link to _that_ link. -- glen From gotar at polanet.pl Fri May 8 12:19:04 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 8 May 2009 12:19:04 +0200 Subject: old links to patches In-Reply-To: <200905081233.46711.glen@pld-linux.org> References: <200904271815.49920.arekm@maven.pl> <200905081222.03804.glen@pld-linux.org> <20090508092813.GA5008@polanet.pl> <200905081233.46711.glen@pld-linux.org> Message-ID: <20090508101904.GA22380@polanet.pl> On Fri, May 08, 2009 at 12:33:46 +0300, Elan Ruusam?e wrote: >> > please give (at least) one sample, so i could write 404 handler in apache >> > to solve this problem. > > i mean, a url to resource which contains link to _that_ link. Like this? http://lists.quagga.net/pipermail/quagga-dev/2009-April/006507.html -- Tomasz Pala From glen at pld-linux.org Fri May 8 12:27:23 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Fri, 8 May 2009 13:27:23 +0300 Subject: old links to patches In-Reply-To: <20090508101904.GA22380@polanet.pl> References: <200904271815.49920.arekm@maven.pl> <200905081233.46711.glen@pld-linux.org> <20090508101904.GA22380@polanet.pl> Message-ID: <200905081327.23594.glen@pld-linux.org> On Friday 08 May 2009 13:19:04 Tomasz Pala wrote: > On Fri, May 08, 2009 at 12:33:46 +0300, Elan Ruusam?e wrote: > >> > please give (at least) one sample, so i could write 404 handler in > >> > apache to solve this problem. > > > > i mean, a url to resource which contains link to _that_ link. > > Like this? > > http://lists.quagga.net/pipermail/quagga-dev/2009-April/006507.html yep. for now added redirect rules: RedirectMatch permanent ^/cgi-bin/cvsweb/SOURCES/(.*)$ http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES.old/$1 RedirectMatch permanent ^/cgi-bin/cvsweb\.cgi/SOURCES/(.*)$ http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES.old/$1 is this sufficent, or we should rather redirect to new location in /packages? i mean if you gave old link, then you likely want to point it to the resource available at that time, which this SOURCES.old redirection satisfies. however this will all go void if the SOURCES.old tree is removed someday. -- glen From ankry at green.mif.pg.gda.pl Fri May 8 12:47:55 2009 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Fri, 8 May 2009 12:47:55 +0200 (CEST) Subject: misc scripts in cvs In-Reply-To: <200905081225.37900.glen@pld-linux.org> Message-ID: <200905081047.n48AltDQ002731@green.mif.pg.gda.pl> Elan =?iso-8859-1?q?Ruusam=E4e?= wrote: > > On Wednesday 29 April 2009 14:08:36 Elan Ruusam?e wrote: > > On Wednesday 29 April 2009 13:55:40 Mariusz Mazur wrote: > > > I just did a server-side read-only SPECS that's full of symlinks to > > > the ../packages spec files. > > > > doing cvs up revealed what other non-spec files were present, where they > > are now? > > so, where should these go, also some misc scripts in SOURCES like: > kdediff.sh, kde4diff.sh, where those should end up? > > /scripts? > /packages? Topdir packages in IMVHO the worst place for them. /packages/scripts or /packages/SCRIPTS ? -- ======================================================================= Andrzej M. Krzysztofowicz ankry at mif.pg.gda.pl phone (48)(58) 347 19 36 Faculty of Applied Phys. & Math., Gdansk University of Technology From sparky at pld-linux.org Fri May 8 23:54:54 2009 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Fri, 8 May 2009 23:54:54 +0200 Subject: packages: transmission/transmission.spec - gui-qt subpackage (there is a Qt... In-Reply-To: References: Message-ID: <20090508215453.GA7379@pld-linux.org> On Fri, May 08, 2009 at 11:34:22PM +0200, uzsolt wrote: > Author: uzsolt Date: Fri May 8 21:34:22 2009 GMT > Module: packages Tag: HEAD > ---- Log message: > - gui-qt subpackage (there is a Qt-based client) > - rel 2 > > +cd qt > +qmake-qt4 > +%{__sed} -i "s@^CFLAGS.*=.*@CFLAGS = %{rpmcflags} -I/usr/include/openssl $(DEFINES)@" Makefile > +%{__sed} -i "s@^CXXFLAGS.*=.*@CXXFLAGS = %{rpmcxxflags} -I/usr/include/openssl $(DEFINES)@" Makefile > +%{__make} That's not what we do. You should rather pass those values to __make. -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From glen at pld-linux.org Mon May 11 19:43:00 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Mon, 11 May 2009 20:43:00 +0300 Subject: topdir macro In-Reply-To: <200905081233.01903.glen@pld-linux.org> References: <200905031326.06928.glen@pld-linux.org> <200905031231.15573.arekm@maven.pl> <200905081233.01903.glen@pld-linux.org> Message-ID: <200905112043.00745.glen@pld-linux.org> On Friday 08 May 2009 12:33:01 Elan Ruusam?e wrote: > On Sunday 03 May 2009 13:31:15 Arkadiusz Miskiewicz wrote: > > It's nice bit it will break in a case when you use some .src.rpm and > > install it. It should be installed in standard place - > > rpm/{SOURCES,SPECS} not in our packages. > > why is it so? i mean why you need it being installed in > rpm/{SOURCES,SPECS}? you can't build such pkg anyway, if building requires > sources/specs being in pld layout.... and otoh no path is hardcoded, the > same macros are used in building as in installing src.rpm... ping? -- glen From glen at pld-linux.org Mon May 11 19:43:34 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Mon, 11 May 2009 20:43:34 +0300 Subject: old links to patches In-Reply-To: <200905081327.23594.glen@pld-linux.org> References: <200904271815.49920.arekm@maven.pl> <20090508101904.GA22380@polanet.pl> <200905081327.23594.glen@pld-linux.org> Message-ID: <200905112043.34908.glen@pld-linux.org> On Friday 08 May 2009 13:27:23 Elan Ruusam?e wrote: > On Friday 08 May 2009 13:19:04 Tomasz Pala wrote: > > On Fri, May 08, 2009 at 12:33:46 +0300, Elan Ruusam?e wrote: > > >> > please give (at least) one sample, so i could write 404 handler in > > >> > apache to solve this problem. > > > > > > i mean, a url to resource which contains link to _that_ link. > > > > Like this? > > > > http://lists.quagga.net/pipermail/quagga-dev/2009-April/006507.html > > yep. > > for now added redirect rules: > > RedirectMatch permanent ^/cgi-bin/cvsweb/SOURCES/(.*)$ > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES.old/$1 RedirectMatch > permanent ^/cgi-bin/cvsweb\.cgi/SOURCES/(.*)$ > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES.old/$1 > > is this sufficent, or we should rather redirect to new location in > /packages? > > i mean if you gave old link, then you likely want to point it to the > resource available at that time, which this SOURCES.old redirection > satisfies. however this will all go void if the SOURCES.old tree is removed > someday. ping? -- glen From glen at pld-linux.org Mon May 11 21:26:20 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Mon, 11 May 2009 22:26:20 +0300 Subject: tcl broken? In-Reply-To: <499D120A.9050501@pld-linux.org> References: <499D120A.9050501@pld-linux.org> Message-ID: <200905112226.20510.glen@pld-linux.org> On Thursday 19 February 2009 10:02:18 Adam Go??biowski wrote: > Hi, > > [adamg at carme-pld-i686 SPECS]$ echo 'puts stdout "a"' | tclsh > a > Tcl_SetObjLength called with shared object > Aborted > [adamg at carme-pld-i686 SPECS]$ > > this causes sqlite3 build failure (and probably other software). http://forums13.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1310861 appears the history.tcl or history related entry in tclIndex is the cause. thus, one of these provide the fix: 1. remove /usr/lib/tcl8.5/history.tcl 2. removing (commenting out) from /usr/lib/tcl8.5/tclIndex this line: set auto_index(history) [list source [file join $dir history.tcl]] manual for Tcl_IsShared says: Command procedures that directly modify objects such as those for lap- pend and linsert must be careful to copy a shared object before chang- ing it. They must first check whether the object is shared by calling Tcl_IsShared. If the object is shared they must copy the object by using Tcl_DuplicateObj; this returns a new duplicate of the original object that has refCount 0. If the object is not shared, the command procedure ?owns? the object and can safely modify it directly. For example, the following code appears in the command procedure that implements linsert. This procedure modifies the list object passed to it in objv[1] by inserting objc-3 new elements before index. listPtr = objv[1]; if (Tcl_IsShared(listPtr)) { listPtr = Tcl_DuplicateObj(listPtr); } result = Tcl_ListObjReplace(interp, listPtr, index, 0, (objc-3), &(objv[3])); ... from which i conclude history.tcl does something too early... -- glen From adamg at pld-linux.org Tue May 12 08:45:07 2009 From: adamg at pld-linux.org (=?ISO-8859-2?Q?Adam_Go=B3=EAbiowski?=) Date: Tue, 12 May 2009 08:45:07 +0200 Subject: old links to patches In-Reply-To: <200905112043.34908.glen@pld-linux.org> References: <200904271815.49920.arekm@maven.pl> <20090508101904.GA22380@polanet.pl> <200905081327.23594.glen@pld-linux.org> <200905112043.34908.glen@pld-linux.org> Message-ID: <4A091AF3.3070709@pld-linux.org> Elan Ruusam?e pisze: > On Friday 08 May 2009 13:27:23 Elan Ruusam?e wrote: >> On Friday 08 May 2009 13:19:04 Tomasz Pala wrote: >>> On Fri, May 08, 2009 at 12:33:46 +0300, Elan Ruusam?e wrote: >>>>>> please give (at least) one sample, so i could write 404 handler in >>>>>> apache to solve this problem. >>>> i mean, a url to resource which contains link to _that_ link. >>> Like this? >>> >>> http://lists.quagga.net/pipermail/quagga-dev/2009-April/006507.html >> yep. >> >> for now added redirect rules: >> >> RedirectMatch permanent ^/cgi-bin/cvsweb/SOURCES/(.*)$ >> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES.old/$1 RedirectMatch >> permanent ^/cgi-bin/cvsweb\.cgi/SOURCES/(.*)$ >> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES.old/$1 >> >> is this sufficent, or we should rather redirect to new location in >> /packages? >> >> i mean if you gave old link, then you likely want to point it to the >> resource available at that time, which this SOURCES.old redirection >> satisfies. however this will all go void if the SOURCES.old tree is removed >> someday. > > ping? Seems fine for me, I provided URLs like: http://cvs.pld-linux.org/SOURCES/foo.patch http://cvs.pld-linux.org/SOURCES/foo.patch?rev=HEAD as in: http://pecl.php.net/bugs/bug.php?id=9697 and the redirect works for these as well. Thanks. From adamg at pld-linux.org Tue May 12 08:57:12 2009 From: adamg at pld-linux.org (=?UTF-8?B?QWRhbSBHb8WCxJliaW93c2tp?=) Date: Tue, 12 May 2009 08:57:12 +0200 Subject: topdir macro In-Reply-To: <200905112043.00745.glen@pld-linux.org> References: <200905031326.06928.glen@pld-linux.org> <200905031231.15573.arekm@maven.pl> <200905081233.01903.glen@pld-linux.org> <200905112043.00745.glen@pld-linux.org> Message-ID: <4A091DC8.2070908@pld-linux.org> Elan Ruusam?e pisze: > On Friday 08 May 2009 12:33:01 Elan Ruusam?e wrote: >> On Sunday 03 May 2009 13:31:15 Arkadiusz Miskiewicz wrote: >>> It's nice bit it will break in a case when you use some .src.rpm >>> and install it. It should be installed in standard place - >>> rpm/{SOURCES,SPECS} not in our packages. >> why is it so? i mean why you need it being installed in >> rpm/{SOURCES,SPECS}? you can't build such pkg anyway, if building >> requires sources/specs being in pld layout.... Is there anything that requires current (packages/foo) layout ? As for now, it looks like that builder supports packages/ layout while rpmbuild the old one. It is not a perfect solution (some magic to detect the layout would be nice), but better than no support for ~/rpm/{SPECS,SOURCES}/ . [adamg at ankh-th ~]$ rpm -q rpm rpm-4.5-16.i686 [adamg at ankh-th ~]$ cd rpm/packages/dev^C [adamg at ankh-th ~]$ rm ~/rpm/{SPECS,SOURCES}/dev* [adamg at ankh-th ~]$ cd rpm/packages/dev [adamg at ankh-th dev]$ ../builder -bs dev builder: SMP make flags are set to -j4 # $Revision: 1.192 $, $Date: 2009/03/01 16:29:51 $ Available branches: RA-branch rpm3 Zapisano: /home/users/adamg/rpm/SRPMS/dev-3.4-4.src.rpm 0.18s real 0.15s user 0.00s system [adamg at ankh-th dev]$ rpm -Uhv /home/users/adamg/rpm/SRPMS/dev-3.4-4.src.rpm 1:dev ########################################### [100%] [adamg at ankh-th dev]$ cd ../../SPECS/ [adamg at ankh-th SPECS]$ rpmbuild -bp dev.spec Wykonywanie(%prep): env -i PATH=/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/home/users/adamg/bin HOME=/home/users/adamg TMP=/home/users/adamg/tmp TMPDIR=/home/users/adamg/tmp /bin/sh -e /home/users/adamg/tmp/rpm-tmp.33191 + umask 022 + cd /home/users/adamg/rpm/BUILD + cd /home/users/adamg/rpm/BUILD + rm -rf dev-3.4 + /bin/mkdir -p dev-3.4 + cd dev-3.4 + /bin/id -u + [ 1000 = 0 ] + true . + /bin/chmod -Rf -Rf a+rX,u+w,g-w,o-w . + exit 0 [adamg at ankh-th SPECS]$ From glen at pld-linux.org Tue May 12 09:18:12 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Tue, 12 May 2009 10:18:12 +0300 Subject: topdir macro In-Reply-To: <4A091DC8.2070908@pld-linux.org> References: <200905031326.06928.glen@pld-linux.org> <200905112043.00745.glen@pld-linux.org> <4A091DC8.2070908@pld-linux.org> Message-ID: <200905121018.12652.glen@pld-linux.org> On Tuesday 12 May 2009 09:57, Adam Go??biowski wrote: > As for now, it looks like that builder supports packages/ layout while > rpmbuild the old one. It is not a perfect solution (some magic to detect > the layout would be nice), but better than no support for > ~/rpm/{SPECS,SOURCES}/ . here's my (current) ~/.rpmmacros, which allows you ~/rpm/SPECS, ~/rpm/something/SPECS, ~/rpm/packages/%{name}, ~/rpm/something/%{name} layouts there could be bugs, but the description matches the goal. likely the ~/rpm/SPECS needs more changes to builder script # topdir is where builder script lives, fallback to old style if builder script was not found and # SPECS/SOURCES dirs exist (XXX: should be reverse?) %_topdir %{expand:%%global _topdir %(d=;\ d=${d:-$([ -x builder -a ! -L builder ] && pwd)};\ d=${d:-$([ -x ../builder -a ! -L ../builder ] && (cd ..; pwd))};\ d=${d:-$([ -d ../SPECS -a -d ../SOURCES ] && (cd .. && pwd))};\ echo ${d:-$HOME/rpm};\ )}%_topdir %_specdir %{_topdir}/%{name} %_sourcedir %{_specdir} # BUILD/RPMS/SRPMS are one same level by default as packages dir, if these exist # if they don't exist assume we are having custom topdir (which is not named as # "packages", i.e ~/rpm/kde/{kdelibs,BUILD/RPMS/SRPMS}) %_builddir %{expand:%%global _builddir %([ -d %{_topdir}/../BUILD ] && (cd %{_topdir}/../BUILD; pwd) || echo %{_topdir}/BUILD)}%_builddir %_rpmdir %{expand:%%global _rpmdir %([ -d %{_topdir}/../RPMS ] && (cd %{_topdir}/../RPMS; pwd) || echo %{_topdir}/RPMS)}%_rpmdir %_srcrpmdir %{expand:%%global _srcrpmdir %([ -d %{_topdir}/../SRPMS ] && (cd %{_topdir}/../SRPMS; pwd) || echo %{_topdir}/SRPMS)}%_srcrpmdir requires such changes to buider too: diff -u -r1.582 builder --- builder 8 May 2009 11:02:54 -0000 1.582 +++ builder 12 May 2009 07:14:36 -0000 @@ -659,8 +660,8 @@ if [ "$NOINIT" != "yes" ] ; then TOP_DIR=$(eval $RPM $RPMOPTS --eval '%{_topdir}') - REPO_DIR=$TOP_DIR/packages - PACKAGE_DIR=$TOP_DIR/packages/$ASSUMED_NAME + REPO_DIR=$TOP_DIR + PACKAGE_DIR=$REPO_DIR/$ASSUMED_NAME else REPO_DIR="." PACKAGE_DIR="." -- glen From glen at pld-linux.org Tue May 12 09:20:10 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Tue, 12 May 2009 10:20:10 +0300 Subject: old links to patches In-Reply-To: <4A091AF3.3070709@pld-linux.org> References: <200904271815.49920.arekm@maven.pl> <200905112043.34908.glen@pld-linux.org> <4A091AF3.3070709@pld-linux.org> Message-ID: <200905121020.10454.glen@pld-linux.org> On Tuesday 12 May 2009 09:45, Adam Go??biowski wrote: > Elan Ruusam?e pisze: > > On Friday 08 May 2009 13:27:23 Elan Ruusam?e wrote: > >> On Friday 08 May 2009 13:19:04 Tomasz Pala wrote: > >>> On Fri, May 08, 2009 at 12:33:46 +0300, Elan Ruusam?e wrote: > >>>>>> please give (at least) one sample, so i could write 404 handler in > >>>>>> apache to solve this problem. > >>>> > >>>> i mean, a url to resource which contains link to _that_ link. > >>> > >>> Like this? > >>> > >>> http://lists.quagga.net/pipermail/quagga-dev/2009-April/006507.html > >> > >> yep. > >> > >> for now added redirect rules: > >> > >> RedirectMatch permanent ^/cgi-bin/cvsweb/SOURCES/(.*)$ > >> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES.old/$1 RedirectMatch > >> permanent ^/cgi-bin/cvsweb\.cgi/SOURCES/(.*)$ > >> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES.old/$1 > >> > >> is this sufficent, or we should rather redirect to new location in > >> /packages? > >> > >> i mean if you gave old link, then you likely want to point it to the > >> resource available at that time, which this SOURCES.old redirection > >> satisfies. however this will all go void if the SOURCES.old tree is > >> removed someday. > > > > ping? > > Seems fine for me, I provided URLs like: > > http://cvs.pld-linux.org/SOURCES/foo.patch > http://cvs.pld-linux.org/SOURCES/foo.patch?rev=HEAD > > as in: > http://pecl.php.net/bugs/bug.php?id=9697 > > and the redirect works for these as well. the question was rather, should redirect go to /SOURCES.old, or find the location where it was moved in /packages/%{name}, as if we discard /SOURCES.old oneday, the links go broken. as i don't know will /SOURCES.old stay or not? -- glen From glen at delfi.ee Wed May 13 13:30:10 2009 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 13 May 2009 14:30:10 +0300 Subject: packages: util-vserver/util-vserver.spec, util-vserver/TODO (NEW) - move TO... In-Reply-To: References: Message-ID: <200905131430.10483.glen@delfi.ee> On Wednesday 13 May 2009 13:44:38 blues wrote: > $Log$ > +Revision 1.225 2009/05/13 10:44:33 blues > +- move TODO to separate file why? ....i liked the otherwise it's 1. in spec file, always around when you edit the file 3. nobody really goes to see what is in TODO, maybe i'm bored and i fix something. 2. PLD-doc/make-todo.sh scanned SPECS for TODO sections 4. if there are lots of SOURCES in package (like php for example), catching eye on TODO in `ls` is unlikely. -- glen From blues at pld-linux.org Wed May 13 13:53:38 2009 From: blues at pld-linux.org (Pawel Golaszewski) Date: Wed, 13 May 2009 13:53:38 +0200 (CEST) Subject: packages: util-vserver/util-vserver.spec, util-vserver/TODO (NEW) - move TO... In-Reply-To: <200905131430.10483.glen@delfi.ee> References: <200905131430.10483.glen@delfi.ee> Message-ID: On Wed, 13 May 2009, Elan Ruusam?e wrote: > On Wednesday 13 May 2009 13:44:38 blues wrote: > > $Log$ > > +Revision 1.225 2009/05/13 10:44:33 blues > > +- move TODO to separate file > why? ....i liked the otherwise > > it's > 1. in spec file, always around when you edit the file > 3. nobody really goes to see what is in TODO, maybe i'm bored and i fix > something. > 2. PLD-doc/make-todo.sh scanned SPECS for TODO sections > 4. if there are lots of SOURCES in package (like php for example), catching > eye on TODO in `ls` is unlikely. Because: - it makes only noise in spec - nobody goes to see TODO in spec too :) - it's clean and nice - TODO can be not only for SPEC - TODO can be veeeery long... - you don't have to catch anything - you know it's there, like spec :D I think it's better way, easier to parse. -- 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 glen at pld-linux.org Wed May 13 17:33:49 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 13 May 2009 18:33:49 +0300 Subject: Fwd: packages (rpm-4_5): rpm/rpm-shescape-memfault.patch (NEW) - doing xrealloc ... Message-ID: <200905131833.50002.glen@pld-linux.org> > _______________________________________________ > pld-cvs-commit mailing list > pld-cvs-commit at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit why there are no more cvsweb links at the end of commit mails? -- glen From gotar at polanet.pl Wed May 13 19:41:13 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 13 May 2009 19:41:13 +0200 Subject: verify rpm package contents Message-ID: <20090513174113.GA10042@polanet.pl> How to verify digest of files in rpm package (like when repackaged modified files)? For example I've got: ~: rpm -qplv xorg-proto-xproto-devel-7.0.14-1.i586.rpm -rw-r--r-- 1 root root 167477 Oct 28 2008 /usr/include/X11/keysymdef.h but after un-cpio there is: 167401 May 22 2008 rpm --verify -p file.rpm verifies against filesystem contents not files within. -- Tomasz Pala From n3npq at mac.com Wed May 13 19:58:18 2009 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 13 May 2009 13:58:18 -0400 Subject: verify rpm package contents In-Reply-To: <20090513174113.GA10042@polanet.pl> References: <20090513174113.GA10042@polanet.pl> Message-ID: On May 13, 2009, at 1:41 PM, Tomasz Pala wrote: > How to verify digest of files in rpm package (like when repackaged > modified files)? For example I've got: > > ~: rpm -qplv xorg-proto-xproto-devel-7.0.14-1.i586.rpm > -rw-r--r-- 1 root root 167477 Oct 28 2008 /usr/ > include/X11/keysymdef.h > but after un-cpio there is: 167401 May 22 2008 > > rpm --verify -p file.rpm > > verifies against filesystem contents not files within. > Repackaged files have no digest verification. The digest carried in repackaged packages is the original digest; but the file in the payload may have been modified or even deleted and not present in te repackaged package payload. You can work around by using a transaction "probe dependency". E.g. mkdir -p /etc/rpm/sysinfo md5sum /etc/passwd | sed -e 's/\([^ ]*\) *\(.*\)/digest(\2) = \1/' >> /etc/rpm/sysinfo/Requirename verifies the md5 of /etc/passwd every time rpm -Uvh is run. hth 73 de Jeff From wrobell at pld-linux.org Wed May 13 20:08:39 2009 From: wrobell at pld-linux.org (wrobell) Date: Wed, 13 May 2009 19:08:39 +0100 Subject: packages: util-vserver/util-vserver.spec, util-vserver/TODO (NEW) - move TO... In-Reply-To: References: <200905131430.10483.glen@delfi.ee> Message-ID: <20090513180839.GB7698@borg.lan> On Wed, May 13, 2009 at 01:53:38PM +0200, Pawel Golaszewski wrote: > On Wed, 13 May 2009, Elan Ruusam?e wrote: > > On Wednesday 13 May 2009 13:44:38 blues wrote: > > > $Log$ > > > +Revision 1.225 2009/05/13 10:44:33 blues > > > +- move TODO to separate file > > why? ....i liked the otherwise > > > > it's > > 1. in spec file, always around when you edit the file > > 3. nobody really goes to see what is in TODO, maybe i'm bored and i fix > > something. > > 2. PLD-doc/make-todo.sh scanned SPECS for TODO sections > > 4. if there are lots of SOURCES in package (like php for example), catching > > eye on TODO in `ls` is unlikely. > > Because: > - it makes only noise in spec not true, because they are usually short > - nobody goes to see TODO in spec too :) it is easy to spot todo in spec, imho > - it's clean and nice > - TODO can be not only for SPEC so what? it is about the package not spec > - TODO can be veeeery long... any examples... even if there is one or two, then usually they are short if i reckon well wrobell From gotar at polanet.pl Wed May 13 22:48:58 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 13 May 2009 22:48:58 +0200 Subject: verify rpm package contents In-Reply-To: References: <20090513174113.GA10042@polanet.pl> Message-ID: <20090513204858.GA20193@polanet.pl> On Wed, May 13, 2009 at 13:58:18 -0400, Jeff Johnson wrote: > Repackaged files have no digest verification. The digest > carried in repackaged packages is the original digest; > but the file in the payload may have been modified or > even deleted and not present in te repackaged package payload. That are exactly the cases I'd like to catch. During package development sometimes it's necessary to make some modifications (or change entire file) in /usr tree for testing purposes. When you forget about it and upgrade package these changes are lost. Recently I've found old ltmain.sh file (this time causing problems) and I can't recall replacing it. Now I'd like to review entire repackage spool for modifications done before upgrade. There would be differences in config files and missing languages for sure, however other permissions, timestamps and modifications are worth pointing out. > You can work around by using a transaction "probe dependency". > > E.g. > > mkdir -p /etc/rpm/sysinfo > md5sum /etc/passwd | sed -e 's/\([^ ]*\) *\(.*\)/digest(\2) = > \1/' >> /etc/rpm/sysinfo/Requirename > > verifies the md5 of /etc/passwd every time rpm -Uvh is run. Nice feature, too. -- Tomasz Pala From pld.lists at grizz.pl Thu May 14 10:01:50 2009 From: pld.lists at grizz.pl (Witold Firlej) Date: Thu, 14 May 2009 10:01:50 +0200 Subject: cia bot at #pld Message-ID: can Anybody? turn on cia bot at #pld channel? -- :: Witek Firlej :: :: Studencka wyprawa do Chin http://chiny2009.pl :: :: http://grizz.pl :: http://galeria.firlej.org :: jid: grizz//jabster.pl :: From glen at pld-linux.org Mon May 18 16:42:05 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Mon, 18 May 2009 17:42:05 +0300 Subject: packages: texlive/texlive.spec - removed empty epsutils and filters package... In-Reply-To: References: Message-ID: <200905181742.05326.glen@pld-linux.org> On Saturday 16 May 2009 20:13:42 baggins wrote: > +%files jadetex > +%defattr(644,root,root,755) ... > +%doc %{texmfdist}/source/jadetex/base/ChangeLog* ... > +%exclude %{texmfdist}/source/jadetex/base/ChangeLog* how is that supposed to work? -- glen From baggins at sith.mimuw.edu.pl Mon May 18 16:55:09 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 18 May 2009 16:55:09 +0200 Subject: packages: texlive/texlive.spec - removed empty epsutils and filters package... In-Reply-To: <200905181742.05326.glen@pld-linux.org> References: <200905181742.05326.glen@pld-linux.org> Message-ID: <20090518145509.GI30663@sith.mimuw.edu.pl> On Mon, 18 May 2009, Elan Ruusam?e wrote: > On Saturday 16 May 2009 20:13:42 baggins wrote: > > +%files jadetex > > +%defattr(644,root,root,755) > ... > > +%doc %{texmfdist}/source/jadetex/base/ChangeLog* > ... > > +%exclude %{texmfdist}/source/jadetex/base/ChangeLog* > > how is that supposed to work? No idea ;) And you missed %{texmfdist}/source/jadetex/base/* That's why I'm trying to do a test build for a few days :/ Janek -- Jan Rekorajski | ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio From sparky at pld-linux.org Thu May 21 13:16:52 2009 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Thu, 21 May 2009 13:16:52 +0200 Subject: packages: VirtualBox/VirtualBox.spec - note the other kernel modules In-Reply-To: References: Message-ID: <20090521111652.GA25637@pld-linux.org> On Thu, May 21, 2009 at 10:39:38AM +0200, glen wrote: > Author: glen Date: Thu May 21 08:39:38 2009 GMT > Module: packages Tag: HEAD > ---- Log message: > - note the other kernel modules > +You must also install kernel module for this software to work: > + kernel-misc-vboxdrv-%{version}-%{rel}@%{_kernel_ver_str} > + > +Additionally you might want to install: > + kernel-misc-vboxadd-%{version}-%{rel}@%{_kernel_ver_str} > + kernel-misc-vboxvfs-%{version}-%{rel}@%{_kernel_ver_str} > + kernel-misc-vboxnetflt-%{version}-%{rel}@%{_kernel_ver_str} Not completely, vboxadd and vboxvfs are for guest Linux system. -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From glen at delfi.ee Sun May 24 15:35:18 2009 From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Sun, 24 May 2009 16:35:18 +0300 Subject: packages: mythtv/mythtv.spec - moved from DEVEL to HEAD branch - up to rece... In-Reply-To: References: Message-ID: <200905241635.18362.glen@delfi.ee> and where exactly did you report it at all so it would get fixed? or you expect out of nowhere the macro being fixed? On Sunday 24 May 2009 15:55, w.kier wrote: > - strange workaround for addtogroup macro error > > ---- Files affected: > packages/mythtv: > mythtv.spec (1.77 -> 1.78) > > ---- Diffs: ... > %clean > rm -rf $RPM_BUILD_ROOT > > +# Empty newline after %addusertogroup %{name} video below is intended. > +# Do not remove it until rpm stop joining lines with that macro. > %pre backend > %groupadd -g 149 %{name} > %useradd -u 149 -d /var/lib/mythtv -g %{name} -c "MythTV User" %{name} > %addusertogroup %{name} video > + > %addusertogroup %{name} audio -- glen From glen at pld-linux.org Mon May 25 08:39:12 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Mon, 25 May 2009 09:39:12 +0300 Subject: packages: mythtv/mythtv.spec - moved from DEVEL to HEAD branch - up to rece... In-Reply-To: <4A19DB40.70900@farba.eu.org> References: <200905241635.18362.glen@delfi.ee> <4A19DB40.70900@farba.eu.org> Message-ID: <200905250939.12384.glen@pld-linux.org> On Monday 25 May 2009 02:41, WK wrote: > Wiadomo?? od Elan Ruusam?e: > > and where exactly did you report it at all so it would get fixed? > > > > or you expect out of nowhere the macro being fixed? > > Exactly nowhere. > I expected that it is just known bug. and known bugs don't have to be fixed? > If it did not appers with other packages I supposed there is some > additional cause of strange behaviour at that point. > For example encodings conflict UTF vs. ISO or something like that. toooooooooooo wild guess. it doesn't happen often because how many specs you know use that macro TWICE? > Do not irritate please. > I wrote about it only on irc channel. that equals to /dev/null, unless somebody explicitly said he will deal with the problem > I did not check even is that pld only or general rpm bug. its pld rpm macros bug, not bug of rpm or rpmbuild. > I found that > %addusertogroup %{name} video > %addusertogroup %{name} audio > > gives: > "quiet= /usr/lib/rpm/user_group.sh user addtogroup mythtv videoquiet= > /usr/lib/rpm/user_group.sh user addtogroup mythtv audio" so append ";" or "\n" (rather both, first for functionality second for readability) to that macro expansion. > Regards -- glen From glen at pld-linux.org Mon May 25 23:22:57 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 26 May 2009 00:22:57 +0300 Subject: /usr/include/X11 Message-ID: <200905260022.58468.glen@pld-linux.org> who should own this dir? poldek:/all-avail> search -f /usr/include/X11 Searching packages..........................................done. 2 package(s) found: xorg-data-xbitmaps-1.0.1-1.x86_64 xorg-proto-xproto-devel-7.0.15-1.x86_64 -- glen From arekm at maven.pl Tue May 26 08:00:07 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 26 May 2009 08:00:07 +0200 Subject: /usr/include/X11 In-Reply-To: <200905260022.58468.glen@pld-linux.org> References: <200905260022.58468.glen@pld-linux.org> Message-ID: <200905260800.08094.arekm@maven.pl> On Monday 25 of May 2009, Elan Ruusam?e wrote: > who should own this dir? > > poldek:/all-avail> search -f /usr/include/X11 > Searching packages..........................................done. > 2 package(s) found: > xorg-data-xbitmaps-1.0.1-1.x86_64 > xorg-proto-xproto-devel-7.0.15-1.x86_64 both as it's now (or some common package if you really want to change) -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Tue May 26 09:32:54 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Tue, 26 May 2009 10:32:54 +0300 Subject: /usr/include/X11 In-Reply-To: <200905260800.08094.arekm@maven.pl> References: <200905260022.58468.glen@pld-linux.org> <200905260800.08094.arekm@maven.pl> Message-ID: <200905261032.54564.glen@pld-linux.org> On Tuesday 26 May 2009 09:00, Arkadiusz Miskiewicz wrote: > On Monday 25 of May 2009, Elan Ruusam?e wrote: > > who should own this dir? > > > > poldek:/all-avail> search -f /usr/include/X11 > > Searching packages..........................................done. > > 2 package(s) found: > > xorg-data-xbitmaps-1.0.1-1.x86_64 > > xorg-proto-xproto-devel-7.0.15-1.x86_64 > > both as it's now (or some common package if you really want to change) and what is the common package? filesystem? FHS? xorg-lib-libX11-devel? as it is symlink on my system and i want to add %pretrans to make it dir. -- glen From glen at pld-linux.org Tue May 26 09:41:05 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 26 May 2009 10:41:05 +0300 Subject: RFC: separate FTP subdirectory for debuginfo In-Reply-To: <20090403111737.GA5050@polanet.pl> References: <20090403111737.GA5050@polanet.pl> Message-ID: <200905261041.05923.glen@pld-linux.org> On Friday 03 April 2009 14:17, Tomasz Pala wrote: > They live within arch subdirectories so can be moved into subdirectory > (arch/debuginfo) or upper directory (e.g. arch-debuginfo). so which version then? of course top level "debuginfo" would make persons mirroring ftp happy, but if you use rsync for mirroring making exclude rules shouldn't be hard either. altho, who mirrors whole site, probably only one arch is interested in? currently: 10:37:21 pldth[load: 2.24]@ep09-pld ~/ftp$ du PLD/*/RPMS -s 9.3G PLD/athlon/RPMS 9.2G PLD/i486/RPMS 9.3G PLD/i686/RPMS 2.8G PLD/noarch/RPMS 8.9G PLD/ppc/RPMS 13G PLD/SRPMS/RPMS 9.4G PLD/x86_64/RPMS ... and test/ready/obsolete trees so it could be added like: 10:37:21 pldth[load: 2.24]@ep09-pld ~/ftp$ du PLD/*/RPMS -s PLD/athlon/debuginfo PLD/i486/debuginfo PLD/i686/debuginfo PLD/ppc/debuginfo PLD/x86_64/debuginfo ready/athlon/debuginfo ready/i486/debuginfo ready/i686/debuginfo ready/ppc/debuginfo ready/x86_64/debuginfo test/athlon/debuginfo test/i486/debuginfo test/i686/debuginfo test/ppc/debuginfo test/x86_64/debuginfo updates/athlon/debuginfo updates/i486/debuginfo updates/i686/debuginfo updates/ppc/debuginfo updates/x86_64/debuginfo obsolete/athlon/debuginfo obsolete/i486/debuginfo obsolete/i686/debuginfo obsolete/ppc/debuginfo obsolete/x86_64/debuginfo yes? i guess first test could be made manually using shell and mv on ftp, then try to hack builder code. the first mv need to be done manually anyway as nobody is going to rebuild whole th-main to get everything split via builders ;) -- glen From arekm at maven.pl Tue May 26 09:54:46 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 26 May 2009 09:54:46 +0200 Subject: /usr/include/X11 In-Reply-To: <200905261032.54564.glen@pld-linux.org> References: <200905260022.58468.glen@pld-linux.org> <200905260800.08094.arekm@maven.pl> <200905261032.54564.glen@pld-linux.org> Message-ID: <200905260954.46755.arekm@maven.pl> On Tuesday 26 of May 2009, Elan Ruusam?e wrote: > On Tuesday 26 May 2009 09:00, Arkadiusz Miskiewicz wrote: > > On Monday 25 of May 2009, Elan Ruusam?e wrote: > > > who should own this dir? > > > > > > poldek:/all-avail> search -f /usr/include/X11 > > > Searching packages..........................................done. > > > 2 package(s) found: > > > xorg-data-xbitmaps-1.0.1-1.x86_64 > > > xorg-proto-xproto-devel-7.0.15-1.x86_64 > > > > both as it's now (or some common package if you really want to change) > > and what is the common package? filesystem? FHS? xorg-lib-libX11-devel? Someone has to decide. xorg-lib-libX11-devel is surely not "common" since xbitmaps are not only used at compilation time but afaik also at runtime. filesystem maybe. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Tue May 26 16:13:26 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 26 May 2009 17:13:26 +0300 Subject: RFC: separate FTP subdirectory for debuginfo In-Reply-To: <200905261041.05923.glen@pld-linux.org> References: <20090403111737.GA5050@polanet.pl> <200905261041.05923.glen@pld-linux.org> Message-ID: <200905261713.27026.glen@pld-linux.org> On Tuesday 26 May 2009 10:41:05 Elan Ruusam?e wrote: > yes? here it is: 17:08:13 pldth[load: 3.14]@ep09-pld ~/ftp/PLD$ du */RPMS */debuginfo 32M athlon/RPMS/repodata 25M athlon/RPMS/packages.i 6.2G athlon/RPMS 25M i486/RPMS/packages.i 32M i486/RPMS/repodata 6.1G i486/RPMS 25M i686/RPMS/packages.i 33M i686/RPMS/repodata 6.2G i686/RPMS 9.1M noarch/RPMS/repodata 8.2M noarch/RPMS/packages.i 2.8G noarch/RPMS 32M ppc/RPMS/repodata 24M ppc/RPMS/packages.i 5.9G ppc/RPMS 13G SRPMS/RPMS 25M x86_64/RPMS/packages.i 32M x86_64/RPMS/repodata 6.3G x86_64/RPMS 3.1G athlon/debuginfo 3.1G i486/debuginfo 3.1G i686/debuginfo 3.1G ppc/debuginfo 3.2G x86_64/debuginfo -- glen From udvzsolt at gmail.com Tue May 26 17:26:53 2009 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Tue, 26 May 2009 17:26:53 +0200 Subject: Anaconda fails Message-ID: <20090526172653.46369bd5@gmail.com> Hi all! An other hungarian man wants to install PLD to his machine (I suggest PLD ;)) with livecd, but the anaconda fails with the following error: anaconda None exception report ? ? Traceback (most recent call first): ? ? File ? ? "/usr/lib/python2.6/site-packages/snack.py", ? ? line 193, in setCurrent ? ? File ? ? "/usr/lib/python2.6/site-packages/snack.py", ? ? line 791, in ListboxChoiceWindow ? ? File ? ? "/home/users/qwiat/tmp/anaconda-11.5.0.6.200901 ? ? 172133-root-qwiat//usr/lib/anaconda/textw/langu ? ? age_text.py", line 50, in __call__ ? ? File ? ? "/home/users/qwiat/tmp/anaconda-11.5.0.6.200901 ? ? 172133-root-qwiat//usr/lib/anaconda/text.py", ? ? line 718, in run ? ? File "/usr/sbin/anaconda", line 1010, in ? ? ? ? anaconda.intf.run(anaconda) ? ? KeyError: 'C' What can he do? Zsolt From patrys at pld-linux.org Tue May 26 17:36:37 2009 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 26 May 2009 17:36:37 +0200 Subject: Anaconda fails In-Reply-To: <20090526172653.46369bd5@gmail.com> References: <20090526172653.46369bd5@gmail.com> Message-ID: <89b6ba3a0905260836wb31dc8an5132d7280c80f2a7@mail.gmail.com> On Tue, May 26, 2009 at 5:26 PM, Zsolt Udvari wrote: > Hi all! > > An other hungarian man wants to install PLD to his machine (I suggest PLD ;)) > with livecd, but the anaconda fails with the following error: You seem to be either using a very old LiveCD with anaconda or a custom CD with broken locale. Could you try the following: 1) reboot the CD so it is in a clean system state 2) upgrade your copy of anaconda (you can upgrade a running LiveCD like any other system) 3) write down the output of "rpm -q anaconda" 4) write down the ouput of "locale" 5) try to install again If it still fails, I'd like to know the version of anaconda and exactly when the error occurs (does it even start, which screen crashes, what was chosen in the previous steps etc.). -- Patryk Zawadzki From sparky at pld-linux.org Sun May 31 19:04:13 2009 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Sun, 31 May 2009 19:04:13 +0200 Subject: packages: dmenu/dmenu.spec (NEW) - initial In-Reply-To: References: Message-ID: <20090531170413.GA30804@pld-linux.org> On Sun, May 31, 2009 at 06:45:28PM +0200, uzsolt wrote: > Author: uzsolt Date: Sun May 31 16:45:28 2009 GMT > Module: packages Tag: HEAD > ---- Log message: > - initial > +%prep > +%setup -q > +sed -i "s@^PREFIX.*@PREFIX=%{_prefix}@" config.mk > +sed -i "s@^\(CFLAGS.*\)-Os\(.*\)@\1 \2 %{rpmcflags}@" config.mk > +sed -i "s@^\(LDFLAGS.*\)@\1 %{rpmldflags}@" config.mk You shouldn't be defining these at %prep stage, doing so in %build is much more secure. And there must be much a simpler way than using sed to do it. You could pass options in %__make invocation, or append them at the end of config.mk file: %build cat << 'EOF' >> config.mk PREFIX = %{_prefix} CFLAGS := %{rpmcflags} $(filter-out -Os,$(CFLAGS)) LDFLAGS = %{rpmldflags} EOF %{__make} BTW, appropriate sed BR is missing. -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org