From kornet at camk.edu.pl Fri Jun 1 18:26:12 2007 From: kornet at camk.edu.pl (Kacper Kornet) Date: Fri, 1 Jun 2007 18:26:12 +0200 Subject: [AC] mutt - security upgrade Message-ID: <20070601162612.GB11939@virgo.camk.edu.pl> There is a new version of mutt which fixes CVE-2007-2683 and CVE-2007-1558. I enclose patch for the AC-branch. Best wishes, -- Kacper Kornet -------------- next part -------------- Index: mutt.spec =================================================================== RCS file: /cvsroot/SPECS/mutt.spec,v retrieving revision 1.183.2.1 diff -u -r1.183.2.1 mutt.spec --- mutt.spec 17 Jul 2006 13:35:04 -0000 1.183.2.1 +++ mutt.spec 1 Jun 2007 16:25:29 -0000 @@ -19,13 +19,13 @@ Summary(tr): Mutt elektronik posta program? Summary(uk): ??????? ?????????? ???????? Mutt Name: mutt -Version: 1.4.2.2 +Version: 1.4.2.3 Release: 1 Epoch: 6 License: GPL Group: Applications/Mail -Source0: ftp://ftp.mutt.org/mutt/%{name}-%{version}i.tar.gz -# Source0-md5: 51a08429c5bd5c34af3f4268b8cbcda3 +Source0: ftp://ftp.mutt.org/mutt/%{name}-%{version}.tar.gz +# Source0-md5: dcb94661827dd090fa813e73e122ea0c Source1: %{name}.desktop Source2: %{name}.png Source3: %{name}.1.pl From arekm at maven.pl Fri Jun 1 20:51:56 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Fri, 1 Jun 2007 20:51:56 +0200 Subject: /dev/null in bind chroot() Message-ID: <200706012051.56443.arekm@maven.pl> Hello I wonder what for /dev/null can be used by named inside of it's chroot() ? Any ideas? I guess glibc itself doesn't really need it. /dev/random for example is no longer needed since bind can use /dev/random from outside of chroot (it opens it early and keeps descriptor). Now if /dev/null could be dropped, too then it would be great. ps. bind 9.4.1-2 makes it way to ac-ready now, please test it -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From ankry at green.mif.pg.gda.pl Fri Jun 1 22:50:01 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Fri, 1 Jun 2007 22:50:01 +0200 (CEST) Subject: /dev/null in bind chroot() In-Reply-To: <200706012051.56443.arekm@maven.pl> from "Arkadiusz Miskiewicz" at Jun 01, 2007 08:51:56 PM Message-ID: <200706012050.l51Ko1sU027279@green.mif.pg.gda.pl> Arkadiusz Miskiewicz wrote: > > > Hello > > I wonder what for /dev/null can be used by named inside of it's chroot() ? Any > ideas? I guess glibc itself doesn't really need it. > > /dev/random for example is no longer needed since bind can use /dev/random > from outside of chroot (it opens it early and keeps descriptor). Is the descriptor kept over a reload of named? AFAIR there were problems with that. > Now if /dev/null could be dropped, too then it would be great. -- ======================================================================= 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 arekm at maven.pl Fri Jun 1 22:57:47 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Fri, 1 Jun 2007 22:57:47 +0200 Subject: /dev/null in bind chroot() In-Reply-To: <200706012050.l51Ko1sU027279@green.mif.pg.gda.pl> References: <200706012050.l51Ko1sU027279@green.mif.pg.gda.pl> Message-ID: <200706012257.47748.arekm@maven.pl> On Friday 01 of June 2007, Andrzej Krzysztofowicz wrote: > Arkadiusz Miskiewicz wrote: > > Hello > > > > I wonder what for /dev/null can be used by named inside of it's chroot() > > ? Any ideas? I guess glibc itself doesn't really need it. > > > > /dev/random for example is no longer needed since bind can use > > /dev/random from outside of chroot (it opens it early and keeps > > descriptor). > > Is the descriptor kept over a reload of named? > AFAIR there were problems with that. Seems so. [root at carme ~]# lsof -n |grep named |grep random named 24763 named 5r CHR 1,8 402654872 /dev/random [root at carme ~]# service named reload Prze?adowanie us?ugi Named....................................... [ ZROBIONE ] [root at carme ~]# lsof -n |grep named |grep random named 24763 named 5r CHR 1,8 402654872 /dev/random no complains in log. For testing I also deleted /var/lib/named/dev/null - so far no problems. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From kornet at camk.edu.pl Sat Jun 2 03:59:25 2007 From: kornet at camk.edu.pl (Kacper Kornet) Date: Sat, 2 Jun 2007 03:59:25 +0200 Subject: [AC] gimp upgrade Message-ID: <20070602015925.GF11939@virgo.camk.edu.pl> I enclose the path with the upgrade of gimp. The new version corrects CVE-2007-2356. P.S. Building new gimp I discovered that pango-devel probably misses requirement for glitz-devel. -- Kacper Kornet -------------- next part -------------- Index: gimp.spec =================================================================== RCS file: /cvsroot/SPECS/gimp.spec,v retrieving revision 1.275 diff -u -r1.275 gimp.spec --- gimp.spec 27 Apr 2007 19:33:20 -0000 1.275 +++ gimp.spec 2 Jun 2007 01:43:30 -0000 @@ -21,13 +21,13 @@ Summary(zh_CN.UTF-8): [??????]GNU???????????????? ? Summary(zh_TW.UTF-8): [??????]GNU???????????????? ? Name: gimp -Version: 2.2.14 +Version: 2.2.15 Release: 1 Epoch: 1 License: GPL Group: X11/Applications/Graphics Source0: ftp://ftp.gimp.org/pub/gimp/v2.2/%{name}-%{version}.tar.bz2 -# Source0-md5: 2f47dd66d714a970356e275dd1d3caac +# Source0-md5: 5e705f0c7a3b37703d407e88bee357bb Patch0: %{name}-home_etc.patch URL: http://www.gimp.org/ %{?with_aalib:BuildRequires: aalib-devel} From adamg at biomerieux.pl Sat Jun 2 20:59:04 2007 From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=) Date: Sat, 2 Jun 2007 20:59:04 +0200 Subject: geninitrd 8385 patches and comments In-Reply-To: <20070522131106.GA16290@jajo.eggsoft.pl> References: <20070522131106.GA16290@jajo.eggsoft.pl> Message-ID: <20070602185904.GA4570@mysza.eu.org> On Tue, May 22, 2007 at 03:11:06PM +0200, Jacek Konieczny wrote: > 2. the initrd (initramfs in fact) was unable to mount my root device, > which was an LVM volume. > > I made two patches (attached) to address the second problem: > > 1. geninitrd-rootdev.patch > > 2. geninitrd-lvm_initramfs.patch They worked for me, +1 from me for applying them, and since noone made any objection so far, please apply. > - Do we still need non-initramfs initrd images? Dropping the legacy > would make things much simpler: writtable filesystem (no need for > temporary tmpfs mounts), the image could be generated with no > mknode/mount/chown privileges. Functionality of the initramfs image > could be easily extended by appending other cpio archives to it. What about initramfs support on ppc? -- http://www.mysza.eu.org/ | Everybody needs someone sure, someone true, PLD Linux developer | Everybody needs some solid rock, I know I do. From gotar at polanet.pl Sun Jun 3 13:59:04 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 3 Jun 2007 13:59:04 +0200 Subject: [webapps] PHP files owner Message-ID: <20070603115904.GA12716@pepin.polanet.pl> Hello, I was considering a bug in any of shipped webapps. Even though the server can be safe_mode enabled there is possibility to read information that should remain confidential, like valuable for spammers users list from passwd. I leave other restrictions out deliberately, as ACLs, open_basedir etc. are not part of our default policy. Currently system-wide package creates bigger threat than any user script, no matter how the environment IS secured (safe_mode, suexec PHP as CGI etc.). Shouldn't we change default root:root owner to some webapps:webapps? -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From patrys at pld-linux.org Mon Jun 4 08:43:42 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Mon, 4 Jun 2007 08:43:42 +0200 Subject: geninitrd 8385 patches and comments In-Reply-To: <20070602185904.GA4570@mysza.eu.org> References: <20070522131106.GA16290@jajo.eggsoft.pl> <20070602185904.GA4570@mysza.eu.org> Message-ID: <89b6ba3a0706032343g5dfced2ag65ac6947bb0443b4@mail.gmail.com> On 6/2/07, Adam Go??biowski wrote: > On Tue, May 22, 2007 at 03:11:06PM +0200, Jacek Konieczny wrote: > > 2. the initrd (initramfs in fact) was unable to mount my root device, > > which was an LVM volume. > > > > I made two patches (attached) to address the second problem: > > > > 1. geninitrd-rootdev.patch > > > > 2. geninitrd-lvm_initramfs.patch > > They worked for me, +1 from me for applying them, and since noone made > any objection so far, please apply. +1, tested and works here -- Patryk Zawadzki Generated Content From kornet at camk.edu.pl Wed Jun 6 01:54:57 2007 From: kornet at camk.edu.pl (Kacper Kornet) Date: Wed, 6 Jun 2007 01:54:57 +0200 Subject: [AC] autoconf-2.61.-1 Message-ID: <20070605235457.GE31766@virgo.camk.edu.pl> autoconf-2.61-1 from ac-updates produces an error when macro AM_GNU_GETTEXT([external]) is used. I think there are two solutions: a) push autoconf from HEAD to Ac b) push m4>=1.4.5 to AC Best wishes, -- Kacper Kornet From glen at pld-linux.org Sat Jun 9 11:20:39 2007 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Sat, 9 Jun 2007 12:20:39 +0300 Subject: SPECS (AC-branch): kernel-vanilla.spec - updated to 2.6.21.4 In-Reply-To: References: Message-ID: <200706091220.39599.glen@pld-linux.org> On Saturday 09 June 2007, hawk wrote: > Author: hawk Date: Sat Jun 9 07:39:17 2007 GMT > Module: SPECS Tag: AC-branch > ---- Log message: > - updated to 2.6.21.4 > > ---- Files affected: > SPECS: > kernel-vanilla.spec (1.43.2.4 -> 1.43.2.5) errr?? why updating AC-branch? why not follow kernel.spec/mysql.spec schema that you update branch (LINUX_2_6 / LINUX_2_6_21) and later just move AC-branch tag? -- glen From hawk at limanowa.net Sat Jun 9 18:57:35 2007 From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=) Date: Sat, 09 Jun 2007 18:57:35 +0200 Subject: SPECS (AC-branch): kernel-vanilla.spec - updated to 2.6.21.4 In-Reply-To: <200706091220.39599.glen@pld-linux.org> References: <200706091220.39599.glen@pld-linux.org> Message-ID: <466ADBFF.1080502@limanowa.net> >> Author: hawk Date: Sat Jun 9 07:39:17 2007 GMT >> Module: SPECS Tag: AC-branch >> ---- Log message: >> - updated to 2.6.21.4 >> >> ---- Files affected: >> SPECS: >> kernel-vanilla.spec (1.43.2.4 -> 1.43.2.5) > > errr?? > > why updating AC-branch? > > why not follow kernel.spec/mysql.spec schema that you update branch > (LINUX_2_6 / LINUX_2_6_21) and later just move AC-branch tag? Because shadzik was about to port HEAD to news-style macros. I don't know if he did it or not, I'm not checking HEAD. M. 1.42 Sun Mar 25 0:31:18 2007 by shadzik - linux-2.6.20.4 - it's still old-style, till now I will try to adapt it to new-style macros so it's rather your last chance to build this on AC From qboosh at pld-linux.org Sun Jun 10 23:04:25 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 10 Jun 2007 23:04:25 +0200 Subject: libmozjs.so/libxpcom.so provides Message-ID: <20070610210425.GA19003@stranger.qboosh.pl> Why xulrunner has blocked libmozjs.so and libxpcom.so provides? mozilla*/seamonkey shouldn't provide them. But it's xulrunner that provides these libs for packages using embedded gecko, so providing them in xulrunner-libs should be OK. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Mon Jun 11 18:26:23 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 11 Jun 2007 18:26:23 +0200 Subject: SPECS: gammu.spec - upgraded to 1.11.92, - switched from autoconf ... In-Reply-To: References: Message-ID: <20070611162623.GA5967@stranger.qboosh.pl> On Fri, Jun 08, 2007 at 02:01:45PM +0200, gotar wrote: > Author: gotar Date: Fri Jun 8 12:01:45 2007 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - upgraded to 1.11.92, > - switched from autoconf to cmake (why there's no R: libbluetooth.so.2 in > libs subpackage?), Probably because cmake installs shared libs as non-executable :/ Could sb check if this issue concerns whole kde* 4 stuff too? -- Jakub Bogusz http://qboosh.pl/ From blues at pld-linux.org Tue Jun 12 19:01:38 2007 From: blues at pld-linux.org (Pawel Golaszewski) Date: Tue, 12 Jun 2007 19:01:38 +0200 (CEST) Subject: [webapps] PHP files owner In-Reply-To: <20070603115904.GA12716@pepin.polanet.pl> References: <20070603115904.GA12716@pepin.polanet.pl> Message-ID: On Sun, 3 Jun 2007, Tomasz Pala wrote: > I was considering a bug in any of shipped webapps. Even though the > server can be safe_mode enabled ...which will be droped in future php releases :) safe_mode is considered to be obsolete in PHP. > there is possibility to read information that should remain > confidential, like valuable for spammers users list from passwd. I leave > other restrictions out deliberately, as ACLs, open_basedir etc. are not > part of our default policy. I see that you have started implementing open_basedir and I think that we should follow this way. Any restrictions, even very wide by default, would be nice. > Currently system-wide package creates bigger threat than any user > script, no matter how the environment IS secured (safe_mode, suexec PHP > as CGI etc.). Shouldn't we change default root:root owner to some > webapps:webapps? What will it give us? I don't get the point in this moment... -- pozdr. Pawel Golaszewski 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 gotar at polanet.pl Wed Jun 13 01:52:01 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 13 Jun 2007 01:52:01 +0200 Subject: [webapps] PHP files owner In-Reply-To: References: <20070603115904.GA12716@pepin.polanet.pl> Message-ID: <20070612235201.GB4696@pepin.polanet.pl> On Tue, Jun 12, 2007 at 07:01:38PM +0200, Pawel Golaszewski wrote: > > ...which will be droped in future php releases :) > safe_mode is considered to be obsolete in PHP. I know. However there's no rational replacement AFAIK and I doubt people will happily switch to new version. I won't until it's ready. Anything I read says how safe_mode is bad and that server should be PROPERLY configured, but none has said what does it mean. I can think of: - vserver for every user (imagine 1000+ users - not so big machine), - open_basedir for every system account (as above, shitty idea as long as there's no system-wide globbing variable, e.g. open_basedir = "$HOME:/tmp", preferably with session.save_path="$HOME/tmp" and upload_tmp_dir="$HOME/tmp" for every user OWNING script, again), - PHP as CGI run via suexec - performance penalty, but the only one solution solving problem of inherited EUID for exec(), system() etc. Well, there's also possibility of modularized PHP to gain OWNING user rights, but this should be considered as The Most Evil and Stupid Idea. I've got ACLs on my server, but as long as every PHP script is run as the same http system user they do no user separation at this level. It's odd, that logged user Joe can do literally nothing with Bill's files, but (without safe_mode) can read something via PHP script (no matter how did he guess filename or path, reading should not be able at all). How can I prevent Joe from reading Bill's files? How can I prevent Joe from running his own (uploaded) programs? How can I prevent Joe from reading my password from /etc/webapps/coppermine-gallery/config.inc.php without safe_mode? > I see that you have started implementing open_basedir and I think that we > should follow this way. Any restrictions, even very wide by default, would > be nice. That's what I thought. But this helps only for system packages. Joe can install anything on his own and I don't want to create dozens of open_basedir rules for every system account I've got. Without safe_mode I would be forced to. > > Currently system-wide package creates bigger threat than any user > > script, no matter how the environment IS secured (safe_mode, suexec PHP > > as CGI etc.). Shouldn't we change default root:root owner to some > > webapps:webapps? > > What will it give us? I don't get the point in this moment... In short - some priviledges are inherited from script owner (at application level in safe_mode or system level with suPHP or suexec+PHP-f?CGI). Thus we should make them ordinary. Assuming a bug in any webapp, e.g. seeking to any file or executing a binary: - safe_mode - as long as root is the owner, an attacker can read root's files having o+r or (g=http)+r, e.g. /etc/passwd or files containing database passwords: /etc/webapps/coppermine-gallery/config.inc.php, /etc/webapps/mediawiki/AdminSettings.php, /etc/webapps/phpMyAdmin/config.inc.php, /etc/webapps/phpwiki/config.ini, /etc/webapps/stacks-wiki/db.php, /etc/webapps/zabbix/db.inc.php Changing script owner makes safe_mode block this[1]. For now open_basedir does it too, but as it is application-level security I don't trust it (there were bugs) and IMHO it would be better to have them two work together, - suPHP and any other solution involving EUID changes - they are all SUID and it's obvious, that the sooner they drop to ordinary user (script owner) the better. Why give them a chance to stay and work with EUID=0? And this time the threat is bigger (although the system seems to be more secure! for users at least) - it includes not only reading some files, but also executing a code with root priviledges. My conclusion: there are some paths of priviledges propagation from script owners. However the risk is low and dependant of system configuration, we shall avoid it. We should not trust separation above operating system. [1] even more - we must set safe_mode_include_dir for every application so that is could read it's configuration file. This way we are sure that no other PHP script will have access. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From jajcus at jajcus.net Wed Jun 13 09:19:10 2007 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 13 Jun 2007 09:19:10 +0200 Subject: [webapps] PHP files owner In-Reply-To: <20070612235201.GB4696@pepin.polanet.pl> References: <20070603115904.GA12716@pepin.polanet.pl> <20070612235201.GB4696@pepin.polanet.pl> Message-ID: <20070613071910.GA30919@jajo.eggsoft.pl> On Wed, Jun 13, 2007 at 01:52:01AM +0200, Tomasz Pala wrote: > - PHP as CGI run via suexec - performance penalty, but the only one solution > solving problem of inherited EUID for exec(), system() etc. There is also another one, safe and easy solution: PHP running as FastCGI, external to the web server. It is the natural solution for lighttpd, but Apache doesn't seem to like FastCGI (there is not mod_fastcgi included in Apache httpd sources). FastCGI application (including PHP interpreter) may be running on a different account or even a different server then the web server process. It can also be started on demand, by the webserver, like regular CGI, but once started it may server many requests. When FastCGI application crashes it doesn't break the main webserver process (as opposite to mod_* solutions). IMHO the Apache's modules approach (mod_php, mod_python, mod_perl) is broken by design (interpreter built into the server process cannot be made multiuser and safe) and suexec and similar are only workarounds for CGI limitations. Maybe PLD could prepare some framework for running PHP applications via FastCGI under Apache? But there still a problem similar to switching to lighttpd: some people just want or need mod_php/Apache and we won't help them by providing other, even better (in some ways) solution. Greets, Jacek From gotar at polanet.pl Wed Jun 13 10:14:47 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 13 Jun 2007 10:14:47 +0200 Subject: [webapps] PHP files owner In-Reply-To: <20070613071910.GA30919@jajo.eggsoft.pl> References: <20070603115904.GA12716@pepin.polanet.pl> <20070612235201.GB4696@pepin.polanet.pl> <20070613071910.GA30919@jajo.eggsoft.pl> Message-ID: <20070613081447.GA15889@pepin.polanet.pl> On Wed, Jun 13, 2007 at 09:19:10AM +0200, Jacek Konieczny wrote: > On Wed, Jun 13, 2007 at 01:52:01AM +0200, Tomasz Pala wrote: > > - PHP as CGI run via suexec - performance penalty, but the only one solution > > solving problem of inherited EUID for exec(), system() etc. > > There is also another one, safe and easy solution: PHP running as > FastCGI, external to the web server. It's not so safe - it's still the same user for every script, so if appX can read it's configuration file (with database password), then appY have access too (unless restricted by safe_mode or dozens of open_basedir). So one should run one FastCGI process for every system account to be secure, or there must be some SUID on the way (that's why I have written about suexec+PHP-f?CGI). > FastCGI application (including PHP interpreter) may be running on > a different account or even a different server then the web server [...] Nice. Doesn't it brake eAccelerator/other optimizers? > IMHO the Apache's modules approach (mod_php, mod_python, mod_perl) is > broken by design (interpreter built into the server process cannot be > made multiuser and safe) and suexec and similar are only workarounds for > CGI limitations. Unfortunatelly, that's right... > Maybe PLD could prepare some framework for running PHP applications via > FastCGI under Apache? apache-mod_fastcgi, apache-mod_fcgid or sth else? BTW description of the latter says: 'and kick out the corrupt fastcgi server as soon as possible'. > But there still a problem similar to switching to > lighttpd: some people just want or need mod_php/Apache and we won't help > them by providing other, even better (in some ways) solution. What other (incompatibile) changes need to be done? -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From patrys at pld-linux.org Wed Jun 13 10:46:29 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Wed, 13 Jun 2007 10:46:29 +0200 Subject: [webapps] PHP files owner In-Reply-To: <20070613081447.GA15889@pepin.polanet.pl> References: <20070603115904.GA12716@pepin.polanet.pl> <20070612235201.GB4696@pepin.polanet.pl> <20070613071910.GA30919@jajo.eggsoft.pl> <20070613081447.GA15889@pepin.polanet.pl> Message-ID: <89b6ba3a0706130146n4dd14734i8d876c1089d301aa@mail.gmail.com> On 6/13/07, Tomasz Pala wrote: > On Wed, Jun 13, 2007 at 09:19:10AM +0200, Jacek Konieczny wrote: > > There is also another one, safe and easy solution: PHP running as > > FastCGI, external to the web server. > It's not so safe - it's still the same user for every script, so if appX > can read it's configuration file (with database password), then appY > have access too (unless restricted by safe_mode or dozens of > open_basedir). No. FCGI is based on the concept of applications, not scripts. Each application (think domain) has its own FCGI daemon running and handling requests. If domain foo dies, bar is supposed to work > So one should run one FastCGI process for every system account to be > secure, or there must be some SUID on the way (that's why I have written > about suexec+PHP-f?CGI). You are supposed to run one process per application. > > FastCGI application (including PHP interpreter) may be running on > > a different account or even a different server then the web server > Nice. Doesn't it brake eAccelerator/other optimizers? These are run by php, not apache. > > IMHO the Apache's modules approach (mod_php, mod_python, mod_perl) is > > broken by design (interpreter built into the server process cannot be > > made multiuser and safe) and suexec and similar are only workarounds for > > CGI limitations. > Unfortunatelly, that's right... +1 -- Patryk Zawadzki Generated Content From jajcus at jajcus.net Wed Jun 13 10:52:58 2007 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 13 Jun 2007 10:52:58 +0200 Subject: [webapps] PHP files owner In-Reply-To: <20070613081447.GA15889@pepin.polanet.pl> References: <20070603115904.GA12716@pepin.polanet.pl> <20070612235201.GB4696@pepin.polanet.pl> <20070613071910.GA30919@jajo.eggsoft.pl> <20070613081447.GA15889@pepin.polanet.pl> Message-ID: <20070613085258.GA302@jajo.eggsoft.pl> On Wed, Jun 13, 2007 at 10:14:47AM +0200, Tomasz Pala wrote: > It's not so safe - it's still the same user for every script, so if appX > can read it's configuration file (with database password), then appY > have access too (unless restricted by safe_mode or dozens of > open_basedir). > So one should run one FastCGI process for every system account to be > secure, or there must be some SUID on the way (that's why I have written > about suexec+PHP-f?CGI). I was thinking about the process-per-uid solution. Or some facility to start such processes on demand (it doesn't have to be SUID, it my run with uid=0 and do not much more than fork() and setuid()). > > FastCGI application (including PHP interpreter) may be running on > > a different account or even a different server then the web server > [...] > > Nice. Doesn't it brake eAccelerator/other optimizers? I don't know those, so I cannot tell you. > > Maybe PLD could prepare some framework for running PHP applications via > > FastCGI under Apache? > > apache-mod_fastcgi, apache-mod_fcgid or sth else? I was thinking about some infrastructure for webapps in PLD packages so they could be run via fastcgi and not require mod_php. But this should be flexible, so mod_php and servers other than Apache would work too... that would mean complicated... and that could mean: not worth doing it. > BTW description of > the latter says: 'and kick out the corrupt fastcgi server as soon as > possible'. Sounds good... as with mod_fastcgi I have often encountered a problem when fastcgi app crashed and Apache still tried to use it for a few requests. Greets, Jacek From glen at delfi.ee Wed Jun 13 14:32:01 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 13 Jun 2007 15:32:01 +0300 Subject: [webapps] PHP files owner In-Reply-To: <20070613085258.GA302@jajo.eggsoft.pl> References: <20070603115904.GA12716@pepin.polanet.pl> <20070613081447.GA15889@pepin.polanet.pl> <20070613085258.GA302@jajo.eggsoft.pl> Message-ID: <200706131532.01952.glen@delfi.ee> On Wednesday 13 June 2007 11:52:58 Jacek Konieczny wrote: > > > FastCGI application (including PHP interpreter) may be running on > > > a different account or even a different server then the web server > > > > [...] > > > > Nice. Doesn't it brake eAccelerator/other optimizers? > > I don't know those, so I cannot tell you. optimizers do work under fastcgi as they are permanent, not spawned per request. -- glen From glen at delfi.ee Wed Jun 13 14:35:44 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 13 Jun 2007 15:35:44 +0300 Subject: [webapps] PHP files owner In-Reply-To: <20070613081447.GA15889@pepin.polanet.pl> References: <20070603115904.GA12716@pepin.polanet.pl> <20070613071910.GA30919@jajo.eggsoft.pl> <20070613081447.GA15889@pepin.polanet.pl> Message-ID: <200706131535.44610.glen@delfi.ee> On Wednesday 13 June 2007 11:14:47 Tomasz Pala wrote: > > But there still a problem similar to switching to > > lighttpd: some people just want or need mod_php/Apache and we won't help > > them by providing other, even better (in some ways) solution. > > What other (incompatibile) changes need to be done? when running under fastcgi there's no easy way to pass php_value, php_admin_value's per location/directory. ps: lighttpd & php work very fine under pld (i use in production), just install either: lighttpd-php-external + php-fcgi-init or lighttpd-php-spawned (%desc should mention what's the difference) -- glen From gotar at polanet.pl Wed Jun 13 15:31:40 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 13 Jun 2007 15:31:40 +0200 Subject: [webapps] PHP files owner In-Reply-To: <89b6ba3a0706130146n4dd14734i8d876c1089d301aa@mail.gmail.com> References: <20070603115904.GA12716@pepin.polanet.pl> <20070612235201.GB4696@pepin.polanet.pl> <20070613071910.GA30919@jajo.eggsoft.pl> <20070613081447.GA15889@pepin.polanet.pl> <89b6ba3a0706130146n4dd14734i8d876c1089d301aa@mail.gmail.com> Message-ID: <20070613133140.GA18729@pepin.polanet.pl> On Wed, Jun 13, 2007 at 10:46:29AM +0200, Patryk Zawadzki wrote: > > So one should run one FastCGI process for every system account to be > > secure, or there must be some SUID on the way (that's why I have written > > about suexec+PHP-f?CGI). > > You are supposed to run one process per application. 1000+ processes for all my users? Well, thanks but no, thanks;] -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From glen at delfi.ee Wed Jun 13 19:18:50 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 13 Jun 2007 20:18:50 +0300 Subject: rpm suggest backport? Message-ID: <200706132018.50170.glen@delfi.ee> can someone with enough rpm hackery mana backport or make rpm ignore Suggests? it would ease Th/Ac parallel developement. $ ./builder -g spamassassin P spamassassin.spec # $Revision: 1.127 $, $Date: 2007/05/11 16:48:16 $ error: line 61: Unknown tag: Suggests: spamassassin-update Error: package build failed. (no more info) -- glen From glen at pld-linux.org Wed Jun 13 19:43:17 2007 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 13 Jun 2007 20:43:17 +0300 Subject: SPECS (AC-branch): spamassassin.spec - more -compile deps In-Reply-To: References: Message-ID: <200706132043.17167.glen@pld-linux.org> On Wednesday 13 June 2007 20:40:53 glen wrote: > Author: glen Date: Wed Jun 13 17:40:52 2007 GMT > Module: SPECS Tag: AC-branch > ---- Log message: > - more -compile deps > > ---- Files affected: > SPECS: > spamassassin.spec (1.125.2.1 -> 1.125.2.2) > > ---- Diffs: > > ================================================================ > Index: SPECS/spamassassin.spec > diff -u SPECS/spamassassin.spec:1.125.2.1 SPECS/spamassassin.spec:1.125.2.2 > --- SPECS/spamassassin.spec:1.125.2.1 Wed Jun 13 19:36:45 2007 > +++ SPECS/spamassassin.spec Wed Jun 13 19:40:47 2007 > @@ -146,6 +146,7 @@ > Summary: sa-compile - compile SpamAssassin ruleset into native code > Group: Applications/Mail > Requires: gcc > +Requires: glibc-headers > Requires: make > Requires: perl(ExtUtils::MakeMaker) > Requires: perl-Mail-SpamAssassin = %{version}-%{release} > @@ -338,6 +339,9 @@ maybe this dependency should be in perl-devel package instead? In file included from body_0.xs:2: /usr/lib/perl5/5.8.8/i686-pld-linux-thread-multi/CORE/perl.h:420:30: sys/types.h: No such file or directory /usr/lib/perl5/5.8.8/i686-pld-linux-thread-multi/CORE/perl.h:451:19: ctype.h: No such file or directory /usr/lib/perl5/5.8.8/i686-pld-linux-thread-multi/CORE/perl.h:463:23: locale.h: No such file or directory /usr/lib/perl5/5.8.8/i686-pld-linux-thread-multi/CORE/perl.h:480:20: setjmp.h: No such file or directory /usr/lib/perl5/5.8.8/i686-pld-linux-thread-multi/CORE/perl.h:486:26: sys/param.h: No such file or directory /usr/lib/perl5/5.8.8/i686-pld-linux-thread-multi/CORE/perl.h:491:23: stdlib.h: No such file or directory -- glen From n3npq at mac.com Wed Jun 13 20:16:28 2007 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 13 Jun 2007 14:16:28 -0400 Subject: rpm suggest backport? In-Reply-To: <200706132018.50170.glen@delfi.ee> References: <200706132018.50170.glen@delfi.ee> Message-ID: On Jun 13, 2007, at 1:18 PM, Elan Ruusam?e wrote: > can someone with enough rpm hackery mana backport or make rpm > ignore Suggests? > it would ease Th/Ac parallel developement. > > $ ./builder -g spamassassin > P spamassassin.spec > # $Revision: 1.127 $, $Date: 2007/05/11 16:48:16 $ > error: line 61: Unknown tag: Suggests: spamassassin-update > Error: package build failed. (no more info) > I don't know where the hack goes, but all that is needed for depsolvers with Suggests: is to ignore all Requires: marked with RPMSENSE_MISSINGOK set in dependency flags. Build failure with changed syntax are a different problem. Point me at whatever you are calling rpmbuild, and I will send you a teensy patch to parse and ignore the new-fangled Suggests: syntax. That's likely the most expedient hack, but backporting the full-blown RPMSENSE_MISSINGOK mechansim is certainly possible too. You can also just comment out the Suggests: line ;-) 73 de Jeff From glen at delfi.ee Wed Jun 13 20:29:56 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 13 Jun 2007 21:29:56 +0300 Subject: rpm suggest backport? In-Reply-To: References: <200706132018.50170.glen@delfi.ee> Message-ID: <200706132129.56361.glen@delfi.ee> On Wednesday 13 June 2007 21:16:28 Jeff Johnson wrote: > Build failure with changed syntax are a different problem. Point > me at whatever you are calling rpmbuild, and I will send > you a teensy patch to parse and ignore the new-fangled Suggests: > syntax. That's likely the most expedient hack, but backporting the > full-blown RPMSENSE_MISSINGOK mechansim is certainly > possible too. i just executed rpmbuild: $ /usr/bin/rpmbuild -bb spamassassin.spec; echo $? error: line 61: Unknown tag: Suggests: spamassassin-update 1 $ -- glen From n3npq at mac.com Wed Jun 13 20:34:34 2007 From: n3npq at mac.com (Jeff Johnson) Date: Wed, 13 Jun 2007 14:34:34 -0400 Subject: rpm suggest backport? In-Reply-To: <200706132129.56361.glen@delfi.ee> References: <200706132018.50170.glen@delfi.ee> <200706132129.56361.glen@delfi.ee> Message-ID: On Jun 13, 2007, at 2:29 PM, Elan Ruusam?e wrote: > On Wednesday 13 June 2007 21:16:28 Jeff Johnson wrote: >> Build failure with changed syntax are a different problem. Point >> me at whatever you are calling rpmbuild, and I will send >> you a teensy patch to parse and ignore the new-fangled Suggests: >> syntax. That's likely the most expedient hack, but backporting the >> full-blown RPMSENSE_MISSINGOK mechansim is certainly >> possible too. > > i just executed rpmbuild: > > $ /usr/bin/rpmbuild -bb spamassassin.spec; echo $? > error: line 61: Unknown tag: Suggests: spamassassin-update > 1 > $ > Send a URI to a relevant rpm-*.src.rpm, please, and I'll send you the patch to parse and ignore the new-fangled Suggests: syntax. 73 de Jeff From glen at delfi.ee Wed Jun 13 20:47:26 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 13 Jun 2007 21:47:26 +0300 Subject: rpm suggest backport? In-Reply-To: References: <200706132018.50170.glen@delfi.ee> <200706132129.56361.glen@delfi.ee> Message-ID: <200706132147.26603.glen@delfi.ee> On Wednesday 13 June 2007 21:34:34 Jeff Johnson wrote: > Send a URI to a relevant rpm-*.src.rpm, please, and I'll send you > the patch to parse and ignore the new-fangled Suggests: syntax. here: ftp://ftp.pld-linux.org/dists/ac/PLD/SRPMS/SRPMS/rpm-4.4.2-41.src.rpm thanks ahead :) -- glen From qboosh at pld-linux.org Thu Jun 14 21:09:39 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 14 Jun 2007 21:09:39 +0200 Subject: SPECS: libopensync.spec - update to 0.30 In-Reply-To: References: Message-ID: <20070614190939.GA31301@stranger.qboosh.pl> On Thu, Jun 14, 2007 at 09:05:40PM +0200, glen wrote: > +%scons \ > + prefix=%{_prefix} \ > + %{?with_python:enable_python=1} What about %{__cc} and %{rpmcflags}? -- Jakub Bogusz http://qboosh.pl/ From glen at delfi.ee Thu Jun 14 21:48:05 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Thu, 14 Jun 2007 22:48:05 +0300 Subject: SPECS: libopensync.spec - update to 0.30 In-Reply-To: <20070614190939.GA31301@stranger.qboosh.pl> References: <20070614190939.GA31301@stranger.qboosh.pl> Message-ID: <200706142248.06210.glen@delfi.ee> On Thursday 14 June 2007, Jakub Bogusz wrote: > On Thu, Jun 14, 2007 at 09:05:40PM +0200, glen wrote: > > +%scons \ > > + prefix=%{_prefix} \ > > + %{?with_python:enable_python=1} > > What about %{__cc} and %{rpmcflags}? those should came from %scons... apparently there's no portable/standard way (yet) to pass them? -- glen From gotar at polanet.pl Thu Jun 14 22:13:51 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Thu, 14 Jun 2007 22:13:51 +0200 Subject: SPECS: libopensync.spec - update to 0.30 In-Reply-To: <200706142248.06210.glen@delfi.ee> References: <20070614190939.GA31301@stranger.qboosh.pl> <200706142248.06210.glen@delfi.ee> Message-ID: <20070614201351.GA20153@pepin.polanet.pl> On Thu, Jun 14, 2007 at 10:48:05PM +0300, Elan Ruusam?e wrote: > > On Thu, Jun 14, 2007 at 09:05:40PM +0200, glen wrote: > > > +%scons \ > > > + prefix=%{_prefix} \ > > > + %{?with_python:enable_python=1} > > > > What about %{__cc} and %{rpmcflags}? > > those should came from %scons... apparently there's no portable/standard way > (yet) to pass them? No. But take a look at mysdl.spec, maybe this helps. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From n3npq at mac.com Thu Jun 14 22:39:58 2007 From: n3npq at mac.com (Jeff Johnson) Date: Thu, 14 Jun 2007 16:39:58 -0400 Subject: rpm suggest backport? In-Reply-To: <200706132147.26603.glen@delfi.ee> References: <200706132018.50170.glen@delfi.ee> <200706132129.56361.glen@delfi.ee> <200706132147.26603.glen@delfi.ee> Message-ID: <53320308-8800-41EE-AB8A-96EA31528990@mac.com> On Jun 13, 2007, at 2:47 PM, Elan Ruusam?e wrote: > On Wednesday 13 June 2007 21:34:34 Jeff Johnson wrote: >> Send a URI to a relevant rpm-*.src.rpm, please, and I'll send you >> the patch to parse and ignore the new-fangled Suggests: syntax. > > here: ftp://ftp.pld-linux.org/dists/ac/PLD/SRPMS/SRPMS/ > rpm-4.4.2-41.src.rpm > Here's most of what you need (I believe, untested): http://wraptastic.org/pub/jbj/rpm-4.4.2-suggests.patch (aside) I don't mind at all generating rpm patches. What is hard for me is getting vendorized rpm to build on the boxes I have access to, and to test vendor specific patches. E.g. it took me 10 times longer to build PLD's rpm than it took to generate the rather easy patch. So holler if the (untested) patch doesn't do what it is intended to do, ignore Suggests: et al. 73 de Jeff From glen at delfi.ee Thu Jun 14 23:13:38 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 15 Jun 2007 00:13:38 +0300 Subject: rpm suggest backport? In-Reply-To: <53320308-8800-41EE-AB8A-96EA31528990@mac.com> References: <200706132018.50170.glen@delfi.ee> <200706132147.26603.glen@delfi.ee> <53320308-8800-41EE-AB8A-96EA31528990@mac.com> Message-ID: <200706150013.39244.glen@delfi.ee> On Thursday 14 June 2007, Jeff Johnson wrote: > (aside) > I don't mind at all generating rpm patches. then it's not much to ask for patch that ignores uname() deps :) this would allow use package manager to upgrade PLD Ac -> PLD Th! > What is hard for me is getting vendorized rpm to build on the boxes I have access to, and to test vendor specific patches. i guess livecd + qemu would help out in such situations. -- glen From glen at delfi.ee Thu Jun 14 23:22:11 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 15 Jun 2007 00:22:11 +0300 Subject: rpm suggest backport? In-Reply-To: <200706150013.39244.glen@delfi.ee> References: <200706132018.50170.glen@delfi.ee> <53320308-8800-41EE-AB8A-96EA31528990@mac.com> <200706150013.39244.glen@delfi.ee> Message-ID: <200706150022.11936.glen@delfi.ee> On Friday 15 June 2007, Elan Ruusam?e wrote: > On Thursday 14 June 2007, Jeff Johnson wrote: > > (aside) > > I don't mind at all generating rpm patches. > > then it's not much to ask for patch that ignores uname() deps :) ok. nevermind. it's already there ;) http://cvs.pld-linux.org/SOURCES/rpm-cpuinfo.patch?r1=1.1&r2=1.2&f=u -- glen From glen at delfi.ee Thu Jun 14 23:23:09 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 15 Jun 2007 00:23:09 +0300 Subject: rpm suggest backport? In-Reply-To: <53320308-8800-41EE-AB8A-96EA31528990@mac.com> References: <200706132018.50170.glen@delfi.ee> <200706132147.26603.glen@delfi.ee> <53320308-8800-41EE-AB8A-96EA31528990@mac.com> Message-ID: <200706150023.10148.glen@delfi.ee> On Thursday 14 June 2007, Jeff Johnson wrote: > Here's most of what you need (I believe, untested): > > ? ? http://wraptastic.org/pub/jbj/rpm-4.4.2-suggests.patch rpm works, poldek works thx :) -- glen From mlukaszek at gmail.com Fri Jun 15 13:46:38 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Fri, 15 Jun 2007 13:46:38 +0200 Subject: [Th] multilib aware poldek? Message-ID: I've got gcc-{,-c++}-multilib installed, along with couple of i686 packages that are needed by nspluginwrapper. The problem is, each time I want to upgrade my x86_64 packages poldek complains about multiple packages installed (i686 and x86_64). So, to upgrade, I _uninstall_ all i686 packages, do an upgrade, and reinstall i686 packages again. This is getting boring..., so 1. Can poldek be told to ignore i686 packages in its checks? 2. I've got a minimal set of needed i686 packages downloaded to a directory. Is there any easy way to check if there are new versions of the packages in repo, and - if there are - download them and delete older? -- regards, Micha? ?ukaszek prism at pld-linux.org From patrys at pld-linux.org Fri Jun 15 14:46:57 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Fri, 15 Jun 2007 14:46:57 +0200 Subject: [Th] multilib aware poldek? In-Reply-To: References: Message-ID: <89b6ba3a0706150546g70804c8j355d06c917796699@mail.gmail.com> On 6/15/07, Micha? ?ukaszek wrote: > I've got gcc-{,-c++}-multilib installed, along with couple of i686 > packages that are needed by nspluginwrapper. > > The problem is, each time I want to upgrade my x86_64 packages poldek > complains about multiple packages installed (i686 and x86_64). > So, to upgrade, I _uninstall_ all i686 packages, do an upgrade, and > reinstall i686 packages again. This is getting boring..., so Try yum and yumex - these should handle it well. -- Patryk Zawadzki Generated Content From mlukaszek at gmail.com Fri Jun 15 22:25:14 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Fri, 15 Jun 2007 22:25:14 +0200 Subject: [Th] multilib aware poldek? In-Reply-To: <89b6ba3a0706150546g70804c8j355d06c917796699@mail.gmail.com> References: <89b6ba3a0706150546g70804c8j355d06c917796699@mail.gmail.com> Message-ID: On 6/15/07, Patryk Zawadzki wrote: > Try yum and yumex - these should handle it well. I tried, and I must admit that I've never seen so fsck-ed up application. When I first run it (yumex), after quite long time (comparing to poldek) I managed to get a list of packages that require update. Of course, update attempt caused rpm to complain about conflicting i686 packages (b/c they have to be updated too). So, I edited yum pld-source.repo and added two entries for th-multilib and th-test-multilib (i686), and, in effect, now I cannot even run yum (not to mention yumex). other.xml.gz 100% |=========================| 3.1 MB 01:09 th-arch : ##### 1142/10365Traceback (most recent call last): File "/usr/bin/yum", line 29, in yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 94, in main result, resultmsgs = base.doCommands() File "/usr/share/yum-cli/cli.py", line 264, in doCommands return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds) File "/usr/share/yum-cli/yumcommands.py", line 277, in doCommand base.repos.populateSack(mdtype='otherdata', cacheonly=1) File "/usr/share/python2.5/site-packages/../site-packages/yum/repos.py", line 206, in populateSack File "/usr/share/python2.5/site-packages/../site-packages/yum/yumRepo.py", line 166, in populate File "/usr/share/python2.5/site-packages/../site-packages/yum/sqlitecache.py", line 120, in getOtherdata File "/usr/share/python2.5/site-packages/../site-packages/yum/sqlitecache.py", line 104, in _getbase File "/usr/share/python2.5/site-packages/../site-packages/yum/sqlitecache.py", line 370, in updateSqliteCache File "/usr/share/python2.5/site-packages/../site-packages/yum/mdparser.py", line 61, in next File "", line 64, in __iter__ SyntaxError: not well-formed (invalid token): line 71508, column 20 Is this a problem with yum indexes on our servers (information about not well-formed xml suggests this), or with yum itself? -- regards, Micha? ?ukaszek prism at pld-linux.org From qboosh at pld-linux.org Sat Jun 16 16:36:29 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 16 Jun 2007 16:36:29 +0200 Subject: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ... In-Reply-To: References: Message-ID: <20070616143629.GA10761@stranger.qboosh.pl> On Thu, Jun 14, 2007 at 08:58:49AM +0200, hawk wrote: > +# build fix for intel network drivers for PPC > +Patch0: linux-2.6-ppc-ICE-hacks.patch It's not vanilla now ;P -- Jakub Bogusz http://qboosh.pl/ From hawk at limanowa.net Sat Jun 16 16:46:17 2007 From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=) Date: Sat, 16 Jun 2007 16:46:17 +0200 Subject: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ... In-Reply-To: <20070616143629.GA10761@stranger.qboosh.pl> References: <20070616143629.GA10761@stranger.qboosh.pl> Message-ID: <4673F7B9.7090802@limanowa.net> >> +# build fix for intel network drivers for PPC >> +Patch0: linux-2.6-ppc-ICE-hacks.patch > > It's not vanilla now ;P Yeah, true, but vanilla doesn't build on PPC :( M. From gotar at polanet.pl Sat Jun 16 17:40:52 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 16 Jun 2007 17:40:52 +0200 Subject: [th] qt4 problems Message-ID: <20070616154052.GA16077@pepin.polanet.pl> Hi, 1. closing any qt4 application (e.g. kpoldek) crashes entire X server, 2. qt4 doesn't honour fontocnfig setup (doesn't draw through freetype/cairo/Xft and I've got badly subpixeled fonts) - is it fourth rendering engine? -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From qboosh at pld-linux.org Sat Jun 16 17:41:55 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 16 Jun 2007 17:41:55 +0200 Subject: [th] qt4 problems In-Reply-To: <20070616154052.GA16077@pepin.polanet.pl> References: <20070616154052.GA16077@pepin.polanet.pl> Message-ID: <20070616154155.GA5240@stranger.qboosh.pl> On Sat, Jun 16, 2007 at 05:40:52PM +0200, Tomasz Pala wrote: > Hi, > > 1. closing any qt4 application (e.g. kpoldek) crashes entire X server, Doesn't occur with lastfm-radio for me. Qt*-4.3.0-1, xorg-xserver-server-1.3.0.0-2, HEAD xorg-driver-tdfx and xorg-lib*. -- Jakub Bogusz http://qboosh.pl/ From blues at pld-linux.org Sat Jun 16 17:54:21 2007 From: blues at pld-linux.org (Pawel Golaszewski) Date: Sat, 16 Jun 2007 17:54:21 +0200 (CEST) Subject: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ... In-Reply-To: <4673F7B9.7090802@limanowa.net> References: <20070616143629.GA10761@stranger.qboosh.pl> <4673F7B9.7090802@limanowa.net> Message-ID: On Sat, 16 Jun 2007, Marcin Kr??l wrote: > >> +# build fix for intel network drivers for PPC > >> +Patch0: linux-2.6-ppc-ICE-hacks.patch > > It's not vanilla now ;P > Yeah, true, but vanilla doesn't build on PPC :( But it's not vanila now :D -- pozdr. Pawel Golaszewski 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 hawk at limanowa.net Sat Jun 16 18:01:16 2007 From: hawk at limanowa.net (=?UTF-8?B?TWFyY2luIEtyw7Ns?=) Date: Sat, 16 Jun 2007 18:01:16 +0200 Subject: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ... In-Reply-To: References: <20070616143629.GA10761@stranger.qboosh.pl> <4673F7B9.7090802@limanowa.net> Message-ID: <4674094C.10504@limanowa.net> > But it's not vanila now :D How about replacing with sed instead of using patch? :) sed was used on makefiles anyway (for extraversion). M. From blues at pld-linux.org Sat Jun 16 18:13:56 2007 From: blues at pld-linux.org (Pawel Golaszewski) Date: Sat, 16 Jun 2007 18:13:56 +0200 (CEST) Subject: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ... In-Reply-To: <4674094C.10504@limanowa.net> References: <20070616143629.GA10761@stranger.qboosh.pl> <4673F7B9.7090802@limanowa.net> <4674094C.10504@limanowa.net> Message-ID: On Sat, 16 Jun 2007, Marcin Kr?l wrote: > > But it's not vanila now :D > How about replacing with sed instead of using patch? :) sed was used on > makefiles anyway (for extraversion). "vanilla" means "unmodified". And you are changing that kernel. Doesn't matter if it's cosmetics or not. No matter if it's patch or sed. It's just mine 0,03? about kernel-vanilla in general :D -- pozdr. Pawel Golaszewski 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 hawk at limanowa.net Sat Jun 16 18:18:26 2007 From: hawk at limanowa.net (=?UTF-8?B?TWFyY2luIEtyw7Ns?=) Date: Sat, 16 Jun 2007 18:18:26 +0200 Subject: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ... In-Reply-To: References: <20070616143629.GA10761@stranger.qboosh.pl> <4673F7B9.7090802@limanowa.net> <4674094C.10504@limanowa.net> Message-ID: <46740D52.6010309@limanowa.net> > "vanilla" means "unmodified". And you are changing that kernel. Doesn't > matter if it's cosmetics or not. No matter if it's patch or sed. Yes. I know all that. By my previous mail I was trying to say: "then it was never vanilla kernel" as sed was used to modify makefile since the first revision. M. From qboosh at pld-linux.org Sat Jun 16 20:01:23 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 16 Jun 2007 20:01:23 +0200 Subject: SPECS (AC-branch): spamassassin.spec - more -compile deps In-Reply-To: <200706132043.17167.glen@pld-linux.org> References: <200706132043.17167.glen@pld-linux.org> Message-ID: <20070616180123.GA1651@stranger.qboosh.pl> On Wed, Jun 13, 2007 at 08:43:17PM +0300, Elan Ruusam?e wrote: > On Wednesday 13 June 2007 20:40:53 glen wrote: [...] > > +Requires: glibc-headers > > Requires: make > > Requires: perl(ExtUtils::MakeMaker) > > Requires: perl-Mail-SpamAssassin = %{version}-%{release} > > @@ -338,6 +339,9 @@ > > maybe this dependency should be in perl-devel package instead? Well, in fact all *-devel packages with glibc-based C interfaces should require glibc-devel... (OC it can be omitted for *-devel which require *-devel already requiring glibc-devel) -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Sat Jun 16 20:19:37 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 16 Jun 2007 20:19:37 +0200 Subject: [webapps] PHP files owner In-Reply-To: <20070612235201.GB4696@pepin.polanet.pl> References: <20070603115904.GA12716@pepin.polanet.pl> <20070612235201.GB4696@pepin.polanet.pl> Message-ID: <20070616181937.GB1651@stranger.qboosh.pl> Just some notes... On Wed, Jun 13, 2007 at 01:52:01AM +0200, Tomasz Pala wrote: [...] > Assuming a bug in any webapp, e.g. seeking to any file or executing a > binary: > - safe_mode - as long as root is the owner, an attacker can read root's > files having o+r or (g=http)+r, e.g. /etc/passwd or files containing > database passwords: /etc/webapps/coppermine-gallery/config.inc.php, > /etc/webapps/mediawiki/AdminSettings.php, > /etc/webapps/phpMyAdmin/config.inc.php, /etc/webapps/phpwiki/config.ini, > /etc/webapps/stacks-wiki/db.php, /etc/webapps/zabbix/db.inc.php > Changing script owner makes safe_mode block this[1]. For now open_basedir > does it too, but as it is application-level security I don't trust it > (there were bugs) and IMHO it would be better to have them two work > together, > - suPHP and any other solution involving EUID changes - they are all > SUID and it's obvious, that the sooner they drop to ordinary user > (script owner) the better. Why give them a chance to stay and work > with EUID=0? And this time the threat is bigger (although the system > seems to be more secure! for users at least) - it includes not only > reading some files, but also executing a code with root priviledges. > > My conclusion: there are some paths of priviledges propagation from > script owners. However the risk is low and dependant of system > configuration, we shall avoid it. We should not trust separation above > operating system. > > [1] even more - we must set safe_mode_include_dir for every application > so that is could read it's configuration file. This way we are sure that > no other PHP script will have access. Actually safe_mode is application-level (interpreter-level) too, placed above operating system. And suPHP utilizes OS security (although it exposes higher risk in case of bug in its code running with EUID=0). -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Sat Jun 16 20:22:01 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 16 Jun 2007 20:22:01 +0200 Subject: [PLD 3.x (Th): Bug 23] binutils segfault Message-ID: <20070616182201.GA3407@stranger.qboosh.pl> Argh, resending. Could sb fix Reply-To address from pld-bugs list? (missing "lists." in domain part) On Sat, Jun 16, 2007 at 05:25:55PM +0200, btsadmin at pld-linux.org wrote: > http://bugs.pld-linux.org/show_bug.cgi?id=23 > > --- Comment #2 from Szymon Siwek 2007-06-16 17:25:55 --- > Not only similar it's the same problem. gdb shows identical backtrace Same with gdal/swig/ruby. Googled: http://www.mail-archive.com/debian-bugs-closed at lists.debian.org/msg124225.html After adding missing -fPIC flags SEGV is gone. (but binutils need fix anyway, as they shouldn't crash) -- Jakub Bogusz http://qboosh.pl/ From ab_1 at abram.eu.org Sat Jun 16 22:56:41 2007 From: ab_1 at abram.eu.org (Michal Abramowicz) Date: Sat, 16 Jun 2007 22:56:41 +0200 Subject: [PLD 3.x (Th): Bug 23] binutils segfault In-Reply-To: <20070616182201.GA3407@stranger.qboosh.pl> References: <20070616182201.GA3407@stranger.qboosh.pl> Message-ID: <20070616205641.GA8636@mail.batek.pl> On Sat, Jun 16, 2007 at 08:22:01PM +0200, Jakub Bogusz wrote: > Argh, resending. > Could sb fix Reply-To address from pld-bugs list? (missing "lists." in > domain part) fixed. ;-) -- Micha? Abramowicz abram pld - linux org From deejay1 at srem.org Sun Jun 17 10:28:57 2007 From: deejay1 at srem.org (=?iso-8859-2?q?=A3ukasz_Jerna=B6?=) Date: Sun, 17 Jun 2007 10:28:57 +0200 Subject: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ... In-Reply-To: <46740D52.6010309@limanowa.net> References: <46740D52.6010309@limanowa.net> Message-ID: <200706171028.58764.deejay1@srem.org> Dnia sobota, 16 czerwca 2007, Marcin Kr?l napisa?: > > "vanilla" means "unmodified". And you are changing that kernel. Doesn't > > matter if it's cosmetics or not. No matter if it's patch or sed. > > Yes. I know all that. By my previous mail I was trying to say: "then it > was never vanilla kernel" as sed was used to modify makefile since the > first revision. mv kernel-vanilla.spec kernel-millivanilli.spec on the CVS side? ;) -- ?ukasz [DeeJay1] Jerna? From glen at delfi.ee Sun Jun 17 15:20:03 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Sun, 17 Jun 2007 16:20:03 +0300 Subject: SPECS (AC-branch): spamassassin.spec - more -compile deps In-Reply-To: <20070616180123.GA1651@stranger.qboosh.pl> References: <200706132043.17167.glen@pld-linux.org> <20070616180123.GA1651@stranger.qboosh.pl> Message-ID: <200706171620.03985.glen@delfi.ee> On Saturday 16 June 2007, Jakub Bogusz wrote: > On Wed, Jun 13, 2007 at 08:43:17PM +0300, Elan Ruusam?e wrote: > > On Wednesday 13 June 2007 20:40:53 glen wrote: > > [...] > > > > +Requires: glibc-headers > > > Requires: make > > > Requires: perl(ExtUtils::MakeMaker) > > > Requires: perl-Mail-SpamAssassin = %{version}-%{release} > > > @@ -338,6 +339,9 @@ > > > > maybe this dependency should be in perl-devel package instead? > > Well, in fact all *-devel packages with glibc-based C interfaces should > require glibc-devel... yes that was fixed later. but the actual question was, should the glibc-devel dep be in sa-compile or perl-devel package? i see two points: - in perl-devel because the perl-devel headers use glibc-headers, - in sa-devel because sa-devel actually invokdes gcc while perl-devel you might need for some other reason. > (OC it can be omitted for *-devel which require *-devel already requiring > glibc-devel) -- glen From qboosh at pld-linux.org Sun Jun 17 17:41:19 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 17 Jun 2007 17:41:19 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: References: Message-ID: <20070617154118.GA29295@stranger.qboosh.pl> On Tue, Jun 05, 2007 at 05:20:07PM +0200, czarny wrote: > Author: czarny Date: Tue Jun 5 15:20:07 2007 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - with python, ruby and tcl by default IIRC this makes vim binary depend on python, ruby and tcl libraries. Is it worth its profits? -- Jakub Bogusz http://qboosh.pl/ From wrobell at pld-linux.org Sun Jun 17 18:55:12 2007 From: wrobell at pld-linux.org (wrobell) Date: Sun, 17 Jun 2007 17:55:12 +0100 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <20070617154118.GA29295@stranger.qboosh.pl> References: <20070617154118.GA29295@stranger.qboosh.pl> Message-ID: <20070617165512.GE3615@borg> On Sun, Jun 17, 2007 at 05:41:19PM +0200, Jakub Bogusz wrote: > On Tue, Jun 05, 2007 at 05:20:07PM +0200, czarny wrote: > > Author: czarny Date: Tue Jun 5 15:20:07 2007 GMT > > Module: SPECS Tag: HEAD > > ---- Log message: > > - with python, ruby and tcl by default > > IIRC this makes vim binary depend on python, ruby and tcl libraries. > Is it worth its profits? imho it should be off by default. if one wants fat vim, then please create vim-enahnced/vim-fat/whatever packages. regards, wrobell From dhubleizh at o2.pl Sun Jun 17 21:45:54 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Sun, 17 Jun 2007 21:45:54 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <20070617165512.GE3615@borg> References: <20070617154118.GA29295@stranger.qboosh.pl> <20070617165512.GE3615@borg> Message-ID: <1182109554.3339.0.camel@ipv6-localnet> Dnia 17-06-2007, N o godzinie 17:55 +0100, wrobell napisa?(a): > imho it should be off by default. if one wants fat vim, then please create > vim-enahnced/vim-fat/whatever packages. 1. What is fat? perl is fat for me, python not and it was on by default 2. Vim static is the choice for slim solutions. Cz at rny From qboosh at pld-linux.org Sun Jun 17 22:02:45 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 17 Jun 2007 22:02:45 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <1182109554.3339.0.camel@ipv6-localnet> References: <20070617154118.GA29295@stranger.qboosh.pl> <20070617165512.GE3615@borg> <1182109554.3339.0.camel@ipv6-localnet> Message-ID: <20070617200245.GA29050@stranger.qboosh.pl> On Sun, Jun 17, 2007 at 09:45:54PM +0200, Cezary Krzyzanowski wrote: > Dnia 17-06-2007, N o godzinie 17:55 +0100, wrobell napisa?(a): > > > imho it should be off by default. if one wants fat vim, then please create > > vim-enahnced/vim-fat/whatever packages. > > 1. What is fat? perl is fat for me, python not and it was on by default > 2. Vim static is the choice for slim solutions. Just for the record: $ rpm -q --qf '%-12{NAME}: %{SIZE}\n' perl-base python-libs ruby tcl vim-rt perl-base : 2936355 python-libs : 1828755 ruby : 1094668 tcl : 4306684 vim-rt : 14952921 (assuming that libs packages suffice to run vim without complaints) But the original question was: do particular language support overhead is worth its benefits? Are there already some packaged or custom vim addons which need all these languages? -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Sun Jun 17 23:42:22 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sun, 17 Jun 2007 23:42:22 +0200 Subject: NEW poldek 0.20070617.23 - please test Message-ID: <200706172342.23069.arekm@maven.pl> Hello, New poldek snap (0.20070617.23) was sent to Th builders. It has improvements in handling package colors and *tadam* multilib capabilities. Please test :) -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From wolf.pld at gmail.com Mon Jun 18 00:16:26 2007 From: wolf.pld at gmail.com (Bartosz Taudul) Date: Mon, 18 Jun 2007 00:16:26 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <200706172342.23069.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> Message-ID: <20070617221626.GA16226@bajzel> On Sun, Jun 17, 2007 at 11:42:22PM +0200, Arkadiusz Miskiewicz wrote: > New poldek snap (0.20070617.23) was sent to Th builders. It has improvements > in handling package colors and *tadam* multilib capabilities. > > Please test :) b??d: libxslt-1.1.21-1.athlon package color (0) is not equal to libxslt-1.1.21-1.athlon.rpm's one (1) b??d: libxslt-progs-1.1.21-1.athlon package color (0) is not equal to libxslt-progs-1.1.21-1.athlon.rpm's one (1) There were package coloring mismatches. Proceed? [y/N] wolf -- Bartek . Taudul : .:.................................................................... w o l f @ p l d - l i n u x . o r g .:. http://wolf.valkyrie.one.pl/ From wiget at pld-linux.org Mon Jun 18 02:08:59 2007 From: wiget at pld-linux.org (Artur Frysiak) Date: Mon, 18 Jun 2007 02:08:59 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <20070617221626.GA16226@bajzel> References: <200706172342.23069.arekm@maven.pl> <20070617221626.GA16226@bajzel> Message-ID: 2007/6/18, Bartosz Taudul : > On Sun, Jun 17, 2007 at 11:42:22PM +0200, Arkadiusz Miskiewicz wrote: > > New poldek snap (0.20070617.23) was sent to Th builders. It has improvements > > in handling package colors and *tadam* multilib capabilities. > > > > Please test :) > b??d: libxslt-1.1.21-1.athlon package color (0) is not equal to libxslt-1.1.21-1.athlon.rpm's one (1) > b??d: libxslt-progs-1.1.21-1.athlon package color (0) is not equal to libxslt-progs-1.1.21-1.athlon.rpm's one (1) > There were package coloring mismatches. Proceed? [y/N] > touch /var/lib/rpm/Packages and re-run poldek. Regards -- Artur Frysiak From arekm at maven.pl Mon Jun 18 08:05:01 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 18 Jun 2007 08:05:01 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <20070617221626.GA16226@bajzel> References: <200706172342.23069.arekm@maven.pl> <20070617221626.GA16226@bajzel> Message-ID: <200706180805.01702.arekm@maven.pl> On Monday 18 of June 2007, Bartosz Taudul wrote: > On Sun, Jun 17, 2007 at 11:42:22PM +0200, Arkadiusz Miskiewicz wrote: > > New poldek snap (0.20070617.23) was sent to Th builders. It has > > improvements in handling package colors and *tadam* multilib > > capabilities. > > > > Please test :) > > b??d: libxslt-1.1.21-1.athlon package color (0) is not equal to > libxslt-1.1.21-1.athlon.rpm's one (1) b??d: libxslt-progs-1.1.21-1.athlon > package color (0) is not equal to libxslt-progs-1.1.21-1.athlon.rpm's one > (1) There were package coloring mismatches. Proceed? [y/N] > > wolf Not sure what's the problem but there is one important thing with new poldek - fetch ALL indexes from scratch using that new poldek. There was bug in poldek that prevented colors from being properly propagated. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Mon Jun 18 08:45:52 2007 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Mon, 18 Jun 2007 09:45:52 +0300 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <20070617200245.GA29050@stranger.qboosh.pl> References: <1182109554.3339.0.camel@ipv6-localnet> <20070617200245.GA29050@stranger.qboosh.pl> Message-ID: <200706180945.52851.glen@pld-linux.org> On Sunday 17 June 2007, Jakub Bogusz wrote: > On Sun, Jun 17, 2007 at 09:45:54PM +0200, Cezary Krzyzanowski wrote: > > Dnia 17-06-2007, N o godzinie 17:55 +0100, wrobell napisa?(a): > > > imho it should be off by default. if one wants fat vim, then please > > > create vim-enahnced/vim-fat/whatever packages. > > > > 1. What is fat? perl is fat for me, python not and it was on by default > > 2. Vim static is the choice for slim solutions. > > Just for the record: > > $ rpm -q --qf '%-12{NAME}: %{SIZE}\n' perl-base python-libs ruby tcl vim-rt > perl-base : 2936355 vim needs just perl-libs (at least on AC) -- $ rpm -q --qf '%-12{NAME}: %{SIZE}\n' perl-libs perl-libs : 1146552 vim works with just perl-libs, but do the perl functions actually work -- no idea never used language bindings. > python-libs : 1828755 > ruby : 1094668 > tcl : 4306684 > vim-rt : 14952921 > > (assuming that libs packages suffice to run vim without complaints) > > But the original question was: do particular language support overhead is > worth its benefits? i believe not. > Are there already some packaged or custom vim addons which need all these > languages? afaik none. the language bindings should be dynamic -- loaded at runtime if needed that would be sane solution :) seems currently impossible as the code is full of #ifdef FEAT_ -- glen From radek at pld-linux.org Mon Jun 18 09:11:39 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 18 Jun 2007 09:11:39 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <200706180945.52851.glen@pld-linux.org> References: <1182109554.3339.0.camel@ipv6-localnet> <20070617200245.GA29050@stranger.qboosh.pl> <200706180945.52851.glen@pld-linux.org> Message-ID: <20070618071139.GC3314@bzium> Elan Ruusam?e [18-06-2007 08:45]: [...] > vim needs just perl-libs (at least on AC) -- > $ rpm -q --qf '%-12{NAME}: %{SIZE}\n' perl-libs > perl-libs : 1146552 What's that? Why has it been separated? 1. Is there a considerable amount of applications it's enough for? 2. Is there a single one? > vim works with just perl-libs, but do the perl functions actually work -- no > idea never used language bindings. It should *work* (like, execute something basic), but I doubt it's usable; a single "use strict" requires perl-base. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zswi at pers.pl Mon Jun 18 09:15:03 2007 From: zswi at pers.pl (=?utf-8?q?Rafa=C5=82_Cygnarowski?=) Date: Mon, 18 Jun 2007 09:15:03 +0200 Subject: [th] qt4 problems In-Reply-To: <20070616154052.GA16077@pepin.polanet.pl> References: <20070616154052.GA16077@pepin.polanet.pl> Message-ID: <200706180915.03756.zswi@pers.pl> Dnia sobota, 16 czerwca 2007, Tomasz Pala napisa?: > Hi, > > 1. closing any qt4 application (e.g. kpoldek) crashes entire X server, > 2. qt4 doesn't honour fontocnfig setup (doesn't draw through > freetype/cairo/Xft and I've got badly subpixeled fonts) - is it fourth > rendering engine? I didn't seen such behaviour. What Qt4 version you use? What is your xorg*drivers*? What about your freetype/cairo/Xft? Regards, -- Rafa? Cygnarowski rafi at pers.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From glen at delfi.ee Mon Jun 18 09:22:57 2007 From: glen at delfi.ee (Elan =?iso-8859-15?q?Ruusam=E4e?=) Date: Mon, 18 Jun 2007 10:22:57 +0300 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <20070618071139.GC3314@bzium> References: <200706180945.52851.glen@pld-linux.org> <20070618071139.GC3314@bzium> Message-ID: <200706181022.57299.glen@delfi.ee> On Monday 18 June 2007, Radoslaw Zielinski wrote: > Elan Ruusam?e [18-06-2007 08:45]: > [...] > > > vim needs just perl-libs (at least on AC) -- > > $ rpm -q --qf '%-12{NAME}: %{SIZE}\n' perl-libs > > perl-libs : 1146552 > > What's that? Why has it been separated? to make vim deps smaller :) (think: vservers where you like to use vim) > 1. Is there a considerable amount of applications it's enough for? > 2. Is there a single one? > > > vim works with just perl-libs, but do the perl functions actually work -- > > no idea never used language bindings. > > It should *work* (like, execute something basic), but I doubt it's > usable; a single "use strict" requires perl-base. exactly, it was done just to cut down perl-base dep :) if you need perl bindings, install (additionally) perl-base + other modules you need -- glen From dhubleizh at o2.pl Mon Jun 18 10:24:21 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Mon, 18 Jun 2007 10:24:21 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <20070617200245.GA29050@stranger.qboosh.pl> References: <20070617154118.GA29295@stranger.qboosh.pl> <20070617165512.GE3615@borg> <1182109554.3339.0.camel@ipv6-localnet> <20070617200245.GA29050@stranger.qboosh.pl> Message-ID: <1182155062.3602.6.camel@ipv6-localnet> Dnia 17-06-2007, N o godzinie 22:02 +0200, Jakub Bogusz napisa?(a): > But the original question was: do particular language support overhead is > worth its benefits? > Are there already some packaged or custom vim addons which need all these > languages? 1. I use vim to develop python code and the bindings are good. 2. I got some plugins from vim.org that assist. I've got so many of them I actually am afraid to try packaging them for PLD as I'm not sure I'll recognize now all the plugins in my ~/.vim dir. 3. PLD is doing the maximum functionality maximum deps packages. Think OO. For all the minimum requirements there's always vim-static and e3. Cz at rny From gotar at polanet.pl Mon Jun 18 11:15:44 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 18 Jun 2007 11:15:44 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <200706180945.52851.glen@pld-linux.org> References: <1182109554.3339.0.camel@ipv6-localnet> <20070617200245.GA29050@stranger.qboosh.pl> <200706180945.52851.glen@pld-linux.org> Message-ID: <20070618091544.GB19155@pepin.polanet.pl> On Mon, Jun 18, 2007 at 09:45:52AM +0300, Elan Ruusam?e wrote: > > the language bindings should be dynamic -- loaded at runtime if needed that > would be sane solution :) So there should be packages having only libs required by vim to start (ldd =vim, and I mean only libs with no other bloat) - just like perl-libs, unusable other way. It's inadmissible for vim to require dozen of MB like it was some time ago with ruby (40MB). BTW dynamic vim-minimal should be nice too. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From loc at toya.net.pl Mon Jun 18 12:16:37 2007 From: loc at toya.net.pl (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=) Date: Mon, 18 Jun 2007 12:16:37 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <1182155062.3602.6.camel@ipv6-localnet> References: <20070617154118.GA29295@stranger.qboosh.pl> <20070617165512.GE3615@borg> <1182109554.3339.0.camel@ipv6-localnet> <20070617200245.GA29050@stranger.qboosh.pl> <1182155062.3602.6.camel@ipv6-localnet> Message-ID: <46765B85.60709@toya.net.pl> Cezary Krzyzanowski wrote: > 1. I use vim to develop python code and the bindings are good. > 2. I got some plugins from vim.org that assist. I've got so many of them > I actually am afraid to try packaging them for PLD as I'm not sure I'll > recognize now all the plugins in my ~/.vim dir. Are there really using the Python bindings or just manage Python code using the built-in language? (I think the latter is more likely) -- regards, Jakub Piotr C?apa From mlukaszek at gmail.com Mon Jun 18 12:53:10 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Mon, 18 Jun 2007 12:53:10 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <200706172342.23069.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> Message-ID: On 6/17/07, Arkadiusz Miskiewicz wrote: > in handling package colors and *tadam* multilib capabilities. > Please test :) poldek:/all-avail> lli glibc* iconv* expat* pakiet data zbudowania rozmiar expat-2.0.0-3.i686 2006/11/21 16:12 151.0 KB expat-2.0.0-3.x86_64 2006/11/21 17:16 175.0 KB expat-devel-2.0.0-3.x86_64 2006/11/21 17:16 136.0 KB glibc-2.6-3.i686 2007/06/04 10:04 2.6 MB glibc-2.6-3.x86_64 2007/06/04 09:53 3.2 MB glibc-devel-2.6-3.i686 2007/06/04 10:04 296.0 KB glibc-devel-2.6-3.x86_64 2007/06/04 09:53 427.0 KB glibc-devel-utils-2.6-3.x86_64 2007/06/04 09:53 66.0 KB glibc-headers-2.6-3.x86_64 2007/06/04 09:53 2.0 MB glibc-misc-2.6-3.x86_64 2007/06/04 09:53 3.8 MB iconv-2.6-3.x86_64 2007/06/04 09:53 5.9 MB 11 pakiet?w, 18.7 MB poldek:/all-avail> llu glibc* iconv* expat* dost?pny zainstalowany data zbudowania rozmiar expat-2.0.1-1.i686 2.0.0-3.i686 2007/06/14 20:12 152.0 KB expat-2.0.1-1.x86_64 2.0.0-3.x86_64 2007/06/14 19:06 174.0 KB expat-devel-2.0.1-1.x86_64 2.0.0-3.x86_64 2007/06/14 19:06 136.0 KB glibc-2.6-4.i686 2.6-3.i686 2007/06/17 18:11 2.6 MB glibc-2.6-4.x86_64 2.6-3.x86_64 2007/06/17 17:59 3.2 MB glibc-2.6-5.i686 2.6-3.i686 2007/06/18 00:39 2.6 MB glibc-2.6-5.x86_64 2.6-3.x86_64 2007/06/18 00:31 3.2 MB glibc-devel-2.6-4.i686 2.6-3.i686 2007/06/17 18:11 296.0 KB glibc-devel-2.6-4.x86_64 2.6-3.x86_64 2007/06/17 17:59 427.0 KB glibc-devel-2.6-5.i686 2.6-3.i686 2007/06/18 00:39 296.0 KB glibc-devel-2.6-5.x86_64 2.6-3.x86_64 2007/06/18 00:31 427.0 KB glibc-devel-utils-2.6-4.x86_64 2.6-3.x86_64 2007/06/17 17:59 66.0 KB glibc-devel-utils-2.6-5.x86_64 2.6-3.x86_64 2007/06/18 00:31 66.0 KB glibc-headers-2.6-4.x86_64 2.6-3.x86_64 2007/06/17 17:59 2.0 MB glibc-headers-2.6-5.x86_64 2.6-3.x86_64 2007/06/18 00:31 2.0 MB glibc-misc-2.6-4.x86_64 2.6-3.x86_64 2007/06/17 17:59 3.8 MB glibc-misc-2.6-5.x86_64 2.6-3.x86_64 2007/06/18 00:31 3.8 MB iconv-2.6-4.x86_64 2.6-3.x86_64 2007/06/17 17:59 5.9 MB iconv-2.6-5.x86_64 2.6-3.x86_64 2007/06/18 00:31 5.9 MB 19 pakiet?w, 36.9 MB poldek:/all-avail> upgrade * Przetwarzanie zale?no?ci... glibc-devel-2.6-3.i686 zostanie zast?piony przez glibc-devel-2.6-5.i686 glibc-devel-2.6-5.i686 zaznaczy? glibc-devel-utils-2.6-5.x86_64 (w?. glibc-devel-utils = 6:2.6-5) glibc-devel-utils-2.6-3.x86_64 zostanie zast?piony przez glibc-devel-utils-2.6-5.x86_64 greedy upgrade glibc-devel-2.6-3.x86_64 to 2.6-5.x86_64 (unresolved glibc-devel-utils = 6:2.6-3) glibc-devel-2.6-3.x86_64 zostanie zast?piony przez glibc-devel-2.6-5.x86_64 glibc-devel-2.6-5.x86_64 zaznaczy? glibc-headers-2.6-5.x86_64 (w?. glibc-headers = 6:2.6-5) glibc-headers-2.6-3.x86_64 zostanie zast?piony przez glibc-headers-2.6-5.x86_64 glibc-2.6-3.i686 zostanie zast?piony przez glibc-2.6-5.i686 glibc-2.6-5.i686 zaznaczy? glibc-misc-2.6-5.x86_64 (w?. glibc-misc = 6:2.6-5) glibc-misc-2.6-3.x86_64 zostanie zast?piony przez glibc-misc-2.6-5.x86_64 greedy upgrade glibc-2.6-3.x86_64 to 2.6-5.x86_64 (unresolved glibc-misc = 6:2.6-3) glibc-2.6-3.x86_64 zostanie zast?piony przez glibc-2.6-5.x86_64 greedy upgrade localedb-src-2.6-3.x86_64 to 2.6-5.x86_64 (unresolved glibc = 6:2.6-3) localedb-src-2.6-3.x86_64 zostanie zast?piony przez localedb-src-2.6-5.x86_64 Zaznaczono 8 pakiet?w do instalacji (6 zaznaczonych po?rednio), 8 do usuni?cia: I glibc-2.6-5.i686, glibc-devel-2.6-5.i686 D glibc-2.6-5.x86_64, glibc-devel-2.6-5.x86_64, glibc-devel-utils-2.6-5.x86_64, glibc-headers-2.6-5.x86_64, glibc-misc-2.6-5.x86_64, D localedb-src-2.6-5.x86_64 R localedb-src-2.6-3.x86_64, glibc-devel-2.6-3.x86_64, glibc-devel-utils-2.6-3.x86_64, glibc-2.6-3.x86_64, glibc-headers-2.6-3.x86_64, R glibc-misc-2.6-3.x86_64, glibc-2.6-3.i686, glibc-devel-2.6-3.i686 Potrzeba pobra? 6.6MB archiw. Po rozpakowaniu 20.4MB b?dzie u?yte. Uruchamianie sudo /bin/rpm --upgrade -vh --root / --noorder... b??d: Niespe?nione zale?no?ci: glibc = 6:2.6-3 jest wymagany przez (zainstalowany) iconv-2.6-3.x86_64 Installing set #2 Przetwarzanie zale?no?ci... expat-2.0.0-3.i686 zostanie zast?piony przez expat-2.0.1-1.i686 Zaznaczono 1 pakiet do instalacji, 1 do usuni?cia: I expat-2.0.1-1.i686 R expat-2.0.0-3.i686 Potrzeba pobra? 66.7KB archiw. Po rozpakowaniu 152.1KB b?dzie u?yte. Uruchamianie sudo /bin/rpm --upgrade -vh --root / --noorder... Przygotowywanie... ########################################### [100%] plik /usr/share/man/man1/xmlwf.1.gz z instalacji expat-2.0.1-1.i686 jest w konflikcie z plikiem z pakietu expat-2.0.0-3.x86_64 Wyst?pi?y b??dy podczas instalacji -- pozdrawiam, Micha? ?ukaszek prism at pld-linux.org From ankry at green.mif.pg.gda.pl Mon Jun 18 14:06:39 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Mon, 18 Jun 2007 14:06:39 +0200 (CEST) Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <1182155062.3602.6.camel@ipv6-localnet> References: <20070617154118.GA29295@stranger.qboosh.pl> <20070617165512.GE3615@borg> <1182109554.3339.0.camel@ipv6-localnet> <20070617200245.GA29050@stranger.qboosh.pl> <1182155062.3602.6.camel@ipv6-localnet> Message-ID: On Mon, 18 Jun 2007, Cezary Krzyzanowski wrote: > 3. PLD is doing the maximum functionality maximum deps packages. Think Unless the dependencies are small, are almost always used by sth. else in the system, or provide functionality required by most of users. Not this case. > OO. For all the minimum requirements there's always vim-static and e3. -static is in contradiction with minimum. -- ======================================================================= 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 mmazur at kernel.pl Mon Jun 18 14:20:27 2007 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 18 Jun 2007 14:20:27 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: References: <1182155062.3602.6.camel@ipv6-localnet> Message-ID: <200706181420.27425.mmazur@kernel.pl> Dnia poniedzia?ek, 18 czerwca 2007, Andrzej Krzysztofowicz napisa?: > > OO. For all the minimum requirements there's always vim-static and e3. > > -static is in contradiction with minimum. Yup. We should have full vim with everything (X, python, perl, ruby, brainfuck, you name it) and a vim-minimal for those, that want to have the lightest version possible. -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde From jajcus at jajcus.net Mon Jun 18 15:10:38 2007 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 18 Jun 2007 15:10:38 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <200706181420.27425.mmazur@kernel.pl> References: <1182155062.3602.6.camel@ipv6-localnet> <200706181420.27425.mmazur@kernel.pl> Message-ID: <20070618131038.GA15759@jajo.eggsoft.pl> On Mon, Jun 18, 2007 at 02:20:27PM +0200, Mariusz Mazur wrote: > Yup. We should have full vim with everything (X, python, perl, ruby, > brainfuck, you name it) and a vim-minimal for those, that want to have the > lightest version possible. It is not that easy... one needs minimum VIM (imagine: to be booted from a pendrive anywhere), just for writing human-readable text... that means: not GUI, no syntax highliting, no built-in interpreters... but a spell-checker is a requirement. Other may use VIM only for writting configuration files (e.g. router set on a constrained hardware) and scripts, syntax highliting is one of the most important feature then... I think I had problem trying to use vim-static (our "minimal but static", no syntax highliting AFAIR) or nvi (not VIM at all, so a lot of functionality is missing) in such cases. It is a pity VIM doesn't support binary plugins (that would be the right solution for the interpreters problem)... Fortunately some heavy functionality may be partitioned by splitting vim-rt package. Greets, Jacek From mmazur at kernel.pl Mon Jun 18 15:14:50 2007 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 18 Jun 2007 15:14:50 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <20070618131038.GA15759@jajo.eggsoft.pl> References: <200706181420.27425.mmazur@kernel.pl> <20070618131038.GA15759@jajo.eggsoft.pl> Message-ID: <200706181514.50691.mmazur@kernel.pl> Dnia poniedzia?ek, 18 czerwca 2007, Jacek Konieczny napisa?: > On Mon, Jun 18, 2007 at 02:20:27PM +0200, Mariusz Mazur wrote: > > Yup. We should have full vim with everything (X, python, perl, ruby, > > brainfuck, you name it) and a vim-minimal for those, that want to have > > the lightest version possible. > > It is not that easy... one needs minimum VIM (imagine: to be booted from > a pendrive anywhere), just for writing human-readable text... that > means: not GUI, no syntax highliting, no built-in interpreters... but a > spell-checker is a requirement. Not really. Minimal in this case means -- minimal set of deps. Meaning maximum functionality with minimal deps. So having a few 50kb libs might be ok. Depending on python, ruby and perl ain't. -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde From arekm at maven.pl Mon Jun 18 15:35:32 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 18 Jun 2007 15:35:32 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: References: <200706172342.23069.arekm@maven.pl> Message-ID: <200706181535.32153.arekm@maven.pl> On Monday 18 of June 2007, Micha? ?ukaszek wrote: > On 6/17/07, Arkadiusz Miskiewicz wrote: > > in handling package colors and *tadam* multilib capabilities. > > Please test :) > > poldek:/all-avail> lli glibc* iconv* expat* > pakiet Try newer snapshot 20070618.11 and report back. It has some important fixes. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Mon Jun 18 15:42:46 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 18 Jun 2007 15:42:46 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <200706181535.32153.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> <200706181535.32153.arekm@maven.pl> Message-ID: <200706181542.46475.arekm@maven.pl> On Monday 18 of June 2007, Arkadiusz Miskiewicz wrote: > On Monday 18 of June 2007, Micha? ?ukaszek wrote: > > On 6/17/07, Arkadiusz Miskiewicz wrote: > > > in handling package colors and *tadam* multilib capabilities. > > > Please test :) > > > > poldek:/all-avail> lli glibc* iconv* expat* > > pakiet > > Try newer snapshot 20070618.11 and report back. It has some important > fixes. Actually I'm not so sure that's poldek bug. rpm -q expat ? -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From mlukaszek at gmail.com Mon Jun 18 15:46:25 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Mon, 18 Jun 2007 15:46:25 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <200706181542.46475.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> <200706181535.32153.arekm@maven.pl> <200706181542.46475.arekm@maven.pl> Message-ID: On 6/18/07, Arkadiusz Miskiewicz wrote: > > Try newer snapshot 20070618.11 and report back. It has some important > > fixes. > > Actually I'm not so sure that's poldek bug. > > rpm -q expat ? $ rpm -q expat poldek expat-2.0.0-3.x86_64 expat-2.0.0-3.i686 poldek-0.20.1-0.20070617.23.x86_64 I'll try newer poldek in a minute. -- regards, Micha? ?ukaszek prism at pld-linux.org From mlukaszek at gmail.com Mon Jun 18 16:13:12 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Mon, 18 Jun 2007 16:13:12 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: References: <200706172342.23069.arekm@maven.pl> <200706181535.32153.arekm@maven.pl> <200706181542.46475.arekm@maven.pl> Message-ID: On 6/18/07, Micha? ?ukaszek wrote: > > Actually I'm not so sure that's poldek bug. > > > > rpm -q expat ? > > $ rpm -q expat poldek > expat-2.0.0-3.x86_64 > expat-2.0.0-3.i686 > poldek-0.20.1-0.20070617.23.x86_64 > > I'll try newer poldek in a minute. With new poldek I managed to update glibc and company, but still no progress for expat. And the following behavio[u]r suprises me: poldek:/all-avail> llu available installed build date size boost-filesystem-1.34.0-0.1.x86_64 1.33.1-10.x86_64 2007/06/17 14:16 52.0 KB boost-regex-1.34.0-0.1.x86_64 1.33.1-10.x86_64 2007/06/17 14:16 567.0 KB expat-2.0.1-1.i686 2.0.0-3.i686 2007/06/14 20:12 152.0 KB expat-2.0.1-1.x86_64 2.0.0-3.x86_64 2007/06/14 19:06 174.0 KB expat-devel-2.0.1-1.x86_64 2.0.0-3.x86_64 2007/06/14 19:06 136.0 KB libsmbclient-3.0.25a-1.x86_64 3.0.24-3.x86_64 2007/06/17 16:41 4.3 MB libsmbclient-3.0.25a-2.x86_64 3.0.24-3.x86_64 2007/06/17 18:15 4.3 MB libwpd-0.8.10-1.x86_64 0.8.9-1.x86_64 2007/06/17 22:18 662.0 KB libxml2-2.6.29-1.x86_64 2.6.28-1.x86_64 2007/06/17 22:10 1.5 MB libxml2-devel-2.6.29-1.x86_64 2.6.28-1.x86_64 2007/06/17 22:10 3.4 MB libxml2-progs-2.6.29-1.x86_64 2.6.28-1.x86_64 2007/06/17 22:10 72.0 KB libxslt-1.1.21-1.x86_64 1.1.20-1.x86_64 2007/06/17 22:13 374.0 KB libxslt-devel-1.1.21-1.x86_64 1.1.20-1.x86_64 2007/06/17 22:13 1.5 MB libxslt-progs-1.1.21-1.x86_64 1.1.20-1.x86_64 2007/06/17 22:13 21.0 KB python-libxml2-2.6.29-1.x86_64 2.6.28-1.x86_64 2007/06/17 22:10 881.0 KB 15 packages, 17.9 MB poldek:/all-avail> upgrade * Processing dependencies... expat-2.0.0-3.i686 obsoleted by expat-2.0.1-1.i686 There are 1 package to install, 1 to uninstall: I expat-2.0.1-1.i686 R expat-2.0.0-3.i686 Need to get 66.7KB of archives. After unpacking 152.1KB will be used. Executing sudo /bin/rpm --upgrade -vh --root / --noorder... Preparing... ########################################### [100%] file /usr/share/man/man1/xmlwf.1.gz from install of expat-2.0.1-1.i686 conflicts with file from package expat-2.0.0-3.x86_64 There were errors poldek:/all-avail> Why "updatable" list differs from the list of packages that are being attempted to update? -- regards, Micha? ?ukaszek prism at pld-linux.org From arekm at maven.pl Mon Jun 18 16:18:56 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 18 Jun 2007 16:18:56 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: References: <200706172342.23069.arekm@maven.pl> Message-ID: <200706181618.56658.arekm@maven.pl> On Monday 18 of June 2007, Micha? ?ukaszek wrote: > On 6/18/07, Micha? ?ukaszek wrote: > > > Actually I'm not so sure that's poldek bug. > > > > > > rpm -q expat ? > > > > $ rpm -q expat poldek > > expat-2.0.0-3.x86_64 > > expat-2.0.0-3.i686 > > poldek-0.20.1-0.20070617.23.x86_64 > > > > I'll try newer poldek in a minute. > > With new poldek I managed to update glibc and company, but still no > progress for expat. > And the following behavio[u]r suprises me: There is a bug in poldek. mis is going to fix it tonight. Could you download manually both new expat packages and try rpm --test -Fvh expat.i686.rpm expat.x86_64.rpm ? -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From ankry at green.mif.pg.gda.pl Mon Jun 18 16:41:28 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Mon, 18 Jun 2007 16:41:28 +0200 (CEST) Subject: SPECS: vim.spec - with python, In-Reply-To: <200706181420.27425.mmazur@kernel.pl> from "Mariusz Mazur" at Jun 18, 2007 02:20:27 PM Message-ID: <200706181441.l5IEfSJo018697@green.mif.pg.gda.pl> Mariusz Mazur wrote: > > Dnia poniedzia?ek, 18 czerwca 2007, Andrzej Krzysztofowicz napisa?: > > > OO. For all the minimum requirements there's always vim-static and e3. > > > > -static is in contradiction with minimum. > > Yup. We should have full vim with everything (X, python, perl, ruby, > brainfuck, you name it) and a vim-minimal for those, that want to have the > lightest version possible. Agreed. -- ======================================================================= 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 mlukaszek at gmail.com Mon Jun 18 16:41:57 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Mon, 18 Jun 2007 16:41:57 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <200706181618.56658.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> <200706181618.56658.arekm@maven.pl> Message-ID: On 6/18/07, Arkadiusz Miskiewicz wrote: > Could you download manually both new expat packages and try > rpm --test -Fvh expat.i686.rpm expat.x86_64.rpm ? poldek:/all-avail> get expat-2.0.1-1.* expat-devel-2.0.1-1.x86_64 Retrieving th-i686::expat-2.0.1-1.i686.rpm... .............................. 100.0% [66.7K (23.8K/s)] Retrieving th::expat-2.0.1-1.x86_64.rpm... .............................. 100.0% [70.9K (31.6K/s)] Retrieving th::expat-devel-2.0.1-1.x86_64.rpm... .............................. 100.0% [35.7K (35.1K/s)] [prism at prism ~]$ LC_ALL=C sudo rpm --test -Fhv expat-2.0.1-1.i686.rpm expat-2.0.1-1.x86_64.rpm expat-devel-2.0.1-1.x86_64.rpm Preparing... ########################################### [100%] Repackaging... ########################################### [ 33%] Upgrading... [prism at prism ~]$ Huh? -- regards, Micha? ?ukaszek prism at pld-linux.org From glen at delfi.ee Mon Jun 18 17:09:49 2007 From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Mon, 18 Jun 2007 18:09:49 +0300 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: References: <200706172342.23069.arekm@maven.pl> <200706181618.56658.arekm@maven.pl> Message-ID: <200706181809.50188.glen@delfi.ee> On Monday 18 June 2007, Micha? ?ukaszek wrote: > [prism at prism ~]$ LC_ALL=C sudo rpm --test -Fhv expat-2.0.1-1.i686.rpm > expat-2.0.1-1.x86_64.rpm expat-devel-2.0.1-1.x86_64.rpm > Preparing... ? ? ? ? ? ? ? ?########################################### > [100%] Repackaging... > ########################################### [ 33%] > Upgrading... > [prism at prism ~]$ i use -Uhv always for multilib arch pkgs. try that. eg when poldek was broken i did upaa [1] as much poldek could do, and later rpmget [2] + rpmget --sn ac-athlon and rpm -Uhv fetched packages (both arch together), carefully looking as poldek tended to fetch more than needed when different archtree was forced. [1] $ type upaa upa upaa is a function upaa () { upa $1; poldek ${1:+--sn $1} --upgrade- } upa is a function upa () { poldek ${1:+--sn $1} --up || poldek ${1:+--sn $1} --upa } [2] $ type rpmget rpmget is aliased to `poldek --fetch=`pwd` --force -u --nodeps --nohold' -- glen From tommat at pimpek.one.pl Mon Jun 18 18:29:21 2007 From: tommat at pimpek.one.pl (Tomasz Mateja) Date: Mon, 18 Jun 2007 18:29:21 +0200 Subject: [Th] rpm@sparc64 Message-ID: <4676B2E1.9040004@pimpek.one.pl> Already mentioned on devel-pl: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-June/141330.html sparc64-pld-linux-gcc -O2 -fno-strict-aliasing -fwrapv -mcpu=ultrasparc -fno-strict-aliasing -gdwarf-2 -g2 -fPIC -DPIC -D_GNU_SOURCE -D_REENTRANT -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -Wl,--as-needed -pie -o .libs/rpm rpm.o ./build/.libs/librpmbuild.a ./lib/.libs/librpm.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmdb/.libs/librpmdb.so -lselinux ./rpmdb/.libs/librpmdb.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmio/.libs/librpmio.so -lelf /usr/lib64/libdb-4.5.so ./rpmio/.libs/librpmio.so /usr/lib64/libbeecrypt.so -lrt -lm -ldl /usr/lib64/libmagic.so /usr/lib64/libpopt.so -lpthread -lz /usr/lib64/libbz2.so rpm.o: In function `argerror': /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:143: relocation truncated to fit: R_SPARC_GOT13 against symbol `stderr@@GLIBC_2.2' defined in .data section in /lib64/libc.so.6 /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:143: relocation truncated to fit: R_SPARC_GOT13 against symbol `__assert_program_name@@LIBRPM_0' defined in .bss section in ./lib/.libs/librpm.so rpm.o: In function `main': /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:238: relocation truncated to fit: R_SPARC_GOT13 against symbol `__assert_program_name@@LIBRPM_0' defined in .bss section in ./lib/.libs/librpm.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:254: relocation truncated to fit: R_SPARC_GOT13 against symbol `rpmQVKArgs@@LIBRPM_0' defined in .bss section in ./lib/.libs/librpm.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:292: relocation truncated to fit: R_SPARC_GOT13 against symbol `rpmQVKArgs@@LIBRPM_0' defined in .bss section in ./lib/.libs/librpm.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:256: relocation truncated to fit: R_SPARC_GOT13 against symbol `rpmQVKArgs@@LIBRPM_0' defined in .bss section in ./lib/.libs/librpm.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:293: relocation truncated to fit: R_SPARC_GOT13 against symbol `rpmDBArgs@@LIBRPMDB_0' defined in .bss section in /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmdb/.libs/librpmdb.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:338: relocation truncated to fit: R_SPARC_GOT13 against symbol `rpmIArgs@@LIBRPM_0' defined in .bss section in ./lib/.libs/librpm.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:457: relocation truncated to fit: R_SPARC_GOT13 against symbol `rpmcliRootDir@@LIBRPM_0' defined in .data section in ./lib/.libs/librpm.so /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:502: relocation truncated to fit: R_SPARC_GOT13 against symbol `stderr@@GLIBC_2.2' defined in .data section in /lib64/libc.so.6 /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:340: additional relocation overflows omitted from the output collect2: ld returned 1 exit status make[2]: *** [rpm] Error 1 make[2]: Leaving directory `/home/users/builder/rpm/BUILD/rpm-4.4.9' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/users/builder/rpm/BUILD/rpm-4.4.9' make: *** [all] Error 2 error: Bad exit status from /home/users/builder/tmp/rpm-tmp.94714 (%build) [builder at moon SPECS]$ rpm -q rpm rpm-4.4.8-0.1.sparc64 [builder at moon SPECS]$ rpm -q glibc glibc-2.6-3.sparc64 [builder at moon SPECS]$ rpm -q gcc gcc-4.2.0-5.sparc64 -- T. From n3npq at mac.com Mon Jun 18 18:36:30 2007 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Jun 2007 12:36:30 -0400 Subject: [Th] rpm@sparc64 In-Reply-To: <4676B2E1.9040004@pimpek.one.pl> References: <4676B2E1.9040004@pimpek.one.pl> Message-ID: <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> This is likely the -pie linkage and -fpie compilation, new in rpm-4.4.9. Remove PIE compilation/linkage is the easy fix. Upgrading binutils and/or rewriting rpm code may help. 73 de Jeff On Jun 18, 2007, at 12:29 PM, Tomasz Mateja wrote: > Already mentioned on devel-pl: > http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-June/ > 141330.html > > sparc64-pld-linux-gcc -O2 -fno-strict-aliasing -fwrapv - > mcpu=ultrasparc > -fno-strict-aliasing -gdwarf-2 -g2 -fPIC -DPIC -D_GNU_SOURCE > -D_REENTRANT -Wall -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wno-char-subscripts -Wl,--as-needed -pie -o > .libs/rpm rpm.o ./build/.libs/librpmbuild.a ./lib/.libs/librpm.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmdb/.libs/librpmdb.so > -lselinux ./rpmdb/.libs/librpmdb.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmio/.libs/librpmio.so -lelf > /usr/lib64/libdb-4.5.so ./rpmio/.libs/librpmio.so > /usr/lib64/libbeecrypt.so -lrt -lm -ldl /usr/lib64/libmagic.so > /usr/lib64/libpopt.so -lpthread -lz /usr/lib64/libbz2.so > rpm.o: In function `argerror': > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:143: relocation > truncated to fit: R_SPARC_GOT13 against symbol `stderr@@GLIBC_2.2' > defined in .data section in /lib64/libc.so.6 > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:143: relocation > truncated to fit: R_SPARC_GOT13 against symbol > `__assert_program_name@@LIBRPM_0' defined in .bss section in > ./lib/.libs/librpm.so > rpm.o: In function `main': > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:238: relocation > truncated to fit: R_SPARC_GOT13 against symbol > `__assert_program_name@@LIBRPM_0' defined in .bss section in > ./lib/.libs/librpm.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:254: relocation > truncated to fit: R_SPARC_GOT13 against symbol `rpmQVKArgs@@LIBRPM_0' > defined in .bss section in ./lib/.libs/librpm.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:292: relocation > truncated to fit: R_SPARC_GOT13 against symbol `rpmQVKArgs@@LIBRPM_0' > defined in .bss section in ./lib/.libs/librpm.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:256: relocation > truncated to fit: R_SPARC_GOT13 against symbol `rpmQVKArgs@@LIBRPM_0' > defined in .bss section in ./lib/.libs/librpm.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:293: relocation > truncated to fit: R_SPARC_GOT13 against symbol `rpmDBArgs@@LIBRPMDB_0' > defined in .bss section in > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmdb/.libs/librpmdb.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:338: relocation > truncated to fit: R_SPARC_GOT13 against symbol `rpmIArgs@@LIBRPM_0' > defined in .bss section in ./lib/.libs/librpm.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:457: relocation > truncated to fit: R_SPARC_GOT13 against symbol > `rpmcliRootDir@@LIBRPM_0' > defined in .data section in ./lib/.libs/librpm.so > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:502: relocation > truncated to fit: R_SPARC_GOT13 against symbol `stderr@@GLIBC_2.2' > defined in .data section in /lib64/libc.so.6 > /home/users/builder/rpm/BUILD/rpm-4.4.9/rpmqv.c:340: additional > relocation overflows omitted from the output > collect2: ld returned 1 exit status > make[2]: *** [rpm] Error 1 > make[2]: Leaving directory `/home/users/builder/rpm/BUILD/rpm-4.4.9' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/users/builder/rpm/BUILD/rpm-4.4.9' > make: *** [all] Error 2 > error: Bad exit status from /home/users/builder/tmp/rpm-tmp.94714 (% > build) > > > [builder at moon SPECS]$ rpm -q rpm > rpm-4.4.8-0.1.sparc64 > [builder at moon SPECS]$ rpm -q glibc > glibc-2.6-3.sparc64 > [builder at moon SPECS]$ rpm -q gcc > gcc-4.2.0-5.sparc64 > > -- > T. > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From wiget at pld-linux.org Mon Jun 18 18:59:19 2007 From: wiget at pld-linux.org (Artur Frysiak) Date: Mon, 18 Jun 2007 18:59:19 +0200 Subject: SPECS: pango.spec - revised archdir patch so /etc/pango or /etc/pa... In-Reply-To: References: Message-ID: 2007/6/18, glen : > Author: glen Date: Mon Jun 18 15:02:33 2007 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - revised archdir patch so /etc/pango or /etc/pango64 is used; rel 2 > > ---- Files affected: > SPECS: > pango.spec (1.173 -> 1.174) > > ---- Diffs: > [..] > @@ -21,6 +17,7 @@ > Patch0: %{name}-xfonts.patch > Patch1: %{name}-arch_confdir.patch > URL: http://www.pango.org/ > +BuildRequires: XFree86-devel XFree86-devel in Th ? -- Artur Frysiak From tommat at pimpek.one.pl Mon Jun 18 20:01:35 2007 From: tommat at pimpek.one.pl (Tomasz Mateja) Date: Mon, 18 Jun 2007 20:01:35 +0200 Subject: [Th] rpm@sparc64 In-Reply-To: <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> References: <4676B2E1.9040004@pimpek.one.pl> <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> Message-ID: <4676C87F.8070009@pimpek.one.pl> Jeff Johnson napisa?(a): > This is likely the -pie linkage and -fpie compilation, new in rpm-4.4.9. > > Remove PIE compilation/linkage is the easy fix. > > Upgrading binutils and/or rewriting rpm code may help. > > 73 de Jeff > removed and it's built right now, btw binutils are current. -- T. From tommat at pimpek.one.pl Mon Jun 18 20:10:13 2007 From: tommat at pimpek.one.pl (Tomasz Mateja) Date: Mon, 18 Jun 2007 20:10:13 +0200 Subject: [Th] rpm@sparc64 In-Reply-To: <4676C87F.8070009@pimpek.one.pl> References: <4676B2E1.9040004@pimpek.one.pl> <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> <4676C87F.8070009@pimpek.one.pl> Message-ID: <4676CA85.6060303@pimpek.one.pl> Tomasz Mateja napisa?(a): > Jeff Johnson napisa?(a): >> This is likely the -pie linkage and -fpie compilation, new in rpm-4.4.9. >> >> Remove PIE compilation/linkage is the easy fix. >> >> Upgrading binutils and/or rewriting rpm code may help. >> >> 73 de Jeff >> > removed and it's built right now, btw binutils are current. > not working: [root at moon RPMS]# gdb rpm GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-pld-linux"... Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) run --rebuilddb Starting program: /bin/rpm --rebuilddb Program received signal SIGBUS, Bus error. 0xfffff8010000fbec in intGetEntry (h=0x26b4e0, tag=1184, type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c, minMem=1) at header.c:1785 1785 if (p) *p = NULL; (gdb) bt #0 0xfffff8010000fbec in intGetEntry (h=0x26b4e0, tag=1184, type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c, minMem=1) at header.c:1785 #1 0xfffff801000162ec in headerGetEntryMinMemory (h=0x26b4e0, tag=1184, type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c) at ./hdrinline.h:299 #2 0xfffff8010001937c in rpmdbAdd (db=0x260c50, iid=, h=0x26b4e0, ts=0x25be90, hdrchk=0xfffff801aca602e0 ) at rpmdb.c:3125 #3 0xfffff8010001c4b8 in rpmdbRebuild (prefix=0x258a90 "/", ts=0x25be90, hdrchk=0xfffff801aca602e0 ) at rpmdb.c:4048 #4 0xfffff801aca8efa0 in rpmtsRebuildDB (ts=0x25be90) at rpmts.c:145 #5 0x0000000000105618 in main (argc=2, argv=) at rpmqv.c:586 #6 0xfffff8010052b030 in __libc_start_main () from /lib64/libc.so.6 #7 0x00000000001041d4 in _start () -- T. From n3npq at mac.com Mon Jun 18 20:33:17 2007 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Jun 2007 14:33:17 -0400 Subject: [Th] rpm@sparc64 In-Reply-To: <4676CA85.6060303@pimpek.one.pl> References: <4676B2E1.9040004@pimpek.one.pl> <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> <4676C87F.8070009@pimpek.one.pl> <4676CA85.6060303@pimpek.one.pl> Message-ID: On Jun 18, 2007, at 2:10 PM, Tomasz Mateja wrote: > Tomasz Mateja napisa?(a): >> Jeff Johnson napisa?(a): >>> This is likely the -pie linkage and -fpie compilation, new in >>> rpm-4.4.9. >>> >>> Remove PIE compilation/linkage is the easy fix. >>> >>> Upgrading binutils and/or rewriting rpm code may help. >>> >>> 73 de Jeff >>> >> removed and it's built right now, btw binutils are current. >> > not working: > > [root at moon RPMS]# gdb rpm > GNU gdb 6.6 > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "sparc64-pld-linux"... > Using host libthread_db library "/lib64/libthread_db.so.1". > (gdb) run --rebuilddb > Starting program: /bin/rpm --rebuilddb > > Program received signal SIGBUS, Bus error. > 0xfffff8010000fbec in intGetEntry (h=0x26b4e0, tag=1184, > type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c, minMem=1) at > header.c:1785 > 1785 if (p) *p = NULL; > (gdb) bt > #0 0xfffff8010000fbec in intGetEntry (h=0x26b4e0, tag=1184, > type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c, minMem=1) at > header.c:1785 > #1 0xfffff801000162ec in headerGetEntryMinMemory (h=0x26b4e0, > tag=1184, > type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c) > at ./hdrinline.h:299 > #2 0xfffff8010001937c in rpmdbAdd (db=0x260c50, iid= out>, h=0x26b4e0, ts=0x25be90, hdrchk=0xfffff801aca602e0 > ) > at rpmdb.c:3125 > #3 0xfffff8010001c4b8 in rpmdbRebuild (prefix=0x258a90 "/", > ts=0x25be90, hdrchk=0xfffff801aca602e0 ) at rpmdb.c:4048 > #4 0xfffff801aca8efa0 in rpmtsRebuildDB (ts=0x25be90) at rpmts.c:145 > #5 0x0000000000105618 in main (argc=2, argv=) at > rpmqv.c:586 > #6 0xfffff8010052b030 in __libc_start_main () from /lib64/libc.so.6 > #7 0x00000000001041d4 in _start () > > -- > T. > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From n3npq at mac.com Mon Jun 18 20:40:27 2007 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Jun 2007 14:40:27 -0400 Subject: [Th] rpm@sparc64 In-Reply-To: <4676CA85.6060303@pimpek.one.pl> References: <4676B2E1.9040004@pimpek.one.pl> <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> <4676C87F.8070009@pimpek.one.pl> <4676CA85.6060303@pimpek.one.pl> Message-ID: <6D80C02F-1B31-426F-A230-DFFEFC4E4FF4@mac.com> On Jun 18, 2007, at 2:10 PM, Tomasz Mateja wrote: >>> >> removed and it's built right now, btw binutils are current. >> > not working: > > [root at moon RPMS]# gdb rpm > GNU gdb 6.6 > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "sparc64-pld-linux"... > Using host libthread_db library "/lib64/libthread_db.so.1". > (gdb) run --rebuilddb > Starting program: /bin/rpm --rebuilddb > > Program received signal SIGBUS, Bus error. > 0xfffff8010000fbec in intGetEntry (h=0x26b4e0, tag=1184, > type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c, minMem=1) at > header.c:1785 > 1785 if (p) *p = NULL; Likely alignment on sparc64. Pointers aligned on 64bit boundary on sparc64? One hack-a-round is: memset(p, 0, sizeof(*p)); instead of *p = NULL; but you may die in caller instead. FWIW, tag=1184 is RPMTAG_PACKAGECOLOR added on multilib systems. That's likely not PLD/sparc64. Lemme look a bit more. 73 de Jeff From n3npq at mac.com Mon Jun 18 21:02:02 2007 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Jun 2007 15:02:02 -0400 Subject: [Th] rpm@sparc64 In-Reply-To: <4676CA85.6060303@pimpek.one.pl> References: <4676B2E1.9040004@pimpek.one.pl> <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> <4676C87F.8070009@pimpek.one.pl> <4676CA85.6060303@pimpek.one.pl> Message-ID: On Jun 18, 2007, at 2:10 PM, Tomasz Mateja wrote: > Tomasz Mateja napisa?(a): >> > #0 0xfffff8010000fbec in intGetEntry (h=0x26b4e0, tag=1184, > type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c, minMem=1) at > header.c:1785 Yes, p=0x7feffef951c, so the SIGBUS is a sparc64 ptr alignment problem afaict. Hmmm ... 73 de Jeff From qboosh at pld-linux.org Mon Jun 18 21:00:40 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 18 Jun 2007 21:00:40 +0200 Subject: [Th] rpm@sparc64 In-Reply-To: <6D80C02F-1B31-426F-A230-DFFEFC4E4FF4@mac.com> References: <4676B2E1.9040004@pimpek.one.pl> <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> <4676C87F.8070009@pimpek.one.pl> <4676CA85.6060303@pimpek.one.pl> <6D80C02F-1B31-426F-A230-DFFEFC4E4FF4@mac.com> Message-ID: <20070618190040.GA7434@stranger.qboosh.pl> On Mon, Jun 18, 2007 at 02:40:27PM -0400, Jeff Johnson wrote: > On Jun 18, 2007, at 2:10 PM, Tomasz Mateja wrote: > >> removed and it's built right now, btw binutils are current. > >> > > not working: > > > > [root at moon RPMS]# gdb rpm > > GNU gdb 6.6 > > Copyright (C) 2006 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, > > and you are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. > > This GDB was configured as "sparc64-pld-linux"... > > Using host libthread_db library "/lib64/libthread_db.so.1". > > (gdb) run --rebuilddb > > Starting program: /bin/rpm --rebuilddb > > > > Program received signal SIGBUS, Bus error. > > 0xfffff8010000fbec in intGetEntry (h=0x26b4e0, tag=1184, > > type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c, minMem=1) at > > header.c:1785 > > 1785 if (p) *p = NULL; > > Likely alignment on sparc64. Pointers aligned on 64bit boundary on > sparc64? > > One hack-a-round is: > memset(p, 0, sizeof(*p)); > instead of > *p = NULL; > but you may die in caller instead. Something odd. In rpmdbAdd() (rpmdb.c) hcolor is declared locally as uint32_t (so it's OK for it to be just 4-byte aligned). Then (in rpmdb.c:3125) its address is casted to void** and passed as *p through hge() finally to intGetEntry(). So intGetEntry() tries to set hcolor as (64-bit) pointer... and on sparc64 it finally crashes on alignment, but on x86_64 it seems that it overwrites some other value on stack (signalMask?). Am I wrong? > FWIW, tag=1184 is RPMTAG_PACKAGECOLOR added on > multilib systems. That's likely not PLD/sparc64. That sparc64 experiment uses multilib. -- Jakub Bogusz http://qboosh.pl/ From n3npq at mac.com Mon Jun 18 21:19:48 2007 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Jun 2007 15:19:48 -0400 Subject: [Th] rpm@sparc64 In-Reply-To: <20070618190040.GA7434@stranger.qboosh.pl> References: <4676B2E1.9040004@pimpek.one.pl> <1CB149FF-773B-4C68-8FE3-019B40F1F6C2@mac.com> <4676C87F.8070009@pimpek.one.pl> <4676CA85.6060303@pimpek.one.pl> <6D80C02F-1B31-426F-A230-DFFEFC4E4FF4@mac.com> <20070618190040.GA7434@stranger.qboosh.pl> Message-ID: On Jun 18, 2007, at 3:00 PM, Jakub Bogusz wrote: > > Something odd. > > In rpmdbAdd() (rpmdb.c) hcolor is declared locally as uint32_t (so > it's > OK for it to be just 4-byte aligned). > Then (in rpmdb.c:3125) its address is casted to void** and passed > as *p > through hge() finally to intGetEntry(). > So intGetEntry() tries to set hcolor as (64-bit) pointer... and on > sparc64 it finally crashes on alignment, but on x86_64 it seems > that it > overwrites some other value on stack (signalMask?). Am I wrong? > Nope. All that is needed is a tag existence check, using NULL skips the test. Index: rpmdb.c =================================================================== RCS file: /v/rpm/cvs/rpm/rpmdb/rpmdb.c,v retrieving revision 1.130 diff -u -b -B -w -p -r1.130 rpmdb.c --- rpmdb.c 10 Jun 2007 20:44:43 -0000 1.130 +++ rpmdb.c 18 Jun 2007 19:16:38 -0000 @@ -3101,7 +3101,7 @@ memset(data, 0, sizeof(*data)); } /* Add the package color if not present. */ - if (!hge(h, RPMTAG_PACKAGECOLOR, &bnt, &hcolor, &count)) { + if (!hge(h, RPMTAG_PACKAGECOLOR, &bnt, NULL, &count)) { hcolor = hGetColor(h); xx = hae(h, RPMTAG_PACKAGECOLOR, RPM_INT32_TYPE, &hcolor, 1); } A better approach would be to use headerIsEntry(h, RPMTAG_PACKAGECOLOR) instead. I'll get a final fix checked in this evening. >> FWIW, tag=1184 is RPMTAG_PACKAGECOLOR added on >> multilib systems. That's likely not PLD/sparc64. > > That sparc64 experiment uses multilib. > Good. And sparc's are always useful for finding alignment (and other) bugs. Thanks for the report. 73 de Jeff From n3npq at mac.com Mon Jun 18 21:42:48 2007 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Jun 2007 15:42:48 -0400 Subject: Fwd: [CVS] RPM: rpm/rpmdb/ rpmdb.c References: <20070618193927.15A1D3484EB@rpm5.org> Message-ID: <19C64DD1-BE80-4830-B536-3390525A3043@mac.com> Begin forwarded message: > From: Jeff Johnson > Date: June 18, 2007 3:39:27 PM EDT > To: rpm-cvs at rpm5.org > Subject: [CVS] RPM: rpm/rpmdb/ rpmdb.c > Reply-To: rpm-devel at rpm5.org > > RPM Package Manager, CVS Repository > http://rpm5.org/cvs/ > > ______________________________________________________________________ > ______ > > Server: rpm5.org Name: Jeff Johnson > Root: /v/rpm/cvs Email: jbj at rpm5.org > Module: rpm Date: 18-Jun-2007 > 21:39:27 > Branch: HEAD Handle: 2007061820392600 > > Modified files: > rpm/rpmdb rpmdb.c > > Log: > fix ptr alignment problem seen on pld/sparc64. > > Summary: > Revision Changes Path > 1.131 +2 -3 rpm/rpmdb/rpmdb.c > > ______________________________________________________________________ > ______ > > patch -p0 <<'@@ .' > Index: rpm/rpmdb/rpmdb.c > > ====================================================================== > ====== > $ cvs diff -u -r1.130 -r1.131 rpmdb.c > --- rpm/rpmdb/rpmdb.c 10 Jun 2007 20:44:43 -0000 1.130 > +++ rpm/rpmdb/rpmdb.c 18 Jun 2007 19:39:26 -0000 1.131 > @@ -3067,7 +3067,6 @@ > HAE_t hae = (HAE_t) headerAddEntry; > HFD_t hfd = headerFreeData; > sigset_t signalMask; > - uint32_t hcolor = 0; > const char ** baseNames; > rpmTagType bnt; > const char ** dirNames; > @@ -3101,8 +3100,8 @@ > } > > /* Add the package color if not present. */ > - if (!hge(h, RPMTAG_PACKAGECOLOR, &bnt, &hcolor, &count)) { > - hcolor = hGetColor(h); > + if (!headerIsEntry(h, RPMTAG_PACKAGECOLOR)) { > + uint32_t hcolor = hGetColor(h); > xx = hae(h, RPMTAG_PACKAGECOLOR, RPM_INT32_TYPE, &hcolor, 1); > } > > @@ . > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > CVS Sources Repository rpm-cvs at rpm5.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommat at pimpek.one.pl Mon Jun 18 23:34:06 2007 From: tommat at pimpek.one.pl (Tomasz Mateja) Date: Mon, 18 Jun 2007 23:34:06 +0200 Subject: Fwd: [CVS] RPM: rpm/rpmdb/ rpmdb.c In-Reply-To: <19C64DD1-BE80-4830-B536-3390525A3043@mac.com> References: <20070618193927.15A1D3484EB@rpm5.org> <19C64DD1-BE80-4830-B536-3390525A3043@mac.com> Message-ID: <4676FA4E.2050107@pimpek.one.pl> Jeff Johnson napisa?(a): > > Ok with this patch and without pie stuff on sparc64. One issue remaining on my sparc64 - I cannot use %_binary_payload w9.lzdio. When I build package with lzdio I have: Upgrading... 1:autoconf ########################################### [100%] error: unpacking of archive failed: cpio: Bad magic When using bzdio it's ok. -- T. From mlukaszek at gmail.com Mon Jun 18 23:59:22 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Mon, 18 Jun 2007 23:59:22 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <200706181618.56658.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> <200706181618.56658.arekm@maven.pl> Message-ID: On 6/18/07, Arkadiusz Miskiewicz wrote: > There is a bug in poldek. mis is going to fix it tonight. It looks much better now (I upgraded most of the system), still no luck with expat (I'll try to reinstall the package, since it cannot be upgraded by rpm as well). But, the following behaviour is another unwanted "feature" (sorry for the locale): Installing set #7 Przetwarzanie zale?no?ci... libsmbclient-3.0.24-3.x86_64 zostanie zast?piony przez libsmbclient-3.0.25a-1.x86_64 Zaznaczono 2 pakiety do instalacji, 1 do usuni?cia: I libsmbclient-3.0.25a-1.x86_64, libsmbclient-3.0.25a-2.x86_64 R libsmbclient-3.0.24-3.x86_64 Potrzeba pobra? 1.6MB archiw (1.6MB do pobrania). Po rozpakowaniu 8.5MB b?dzie u?yte. Pobieranie th-test::libsmbclient-3.0.25a-2.x86_64.rpm... .............................. 100.0% [832.3K (28.0K/s)] Pobieranie th-test::libsmbclient-3.0.25a-1.x86_64.rpm... .............................. 100.0% [832.0K (29.5K/s)] Uruchamianie sudo /bin/rpm --upgrade -vh --root / --noorder... ostrze?enie: pakiet libsmbclient = 1:3.0.25a-2 by? ju? dodany, pomijanie libsmbclient < 1:3.0.25a-1 ostrze?enie: package file /home/users/prism/tmp/ftp_ftp.th.pld-linux.org.dists.th.test.x86.64.RPMS/libsmbclient-3.0.25a-1.x86_64.rpm was skipped Przygotowywanie... ########################################### [100%] Ponowne pakowanie... 1:libsmbclient ########################################### [100%] Uaktualnianie... 1:libsmbclient ########################################### [100%] In short: poldek fetches two packages if both are newer than the currently installed one. Then it executes rpm -Uhv, and rpm skips the older of them. -- regards, Micha? ?ukaszek prism at pld-linux.org From n3npq at mac.com Tue Jun 19 01:34:21 2007 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 18 Jun 2007 19:34:21 -0400 Subject: [CVS] RPM: rpm/rpmdb/ rpmdb.c In-Reply-To: <4676FA4E.2050107@pimpek.one.pl> References: <20070618193927.15A1D3484EB@rpm5.org> <19C64DD1-BE80-4830-B536-3390525A3043@mac.com> <4676FA4E.2050107@pimpek.one.pl> Message-ID: On Jun 18, 2007, at 5:34 PM, Tomasz Mateja wrote: > Jeff Johnson napisa?(a): >> >> > Ok with this patch and without pie stuff on sparc64. > One issue remaining on my sparc64 - I cannot use > %_binary_payload w9.lzdio. > When I build package with lzdio I have: > Upgrading... > 1:autoconf > ########################################### > [100%] > error: unpacking of archive failed: cpio: Bad magic > Can you send me a ptr to the lzdio compressed autoconf pkg that is failing please? > When using bzdio it's ok. > Personally, I'd use gzdio, lzdio has no magic (and is likely to change format in order to achieve magic), and bzdio is 5-7 times slower that gzdio, zlib compression is still the "sweet" spot between minimal size and maximum speed imho. 73 de Jeff From tommat at pimpek.one.pl Tue Jun 19 10:07:33 2007 From: tommat at pimpek.one.pl (Tomasz Mateja) Date: Tue, 19 Jun 2007 10:07:33 +0200 Subject: [CVS] RPM: rpm/rpmdb/ rpmdb.c In-Reply-To: References: <20070618193927.15A1D3484EB@rpm5.org> <19C64DD1-BE80-4830-B536-3390525A3043@mac.com> <4676FA4E.2050107@pimpek.one.pl> Message-ID: <46778EC5.3020701@pimpek.one.pl> Jeff Johnson napisa?(a): > On Jun 18, 2007, at 5:34 PM, Tomasz Mateja wrote: > >> Jeff Johnson napisa?(a): >> One issue remaining on my sparc64 - I cannot use >> %_binary_payload w9.lzdio. >> When I build package with lzdio I have: >> Upgrading... >> 1:autoconf >> ########################################### >> [100%] >> error: unpacking of archive failed: cpio: Bad magic >> > > Can you send me a ptr to the lzdio compressed autoconf pkg that is > failing please? Not a problem :) http://pimpek.one.pl/~tommat/autoconf-2.61-7.noarch.rpm -- T. From mis at pld-linux.org Tue Jun 19 10:19:03 2007 From: mis at pld-linux.org (Pawel A. Gajda) Date: Tue, 19 Jun 2007 10:19:03 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: Message-ID: <20070619081903.GA5762@smok.emunet.pl> Monday 18/06/2007 23:59:22, Micha? ?ukaszek: > But, the following behaviour is another unwanted "feature" (sorry for > the locale): > > Installing set #7 > Przetwarzanie zale?no?ci... > libsmbclient-3.0.24-3.x86_64 zostanie zast?piony przez > libsmbclient-3.0.25a-1.x86_64 > Zaznaczono 2 pakiety do instalacji, 1 do usuni?cia: > I libsmbclient-3.0.25a-1.x86_64, libsmbclient-3.0.25a-2.x86_64 > R libsmbclient-3.0.24-3.x86_64 Can't reproduce this: poldek:/all-avail> ls zlib-* zlib-1.2.3-5.x86_64 zlib-1.2.3-6.x86_64 poldek:/all-avail> upgrade * Processing dependencies... zlib-static-1.2.3-4.x86_64 obsoleted by zlib-static-1.2.3-6.x86_64 zlib-devel-1.2.3-4.x86_64 obsoleted by zlib-devel-1.2.3-6.x86_64 zlib-1.2.3-4.x86_64 obsoleted by zlib-1.2.3-6.x86_64 There are 3 packages to install, 3 to uninstall: I zlib-1.2.3-6.x86_64, zlib-devel-1.2.3-6.x86_64, zlib-static-1.2.3-6.x86_64 R zlib-devel-1.2.3-4.x86_64, zlib-1.2.3-4.x86_64, zlib-static-1.2.3-4.x86_64 I need more info to investigate: how poldek is invoked, what is config, etc Could you give me your /var/lib/rpm/Packages? From mlukaszek at gmail.com Tue Jun 19 10:59:17 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Tue, 19 Jun 2007 10:59:17 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <20070619081903.GA5762@smok.emunet.pl> References: <20070619081903.GA5762@smok.emunet.pl> Message-ID: On 6/19/07, Pawel A. Gajda wrote: > Can't reproduce this: Maybe it only shows up when multilib repository is also enabled? See below for poldek invokation. > I need more info to investigate: how poldek is invoked, what is config, etc > Could you give me your /var/lib/rpm/Packages? Invoked: poldek -n th -n th-test -n th-i686 -n th-test-i686 My arch: x86_64 Config: $ grep -v '^[ \t]*#' /etc/poldek/poldek.conf | tr -s '\n' _distro = pld %include %{_distro}-source.conf %include %{_distro}-multilib-source.conf %include source.conf [global] choose equivalents manually = yes ignore = vserver-packages I did not manage to upgrade expat. I had to uninstall expat (i686) and expat, expat-devel (x86_64) with --nodeps --nofollow, and then install them again. Another strange thing I saw: * character does not work for archs, I mean, when I wanted to uninstall all expat-* packages (total 3 of them, listed above), no packages were matched. I had to enter whole package name-rel.arch triplet to uninstall. -- regards, Micha? ?ukaszek prism at pld-linux.org From mlukaszek at gmail.com Tue Jun 19 11:00:35 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Tue, 19 Jun 2007 11:00:35 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: References: <20070619081903.GA5762@smok.emunet.pl> Message-ID: On 6/19/07, Micha? ?ukaszek wrote: > package name-rel.arch triplet to uninstall. I meant, name-ver-rel.arch ;-) -- regards, Micha? ?ukaszek prism at pld-linux.org From glen at delfi.ee Tue Jun 19 12:58:30 2007 From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Tue, 19 Jun 2007 13:58:30 +0300 Subject: NEW poldek 0.20070618.11.1 (Ac) In-Reply-To: <200706172342.23069.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> Message-ID: <200706191358.31320.glen@delfi.ee> On Monday 18 June 2007, Arkadiusz Miskiewicz wrote: > Hello, > > New poldek snap (0.20070617.23) was sent to Th builders. It has > improvements in handling package colors and *tadam* multilib capabilities. > > Please test :) poldek-0:0.20.1-0.20070618.11.1.amd64 (ac) rpm-0:4.4.2-45.amd64 builder at haarber-amd64 pld/SPECS $ poldek -l ac http://distrib.dev.delfi.ee/pld/dists/ac/PLD/amd64/PLD/RPMS/ (type=pndir,pri=1) ac-athlon http://distrib.dev.delfi.ee/pld/dists/ac/PLD/athlon/PLD/RPMS/ (type=pndir,pri=2) both amd64/athlon sources are active. i've done poldek --clean-whole before using this poldek it shouldn't install deps from both sources :/ builder at haarber-amd64 pld/SPECS $ ./builder -bb glibc:AC-branch -R [...] Trying to install dependencies (audit-libs-devel dietlibc-static gd-devel): Retrieving ac-athlon::glibc-2.3.6-11.athlon.rpm... ..............................done Retrieving ac-athlon::audit-libs-1.3.1-2.athlon.rpm... ..............................done Retrieving ac-athlon::audit-libs-devel-1.3.1-2.athlon.rpm... ..............................done error: audit-libs-1.3.1-2.athlon package color (0) is not equal to audit-libs-1.3.1-2.athlon.rpm's one (1) There were package coloring mismatches. Proceed? [y/N] n Retrieving ac::audit-libs-1.3.1-2.amd64.rpm... ..............................done Retrieving ac::audit-libs-devel-1.3.1-2.amd64.rpm... ..............................done error: audit-libs-1.3.1-2.amd64 package color (0) is not equal to audit-libs-1.3.1-2.amd64.rpm's one (2) There were package coloring mismatches. Proceed? [y/N]y Retrieving ac-updates::dietlibc-devel-0.30-5.amd64.rpm... ..............................done Retrieving ac-updates::dietlibc-static-0.30-5.amd64.rpm... ..............................done Retrieving ac-athlon::dietlibc-0.29-2.athlon.rpm... ..............................done Retrieving ac-athlon::dietlibc-devel-0.29-2.athlon.rpm... ..............................done Retrieving ac-athlon::dietlibc-static-0.29-2.athlon.rpm... ..............................done error: dietlibc-0.29-2.athlon package color (0) is not equal to dietlibc-0.29-2.athlon.rpm's one (1) error: dietlibc-devel-0.29-2.athlon package color (0) is not equal to dietlibc-devel-0.29-2.athlon.rpm's one (1) There were package coloring mismatches. Proceed? [y/N]n Retrieving ac-athlon::gd-devel-2.0.33-13.athlon.rpm... ..............................done Retrieving ac::gd-devel-2.0.33-13.amd64.rpm... ..............................done -- glen From baggins at sith.mimuw.edu.pl Tue Jun 19 13:15:04 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Tue, 19 Jun 2007 13:15:04 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <200706172342.23069.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> Message-ID: <20070619111504.GP15787@sith.mimuw.edu.pl> On Sun, 17 Jun 2007, Arkadiusz Miskiewicz wrote: > > Hello, > > New poldek snap (0.20070617.23) was sent to Th builders. It has improvements > in handling package colors and *tadam* multilib capabilities. > > Please test :) poldek:/all-avail> uninstall php-* error: php-*: no such package Always worked till now. 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 glen at delfi.ee Tue Jun 19 13:19:06 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 19 Jun 2007 14:19:06 +0300 Subject: NEW poldek 0.20070618.11.1 (Ac) In-Reply-To: <200706191358.31320.glen@delfi.ee> References: <200706172342.23069.arekm@maven.pl> <200706191358.31320.glen@delfi.ee> Message-ID: <200706191419.06894.glen@delfi.ee> On Tuesday 19 June 2007, Elan Ruusam?e wrote: > On Monday 18 June 2007, Arkadiusz Miskiewicz wrote: > > Hello, > > > > New poldek snap (0.20070617.23) was sent to Th builders. It has > > improvements in handling package colors and *tadam* multilib > > capabilities. > > > > Please test :) > > poldek-0:0.20.1-0.20070618.11.1.amd64 (ac) > rpm-0:4.4.2-45.amd64 > > builder at haarber-amd64 pld/SPECS $ poldek -l > ac http://distrib.dev.delfi.ee/pld/dists/ac/PLD/amd64/PLD/RPMS/ > (type=pndir,pri=1) ac-athlon > http://distrib.dev.delfi.ee/pld/dists/ac/PLD/athlon/PLD/RPMS/ > (type=pndir,pri=2) here's another one -- it attempted to install both arch pkgs builder at haarber-amd64 pld/SPECS $ poldek -l ac http://distrib/pld/dists/ac/PLD/amd64/PLD/RPMS/ (type=pndir,pri=1) ac-athlon http://distrib/pld/dists/ac/PLD/athlon/PLD/RPMS/ (type=pndir,pri=2) local-pld /home/builder/rpm/pld/RPMS/ (noautoup,type=dir) Set #2 shouldn't exist at all here. $ poldek -u poldek 30276 packages read Removed 3734 duplicate packages from available set warn: poldek: ambiguous name Processing dependencies... poldek-0.20.1-0.20070618.11.1.amd64 obsoleted by poldek-0.20.1-0.20070618.11.1.1.amd64 poldek-0.20.1-0.20070618.11.1.1.amd64 marks poldek-libs-0.20.1-0.20070618.11.1.1.amd64 (cap poldek-libs = 0.20.1-0.20070618.11.1.1) poldek-libs-0.20.1-0.20070618.11.1.amd64 obsoleted by poldek-libs-0.20.1-0.20070618.11.1.1.amd64 There are 2 packages to install (1 marked by dependencies), 2 to uninstall: I poldek-0.20.1-0.20070618.11.1.1.amd64 D poldek-libs-0.20.1-0.20070618.11.1.1.amd64 R poldek-libs-0.20.1-0.20070618.11.1.amd64, poldek-0.20.1-0.20070618.11.1.amd64 Need to get 398.7KB of archives. After unpacking 885.5KB will be used. Executing sudo /bin/rpm --upgrade -vh --root / --noorder... Preparing... ################################################## poldek-libs ################################################## poldek ################################################## Installing set #2 Processing dependencies... poldek-0.20-13.athlon marks beecrypt-4.1.2-4.athlon (cap libbeecrypt.so.6) beecrypt-4.1.2-4.athlon marks glibc-2.3.6-11.athlon (cap libc.so.6) poldek-0.20-13.athlon marks bzip2-libs-1.0.3-6.athlon (cap libbz2.so.1) poldek-0.20-13.athlon marks openssl-0.9.7l-1.athlon (cap libcrypto.so.0.9.7) poldek-0.20-13.athlon marks db-4.2.52-12.athlon (cap libdb-4.2.so) poldek-0.20-13.athlon marks elfutils-libelf-0.108-3.athlon (cap libelf.so.1) poldek-0.20-13.athlon marks libmagic-4.18-4.athlon (cap libmagic.so.1) libmagic-4.18-4.athlon marks zlib-1.2.3-3.athlon (cap libz.so.1) poldek-0.20-13.athlon marks pcre-7.0-1.athlon (cap libpcre.so.0) poldek-0.20-13.athlon marks poldek-libs-0.20-13.athlon (cap libpoclidek.so.0) poldek-libs-0.20-13.athlon marks popt-1.10.4-1.athlon (cap libpopt.so.0) poldek-libs-0.20-13.athlon marks readline-5.2-1.athlon (cap libreadline.so.5) readline-5.2-1.athlon marks ncurses-5.5-2.athlon (cap libtinfo.so.5) poldek-libs-0.20-13.athlon marks rpm-lib-4.4.2-41.athlon (cap librpm-4.4.so) rpm-lib-4.4.2-41.athlon marks libselinux-1.32-3.athlon (cap libselinux.so.1) libselinux-1.32-3.athlon marks libsepol-1.14-1.athlon (cap libsepol.so.1) poldek-libs-0.20-13.athlon marks libxml2-2.6.27-1.athlon (cap libxml2.so.2) There are 18 packages to install (17 marked by dependencies): I poldek-0.20-13.athlon D beecrypt-4.1.2-4.athlon, bzip2-libs-1.0.3-6.athlon, db-4.2.52-12.athlon, elfutils-libelf-0.108-3.athlon, D glibc-2.3.6-11.athlon, libmagic-4.18-4.athlon, libselinux-1.32-3.athlon, libsepol-1.14-1.athlon, D libxml2-2.6.27-1.athlon, ncurses-5.5-2.athlon, openssl-0.9.7l-1.athlon, pcre-7.0-1.athlon, poldek-libs-0.20-13.athlon, D popt-1.10.4-1.athlon, readline-5.2-1.athlon, rpm-lib-4.4.2-41.athlon, zlib-1.2.3-3.athlon Need to get 5.4MB of archives (3.9MB to download). After unpacking 11.6MB will be used. Retrieving ac-athlon::popt-1.10.4-1.athlon.rpm... .............................. 100.0% [40.1K (40.1K/s)] Retrieving ac-athlon::libsepol-1.14-1.athlon.rpm... .............................. 100.0% [93.4K (32.1K/s)] Retrieving ac-athlon::libselinux-1.32-3.athlon.rpm... .............................. 100.0% [48.8K (48.8K/s)] Retrieving ac-athlon::ncurses-5.5-2.athlon.rpm... .............................. 100.0% [500.0K (116.1K/s)] Retrieving ac-athlon::db-4.2.52-12.athlon.rpm... .............................. 100.0% [342.4K (101.8K/s)] Retrieving ac-athlon::openssl-0.9.7l-1.athlon.rpm... .. 8.8% [78.6K of 892.7K (75.8K/s)] [00:11 ETA] -- glen From hawk at limanowa.net Tue Jun 19 13:36:56 2007 From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=) Date: Tue, 19 Jun 2007 13:36:56 +0200 Subject: SOURCES (AC-branch): poldek-ignorecaps.patch - update to poldek-0.... In-Reply-To: References: Message-ID: <4677BFD8.90302@limanowa.net> > Author: glen Date: Tue Jun 19 11:12:32 2007 GMT > Module: SOURCES Tag: AC-branch > ---- Log message: > - update to poldek-0.20.1-cvs20070618.11 Snapshot on AC-branch? I hope you've good reasons like security fixes :) M. From glen at delfi.ee Tue Jun 19 13:45:34 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 19 Jun 2007 14:45:34 +0300 Subject: SOURCES (AC-branch): poldek-ignorecaps.patch - update to poldek-0.... In-Reply-To: <4677BFD8.90302@limanowa.net> References: <4677BFD8.90302@limanowa.net> Message-ID: <200706191445.34173.glen@delfi.ee> On Tuesday 19 June 2007, Marcin Kr?l wrote: > > Author: glen Date: Tue Jun 19 11:12:32 2007 GMT > > Module: SOURCES Tag: AC-branch > > ---- Log message: > > - update to poldek-0.20.1-cvs20070618.11 > > Snapshot on AC-branch? I hope you've good reasons like security fixes :) where should i commit it then? it's USABLE for AC, as it fixes (hopefully when more tested) long-lasting pain on multiarch, making total pita upgrading packages on those arches. and there's no ac-security-updates anymore, it's just ac-updates ;)) -- glen From hawk at limanowa.net Tue Jun 19 13:57:31 2007 From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=) Date: Tue, 19 Jun 2007 13:57:31 +0200 Subject: SOURCES (AC-branch): poldek-ignorecaps.patch - update to poldek-0.... In-Reply-To: <200706191445.34173.glen@delfi.ee> References: <4677BFD8.90302@limanowa.net> <200706191445.34173.glen@delfi.ee> Message-ID: <4677C4AB.50302@limanowa.net> > where should i commit it then? it's USABLE for AC, as it fixes (hopefully when > more tested) long-lasting pain on multiarch, making total pita upgrading > packages on those arches. Snapshots have bad habbit of making things not working :/ As I see it few threads above those snapshots still contain lots of bugs. Since these snapshot shouldn't go to ready until 99% sure that all known issues were fixed they should be IMO put on devel. If we will need for example poldek rebuild in few days we will be blocked :/ M. From mis at pld-linux.org Tue Jun 19 17:58:43 2007 From: mis at pld-linux.org (=?iso-8859-2?Q?Pawe=B3_A=2E?= Gajda) Date: Tue, 19 Jun 2007 17:58:43 +0200 Subject: NEW poldek 0.20070617.23 - please test Message-ID: <20070619155843.GA6317@smok.emunet.pl> Tuesday 19/06/2007 10:59:17, Micha? ?ukaszek: > Invoked: poldek -n th -n th-test -n th-i686 -n th-test-i686 > My arch: x86_64 > Fixed. > I did not manage to upgrade expat. I had to uninstall expat (i686) and > expat, expat-devel (x86_64) with --nodeps --nofollow, and then install > them again. Seems both file-conflicted packages should be passed to rpm at once. I'll try to manage this. > Another strange thing I saw: * character does not work for archs, I > mean, when I wanted to uninstall all expat-* packages (total 3 of > them, listed above), no packages were matched. I had to enter whole > package name-rel.arch triplet to uninstall. Fixed too, try new snap. From qboosh at pld-linux.org Wed Jun 20 07:17:09 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 20 Jun 2007 07:17:09 +0200 Subject: SPECS: poldek.spec - does not require sed In-Reply-To: References: Message-ID: <20070620051709.GA26531@stranger.qboosh.pl> On Wed, Jun 20, 2007 at 02:20:31AM +0200, glen wrote: > Author: glen Date: Wed Jun 20 00:20:31 2007 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - does not require sed IIRC it was for vfjuggle and other scripts... -- Jakub Bogusz http://qboosh.pl/ From jajcus at jajcus.net Wed Jun 20 09:01:41 2007 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 20 Jun 2007 09:01:41 +0200 Subject: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for... In-Reply-To: <200706181514.50691.mmazur@kernel.pl> References: <200706181420.27425.mmazur@kernel.pl> <20070618131038.GA15759@jajo.eggsoft.pl> <200706181514.50691.mmazur@kernel.pl> Message-ID: <20070620070141.GA1037@jajo.eggsoft.pl> On Mon, Jun 18, 2007 at 03:14:50PM +0200, Mariusz Mazur wrote: > Not really. Minimal in this case means -- minimal set of deps. Meaning maximum > functionality with minimal deps. So having a few 50kb libs might be ok. > Depending on python, ruby and perl ain't. Please note, that a lot of functionality depends on vim-rt, which is quite big. So making a minimal VIM would mean splitting vim-rt to me. Greets, Jacek From glen at delfi.ee Wed Jun 20 12:21:59 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 20 Jun 2007 13:21:59 +0300 Subject: SPECS: poldek.spec - does not require sed In-Reply-To: <20070620051709.GA26531@stranger.qboosh.pl> References: <20070620051709.GA26531@stranger.qboosh.pl> Message-ID: <200706201321.59861.glen@delfi.ee> On Wednesday 20 June 2007, Jakub Bogusz wrote: > On Wed, Jun 20, 2007 at 02:20:31AM +0200, glen wrote: > > Author: glen Date: Wed Jun 20 00:20:31 2007 GMT > > Module: SPECS Tag: HEAD > > ---- Log message: > > - does not require sed > > IIRC it was for vfjuggle and other scripts... then should also depend on smbclient :) ? $ ql poldek|xargs grep sed /etc/poldek/poldek.conf:# Comma separated list of hosts or domains which will not be accessed via proxy. /usr/lib64/poldek/vfcompr:# File (de)compression helper script. Used by vfile library when external /usr/lib64/poldek/vfcompr: echo "$src already decompressed" /usr/lib64/poldek/vfjuggle: CDID=`echo $URI | sed 's@/.*@@'` /usr/lib64/poldek/vfjuggle: URI=`echo $URI | sed 's@[^/]*/@@'` /usr/lib64/poldek/vfsmb:# requires: basename, grep, sed, smbclient /usr/lib64/poldek/vfsmb: passwd=$(echo $src|sed 's|^smb://[^:]\+:\([^@]\+\)@.*|\1|') /usr/lib64/poldek/vfsmb: user=$(echo $src|sed 's|^smb://\([^:]\+\):[^@]\+ at .*|\1|') /usr/lib64/poldek/vfsmb: user=$(echo $src|sed 's|^smb://\([^@]\+\)@.*|\1|') /usr/lib64/poldek/vfsmb: src=$(echo $src|sed 's|^smb://[^@]\+@|smb://|') /usr/lib64/poldek/vfsmb:service=$(echo $src|sed 's|^smb://\([^/]\+/[^/]\+\)/|//\1|') /usr/lib64/poldek/vfsmb:file=$(echo $src|sed 's|^smb://[^/]\+/[^/]\+/||') are those vf* used by default? if not we could leave comments inside poldek.conf that you need foo and bar when enabling these config options? -- glen From qboosh at pld-linux.org Wed Jun 20 18:30:04 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 20 Jun 2007 18:30:04 +0200 Subject: SPECS: poldek.spec - does not require sed In-Reply-To: <200706201321.59861.glen@delfi.ee> References: <20070620051709.GA26531@stranger.qboosh.pl> <200706201321.59861.glen@delfi.ee> Message-ID: <20070620163004.GA22768@stranger.qboosh.pl> On Wed, Jun 20, 2007 at 01:21:59PM +0300, Elan Ruusam?e wrote: > On Wednesday 20 June 2007, Jakub Bogusz wrote: > > On Wed, Jun 20, 2007 at 02:20:31AM +0200, glen wrote: > > > Author: glen Date: Wed Jun 20 00:20:31 2007 GMT > > > Module: SPECS Tag: HEAD > > > ---- Log message: > > > - does not require sed > > > > IIRC it was for vfjuggle and other scripts... > > then should also depend on smbclient :) ? > > $ ql poldek|xargs grep sed > /etc/poldek/poldek.conf:# Comma separated list of hosts or domains which will not be accessed via proxy. > /usr/lib64/poldek/vfcompr:# File (de)compression helper script. Used by vfile library when external > /usr/lib64/poldek/vfcompr: echo "$src already decompressed" > /usr/lib64/poldek/vfjuggle: CDID=`echo $URI | sed 's@/.*@@'` > /usr/lib64/poldek/vfjuggle: URI=`echo $URI | sed 's@[^/]*/@@'` > /usr/lib64/poldek/vfsmb:# requires: basename, grep, sed, smbclient > /usr/lib64/poldek/vfsmb: passwd=$(echo $src|sed 's|^smb://[^:]\+:\([^@]\+\)@.*|\1|') > /usr/lib64/poldek/vfsmb: user=$(echo $src|sed 's|^smb://\([^:]\+\):[^@]\+ at .*|\1|') > /usr/lib64/poldek/vfsmb: user=$(echo $src|sed 's|^smb://\([^@]\+\)@.*|\1|') > /usr/lib64/poldek/vfsmb: src=$(echo $src|sed 's|^smb://[^@]\+@|smb://|') > /usr/lib64/poldek/vfsmb:service=$(echo $src|sed 's|^smb://\([^/]\+/[^/]\+\)/|//\1|') > /usr/lib64/poldek/vfsmb:file=$(echo $src|sed 's|^smb://[^/]\+/[^/]\+/||') > > are those vf* used by default? Depends on source scheme? vfjuggle is for cdrom://, vfsmb probably for smb://. I don't remember now - aren't cdrom:// sources used by default after installation from CD? > if not we could leave comments inside poldek.conf that you need foo and bar when enabling these config options? Either way... - R: sed is not big deal - it seems not too hard to rewrite sed calls in vfjuggle using sh or awk "install sed from CD to be able to install packages from CD" is not preferred solution ;) -- Jakub Bogusz http://qboosh.pl/ From kiesyoo at o2.pl Wed Jun 20 19:41:40 2007 From: kiesyoo at o2.pl (kiesiu) Date: Wed, 20 Jun 2007 19:41:40 +0200 Subject: NEW poldek 0.20070618.11.1 (Ac) In-Reply-To: <200706172342.23069.arekm@maven.pl> References: <200706172342.23069.arekm@maven.pl> Message-ID: <467966D4.3060808@o2.pl> Arkadiusz Miskiewicz pisze: > Hello, > > New poldek snap (0.20070617.23) was sent to Th builders. It has improvements > in handling package colors and *tadam* multilib capabilities. > > Please test :) I can't install anything with poldek under Ac. Follownig error occours on every package which I was trying to install. [kiesiu at seth ~]$ rpm -q poldek poldek-0.20.1-0.20070618.11.1 [kiesiu at seth ~]$ LANG=C poldek -vi mdf2iso Loading [pndir]ac... Loading [pndir]ac-updates... Loading [pndir]ac-supported... Loading [pndir]ac-ready... Loading [pndir]ac-test... 15853 packages read Removed 1870 duplicate packages from available set dbg:pkg_add_pkgcnfl : X11-Xserver-6.9.0-19 XFree86-Servers-common-3.3.6-36 (bastard)dbg:pkg_add_pkgcnfl : XFree86-Servers-common-3.3.6-36 X11-Xserver-6.9.0-19 (bastard)dbg:pkg_add_pkgcnfl : X11-driver-nvidia-legacy-progs-1.0.7185-52 X11-driver-nvidia-legacy2-progs-1.0.9639-52 (bastard)dbg:pkg_add_pkgcnfl : X11-driver-nvidia-legacy2-progs-1.0.9639-52 X11-driver-nvidia-legacy-progs-1.0.7185-52 (bastard)dbg:pkg_add_pkgcnfl : X11-driver-nvidia-progs-100.14.09-52 X11-driver-nvidia-legacy2-progs-1.0.9639-52 (bastard)dbg:pkg_add_pkgcnfl : X11-driver-nvidia-legacy2-progs-1.0.9639-52 X11-driver-nvidia-progs-100.14.09-52 (bastard)dbg:pkg_add_pkgcnfl : unixODBC-2.2.12-2 libiodbc-3.51.1-1 (bastard)dbg:pkg_add_pkgcnfl : libiodbc-3.51.1-1 unixODBC-2.2.12-2 (bastard)dbg:pkg_add_pkgcnfl : radiusd-cistron-1.6.6-6 icradius-0.18.1-6 (bastard)dbg:pkg_add_pkgcnfl : icradius-0.18.1-6 radiusd-cistron-1.6.6-6 (bastard)dbg:pkg_add_pkgcnfl : radiusd-cistron-1.6.6-6 freeradius-1.1.0-6 (bastard)dbg:pkg_add_pkgcnfl : freeradius-1.1.0-6 radiusd-cistron-1.6.6-6 (bastard)dbg:pkg_add_pkgcnfl : icradius-0.18.1-6 freeradius-1.1.0-6 (bastard)dbg:pkg_add_pkgcnfl : freeradius-1.1.0-6 icradius-0.18.1-6 (bastard)dbg:pkg_add_pkgcnfl : lvm2-initrd-2.01.15-2 lvm-initrd-1.0.8-1 (bastard)dbg:pkg_add_pkgcnfl : lvm-initrd-1.0.8-1 lvm2-initrd-2.01.15-2 (bastard)dbg:pkg_add_pkgcnfl : vim-static-7.0.243-1 vile-static-9.4-2 (bastard)dbg:pkg_add_pkgcnfl : vile-static-9.4-2 vim-static-7.0.243-1 (bastard)dbg:pkg_add_pkgcnfl : elvis-static-2.2_0-2 vile-static-9.4-2 (bastard)dbg:pkg_add_pkgcnfl : vile-static-9.4-2 elvis-static-2.2_0-2 (bastard)dbg:pkg_add_pkgcnfl : vile-static-9.4-2 nvi-1.79-7 (bastard)dbg:pkg_add_pkgcnfl : nvi-1.79-7 vile-static-9.4-2 (bastard)dbg:pkg_add_pkgcnfl : openmosix-tools-devel-0.3.6.2-3 openmosix-tools-static-0.3.6.2-3 (bastard)dbg:pkg_add_pkgcnfl : openmosix-tools-static-0.3.6.2-3 openmosix-tools-devel-0.3.6.2-3 (bastard)dbg:pkg_add_pkgcnfl : apache1-tools-1.3.37-7 apache-tools-2.2.4-3 (bastard)dbg:pkg_add_pkgcnfl : apache-tools-2.2.4-3 apache1-tools-1.3.37-7 (bastard)dbg:pkg_add_pkgcnfl : amavisd-new-sendmail-2.4.5-2 amavisd-0.1-8 (bastard)dbg:pkg_add_pkgcnfl : amavisd-0.1-8 amavisd-new-sendmail-2.4.5-2 (bastard)dbg:pkg_add_pkgcnfl : amavis-ng-0.1.6.9-3 amavisd-new-sendmail-2.4.5-2 (bastard)dbg:pkg_add_pkgcnfl : amavisd-new-sendmail-2.4.5-2 amavis-ng-0.1.6.9-3 (bastard)dbg:pkg_add_pkgcnfl : amavisd-new-2.4.5-2 amavisd-sendmail-0.1-8 (bastard)dbg:pkg_add_pkgcnfl : amavisd-sendmail-0.1-8 amavisd-new-2.4.5-2 (bastard)dbg:pkg_add_pkgcnfl : quagga-bgpd-0.98.6-5 zebra-bgpd-0.94-5 (bastard)dbg:pkg_add_pkgcnfl : zebra-bgpd-0.94-5 quagga-bgpd-0.98.6-5 (bastard)dbg:pkg_add_pkgcnfl : heimdal-ftpd-0.7.2-4 proftpd-common-1.3.1rc1-1 (bastard)dbg:pkg_add_pkgcnfl : proftpd-common-1.3.1rc1-1 heimdal-ftpd-0.7.2-4 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-apache-2.2.4-3 htpasswd-apache1-1.3.37-7 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-apache1-1.3.37-7 htpasswd-apache-2.2.4-3 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-apache-2.2.4-3 htpasswd-thttpd-2.25b-8 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-thttpd-2.25b-8 htpasswd-apache-2.2.4-3 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-mini_httpd-1.19-4 htpasswd-apache1-1.3.37-7 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-apache1-1.3.37-7 htpasswd-mini_httpd-1.19-4 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-mini_httpd-1.19-4 htpasswd-thttpd-2.25b-8 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-thttpd-2.25b-8 htpasswd-mini_httpd-1.19-4 (bastard)dbg:pkg_add_pkgcnfl : imap-2006i-1 courier-imapd-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : courier-imapd-0.53.3-3 imap-2006i-1 (bastard)dbg:pkg_add_pkgcnfl : logcheck-1.1.1-3 logsentry-1.1.1-3 (bastard)dbg:pkg_add_pkgcnfl : logsentry-1.1.1-3 logcheck-1.1.1-3 (bastard)dbg:pkg_add_pkgcnfl : courier-pop3d-0.53.3-3 courier-imap-pop3-4.1.1-4 (bastard)dbg:pkg_add_pkgcnfl : courier-imap-pop3-4.1.1-4 courier-pop3d-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : zebra-ospf6d-0.94-5 quagga-ospf6d-0.98.6-5 (bastard)dbg:pkg_add_pkgcnfl : quagga-ospf6d-0.98.6-5 zebra-ospf6d-0.94-5 (bastard)dbg:pkg_add_pkgcnfl : quagga-ospfd-0.98.6-5 zebra-ospfd-0.94-5 (bastard)dbg:pkg_add_pkgcnfl : zebra-ospfd-0.94-5 quagga-ospfd-0.98.6-5 (bastard)dbg:pkg_add_pkgcnfl : quagga-ripd-0.98.6-5 zebra-ripd-0.94-5 (bastard)dbg:pkg_add_pkgcnfl : zebra-ripd-0.94-5 quagga-ripd-0.98.6-5 (bastard)dbg:pkg_add_pkgcnfl : quagga-ripngd-0.98.6-5 zebra-ripngd-0.94-5 (bastard)dbg:pkg_add_pkgcnfl : zebra-ripngd-0.94-5 quagga-ripngd-0.98.6-5 (bastard)dbg:pkg_add_pkgcnfl : masqmail-0.2.21-1 msmtp-sendmail-1.4.10-1 (bastard)dbg:pkg_add_pkgcnfl : msmtp-sendmail-1.4.10-1 masqmail-0.2.21-1 (bastard)dbg:pkg_add_pkgcnfl : postfix-2.2.5-9 msmtp-sendmail-1.4.10-1 (bastard)dbg:pkg_add_pkgcnfl : msmtp-sendmail-1.4.10-1 postfix-2.2.5-9 (bastard)dbg:pkg_add_pkgcnfl : ssmtp-2.60.12-1 msmtp-sendmail-1.4.10-1 (bastard)dbg:pkg_add_pkgcnfl : msmtp-sendmail-1.4.10-1 ssmtp-2.60.12-1 (bastard)dbg:pkg_add_pkgcnfl : sendmail-8.13.8-6 msmtp-sendmail-1.4.10-1 (bastard)dbg:pkg_add_pkgcnfl : msmtp-sendmail-1.4.10-1 sendmail-8.13.8-6 (bastard)dbg:pkg_add_pkgcnfl : omta-0.51-14 msmtp-sendmail-1.4.10-1 (bastard)dbg:pkg_add_pkgcnfl : msmtp-sendmail-1.4.10-1 omta-0.51-14 (bastard)dbg:pkg_add_pkgcnfl : exim-4.67-1 msmtp-sendmail-1.4.10-1 (bastard)dbg:pkg_add_pkgcnfl : msmtp-sendmail-1.4.10-1 exim-4.67-1 (bastard)dbg:pkg_add_pkgcnfl : msmtp-sendmail-1.4.10-1 zmailer-2.99.56-7 (bastard)dbg:pkg_add_pkgcnfl : zmailer-2.99.56-7 msmtp-sendmail-1.4.10-1 (bastard)dbg:pkg_add_pkgcnfl : msmtp-sendmail-1.4.10-1 courier-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : courier-0.53.3-3 msmtp-sendmail-1.4.10-1 (bastard)dbg:pkg_add_pkgcnfl : courier-imap-4.1.1-4 courier-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : courier-0.53.3-3 courier-imap-4.1.1-4 (bastard)dbg:pkg_add_pkgcnfl : sqwebmail-5.0.4-5 courier-webmail-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : courier-webmail-0.53.3-3 sqwebmail-5.0.4-5 (bastard)dbg:pkg_add_pkgcnfl : wmWeather-1.31-5 gkrellm-weather-2.0.6-2 (bastard)dbg:pkg_add_pkgcnfl : gkrellm-weather-2.0.6-2 wmWeather-1.31-5 (bastard)dbg:pkg_add_pkgcnfl : amrita-1.0.2-3 alsa-modular-synth-1.8.6-2 (bastard)dbg:pkg_add_pkgcnfl : alsa-modular-synth-1.8.6-2 amrita-1.0.2-3 (bastard)dbg:pkg_add_pkgcnfl : kaffe-1.0.6-13 java-sun-appletviewer-1.6.0-6 (bastard)dbg:pkg_add_pkgcnfl : java-sun-appletviewer-1.6.0-6 kaffe-1.0.6-13 (bastard)dbg:pkg_add_pkgcnfl : emu10k1-utils-devel-0.9.4-7 alsa-tools-1.0.13-1 (bastard)dbg:pkg_add_pkgcnfl : alsa-tools-1.0.13-1 emu10k1-utils-devel-0.9.4-7 (bastard)dbg:pkg_add_pkgcnfl : xemacs-extras-21.4.19-1 emacs-extras-21.4a-1 (bastard)dbg:pkg_add_pkgcnfl : emacs-extras-21.4a-1 xemacs-extras-21.4.19-1 (bastard)dbg:pkg_add_pkgcnfl : coreutils-6.9-1 base64-1.3-3 (bastard)dbg:pkg_add_pkgcnfl : base64-1.3-3 coreutils-6.9-1 (bastard)dbg:pkg_add_pkgcnfl : bcc-0.16.15-1 qb2c-3.41-4 (bastard)dbg:pkg_add_pkgcnfl : qb2c-3.41-4 bcc-0.16.15-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-esp-8.15.1-1 ghostscript-afpl-8.53-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-afpl-8.53-1 ghostscript-esp-8.15.1-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-esp-8.15.1-1 ghostscript-gpl-8.15-2 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-gpl-8.15-2 ghostscript-esp-8.15.1-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-afpl-8.53-1 ghostscript-gpl-8.15-2 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-gpl-8.15-2 ghostscript-afpl-8.53-1 (bastard)dbg:pkg_add_pkgcnfl : db4.5-utils-4.5.20-3 db-utils-4.2.52-12 (bastard)dbg:pkg_add_pkgcnfl : db-utils-4.2.52-12 db4.5-utils-4.5.20-3 (bastard)dbg:pkg_add_pkgcnfl : Radiance-3R5-3 calc-2.11.10.1-2 (bastard)dbg:pkg_add_pkgcnfl : calc-2.11.10.1-2 Radiance-3R5-3 (bastard)dbg:pkg_add_pkgcnfl : xephem-tools-3.7.1-2 feh-1.3.0-1 (bastard)dbg:pkg_add_pkgcnfl : feh-1.3.0-1 xephem-tools-3.7.1-2 (bastard)dbg:pkg_add_pkgcnfl : capi4k-utils-2005.07.18-1 capi-tools-040111-4 (bastard)dbg:pkg_add_pkgcnfl : capi-tools-040111-4 capi4k-utils-2005.07.18-1 (bastard)dbg:pkg_add_pkgcnfl : dvdrtools-cdda2wav-0.3.1-1 cdrkit-cdda2wav-1.1.2-1 (bastard)dbg:pkg_add_pkgcnfl : cdrkit-cdda2wav-1.1.2-1 dvdrtools-cdda2wav-0.3.1-1 (bastard)dbg:pkg_add_pkgcnfl : dvdrtools-0.3.1-1 cdrkit-1.1.2-1 (bastard)dbg:pkg_add_pkgcnfl : cdrkit-1.1.2-1 dvdrtools-0.3.1-1 (bastard)dbg:pkg_add_pkgcnfl : cdrtools-2.01-3 cdrkit-1.1.2-1 (bastard)dbg:pkg_add_pkgcnfl : cdrkit-1.1.2-1 cdrtools-2.01-3 (bastard)dbg:pkg_add_pkgcnfl : cftp-0.12-2 python-TwistedConch-0.5.0-0.2 (bastard)dbg:pkg_add_pkgcnfl : python-TwistedConch-0.5.0-0.2 cftp-0.12-2 (bastard)dbg:pkg_add_pkgcnfl : compface-1.5.2-1 faces-1.6.1-20 (bastard)dbg:pkg_add_pkgcnfl : faces-1.6.1-20 compface-1.5.2-1 (bastard)dbg:pkg_add_pkgcnfl : perl-CPAN-1.76-2 perl-tools-5.8.8-10 (bastard)dbg:pkg_add_pkgcnfl : perl-tools-5.8.8-10 perl-CPAN-1.76-2 (bastard)dbg:pkg_add_pkgcnfl : dvdrtools-utils-0.3.1-1 cdrkit-utils-1.1.2-1 (bastard)dbg:pkg_add_pkgcnfl : cdrkit-utils-1.1.2-1 dvdrtools-utils-0.3.1-1 (bastard)dbg:pkg_add_pkgcnfl : dia-0.95.1-1 libdvb-0.5.4-2 (bastard)dbg:pkg_add_pkgcnfl : libdvb-0.5.4-2 dia-0.95.1-1 (bastard)dbg:pkg_add_pkgcnfl : nss-tools-3.11.4-1 perl-XML-Filter-Digest-0.06-1 (bastard)dbg:pkg_add_pkgcnfl : perl-XML-Filter-Digest-0.06-1 nss-tools-3.11.4-1 (bastard)dbg:pkg_add_pkgcnfl : tetex-3.0-2 dvipng-1.6-1 (bastard)dbg:pkg_add_pkgcnfl : dvipng-1.6-1 tetex-3.0-2 (bastard)dbg:pkg_add_pkgcnfl : perl-Encode-2.09-1 perl-tools-devel-5.8.8-10 (bastard)dbg:pkg_add_pkgcnfl : perl-tools-devel-5.8.8-10 perl-Encode-2.09-1 (bastard)dbg:pkg_add_pkgcnfl : firehose-0.6.0-1 libextractor-0.5.11-1 (bastard)dbg:pkg_add_pkgcnfl : libextractor-0.5.11-1 firehose-0.6.0-1 (bastard)dbg:pkg_add_pkgcnfl : mgetty-sendfax-1.1.30-2 hylafax-client-4.3.0.12-2 (bastard)dbg:pkg_add_pkgcnfl : hylafax-client-4.3.0.12-2 mgetty-sendfax-1.1.30-2 (bastard)dbg:pkg_add_pkgcnfl : heimdal-ftp-0.7.2-4 tnftp-2.0-0.20050103.1 (bastard)dbg:pkg_add_pkgcnfl : tnftp-2.0-0.20050103.1 heimdal-ftp-0.7.2-4 (bastard)dbg:pkg_add_pkgcnfl : metisse-0.3.5-3 fvwm2-2.5.14-2 (bastard)dbg:pkg_add_pkgcnfl : fvwm2-2.5.14-2 metisse-0.3.5-3 (bastard)dbg:pkg_add_pkgcnfl : metisse-0.3.5-3 fvwm2-perl-2.5.14-2 (bastard)dbg:pkg_add_pkgcnfl : fvwm2-perl-2.5.14-2 metisse-0.3.5-3 (bastard)dbg:pkg_add_pkgcnfl : gpp-2.24-1 k3d-0.4.5.0-4 (bastard)dbg:pkg_add_pkgcnfl : k3d-0.4.5.0-4 gpp-2.24-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-afpl-gtk-8.53-1 ghostscript-gpl-gtk-8.15-2 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-gpl-gtk-8.15-2 ghostscript-afpl-gtk-8.53-1 (bastard)dbg:pkg_add_pkgcnfl : gview-0.1.15-5 gvim-gtk-7.0.243-1 (bastard)dbg:pkg_add_pkgcnfl : gvim-gtk-7.0.243-1 gview-0.1.15-5 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-apache1-1.3.37-7 htpasswd-thttpd-2.25b-8 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-thttpd-2.25b-8 htpasswd-apache1-1.3.37-7 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-mini_httpd-1.19-4 htpasswd-apache-2.2.4-3 (bastard)dbg:pkg_add_pkgcnfl : htpasswd-apache-2.2.4-3 htpasswd-mini_httpd-1.19-4 (bastard)dbg:pkg_add_pkgcnfl : xephem-tools-3.7.1-2 kdeedu-kstars-3.5.7-1 (bastard)dbg:pkg_add_pkgcnfl : kdeedu-kstars-3.5.7-1 xephem-tools-3.7.1-2 (bastard)dbg:pkg_add_pkgcnfl : perl-ExtUtils-MakeMaker-6.30-1 perl-tools-5.8.8-10 (bastard)dbg:pkg_add_pkgcnfl : perl-tools-5.8.8-10 perl-ExtUtils-MakeMaker-6.30-1 (bastard)dbg:pkg_add_pkgcnfl : java-sun-tools-1.6.0-6 gcc-java-tools-3.3.6-5 (bastard)dbg:pkg_add_pkgcnfl : gcc-java-tools-3.3.6-5 java-sun-tools-1.6.0-6 (bastard)dbg:pkg_add_pkgcnfl : kaffe-1.0.6-13 java-sun-jre-1.6.0-6 (bastard)dbg:pkg_add_pkgcnfl : java-sun-jre-1.6.0-6 kaffe-1.0.6-13 (bastard)dbg:pkg_add_pkgcnfl : kaffe-1.0.6-13 jdkgcj-0.3.1-3 (bastard)dbg:pkg_add_pkgcnfl : jdkgcj-0.3.1-3 kaffe-1.0.6-13 (bastard)dbg:pkg_add_pkgcnfl : java-sun-jre-1.6.0-6 jdkgcj-0.3.1-3 (bastard)dbg:pkg_add_pkgcnfl : jdkgcj-0.3.1-3 java-sun-jre-1.6.0-6 (bastard)dbg:pkg_add_pkgcnfl : java-sun-1.6.0-6 jdkgcj-0.3.1-3 (bastard)dbg:pkg_add_pkgcnfl : jdkgcj-0.3.1-3 java-sun-1.6.0-6 (bastard)dbg:pkg_add_pkgcnfl : laola-013-3 perl-OLE-Storage-0.386-13 (bastard)dbg:pkg_add_pkgcnfl : perl-OLE-Storage-0.386-13 laola-013-3 (bastard)dbg:pkg_add_pkgcnfl : setarch-1.7-1 linux32-1.0-1 (bastard)dbg:pkg_add_pkgcnfl : linux32-1.0-1 setarch-1.7-1 (bastard)dbg:pkg_add_pkgcnfl : maildrop-2.0.2-2 courier-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : courier-0.53.3-3 maildrop-2.0.2-2 (bastard)dbg:pkg_add_pkgcnfl : courier-imap-4.1.1-4 courier-maildir-tools-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : courier-maildir-tools-0.53.3-3 courier-imap-4.1.1-4 (bastard)dbg:pkg_add_pkgcnfl : courier-maildrop-0.53.3-3 maildrop-2.0.2-2 (bastard)dbg:pkg_add_pkgcnfl : maildrop-2.0.2-2 courier-maildrop-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : courier-authlib-0.58-10 courier-0.53.3-3 (bastard)dbg:pkg_add_pkgcnfl : courier-0.53.3-3 courier-authlib-0.58-10 (bastard)dbg:pkg_add_pkgcnfl : mirror-2.9-7 emirror-2.1.21-3 (bastard)dbg:pkg_add_pkgcnfl : emirror-2.1.21-3 mirror-2.9-7 (bastard)dbg:pkg_add_pkgcnfl : cdrkit-mkisofs-1.1.2-1 dvdrtools-mkisofs-0.3.1-1 (bastard)dbg:pkg_add_pkgcnfl : dvdrtools-mkisofs-0.3.1-1 cdrkit-mkisofs-1.1.2-1 (bastard)dbg:pkg_add_pkgcnfl : mpich-1.2.6-3 lam-7.0.6-3 (bastard)dbg:pkg_add_pkgcnfl : lam-7.0.6-3 mpich-1.2.6-3 (bastard)dbg:pkg_add_pkgcnfl : skrypty-sms-nc-1.62-4 nc-1.10-18 (bastard)dbg:pkg_add_pkgcnfl : nc-1.10-18 skrypty-sms-nc-1.62-4 (bastard)dbg:pkg_add_pkgcnfl : normalize-0.7.6-4 num-utils-0.5-1 (bastard)dbg:pkg_add_pkgcnfl : num-utils-0.5-1 normalize-0.7.6-4 (bastard)dbg:pkg_add_pkgcnfl : tetex-omega-3.0-2 omega-0.80.2-1 (bastard)dbg:pkg_add_pkgcnfl : omega-0.80.2-1 tetex-omega-3.0-2 (bastard)dbg:pkg_add_pkgcnfl : Par-1.52-2 par2cmdline-0.4-2 (bastard)dbg:pkg_add_pkgcnfl : par2cmdline-0.4-2 Par-1.52-2 (bastard)dbg:pkg_add_pkgcnfl : mutt-1.4.2.3-1 keyanalyze-200204-3 (bastard)dbg:pkg_add_pkgcnfl : keyanalyze-200204-3 mutt-1.4.2.3-1 (bastard)dbg:pkg_add_pkgcnfl : php-program-5.2.3-2 php4-program-4.4.7-1 (bastard)dbg:pkg_add_pkgcnfl : php4-program-4.4.7-1 php-program-5.2.3-2 (bastard)dbg:pkg_add_pkgcnfl : perl-tools-5.8.8-10 perl-Encode-2.09-1 (bastard)dbg:pkg_add_pkgcnfl : perl-Encode-2.09-1 perl-tools-5.8.8-10 (bastard)dbg:pkg_add_pkgcnfl : ming-utils-0.3.0-1 swftools-0.8.0-2 (bastard)dbg:pkg_add_pkgcnfl : swftools-0.8.0-2 ming-utils-0.3.0-1 (bastard)dbg:pkg_add_pkgcnfl : perl-PAR-0.89-1 nss-tools-3.11.4-1 (bastard)dbg:pkg_add_pkgcnfl : nss-tools-3.11.4-1 perl-PAR-0.89-1 (bastard)dbg:pkg_add_pkgcnfl : synce-librapi2-0.9.1-1 pTools-0.1-10 (bastard)dbg:pkg_add_pkgcnfl : pTools-0.1-10 synce-librapi2-0.9.1-1 (bastard)dbg:pkg_add_pkgcnfl : procps-3.2.7-1 pTools-0.1-10 (bastard)dbg:pkg_add_pkgcnfl : pTools-0.1-10 procps-3.2.7-1 (bastard)dbg:pkg_add_pkgcnfl : quicktime4linux-progs-2.2-4 libquicktime-utils-0.9.10-2 (bastard)dbg:pkg_add_pkgcnfl : libquicktime-utils-0.9.10-2 quicktime4linux-progs-2.2-4 (bastard)dbg:pkg_add_pkgcnfl : num-utils-0.5-1 bsd-games-2.16-3 (bastard)dbg:pkg_add_pkgcnfl : bsd-games-2.16-3 num-utils-0.5-1 (bastard)dbg:pkg_add_pkgcnfl : rc-1.7.1-2 lirc-0.6.6-3 (bastard)dbg:pkg_add_pkgcnfl : lirc-0.6.6-3 rc-1.7.1-2 (bastard)dbg:pkg_add_pkgcnfl : cvs-nserver-common-1.11.1.52-18 cvs-1.11.21-5 (bastard)dbg:pkg_add_pkgcnfl : cvs-1.11.21-5 cvs-nserver-common-1.11.1.52-18 (bastard)dbg:pkg_add_pkgcnfl : nasm-rdoff-0.98.38-3 repat-20001224-1 (bastard)dbg:pkg_add_pkgcnfl : repat-20001224-1 nasm-rdoff-0.98.38-3 (bastard)dbg:pkg_add_pkgcnfl : cdrkit-readcd-1.1.2-1 dvdrtools-readcd-0.3.1-1 (bastard)dbg:pkg_add_pkgcnfl : dvdrtools-readcd-0.3.1-1 cdrkit-readcd-1.1.2-1 (bastard)dbg:pkg_add_pkgcnfl : pnet-compiler-common-0.7.0-1 mono-compat-links-1.2.3.1-2 (bastard)dbg:pkg_add_pkgcnfl : mono-compat-links-1.2.3.1-2 pnet-compiler-common-0.7.0-1 (bastard)dbg:pkg_add_pkgcnfl : kaffe-1.0.6-13 gcc-java-tools-3.3.6-5 (bastard)dbg:pkg_add_pkgcnfl : gcc-java-tools-3.3.6-5 kaffe-1.0.6-13 (bastard)dbg:pkg_add_pkgcnfl : kaffe-1.0.6-13 java-sun-tools-1.6.0-6 (bastard)dbg:pkg_add_pkgcnfl : java-sun-tools-1.6.0-6 kaffe-1.0.6-13 (bastard)dbg:pkg_add_pkgcnfl : scsiutils-1.7.2.10.0.97-4 sg3_utils-1.24-1 (bastard)dbg:pkg_add_pkgcnfl : sg3_utils-1.24-1 scsiutils-1.7.2.10.0.97-4 (bastard)dbg:pkg_add_pkgcnfl : spfd-1.999.1-2 libspf2-tools-1.2.5-2 (bastard)dbg:pkg_add_pkgcnfl : libspf2-tools-1.2.5-2 spfd-1.999.1-2 (bastard)dbg:pkg_add_pkgcnfl : libspf2-tools-1.2.5-2 perl-Mail-SPF-2.004-1 (bastard)dbg:pkg_add_pkgcnfl : perl-Mail-SPF-2.004-1 libspf2-tools-1.2.5-2 (bastard)dbg:pkg_add_pkgcnfl : svk-0.19-1 perl-SVK-0.28-1 (bastard)dbg:pkg_add_pkgcnfl : perl-SVK-0.28-1 svk-0.19-1 (bastard)dbg:pkg_add_pkgcnfl : devtodo-0.1.19-1 tdl-1.4.1-3 (bastard)dbg:pkg_add_pkgcnfl : tdl-1.4.1-3 devtodo-0.1.19-1 (bastard)dbg:pkg_add_pkgcnfl : devtodo-0.1.19-1 openmotif-demos-2.2.3-6 (bastard)dbg:pkg_add_pkgcnfl : openmotif-demos-2.2.3-6 devtodo-0.1.19-1 (bastard)dbg:pkg_add_pkgcnfl : faces-xface-1.6.1-20 compface-1.5.2-1 (bastard)dbg:pkg_add_pkgcnfl : compface-1.5.2-1 faces-xface-1.6.1-20 (bastard)dbg:pkg_add_pkgcnfl : myspell-tools-3.1-0.pre.5 hunspell-tools-1.1.4-1 (bastard)dbg:pkg_add_pkgcnfl : hunspell-tools-1.1.4-1 myspell-tools-3.1-0.pre.5 (bastard)dbg:pkg_add_pkgcnfl : pmake-2.1.36-3 hdf-progs-4.2r1-2 (bastard)dbg:pkg_add_pkgcnfl : hdf-progs-4.2r1-2 pmake-2.1.36-3 (bastard)dbg:pkg_add_pkgcnfl : infocom-weather-960613-2 expect-5.42.1-2 (bastard)dbg:pkg_add_pkgcnfl : expect-5.42.1-2 infocom-weather-960613-2 (bastard)dbg:pkg_add_pkgcnfl : lam-7.0.6-3 wipe-0.16-4 (bastard)dbg:pkg_add_pkgcnfl : wipe-0.16-4 lam-7.0.6-3 (bastard)dbg:pkg_add_pkgcnfl : wtf-20051104-1 bsd-games-2.16-3 (bastard)dbg:pkg_add_pkgcnfl : bsd-games-2.16-3 wtf-20051104-1 (bastard)dbg:pkg_add_pkgcnfl : wwwoffle-hyperestraier-2.9a-3 wwwoffle-2.9a-3 (bastard)dbg:pkg_add_pkgcnfl : wwwoffle-2.9a-3 wwwoffle-hyperestraier-2.9a-3 (bastard)dbg:pkg_add_pkgcnfl : libvncserver-progs-0.8.2-1 x11vnc-0.8.4-1 (bastard)dbg:pkg_add_pkgcnfl : x11vnc-0.8.4-1 libvncserver-progs-0.8.2-1 (bastard)dbg:pkg_add_pkgcnfl : nss-static-3.11.4-1 heimdal-static-0.7.2-4 (bastard)dbg:pkg_add_pkgcnfl : heimdal-static-0.7.2-4 nss-static-3.11.4-1 (bastard)dbg:pkg_add_pkgcnfl : capi-libs-static-040111-4 capi4k-utils-static-2005.07.18-1 (bastard)dbg:pkg_add_pkgcnfl : capi4k-utils-static-2005.07.18-1 capi-libs-static-040111-4 (bastard)dbg:pkg_add_pkgcnfl : capi4k-utils-devel-2005.07.18-1 capi-devel-040111-4 (bastard)dbg:pkg_add_pkgcnfl : capi-devel-040111-4 capi4k-utils-devel-2005.07.18-1 (bastard)dbg:pkg_add_pkgcnfl : k3d-devel-0.4.5.0-4 cblas-devel-3.0-3 (bastard)dbg:pkg_add_pkgcnfl : cblas-devel-3.0-3 k3d-devel-0.4.5.0-4 (bastard)dbg:pkg_add_pkgcnfl : compface-devel-1.5.2-1 faces-devel-1.6.1-20 (bastard)dbg:pkg_add_pkgcnfl : faces-devel-1.6.1-20 compface-devel-1.5.2-1 (bastard)dbg:pkg_add_pkgcnfl : db-static-4.2.52-12 db4.5-static-4.5.20-3 (bastard)dbg:pkg_add_pkgcnfl : db4.5-static-4.5.20-3 db-static-4.2.52-12 (bastard)dbg:pkg_add_pkgcnfl : db4.5-devel-4.5.20-3 db-devel-4.2.52-12 (bastard)dbg:pkg_add_pkgcnfl : db-devel-4.2.52-12 db4.5-devel-4.5.20-3 (bastard)dbg:pkg_add_pkgcnfl : db4.5-cxx-static-4.5.20-3 db-cxx-static-4.2.52-12 (bastard)dbg:pkg_add_pkgcnfl : db-cxx-static-4.2.52-12 db4.5-cxx-static-4.5.20-3 (bastard)dbg:pkg_add_pkgcnfl : db-cxx-devel-4.2.52-12 db4.5-cxx-devel-4.5.20-3 (bastard)dbg:pkg_add_pkgcnfl : db4.5-cxx-devel-4.5.20-3 db-cxx-devel-4.2.52-12 (bastard)dbg:pkg_add_pkgcnfl : db4.5-tcl-devel-4.5.20-3 db-tcl-devel-4.2.52-12 (bastard)dbg:pkg_add_pkgcnfl : db-tcl-devel-4.2.52-12 db4.5-tcl-devel-4.5.20-3 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-gpl-devel-8.15-2 ghostscript-afpl-devel-8.53-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-afpl-devel-8.53-1 ghostscript-gpl-devel-8.15-2 (bastard)dbg:pkg_add_pkgcnfl : heimdal-static-0.7.2-4 libgssapi-static-0.9-1 (bastard)dbg:pkg_add_pkgcnfl : libgssapi-static-0.9-1 heimdal-static-0.7.2-4 (bastard)dbg:pkg_add_pkgcnfl : heimdal-devel-0.7.2-4 libgssapi-devel-0.9-1 (bastard)dbg:pkg_add_pkgcnfl : libgssapi-devel-0.9-1 heimdal-devel-0.7.2-4 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-afpl-ijs-devel-8.53-1 ghostscript-esp-ijs-devel-8.15.1-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-esp-ijs-devel-8.15.1-1 ghostscript-afpl-ijs-devel-8.53-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-afpl-ijs-devel-8.53-1 ghostscript-gpl-ijs-devel-8.15-2 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-gpl-ijs-devel-8.15-2 ghostscript-afpl-ijs-devel-8.53-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-esp-ijs-devel-8.15.1-1 ghostscript-gpl-ijs-devel-8.15-2 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-gpl-ijs-devel-8.15-2 ghostscript-esp-ijs-devel-8.15.1-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-7.07.1-1 ghostscript-esp-ijs-devel-8.15.1-1 (bastard)dbg:pkg_add_pkgcnfl : ghostscript-esp-ijs-devel-8.15.1-1 ghostscript-7.07.1-1 (bastard)dbg:pkg_add_pkgcnfl : koffice-devel-1.6.3-1 kexi-devel-0.9-7 (bastard)dbg:pkg_add_pkgcnfl : kexi-devel-0.9-7 koffice-devel-1.6.3-1 (bastard)dbg:pkg_add_pkgcnfl : ortp-static-0.11.0-1 linphone-static-1.2.0-1 (bastard)dbg:pkg_add_pkgcnfl : linphone-static-1.2.0-1 ortp-static-0.11.0-1 (bastard)dbg:pkg_add_pkgcnfl : linphone-devel-1.2.0-1 ortp-devel-0.11.0-1 (bastard)dbg:pkg_add_pkgcnfl : ortp-devel-0.11.0-1 linphone-devel-1.2.0-1 (bastard)dbg:pkg_add_pkgcnfl : cdrkit-devel-1.1.2-1 cdrtools-devel-2.01-3 (bastard)dbg:pkg_add_pkgcnfl : cdrtools-devel-2.01-3 cdrkit-devel-1.1.2-1 (bastard)dbg:pkg_add_pkgcnfl : heimdal-static-0.7.2-4 e2fsprogs-static-1.39-3 (bastard)dbg:pkg_add_pkgcnfl : e2fsprogs-static-1.39-3 heimdal-static-0.7.2-4 (bastard)dbg:pkg_add_pkgcnfl : trurlib-static-0.43.6-4 poldek-static-0.20.1-0.20070618.11.1 (bastard)dbg:pkg_add_pkgcnfl : poldek-static-0.20.1-0.20070618.11.1 trurlib-static-0.43.6-4 (bastard)dbg:pkg_add_pkgcnfl : trurlib-devel-0.43.6-4 poldek-devel-0.20.1-0.20070618.11.1 (bastard)dbg:pkg_add_pkgcnfl : poldek-devel-0.20.1-0.20070618.11.1 trurlib-devel-0.43.6-4 (bastard)Processing dependencies... There are 1 package to install: I mdf2iso-0.2.2-1 Need to get 7.2KB of archives (7.2KB to download). After unpacking 7.0KB will be used. Something wrong, something not quite right. Assertion 'rpmtag' failed, misc.c:248 Please report this bug to . Any suggestions? -- ?ukasz Kie? From glen at delfi.ee Wed Jun 20 22:35:49 2007 From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Wed, 20 Jun 2007 23:35:49 +0300 Subject: NEW poldek 0.20070618.11.1 (Ac) In-Reply-To: <467966D4.3060808@o2.pl> References: <200706172342.23069.arekm@maven.pl> <467966D4.3060808@o2.pl> Message-ID: <200706202335.50215.glen@delfi.ee> On Wednesday 20 June 2007, kiesiu wrote: > Any suggestions? https://bugs.pld-linux.org/show_bug.cgi?id=25 -- glen From zswi at pers.pl Thu Jun 21 10:14:14 2007 From: zswi at pers.pl (=?utf-8?q?Rafa=C5=82_Cygnarowski?=) Date: Thu, 21 Jun 2007 10:14:14 +0200 Subject: SPECS: qt4.spec - adapter In-Reply-To: References: Message-ID: <200706211014.20500.zswi@pers.pl> Dnia ?roda, 20 czerwca 2007, glen napisa?: > Author: glen Date: Wed Jun 20 21:51:01 2007 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - adapter > > ---- Files affected: > SPECS: > qt4.spec (1.134 -> 1.135) > > ---- Diffs: > > ================================================================ > Index: SPECS/qt4.spec > diff -u SPECS/qt4.spec:1.134 SPECS/qt4.spec:1.135 > --- SPECS/qt4.spec:1.134 Fri Jun 15 07:42:03 2007 > +++ SPECS/qt4.spec Wed Jun 20 23:50:56 2007 > @@ -1537,19 +1537,33 @@ > %{_qtdir}/doc > > %files -n QtCore-devel -f QtCore-devel.files > +%defattr(644,root,root,755) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This change is wrong. Qt*-devel.files already contains this and it's respected. If this is done by adapter, then adapter needs to be fixed. Remove these lines, please. Regards, -- Rafa? Cygnarowski rafi at pers.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From radek at pld-linux.org Thu Jun 21 10:48:20 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Thu, 21 Jun 2007 10:48:20 +0200 Subject: SPECS: qt4.spec - adapter In-Reply-To: <200706211014.20500.zswi@pers.pl> References: <200706211014.20500.zswi@pers.pl> Message-ID: <20070621084820.GA3557@bzium> Rafa? Cygnarowski [21-06-2007 10:14]: > Dnia ?roda, 20 czerwca 2007, glen napisa?: [...] >> %files -n QtCore-devel -f QtCore-devel.files >> +%defattr(644,root,root,755) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This change is wrong. Why do you think so? > Qt*-devel.files already contains this and it's > respected. If this is done by adapter, then adapter needs to be fixed. > Remove these lines, please. All %files sections should begin with %defattr; no exceptions. This cuts down the time needed to wonder if it's needed here and just missing or defined somewhere else... Consider it a policy. Benefit: less bugs, saved time. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From glen at delfi.ee Thu Jun 21 10:53:35 2007 From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Thu, 21 Jun 2007 11:53:35 +0300 Subject: SPECS: qt4.spec - adapter In-Reply-To: <20070621084820.GA3557@bzium> References: <200706211014.20500.zswi@pers.pl> <20070621084820.GA3557@bzium> Message-ID: <200706211153.35539.glen@delfi.ee> On Thursday 21 June 2007, Radoslaw Zielinski wrote: > Rafa? Cygnarowski [21-06-2007 10:14]: > > Dnia ?roda, 20 czerwca 2007, glen napisa?: > > [...] > > >> %files -n QtCore-devel -f QtCore-devel.files > >> +%defattr(644,root,root,755) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This change is wrong. > > Why do you think so? > > > Qt*-devel.files already contains this and it's > > respected. If this is done by adapter, then adapter needs to be fixed. > > Remove these lines, please. > > All %files sections should begin with %defattr; no exceptions. This > cuts down the time needed to wonder if it's needed here and just missing > or defined somewhere else... Consider it a policy. Benefit: less bugs, > saved time. agree (that's why i commited it too), and it made branch diffing easier of both branches in comparision are adaptered. the same topic can be argued around any *-i18n* *-i10l* packages. and extra note: it doesn't break anything, the %defattr from -f overrides it anyway. -- glen From zswi at pers.pl Thu Jun 21 11:03:42 2007 From: zswi at pers.pl (=?iso-8859-2?q?Rafa=B3_Cygnarowski?=) Date: Thu, 21 Jun 2007 11:03:42 +0200 Subject: SPECS: qt4.spec - adapter In-Reply-To: <20070621084820.GA3557@bzium> References: <200706211014.20500.zswi@pers.pl> <20070621084820.GA3557@bzium> Message-ID: <200706211103.49351.zswi@pers.pl> Dnia czwartek, 21 czerwca 2007, Radoslaw Zielinski napisa?: > Rafa? Cygnarowski [21-06-2007 10:14]: > > Dnia ?roda, 20 czerwca 2007, glen napisa?: > > [...] > > >> %files -n QtCore-devel -f QtCore-devel.files > >> +%defattr(644,root,root,755) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This change is wrong. > > Why do you think so? Because 1. it's already there 2. it's less readable now (so bugs prone). > > Qt*-devel.files already contains this and it's > > respected. If this is done by adapter, then adapter needs to be fixed. > > Remove these lines, please. > > All %files sections should begin with %defattr; no exceptions. And there is no exception in this situation. > This > cuts down the time needed to wonder if it's needed here and just missing > or defined somewhere else... Consider it a policy. If someone(tm) took care of it to be right, then it's not policy but too smart adapter... In the same way I could check every thing 100 times to be sure that one variable is set correctly but one place is enough if done right in right place. Regards, -- Rafa? Cygnarowski rafi at pers.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From zswi at pers.pl Thu Jun 21 11:12:38 2007 From: zswi at pers.pl (=?utf-8?q?Rafa=C5=82_Cygnarowski?=) Date: Thu, 21 Jun 2007 11:12:38 +0200 Subject: SPECS: qt4.spec - adapter In-Reply-To: <200706211153.35539.glen@delfi.ee> References: <20070621084820.GA3557@bzium> <200706211153.35539.glen@delfi.ee> Message-ID: <200706211112.38817.zswi@pers.pl> Dnia czwartek, 21 czerwca 2007, Elan Ruusam?e napisa?: > agree (that's why i commited it too), and it made branch diffing easier of > both branches in comparision are adaptered. On AC-branch it's also included in *-files so it's not an argument. > > the same topic can be argued around any *-i18n* *-i10l* packages. And it is... if there is this definition already then why makes it double? Besides it makes spec-s more readable and a little bit smaller. I understand including this in %files when file list is only addition, but when it's only one source of file list - it's not necessary. Regards, -- Rafa? Cygnarowski rafi at pers.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From gotar at polanet.pl Thu Jun 21 18:02:44 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Thu, 21 Jun 2007 18:02:44 +0200 Subject: broken pl LC_TIME Message-ID: <20070621160244.GA15394@pepin.polanet.pl> What the f* is that? [root at quarto /etc]# LC_TIME=pl_PL date Cz, 21 VI 2007, 18:02:04 CEST XICIIVIM months are archaic in polish. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From qboosh at pld-linux.org Thu Jun 21 19:03:34 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 21 Jun 2007 19:03:34 +0200 Subject: broken pl LC_TIME In-Reply-To: <20070621160244.GA15394@pepin.polanet.pl> References: <20070621160244.GA15394@pepin.polanet.pl> Message-ID: <20070621170334.GA11549@stranger.qboosh.pl> On Thu, Jun 21, 2007 at 06:02:44PM +0200, Tomasz Pala wrote: > What the f* is that? > > [root at quarto /etc]# LC_TIME=pl_PL date > Cz, 21 VI 2007, 18:02:04 CEST > > XICIIVIM months are archaic in polish. http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-June/141423.html -- Jakub Bogusz http://qboosh.pl/ From ankry at green.mif.pg.gda.pl Thu Jun 21 19:14:13 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Thu, 21 Jun 2007 19:14:13 +0200 (CEST) Subject: SPECS: qt4.spec - adapter In-Reply-To: <200706211014.20500.zswi@pers.pl> from "=?utf-8?q?Rafa=C5=82_Cygnarowski?=" at Jun 21, 2007 10:14:14 AM Message-ID: <200706211714.l5LHEDwB032138@green.mif.pg.gda.pl> =?utf-8?q?Rafa=C5=82_Cygnarowski?= wrote: > > --===============0990176345== > Content-Type: multipart/signed; boundary="nextPart5329749.Eslldous2x"; > protocol="application/pgp-signature"; micalg=pgp-sha1 > Content-Transfer-Encoding: 7bit > > %files -n QtCore-devel -f QtCore-devel.files > > +%defattr(644,root,root,755) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This change is wrong. Qt*-devel.files already contains this and it's=20 > respected. If this is done by adapter, then adapter needs to be fixed. > Remove these lines, please. It was told some times ago that the rule is to have the %defattr line just after %files. Even if file used via -f (generally language file) already contains it - just for case the "-f" option is temporary disabled for any reason. This may be a little overloading but should not hurt. -- ======================================================================= 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 tiwek at manta.univ.gda.pl Thu Jun 21 21:06:59 2007 From: tiwek at manta.univ.gda.pl (Tomasz Witek) Date: Thu, 21 Jun 2007 21:06:59 +0200 Subject: broken pl LC_TIME In-Reply-To: <20070621170334.GA11549@stranger.qboosh.pl> References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> Message-ID: <1182452819.5810.0.camel@localhost> Dnia 21-06-2007, Cz o godzinie 19:03 +0200, Jakub Bogusz napisa?(a): > On Thu, Jun 21, 2007 at 06:02:44PM +0200, Tomasz Pala wrote: > > What the f* is that? > > > > [root at quarto /etc]# LC_TIME=pl_PL date > > Cz, 21 VI 2007, 18:02:04 CEST > > > > XICIIVIM months are archaic in polish. > > http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-June/141423.html > > ok, but $ cal czerwiec 2007 N Pn Wt ?r Cz Pt So 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 one letter for Sunday is ... TiweK -- From glen at delfi.ee Thu Jun 21 21:26:00 2007 From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Thu, 21 Jun 2007 22:26:00 +0300 Subject: broken pl LC_TIME In-Reply-To: <1182452819.5810.0.camel@localhost> References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> <1182452819.5810.0.camel@localhost> Message-ID: <200706212226.00915.glen@delfi.ee> On Thursday 21 June 2007 22:06, Tomasz Witek wrote: > ok, but > > $ cal > czerwiec 2007 > N Pn Wt ?r Cz Pt So > 1 2 > 3 4 5 6 7 8 9 > 10 11 12 13 14 15 16 > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 > > one letter for Sunday is ... what? we have all days single letter ;) $ LC_ALL= LC_TIME=et_EE cal -m juuni 2007 E T K N R L P 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 > TiweK -- glen From patrys at pld-linux.org Thu Jun 21 21:33:18 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Thu, 21 Jun 2007 21:33:18 +0200 Subject: broken pl LC_TIME In-Reply-To: <1182452819.5810.0.camel@localhost> References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> <1182452819.5810.0.camel@localhost> Message-ID: <89b6ba3a0706211233j7a82c1e7tfdee4670f5d20127@mail.gmail.com> On 6/21/07, Tomasz Witek wrote: > ok, but > > $ cal > czerwiec 2007 > N Pn Wt ?r Cz Pt So > 1 2 > 3 4 5 6 7 8 9 > 10 11 12 13 14 15 16 > 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 > > one letter for Sunday is ... ...perfectly normal? Or do you prefer "the knights who call Sunday Ni"? -- Patryk Zawadzki Generated Content From n3npq at mac.com Thu Jun 21 21:50:55 2007 From: n3npq at mac.com (Jeff Johnson) Date: Thu, 21 Jun 2007 15:50:55 -0400 Subject: broken pl LC_TIME In-Reply-To: <89b6ba3a0706211233j7a82c1e7tfdee4670f5d20127@mail.gmail.com> References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> <1182452819.5810.0.camel@localhost> <89b6ba3a0706211233j7a82c1e7tfdee4670f5d20127@mail.gmail.com> Message-ID: <9E8AAFC9-243B-47F4-9189-4E5E94DED236@mac.com> On Jun 21, 2007, at 3:33 PM, Patryk Zawadzki wrote: > > Or do you prefer "the knights who call Sunday Ni"? > Hehe. You made my day. Permit me to share in the fun: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=10331 One of my memorable "BLONDE" bugs ;-) 73 de Jeff From tiwek at manta.univ.gda.pl Thu Jun 21 21:54:34 2007 From: tiwek at manta.univ.gda.pl (Tomasz Witek) Date: Thu, 21 Jun 2007 21:54:34 +0200 Subject: broken pl LC_TIME In-Reply-To: <89b6ba3a0706211233j7a82c1e7tfdee4670f5d20127@mail.gmail.com> References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> <1182452819.5810.0.camel@localhost> <89b6ba3a0706211233j7a82c1e7tfdee4670f5d20127@mail.gmail.com> Message-ID: <1182455674.5810.6.camel@localhost> Dnia 21-06-2007, Cz o godzinie 21:33 +0200, Patryk Zawadzki napisa?(a): > On 6/21/07, Tomasz Witek wrote: > > ok, but > > > > $ cal > > czerwiec 2007 > > N Pn Wt ?r Cz Pt So > > 1 2 > > 3 4 5 6 7 8 9 > > 10 11 12 13 14 15 16 > > 17 18 19 20 21 22 23 > > 24 25 26 27 28 29 30 > > > > one letter for Sunday is ... > > ...perfectly normal? > > Or do you prefer "the knights who call Sunday Ni"? > Why if all have two ? Nd ? -- From zswi at pers.pl Thu Jun 21 22:03:25 2007 From: zswi at pers.pl (=?utf-8?q?Rafa=C5=82_Cygnarowski?=) Date: Thu, 21 Jun 2007 22:03:25 +0200 Subject: SPECS: qt4.spec - adapter In-Reply-To: <200706211714.l5LHEDwB032138@green.mif.pg.gda.pl> References: <200706211714.l5LHEDwB032138@green.mif.pg.gda.pl> Message-ID: <200706212203.29848.zswi@pers.pl> Dnia czwartek, 21 czerwca 2007, Andrzej Krzysztofowicz napisa?: > It was told some times ago that the rule is to have the %defattr line just > after %files. Even if file used via -f (generally language file) already > contains it - just for case the "-f" option is temporary disabled for any > reason. > > This may be a little overloading but should not hurt. Adapter starts remind me MS Word autocorrection (not every dot followed by space is new sentence!). -- Rafa? Cygnarowski rafi at pers.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From arekm at maven.pl Thu Jun 21 22:05:28 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 21 Jun 2007 22:05:28 +0200 Subject: createrepo slowness - reconsidering yum indexes in pld th support Message-ID: <200706212205.28860.arekm@maven.pl> Hello, Can createrepo index update process can be made faster? It takes about *1 hour* to update Th indexes (where poldek does the same thing in less that 1 minute for pndir format). Currently it's called as: os.system('%s.stat/bin/createrepo --cache %s/tmp/createrepo %s%s/%s/RPMS' % (ftp_dir,home,ftp_dir,tree,arch)) using ep09 packages (pld ac). -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From sparky at pld-linux.org Thu Jun 21 23:56:28 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Thu, 21 Jun 2007 23:56:28 +0200 Subject: broken pl LC_TIME In-Reply-To: <200706212226.00915.glen@delfi.ee> References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> <1182452819.5810.0.camel@localhost> <200706212226.00915.glen@delfi.ee> Message-ID: <20070621215628.GA14455@pld-linux.org> On Thu, Jun 21, 2007 at 10:26:00PM +0300, Elan Ruusam?e wrote: > On Thursday 21 June 2007 22:06, Tomasz Witek wrote: > > ok, but > > > > $ cal > > czerwiec 2007 > > N Pn Wt ?r Cz Pt So > > one letter for Sunday is ... > what? we have all days single letter ;) > > $ LC_ALL= LC_TIME=et_EE cal -m > juuni 2007 > E T K N R L P and here all week days start by letter 'd', so this: juny de 2007 dl dt dc dj dv ds dg 1 2 3 should be considered 2 or one letter ? :P -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From adam.ryba at gmail.com Fri Jun 22 00:25:50 2007 From: adam.ryba at gmail.com (Adam Ryba) Date: Fri, 22 Jun 2007 00:25:50 +0200 Subject: broken pl LC_TIME In-Reply-To: <20070621170334.GA11549@stranger.qboosh.pl> References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> Message-ID: 2007/6/21, Jakub Bogusz : > On Thu, Jun 21, 2007 at 06:02:44PM +0200, Tomasz Pala wrote: > > What the f* is that? > > > > [root at quarto /etc]# LC_TIME=pl_PL date > > Cz, 21 VI 2007, 18:02:04 CEST > > > > XICIIVIM months are archaic in polish. > > http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-June/141423.html IMHO using roman numerals is plain wrong. First and foremost it is not compliant with polish standard PN-EN 28601:2002 and international standard ISO 8601:2004. Dictionary rules allow use of roman numerals, but it is not obligatory. It just an option. -- Adam 'Pooh' Ryba From patrys at pld-linux.org Fri Jun 22 00:43:56 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Fri, 22 Jun 2007 00:43:56 +0200 Subject: NEW poldek 0.20070618.11.1 (Ac) In-Reply-To: <200706202335.50215.glen@delfi.ee> References: <200706172342.23069.arekm@maven.pl> <467966D4.3060808@o2.pl> <200706202335.50215.glen@delfi.ee> Message-ID: <89b6ba3a0706211543v5e2f8915le8d2fbbf902d4995@mail.gmail.com> On 6/20/07, Elan Ruusam?e wrote: > On Wednesday 20 June 2007, kiesiu wrote: > > Any suggestions? > > https://bugs.pld-linux.org/show_bug.cgi?id=25 Another goodie: Zapisywanie /home/users/patrys/tmp/[...]/packages.ndir.gz... B??d w obliczeniach zmiennoprzecinkowych Cannot reproduce (above says "floating point arithmetic error") -- Patryk Zawadzki Generated Content From gotar at polanet.pl Fri Jun 22 01:09:38 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 22 Jun 2007 01:09:38 +0200 Subject: broken pl LC_TIME In-Reply-To: References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> Message-ID: <20070621230937.GA19958@pepin.polanet.pl> On Fri, Jun 22, 2007 at 12:25:50AM +0200, Adam Ryba wrote: > > > > > > XICIIVIM months are archaic in polish. > > > > http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-June/141423.html > > IMHO using roman numerals is plain wrong. First and foremost it is not > compliant with polish standard PN-EN 28601:2002 and international > standard ISO 8601:2004. > > Dictionary rules allow use of roman numerals, but it is not > obligatory. It just an option. Exactly. There's absolutely no reason to use roman numbers. The most common and proper way is [day].mm.yyyy (day<10 with or without leading zero, two decimal month and four decimal year). However these dictionary rules don't meet PN either. I don't know what was the patch author intention, but thanks god he didn't use MCMLXXXVIII years... -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From sparky at pld-linux.org Fri Jun 22 03:42:50 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Fri, 22 Jun 2007 03:42:50 +0200 Subject: SOURCES: nightfall-desktop.patch (NEW) - fix some things In-Reply-To: References: Message-ID: <20070622014250.GA23894@pld-linux.org> On Fri, Jun 22, 2007 at 01:21:30AM +0200, lisu wrote: > Author: lisu Date: Thu Jun 21 23:21:30 2007 GMT > Module: SOURCES Tag: HEAD > ---- Log message: > - fix some things > ++Categories=Qt;KDE;Education;Science;Astronomy; if it's a qt/kde thing why does it use gtk ? i noticed that because there is no better application to start it's name with a 'K' knightfall (: -- ____ 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 Fri Jun 22 06:02:48 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Fri, 22 Jun 2007 06:02:48 +0200 (CEST) Subject: broken pl LC_TIME In-Reply-To: <1182455674.5810.6.camel@localhost> from "Tomasz Witek" at Jun 21, 2007 09:54:34 PM Message-ID: <200706220402.l5M42mlP012018@green.mif.pg.gda.pl> Tomasz Witek wrote: > > Dnia 21-06-2007, Cz o godzinie 21:33 +0200, Patryk Zawadzki napisa??(a): > > On 6/21/07, Tomasz Witek wrote: > > > ok, but > > > > > > $ cal > > > czerwiec 2007 > > > N Pn Wt ??r Cz Pt So > > > 1 2 > > > 3 4 5 6 7 8 9 > > > 10 11 12 13 14 15 16 > > > 17 18 19 20 21 22 23 > > > 24 25 26 27 28 29 30 > > > > > > one letter for Sunday is ... > > > > ...perfectly normal? > > > > Or do you prefer "the knights who call Sunday Ni"? > > > > > Why if all have two ? > > Nd ? "N " or " N" should solve it. -- ======================================================================= 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 glen at delfi.ee Fri Jun 22 08:43:29 2007 From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Fri, 22 Jun 2007 09:43:29 +0300 Subject: NEW poldek 0.20070618.11.1 (Ac) In-Reply-To: <89b6ba3a0706211543v5e2f8915le8d2fbbf902d4995@mail.gmail.com> References: <200706172342.23069.arekm@maven.pl> <200706202335.50215.glen@delfi.ee> <89b6ba3a0706211543v5e2f8915le8d2fbbf902d4995@mail.gmail.com> Message-ID: <200706220943.30256.glen@delfi.ee> On Friday 22 June 2007 01:43, Patryk Zawadzki wrote: > On 6/20/07, Elan Ruusam?e wrote: > > On Wednesday 20 June 2007, kiesiu wrote: > > > Any suggestions? > > > > https://bugs.pld-linux.org/show_bug.cgi?id=25 > > Another goodie: > > Zapisywanie /home/users/patrys/tmp/[...]/packages.ndir.gz... > B??d w obliczeniach zmiennoprzecinkowych > > Cannot reproduce (above says "floating point arithmetic error") oujee. it seems related with new poldek indexes, because it happened to the old poldek too: 09:40:25 root[pts/2]@ravenous /etc/poldek# poldek -c th.conf --up [...] Retrieving diff::packages.ndir.2007.06.21-15.13.01.gz... Applying packages.ndir.2007.06.21-15.13.01.gz... Writing /home/users/glen/tmp/[...]/packages.ndir.gz... Floating point exception 09:40:05 root[pts/2]@ravenous /etc/poldek# q poldek poldek-0.20-14.i686 -- glen From ankry at green.mif.pg.gda.pl Fri Jun 22 10:16:56 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Fri, 22 Jun 2007 10:16:56 +0200 (CEST) Subject: broken pl LC_TIME In-Reply-To: <20070621230937.GA19958@pepin.polanet.pl> References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> <20070621230937.GA19958@pepin.polanet.pl> Message-ID: On Fri, 22 Jun 2007, Tomasz Pala wrote: > On Fri, Jun 22, 2007 at 12:25:50AM +0200, Adam Ryba wrote: > > > > > > > > XICIIVIM months are archaic in polish. > > > > > > http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-June/141423.html > > > > IMHO using roman numerals is plain wrong. First and foremost it is not > > compliant with polish standard PN-EN 28601:2002 and international > > standard ISO 8601:2004. > > > > Dictionary rules allow use of roman numerals, but it is not > > obligatory. It just an option. > > Exactly. There's absolutely no reason to use roman numbers. The most > common and proper way is [day].mm.yyyy (day<10 with or without leading Numeric mm is NOT month name _abbreviayion_. I don't know whether it can be left undefined (en will be used?). > zero, two decimal month and four decimal year). However these dictionary > rules don't meet PN either. > I don't know what was the patch author intention, but thanks god he Intention is clearly explained in bugzilla references. IMO I/II/III is better than sty/lut/mar. But maybe yhey all should have trailing/leading spaces to keep fixed length. -- ======================================================================= 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 gotar at polanet.pl Fri Jun 22 11:20:58 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 22 Jun 2007 11:20:58 +0200 Subject: broken pl LC_TIME In-Reply-To: References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> <20070621230937.GA19958@pepin.polanet.pl> Message-ID: <20070622092058.GA9043@pepin.polanet.pl> On Fri, Jun 22, 2007 at 10:16:56AM +0200, Andrzej Krzysztofowicz wrote: > > > > Exactly. There's absolutely no reason to use roman numbers. The most > > common and proper way is [day].mm.yyyy (day<10 with or without leading > > Numeric mm is NOT month name _abbreviayion_. Yep. Roman numeric neither. These abbreviations don't exist thus we use numbers. Arabic numbers. > Intention is clearly explained in bugzilla references. And it's wrong. > IMO I/II/III is better than sty/lut/mar. Roman numbers ARE NOT abbreviations. They are obsoleted form of writing dates in numeric. > But maybe yhey all should have trailing/leading spaces to keep fixed length. We should not follow grammar from '70s. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From kiesyoo at o2.pl Fri Jun 22 13:51:09 2007 From: kiesyoo at o2.pl (kiesiu) Date: Fri, 22 Jun 2007 13:51:09 +0200 Subject: NEW poldek 0.20070618.11.1 (Ac) In-Reply-To: <200706202335.50215.glen@delfi.ee> References: <200706172342.23069.arekm@maven.pl> <467966D4.3060808@o2.pl> <200706202335.50215.glen@delfi.ee> Message-ID: <467BB7AD.8010109@o2.pl> Elan Ruusam?e pisze: > On Wednesday 20 June 2007, kiesiu wrote: >> Any suggestions? > > https://bugs.pld-linux.org/show_bug.cgi?id=25 > Thanks. It works for me. -- ?ukasz Kie? From hawk at limanowa.net Fri Jun 22 14:37:41 2007 From: hawk at limanowa.net (=?ISO-8859-2?Q?Marcin_Kr=F3l?=) Date: Fri, 22 Jun 2007 14:37:41 +0200 Subject: Looking for full mirror of PLD 2.0! Message-ID: <467BC295.9020609@limanowa.net> EN: Hello, I'm looking for full mirror of PLD 2.0 which wasn't updated after June 20th. I need to restore ac-updates indexes (the were deleted). If any one has such mirror (official ones have already resynced) please disable its synchronization and mail me ASAP. P.S. Partial mirrors are welcome too. Maybe I'll collect all indexes that way. PL: Witam, Poszukuje pelnego mirrora PLD 2.0, ktory nie byl aktualizowany po 20 czerwca. Potrzebuje odtworzyc indexy ac-updates (zostaly usuniete). Jezeli ktos posiada taki mirror (oficjalne niestety sie juz zsynchronizowaly) prosze o wylaczenie jego synchronizacji i jak najszybszy kontakt mailowy ze mna. P.S. Czesciowe mirrory tez mile widziane. Moze w ten sposob zbiore wszystkie indeksy. M. From ankry at green.mif.pg.gda.pl Fri Jun 22 14:52:45 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Fri, 22 Jun 2007 14:52:45 +0200 (CEST) Subject: broken pl LC_TIME In-Reply-To: <20070622092058.GA9043@pepin.polanet.pl> from "Tomasz Pala" at Jun 22, 2007 11:20:58 AM Message-ID: <200706221252.l5MCqjGk016273@green.mif.pg.gda.pl> Tomasz Pala wrote: > > Numeric mm is NOT month name _abbreviayion_. > > Yep. Roman numeric neither. These abbreviations don't exist thus we use > numbers. Arabic numbers. It is used instead of non-existent abreviation. What do you suggest to use if you want to write "17 lutego" shortly? "17.02" (eg.: 17.02 ) IMO 17.II is less misleading. But if you do not agree, talk to glibc-locale people (and do not forget to document your arguments with examples of current use). > > IMO I/II/III is better than sty/lut/mar. > > Roman numbers ARE NOT abbreviations. They are obsoleted form of writing > dates in numeric. Yeah. Don't forget to document that this form is no longer in use :) -- ======================================================================= 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 adam.ryba at gmail.com Fri Jun 22 15:29:47 2007 From: adam.ryba at gmail.com (Adam Ryba) Date: Fri, 22 Jun 2007 15:29:47 +0200 Subject: broken pl LC_TIME In-Reply-To: References: <20070621160244.GA15394@pepin.polanet.pl> <20070621170334.GA11549@stranger.qboosh.pl> <20070621230937.GA19958@pepin.polanet.pl> Message-ID: 2007/6/22, Andrzej Krzysztofowicz : > Intention is clearly explained in bugzilla references. > IMO I/II/III is better than sty/lut/mar. I have no idea, why "VII" is better and more readable than "lip". As for me, shortened names are better. According to http://www.rjp.pl/?mod=kr&type=ort&subtype=37&id=123 using sty/lut/mar... is acceptable, even if these names are not legal abbreviations (there is no legal and official abbreviation for weekdays and months names). BTW there is a note in bugzilla: > With the patch, dates are displayed as: > Pn, 6 VIII 1984, 01:23:45 CEST > which matches the most common usage. I do not remember last time I saw date with roman numerals. I have checked some legal papers, invoices and magazines... And there were no dates written like this. Is this really "most common usage"? IMHO this is rare and obsolete. -- Adam 'Pooh' Ryba From hawk at limanowa.net Fri Jun 22 16:36:03 2007 From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=) Date: Fri, 22 Jun 2007 16:36:03 +0200 Subject: [update] Looking for full mirror of PLD 2.0! In-Reply-To: <467BC295.9020609@limanowa.net> References: <467BC295.9020609@limanowa.net> Message-ID: <467BDE53.5080904@limanowa.net> EN: ac-supported indexes got smoked too :( ac-updates i686 will be soon restored to state from June 13th. If you wasn't updating your poldek indexes after that day you are lucky. Other people will need to do --upa. If you had bad luck and updated your indexes today or yesterday you have to do --upa for second time. My apologies for that. I'm still searching for other indexes. PL: Indeksy ac-supported tez poszly w kosmos :( Indeksy ac-updates dla i686 beda niebawem odtworzone do stanu z 13 czerwca. Jezeli nie uaktualniales swoich lokalnych indeksow poldka po tej dacie masz szczescie. Pozostale osoby beda musialy zrobic --upa. Jezeli masz pecha byc wsrod osob, ktore uaktualnialy swoje indeksy dzis lub wczoraj bedziesz musial zrobic --upa po raz drugi. Przepraszam za problemy. Ciagle poszukuje pozostalych indeksow. M. From dhubleizh at o2.pl Fri Jun 22 21:14:29 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Fri, 22 Jun 2007 21:14:29 +0200 Subject: createrepo slowness - reconsidering yum indexes in pld th support In-Reply-To: <200706212205.28860.arekm@maven.pl> References: <200706212205.28860.arekm@maven.pl> Message-ID: <1182539669.3559.4.camel@ipv6-localnet> Dnia 21-06-2007, Cz o godzinie 22:05 +0200, Arkadiusz Miskiewicz napisa?(a): > Currently it's called as: > > os.system('%s.stat/bin/createrepo --cache %s/tmp/createrepo %s%s/%s/RPMS' % > (ftp_dir,home,ftp_dir,tree,arch)) Well, as noted it uses cache. I can't make anything out of it. Maybe ensure correct rights to %s/tmp/createrepo?? Ensure it is using it?? That dates there change, or something? Cz at rny From mis at pld-linux.org Fri Jun 22 21:47:24 2007 From: mis at pld-linux.org (=?ISO-8859-2?Q?Pawe=B3_A._Gajda?=) Date: Fri, 22 Jun 2007 21:47:24 +0200 Subject: NEW poldek 0.20070618.11.1 (Ac) In-Reply-To: <200706220943.30256.glen@delfi.ee> References: <200706172342.23069.arekm@maven.pl> <200706202335.50215.glen@delfi.ee> <89b6ba3a0706211543v5e2f8915le8d2fbbf902d4995@mail.gmail.com> <200706220943.30256.glen@delfi.ee> Message-ID: On 6/22/07, Elan Ruusam?e wrote: > On Friday 22 June 2007 01:43, Patryk Zawadzki wrote: > > > > Zapisywanie /home/users/patrys/tmp/[...]/packages.ndir.gz... > > B??d w obliczeniach zmiennoprzecinkowych > > > > oujee. it seems related with new poldek indexes, because it happened to the > old poldek too: > > Writing /home/users/glen/tmp/[...]/packages.ndir.gz... > Floating point exception > 09:40:05 root[pts/2]@ravenous /etc/poldek# q poldek > poldek-0.20-14.i686 Weird, nothing change in the "ndir" code lately. Is this reproducible? I've tested indexes for 4 hours today and works fine. Maybe something is wrong with openssl's libcrypto from Th? Anyway, you can try to catch the problem with tests/test_patch.sh script from poldek distribution. Script creates testing repo, then a) add/remove packages from it b) --mkidx c) --up d) goto a). All you need is local package source, and remote accessible directory for testing repo. From gotar at polanet.pl Sat Jun 23 12:06:52 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 23 Jun 2007 12:06:52 +0200 Subject: broken pl LC_TIME In-Reply-To: <200706221252.l5MCqjGk016273@green.mif.pg.gda.pl> References: <20070622092058.GA9043@pepin.polanet.pl> <200706221252.l5MCqjGk016273@green.mif.pg.gda.pl> Message-ID: <20070623100651.GA13305@pepin.polanet.pl> On Fri, Jun 22, 2007 at 02:52:45PM +0200, Andrzej Krzysztofowicz wrote: > > IMO 17.II is less misleading. But if you do not agree, talk to glibc-locale First of all - 17.II with dot between them is grammar mistake. Hey! I've found we need to change clock too: http://www.zegarkiclub.pl/forum/viewtopic.php?t=8334&sid=7cced6260274a9d3f50628115ccc03b2 apparently most common in Poland is 12h system with roman numbers for hours. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From ankry at green.mif.pg.gda.pl Sat Jun 23 13:05:10 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Sat, 23 Jun 2007 13:05:10 +0200 (CEST) Subject: broken pl LC_TIME In-Reply-To: <20070623100651.GA13305@pepin.polanet.pl> from "Tomasz Pala" at Jun 23, 2007 12:06:52 PM Message-ID: <200706231105.l5NB5Abp030334@green.mif.pg.gda.pl> Tomasz Pala wrote: > Hey! I've found we need to change clock too: > http://www.zegarkiclub.pl/forum/viewtopic.php?t=8334&sid=7cced6260274a9d3f50628115ccc03b2 > > apparently most common in Poland is 12h system with roman numbers for > hours. This is definitely wrong list. -- ======================================================================= 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 hawk at limanowa.net Sat Jun 23 14:13:44 2007 From: hawk at limanowa.net (=?ISO-8859-2?Q?Marcin_Kr=F3l?=) Date: Sat, 23 Jun 2007 14:13:44 +0200 Subject: Ac poldek indexes are now fixed Message-ID: <467D0E78.5040103@limanowa.net> EN: Short backstory: between June 18th and June 21st all Ac poldek indexes for following trees: updates, supported, ready and test were deleted (instead of being updated) and regenerated from scratch using snapshot of poldek 0.21. Unfortunately these new indexes were somehow broken because both stable and snapshot poldek were occasionally throwing "floating point exception" when using them. Today all indexes were deleted again and regenerated from scratch using stable version of poldek. Since we have no backups of our ftp and all mirrors are syncing to often to serve as ones we lost all incremental diffs for all architectures. The only exception is i686: ac-updates indexes for i686 were partially recovered, following diffs were lost: packages.ndir.dscr.i18n.2007.06.16-20.39.12.gz packages.ndir.dscr.i18n.2007.06.14-23.55.56.gz packages.ndir.dscr.i18n.2007.06.14-13.51.54.gz packages.ndir.dscr.i18n.2007.06.13-23.11.13.gz packages.ndir.dscr.i18n.2007.06.12-12.24.47.gz so if you were updating your indexes on or after June 12th you must do poldek --upa now. ac-supported indexes for i686 were completly recovered. Sorry for any inconvenience this situation may cause. PL: Krotka historia: w dniach miedzy 18 a 21 czerwca wszystkie indeksy poldka dla drzewek Ac: updates, supported, ready, test zostaly usuniete (zamiast uaktualnione) i przegenerowane od zera z uzyciem snaphsotu poldka 0.21. Niestety nowe indeksy wygladaly na uszkodzone poniewaz zarowno stabilny poldek jak i snapshot okazyjnie rzucaly na ekran bledem operacji zmiennoprzecinkowych w czasie korzystania z indeksow. Dzis wszystkie indeksy zostaly ponownie usuniete i przegenerowane od zera z uzyciem stabilnej wersji poldka. Poniewaz nie ftp nie jest backupowany, a mirrory synchronizuja sie zbyt czesto aby robic za backup stracilismy wszystkie inkrementowane diffy dla wszystkich architektur. Wyjatkiem jest i686: Indeksy ac-updates dla i686 udalo sie czesciowo odtworzyc. Stracone zostaly tylko diffy: packages.ndir.dscr.i18n.2007.06.16-20.39.12.gz packages.ndir.dscr.i18n.2007.06.14-23.55.56.gz packages.ndir.dscr.i18n.2007.06.14-13.51.54.gz packages.ndir.dscr.i18n.2007.06.13-23.11.13.gz packages.ndir.dscr.i18n.2007.06.12-12.24.47.gz tak wiec jezeli ktos uaktualnia indeksy 12 czerwca lub pozniej musi zrobic poldek --upa. Indesky ac-supported dla i686 zostaly odzyskane w calosci. Przepraszam za wszelkie niedogodnosci jakie moga wynikac z tej sytuacji. M. From ankry at green.mif.pg.gda.pl Sat Jun 23 19:46:27 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Sat, 23 Jun 2007 19:46:27 +0200 (CEST) Subject: broken pl LC_TIME In-Reply-To: <200706231105.l5NB5Abp030334@green.mif.pg.gda.pl> from "Andrzej Krzysztofowicz" at Jun 23, 2007 01:05:10 PM Message-ID: <200706231746.l5NHkRkm031242@green.mif.pg.gda.pl> OK. So I finally checked what date format is commonly used in newest printed sources. It is with roman numbers for months. References: Multimedialna Encyklopedia Brittanica (C) 2006 N. Davies "Wyspy", translation (C) 2003 This sources are just the first modern books containing dates inside that I found. BTW, it is not my intention to prove that "17 XII 1999" is the only valid date format in pl. My intension is to prove that the statement claiming it is invalid for 30 years is simply false. -- ======================================================================= 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 Sat Jun 23 21:41:19 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Sat, 23 Jun 2007 21:41:19 +0200 Subject: SOURCES: linux-nvidia.patch (NEW) - http://download.nvidia.com/XFr... In-Reply-To: References: Message-ID: <20070623194119.GA19728@pld-linux.org> On Sat, Jun 23, 2007 at 08:28:39PM +0200, marcus wrote: > Author: marcus Date: Sat Jun 23 18:28:39 2007 GMT > Module: SOURCES Tag: HEAD > ---- Log message: > - http://download.nvidia.com/XFree86/nforce/1.21/NFORCE-Linux-x86-1.21.zip > > ++#define RHES3 0 > ++#define SLES9 1 > ++#define RHES4 2 > ++#define SUSE10 3 > ++#define FEDORA5 4 > ++ > ++ > ++#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,13) > ++#define NVVER FEDORA5 > ++#elif LINUX_VERSION_CODE > KERNEL_VERSION(2,6,9) > ++#define NVVER SUSE10 > ++#elif LINUX_VERSION_CODE > KERNEL_VERSION(2,6,6) > ++#define NVVER RHES4 > ++#elif LINUX_VERSION_CODE > KERNEL_VERSION(2,6,0) > ++#define NVVER SLES9 > ++#else > ++#define NVVER RHES3 > ++#endif lol, that sucks very, very badly :P -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From hawk at limanowa.net Sat Jun 23 23:07:21 2007 From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=) Date: Sat, 23 Jun 2007 23:07:21 +0200 Subject: Ac poldek indexes are now fixed In-Reply-To: <467D0E78.5040103@limanowa.net> References: <467D0E78.5040103@limanowa.net> Message-ID: <467D8B89.8000104@limanowa.net> EN: Correction. Full indexes of ac-updates for i686 have been recovered. PL: Poprawka. Pelne indeksy ac-updates dla i686 zostaly odtworzone. M. From gotar at polanet.pl Sun Jun 24 10:56:17 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 24 Jun 2007 10:56:17 +0200 Subject: broken pl LC_TIME In-Reply-To: <200706231746.l5NHkRkm031242@green.mif.pg.gda.pl> References: <200706231105.l5NB5Abp030334@green.mif.pg.gda.pl> <200706231746.l5NHkRkm031242@green.mif.pg.gda.pl> Message-ID: <20070624085617.GA24747@pepin.polanet.pl> On Sat, Jun 23, 2007 at 07:46:27PM +0200, Andrzej Krzysztofowicz wrote: > > BTW, it is not my intention to prove that "17 XII 1999" is the only valid > date format in pl. My intension is to prove that the statement claiming it > is invalid for 30 years is simply false. Not 'invalid' but archaic. Just like our past perfect tense. And that's not the case as you have noticed yourself - "17 XII 1999" is NUMERIC format for full date (day, mount, year). Do you understand such a sentence: "W Pn b?dziemy jechali"? I do. How about "Na wakacjach jest do po?owy sie"? I do. But I doubt anyone will "Na wakacjach jest do po?owy VIII". It looks like 8th century. And there's a link to RJP. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From mlukaszek at gmail.com Sun Jun 24 11:21:27 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Sun, 24 Jun 2007 11:21:27 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: <20070619155843.GA6317@smok.emunet.pl> References: <20070619155843.GA6317@smok.emunet.pl> Message-ID: On 6/19/07, Pawe? A. Gajda wrote: > Fixed too, try new snap. Here's another one: poldek:/all-avail> desc p7zip Package: p7zip-4.47-1.x86_64 Summary: ?w z najwy?szym stopniem kompresji Group: Applications/Archiving License: LGPL Arch/OS/Color: x86_64/linux/2 URL: http://p7zip.sourceforge.net/ Built: 2007/06/01 11:32 at builderth Size: 2.4 MB (2503838 B) Package size: 668.0 KB (684914 B) Path: ftp://ftp.th.pld-linux.org/dists/th/PLD/x86_64/RPMS File: p7zip-4.47-1.x86_64.rpm Description: ?w z najwy?szym stopniem kompresji. G??wne cechy formatu 7z: - otwarta architektura, - wysoki stopie? kompresji, - silne kodowanie AES-256, - mo?liwo?? u?ywania dowolnych metod kodowania, kompresji, konwersji, - obs?uga bardzo du?ych plik?w (powy?ej 16000000000 GB), - obs?uga nazw plik?w w unikodzie, - kompresja upakowana, - kompresja nag??wk?w archiwum. *** glibc detected *** poldek: munmap_chunk(): invalid pointer: 0x00007fffe3aa238c *** ======= Backtrace: ========= /lib64/libc.so.6[0x2ac5c7b644ad] /usr/lib64/libpoldek.so.0(pkguinf_free+0xa5)[0x2ac5c7450b65] /usr/lib64/libpoclidek.so.0[0x2ac5c7230669] /usr/lib64/libpoclidek.so.0[0x2ac5c7226a13] /usr/lib64/libpoclidek.so.0[0x2ac5c7226ae6] poldek[0x40265a] poldek[0x40365f] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2ac5c7b13b54] poldek[0x4022a9] ======= Memory map: ======== 00400000-00405000 r-xp 00000000 03:03 1490307 /usr/bin/poldek 00605000-00606000 rw-p 00005000 03:03 1490307 /usr/bin/poldek 00606000-0194a000 rw-p 00606000 00:00 0 [heap] 2ac5c7002000-2ac5c701d000 r-xp 00000000 03:03 2736740 /lib64/ld-2.6.so 2ac5c701d000-2ac5c701e000 rw-p 2ac5c701d000 00:00 0 2ac5c7037000-2ac5c7038000 rw-p 2ac5c7037000 00:00 0 2ac5c7038000-2ac5c715f000 r--p 00000000 03:03 1622018 /usr/lib64/locale/locale-archive 2ac5c715f000-2ac5c7169000 r--p 00000000 03:03 1490311 /usr/share/locale/pl/LC_MESSAGES/poldek.mo 2ac5c7169000-2ac5c7170000 r--s 00000000 03:03 1494477 /usr/lib64/gconv/gconv-modules.cache 2ac5c7170000-2ac5c7183000 rw-p 2ac5c7170000 00:00 0 2ac5c7188000-2ac5c7211000 rw-p 2ac5c7188000 00:00 0 2ac5c721c000-2ac5c721d000 r--p 0001a000 03:03 2736740 /lib64/ld-2.6.so 2ac5c721d000-2ac5c721e000 rw-p 0001b000 03:03 2736740 /lib64/ld-2.6.so 2ac5c721e000-2ac5c7237000 r-xp 00000000 03:03 1490301 /usr/lib64/libpoclidek.so.0.0.0 2ac5c7237000-2ac5c7437000 ---p 00019000 03:03 1490301 /usr/lib64/libpoclidek.so.0.0.0 2ac5c7437000-2ac5c743b000 rw-p 00019000 03:03 1490301 /usr/lib64/libpoclidek.so.0.0.0 2ac5c743b000-2ac5c74a6000 r-xp 00000000 03:03 1490302 /usr/lib64/libpoldek.so.0.1.0 2ac5c74a6000-2ac5c76a5000 ---p 0006b000 03:03 1490302 /usr/lib64/libpoldek.so.0.1.0 2ac5c76a5000-2ac5c76aa000 rw-p 0006a000 03:03 1490302 /usr/lib64/libpoldek.so.0.1.0 2ac5c76aa000-2ac5c76ac000 rw-p 2ac5c76aa000 00:00 0 2ac5c76ac000-2ac5c76b8000 r-xp 00000000 03:03 1490304 /usr/lib64/libtrurl.so.0.6.0 2ac5c76b8000-2ac5c78b7000 ---p 0000c000 03:03 1490304 /usr/lib64/libtrurl.so.0.6.0 2ac5c78b7000-2ac5c78b8000 rw-p 0000b000 03:03 1490304 /usr/lib64/libtrurl.so.0.6.0 2ac5c78b8000-2ac5c78b9000 rw-p 2ac5c78b8000 00:00 0 2ac5c78b9000-2ac5c78ee000 r-xp 00000000 03:03 2572414 /lib64/libreadline.so.5.2 2ac5c78ee000-2ac5c7aed000 ---p 00035000 03:03 2572414 /lib64/libreadline.so.5.2 2ac5c7aed000-2ac5c7af5000 rw-p 00034000 03:03 2572414 /lib64/libreadline.so.5.2 2ac5c7af5000-2ac5c7af6000 rw-p 2ac5c7af5000 00:00 0 2ac5c7af6000-2ac5c7c30000 r-xp 00000000 03:03 2736747 /lib64/libc-2.6.so 2ac5c7c30000-2ac5c7e2f000 ---p 0013a000 03:03 2736747 /lib64/libc-2.6.so 2ac5c7e2f000-2ac5c7e32000 r--p 00139000 03:03 2736747 /lib64/libc-2.6.so 2ac5c7e32000-2ac5c7e34000 rw-p 0013c000 03:03 2736747 /lib64/libc-2.6.so 2ac5c7e34000-2ac5c7e39000 rw-p 2ac5c7e34000 00:00 0 2ac5c7e39000-2ac5c7e4b000 r-xp 00000000 03:03 1490305 /usr/lib64/libvfile.so.0.0.0 2ac5c7e4b000-2ac5c804b000 ---p 00012000 03:03 1490305 /usr/lib64/libvfile.so.0.0.0 2ac5c804b000-2ac5c804c000 rw-p 00012000 03:03 1490305 /usr/lib64/libvfile.so.0.0.0 2ac5c804c000-2ac5c804f000 rw-p 2ac5c804c000 00:00 0 2ac5c804f000-2ac5c8074000 r-xp 00000000 03:03 4801265 /lib64/libpcre.so.0.0.1 2ac5c8074000-2ac5c8274000 ---p 00025000 03:03 4801265 /lib64/libpcre.so.0.0.1 2ac5c8274000-2ac5c8275000 rw-p 00025000 03:03 4801265 /lib64/libpcre.so.0.0.1 2ac5c8275000-2ac5c828a000 r-xp 00000000 03:03 2736763 /lib64/libpthread-2.6.so 2ac5c828a000-2ac5c848a000 ---p 00015000 03:03 2736763 Przerwane [prism at laptop ~]$ rpm -q poldek poldek-0.21-0.20070623.21.2.x86_64 -- regards, Micha? ?ukaszek prism at pld-linux.org From mlukaszek at gmail.com Sun Jun 24 15:33:58 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Sun, 24 Jun 2007 15:33:58 +0200 Subject: NEW poldek 0.20070617.23 - please test In-Reply-To: References: <20070619155843.GA6317@smok.emunet.pl> Message-ID: On 6/24/07, Micha? ?ukaszek wrote: > On 6/19/07, Pawe? A. Gajda wrote: > > > Fixed too, try new snap. > > Here's another one: And another: $ LC_ALL=C po -n th-i686 -n th-test-i686 Loading [pndir]th... Loading [pndir]th... Loading [pndir]th-test... Loading [pndir]th-test... Loading [pndir]th-i686... Loading [pndir]th-test-i686... 24359 packages read Loading [rpmdbcache]/var/lib/rpm... 953 packages loaded Welcome to the poldek shell mode. Type "help" for help with commands. poldek:/all-avail> install crossmingw32-gcc-4.1.2-1.x86_64 -t Processing dependencies... crossmingw32-gcc-4.1.2-1.x86_64 marks crossmingw32-binutils-2.17.50.0.17-1.i686 (cap crossmingw32-binutils >= 2.15.91.0.2-2) crossmingw32-gcc-4.1.2-1.x86_64 marks gcc-dirs-1.0-4.i686 (cap gcc-dirs) There are 3 packages to install (2 marked by dependencies): I crossmingw32-gcc-4.1.2-1.x86_64 D crossmingw32-binutils-2.17.50.0.17-1.i686, gcc-dirs-1.0-4.i686 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Need to get 3.1MB of archives (3.1MB to download). After unpacking 14.5MB will be used. poldek:/all-avail> ll crossmingw32-binutils-* gcc-dirs-* package build date size crossmingw32-binutils-2.17.50.0.17-1.i686 2007/06/21 00:09 8.5 MB crossmingw32-binutils-2.17.50.0.17-1.x86_64 2007/06/21 00:16 10.0 MB crossmingw32-binutils-debuginfo-2.17.50.0.17-1.i686 2007/06/21 00:09 57.3 MB crossmingw32-binutils-debuginfo-2.17.50.0.17-1.x86_64 2007/06/21 00:16 83.8 MB gcc-dirs-1.0-4.i686 2005/12/09 02:30 gcc-dirs-1.0-4.x86_64 2005/12/09 02:51 6 packages, 159.5 MB When I'm specifying x86_64 package to be installed, i686 alternatives should have lower priority during resolving dependencies. -- regards, Micha? ?ukaszek prism at pld-linux.org From ankry at green.mif.pg.gda.pl Sun Jun 24 16:38:10 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Sun, 24 Jun 2007 16:38:10 +0200 (CEST) Subject: broken pl LC_TIME In-Reply-To: <20070624085617.GA24747@pepin.polanet.pl> from "Tomasz Pala" at Jun 24, 2007 10:56:17 AM Message-ID: <200706241438.l5OEcAeH013003@green.mif.pg.gda.pl> Tomasz Pala wrote: > > On Sat, Jun 23, 2007 at 07:46:27PM +0200, Andrzej Krzysztofowicz wrote: > > > > BTW, it is not my intention to prove that "17 XII 1999" is the only valid > > date format in pl. My intension is to prove that the statement claiming it > > is invalid for 30 years is simply false. > > Not 'invalid' but archaic. Just like our past perfect tense. Not archaic as used in modern sources. > And that's not the case as you have noticed yourself - "17 XII 1999" is > NUMERIC format for full date (day, mount, year). Do you understand such > a sentence: "W Pn b?dziemy jechali"? I do. How about "Na wakacjach jest Do you think "W nie b?dziemy jechali" is better? But these are irrelevant. Let's concentrate on examples: which program uses weekday/month abreviations in the way you mention? > do po?owy sie"? I do. But I doubt anyone will "Na wakacjach jest do > po?owy VIII". It looks like 8th century. And there's a link to RJP. -- ======================================================================= 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 patrys at pld-linux.org Mon Jun 25 15:48:35 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Mon, 25 Jun 2007 15:48:35 +0200 Subject: createrepo slowness - reconsidering yum indexes in pld th support In-Reply-To: <1182539669.3559.4.camel@ipv6-localnet> References: <200706212205.28860.arekm@maven.pl> <1182539669.3559.4.camel@ipv6-localnet> Message-ID: <89b6ba3a0706250648k7ab4ba72h7357cae8998c5d13@mail.gmail.com> On 6/22/07, Cezary Krzyzanowski wrote: > Dnia 21-06-2007, Cz o godzinie 22:05 +0200, Arkadiusz Miskiewicz > napisa?(a): > > > Currently it's called as: > > > > os.system('%s.stat/bin/createrepo --cache %s/tmp/createrepo %s%s/%s/RPMS' % > > (ftp_dir,home,ftp_dir,tree,arch)) > > Well, as noted it uses cache. I can't make anything out of it. Maybe > ensure correct rights to %s/tmp/createrepo?? Ensure it is using it?? > That dates there change, or something? Maybe it uses some attributes (mtime, ctime) that are turned off for the temp dir? -- Patryk Zawadzki Generated Content From gotar at polanet.pl Wed Jun 27 14:27:54 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 27 Jun 2007 14:27:54 +0200 Subject: builder malfunction? Message-ID: <20070627122754.GA2840@pepin.polanet.pl> $ ./builder -bb -r PG_7 postgresql.spec --without tcl --without perl --without python M postgresql.spec # $Revision: 1.288.2.6 $, $Date: 2006/01/08 16:57:08 $ Building postgresql.spec with the following conditional flags: --without tcl --without perl --without python from available: --with : absolute_dbpaths jdbc --without: kerberos5 pgsql_locale pgsql_multibyte slony1 tests Available branches: POSTGRESQL_8_1 AC-branch PG_7 DEVEL RA-branch_security RA-branch-pg73 LEFTHAND RA-branch Error: some source, patch or icon files not stored in CVS repo. (pgsql-Database-HOWTO-html.tar.gz) Why doesn't it use DF to fetch this source? $ ./builder -sd postgresql.spec builder: Stick tag PG_7 active. Use -r TAGNAME to override. ftp://distfiles.pld-linux.org/distfiles/by-md5/c/d/cdb4b2cd37e9c26773cddeebfa960675/postgresql-7.4.17.tar.bz2 ftp://distfiles.pld-linux.org/distfiles/by-md5/5/b/5b656ddf1db41965761f85204a14398e/pgsql-Database-HOWTO-html.tar.gz ftp://distfiles.pld-linux.org/distfiles/by-md5/2/8/2896d5a6dbf1b40002fd5713bc350ae4/slony1-1.0.6.tar.gz After manual downloading of pgsql-Database-HOWTO-html.tar.gz into SOURCES slony1 is get from URL instead of DF too. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From qboosh at pld-linux.org Sun Jun 24 16:55:42 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 24 Jun 2007 16:55:42 +0200 Subject: builder - Source vs distfiles priority Message-ID: <20070624145542.GA9944@stranger.qboosh.pl> It seems that current (HEAD) builder tries to fetch source from SourceX URL (mirror) first... but distfiles (or its mirror) should have higher priority. Unless -nd (or some equivalent upgrade option) is given. Same for sources/patches with URLs and NoSource*-md5, for which CVS should have higher priority than Source/Patch URL. Or at least some configuration option should exist to select preferred source of files. -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Thu Jun 28 20:07:06 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 28 Jun 2007 20:07:06 +0200 Subject: db4.5 rel 5 in th-test Message-ID: <200706282007.07648.arekm@maven.pl> Please be very careful when upgrading db4.5 rel 5 from th-test. It contains new patch that looks problematic on (it looks like) some kernel versions while works nicely on others (no problem seen on carme for example). The problem is: rpmdb: unable to initialize mutex: Operation not supported error: cannot open Packages index using db3 - Operation not supported (95) error: cannot open Packages database in /var/lib/rpm rpmdb: unable to initialize mutex: Operation not supported error: cannot open Packages database in /var/lib/rpm -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From mlukaszek at gmail.com Thu Jun 28 20:47:14 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Thu, 28 Jun 2007 20:47:14 +0200 Subject: db4.5 rel 5 in th-test In-Reply-To: <200706282007.07648.arekm@maven.pl> References: <200706282007.07648.arekm@maven.pl> Message-ID: On 6/28/07, Arkadiusz Miskiewicz wrote: > Please be very careful when upgrading db4.5 rel 5 from th-test. It contains > new patch that looks problematic on (it looks like) some kernel versions > while works nicely on others (no problem seen on carme for example). More details please? Which kernel version do you mean? -- regards, Micha? ?ukaszek prism at pld-linux.org From arekm at maven.pl Thu Jun 28 20:59:06 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 28 Jun 2007 20:59:06 +0200 Subject: db4.5 rel 5 in th-test In-Reply-To: References: <200706282007.07648.arekm@maven.pl> Message-ID: <200706282059.06923.arekm@maven.pl> On Thursday 28 of June 2007, Micha? ?ukaszek wrote: > On 6/28/07, Arkadiusz Miskiewicz wrote: > > Please be very careful when upgrading db4.5 rel 5 from th-test. It > > contains new patch that looks problematic on (it looks like) some kernel > > versions while works nicely on others (no problem seen on carme for > > example). > > More details please? Which kernel version do you mean? Problem seen on: x86_64: 2.6.16.45-1 i686: 2.6.16-2-vserver-amd64-k8 ppc: 2.6.15-1-powerpc64 Not seen on: athlon: 2.6.17-2-vserver-amd64 x86_64: 2.6.20.4-1 i486: 2.6.17-2-vserver-686 So probably you are safe when using kernel >= 2.6.17. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Thu Jun 28 21:08:56 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 28 Jun 2007 21:08:56 +0200 Subject: db4.5 rel 5 in th-test In-Reply-To: <200706282059.06923.arekm@maven.pl> References: <200706282007.07648.arekm@maven.pl> <200706282059.06923.arekm@maven.pl> Message-ID: <200706282108.56766.arekm@maven.pl> On Thursday 28 of June 2007, Arkadiusz Miskiewicz wrote: > On Thursday 28 of June 2007, Micha? ?ukaszek wrote: > > On 6/28/07, Arkadiusz Miskiewicz wrote: > > > Please be very careful when upgrading db4.5 rel 5 from th-test. It > > > contains new patch that looks problematic on (it looks like) some > > > kernel versions while works nicely on others (no problem seen on carme > > > for example). > > > > More details please? Which kernel version do you mean? > > Problem seen on: > x86_64: 2.6.16.45-1 > i686: 2.6.16-2-vserver-amd64-k8 > ppc: 2.6.15-1-powerpc64 > > Not seen on: > athlon: 2.6.17-2-vserver-amd64 > x86_64: 2.6.20.4-1 > i486: 2.6.17-2-vserver-686 > > So probably you are safe when using kernel >= 2.6.17. I've finally disabled the patch in rel 6. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From qboosh at pld-linux.org Fri Jun 29 11:18:16 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 29 Jun 2007 11:18:16 +0200 Subject: db4.5 rel 5 in th-test In-Reply-To: <200706282007.07648.arekm@maven.pl> References: <200706282007.07648.arekm@maven.pl> Message-ID: <20070629091816.GA14125@mail> On Thu, Jun 28, 2007 at 08:07:06PM +0200, Arkadiusz Miskiewicz wrote: > Please be very careful when upgrading db4.5 rel 5 from th-test. It contains > new patch that looks problematic on (it looks like) some kernel versions > while works nicely on others (no problem seen on carme for example). > > The problem is: > rpmdb: unable to initialize mutex: Operation not supported IIRC robust mutexes are realtively new feature, so they probably need recent kernel version. -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Fri Jun 29 11:38:51 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Fri, 29 Jun 2007 11:38:51 +0200 Subject: db4.5 rel 5 in th-test In-Reply-To: <20070629091816.GA14125@mail> References: <200706282007.07648.arekm@maven.pl> <20070629091816.GA14125@mail> Message-ID: <200706291138.52332.arekm@maven.pl> On Friday 29 of June 2007, Jakub Bogusz wrote: > On Thu, Jun 28, 2007 at 08:07:06PM +0200, Arkadiusz Miskiewicz wrote: > > Please be very careful when upgrading db4.5 rel 5 from th-test. It > > contains new patch that looks problematic on (it looks like) some kernel > > versions while works nicely on others (no problem seen on carme for > > example). > > > > The problem is: > > rpmdb: unable to initialize mutex: Operation not supported > > IIRC robust mutexes are realtively new feature, so they probably need > recent kernel version. >= 2.6.17 it seems. What I'm more interested in is impact of that robustness patch on software other than rpm itself. Will it cause problems and so on... -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From n3npq at mac.com Fri Jun 29 13:08:26 2007 From: n3npq at mac.com (Jeff Johnson) Date: Fri, 29 Jun 2007 07:08:26 -0400 Subject: db4.5 rel 5 in th-test In-Reply-To: <200706291138.52332.arekm@maven.pl> References: <200706282007.07648.arekm@maven.pl> <20070629091816.GA14125@mail> <200706291138.52332.arekm@maven.pl> Message-ID: <90A2D5AA-CF89-4B52-84DF-8F4A9FFF8AD0@mac.com> On Jun 29, 2007, at 5:38 AM, Arkadiusz Miskiewicz wrote: > > What I'm more interested in is impact of that robustness patch on > software > other than rpm itself. Will it cause problems and so on... > When one inherits a lock, then one also inherits the responsibility for insuring that whatever the lock was protecting is sane. For rpm, the Berkeley DB access patterns are simple and predictable. Header data used for secondary lookup is verified with digests. The benefit of avoiding a deadlock (that can only be cleared by rebooting) outweighs the risk of ignoring side effects and clearing the lock. Even if that assumption is wrong, the header sha1 will detect damaged headers and --rebuilddb will regenerate indices. I don't think that the robust mutex patch can simply be pushed into system db. One could/should add a flag to explicitly enable the functionality and the default behavior of system db should not use robust mutexes. 73 de Jeff