From arekm at maven.pl Wed Mar 4 09:50:45 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 4 Mar 2009 09:50:45 +0100 Subject: INFO: Parallel single builds on Th builders starting today Message-ID: <200903040950.46112.arekm@maven.pl> Starting from today Th builders will do parallel builds by default where possible (where parallel mean that single build is using make -jX). x86_64 and ppc builders are doing -j1 builds because machines probably won't be able to handle higher values well. x86_64, ppc: max_jobs = 2, default 1 i486, i686: max_jobs =16, default 12 athlon: max_jobs = 8, default 6 make-request.sh has now a "-j" option that allows user to choose different value than default ones. Note that if user specifies value that doesn't match <1, max_jobs config option specified on builder> range then builder default will be used. -t -j1 can be used to test if some build succeeds without parallel make. http://ep09.pld-linux.org/~builderth/queue.html shows jobs=X value where X always show what user requested (or 0 if used didn't use -jX at all). Of course <1, max_jobs config option specified on builder> still applies so there can be jobs=1000 in queue while builder will use -j1 because that's what max_jobs said. If some app has broken build system then: * -t -j1 can be used to test if some build succeeds without parallel make * workaround in spec is to put -j1 there -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Mon Mar 9 22:41:12 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 9 Mar 2009 22:41:12 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? Message-ID: <200903092241.12695.arekm@maven.pl> I'm considering dropping athlon architecture since I see no real gain over i686. athlon would be deleted from ftp and athlon->i686 symlink created. The other platform is ppc. There is unforuntately close to zero developers solving ppc related bugs :-( ppc would be moved to unsupported or something like unofficial sparc (AIDA) as seen on ftp. Someone would have to step in to maintain this. Opinions? Current plan is to do this on a incoming weekend. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Tue Mar 10 00:07:09 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 10 Mar 2009 01:07:09 +0200 Subject: Bug #336742 in PLD Linux: =?utf-8?q?=E2=80=9Cgconv-modules=2Ecache_invalid_for_32bit_apps_on?= =?utf-8?q?_multilib=E2=80=9D?= Message-ID: <200903100107.09565.glen@pld-linux.org> https://bugs.launchpad.net/pld-linux/+bug/336742 plz somebody answer on comment #1 -- glen From sparky at pld-linux.org Tue Mar 10 00:10:52 2009 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Tue, 10 Mar 2009 00:10:52 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903092241.12695.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> Message-ID: <20090309231052.GA29014@pld-linux.org> On Mon, Mar 09, 2009 at 10:41:12PM +0100, Arkadiusz Miskiewicz wrote: > > I'm considering dropping athlon architecture since I see no real gain over > i686. athlon would be deleted from ftp and athlon->i686 symlink created. Personally I use "athlon", but for binary crap only, which is built for i386/i586 anyways, so I'm OK with dropping it. > The other platform is ppc. There is unforuntately close to zero developers > solving ppc related bugs :-( ppc would be moved to unsupported or something > like unofficial sparc (AIDA) as seen on ftp. Someone would have to step in to > maintain this. Even tho I'm not very acrive (lately), I could step up as ppc maintainer when it becomes AIDA. I could be fixing the packages I use, or if someone asks me nicely to fix some (payment in goats no longer accepted). All the packages that build cleanly on main th archs and have no history of being problematic on powerpc would be send to ppc builder as well. If some package starts to give problems and there would be noone to fix it, it would be banned from ppc builder and last package in main repository would be kept until its bependencies become broken. Then it would be deleted from main without prior warning. What you think about such solution ? -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From arekm at maven.pl Tue Mar 10 08:19:44 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 10 Mar 2009 08:19:44 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090309231052.GA29014@pld-linux.org> References: <200903092241.12695.arekm@maven.pl> <20090309231052.GA29014@pld-linux.org> Message-ID: <200903100819.45094.arekm@maven.pl> On Tuesday 10 of March 2009, Przemyslaw Iskra wrote: > On Mon, Mar 09, 2009 at 10:41:12PM +0100, Arkadiusz Miskiewicz wrote: > > I'm considering dropping athlon architecture since I see no real gain > > over i686. athlon would be deleted from ftp and athlon->i686 symlink > > created. > > Personally I use "athlon", but for binary crap only, which is built for > i386/i586 anyways, so I'm OK with dropping it. Could some athlon*rpm owner see if upgrading athlon->i686 is nicely handled in poldek (as amd64->x86_64 is for example) ? > > > The other platform is ppc. There is unforuntately close to zero > > developers solving ppc related bugs :-( ppc would be moved to unsupported > > or something like unofficial sparc (AIDA) as seen on ftp. Someone would > > have to step in to maintain this. > > Even tho I'm not very acrive (lately), I could step up as ppc maintainer > when it becomes AIDA. > > I could be fixing the packages I use, or if someone asks me nicely to > fix some (payment in goats no longer accepted). All the packages that > build cleanly on main th archs and have no history of being problematic > on powerpc would be send to ppc builder as well. If some package starts > to give problems and there would be noone to fix it, it would be > banned from ppc builder and last package in main repository would be > kept until its bependencies become broken. Then it would be deleted from > main without prior warning. > > What you think about such solution ? Works for me. After it disappears from Th I don't care about it (unless I'll become owner of some ppc again, which is unlikely). -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From gotar at polanet.pl Tue Mar 10 09:59:58 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 10 Mar 2009 09:59:58 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903100819.45094.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> <20090309231052.GA29014@pld-linux.org> <200903100819.45094.arekm@maven.pl> Message-ID: <20090310085954.GB14277@polanet.pl> On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely handled > in poldek (as amd64->x86_64 is for example) ? Upgrading rpms in one thing, upgrading packages having sth in */athlon-pld-linux/* (like perl) is another. -- Tomasz Pala From blues at pld-linux.org Tue Mar 10 10:02:30 2009 From: blues at pld-linux.org (Pawel Golaszewski) Date: Tue, 10 Mar 2009 10:02:30 +0100 (CET) Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903092241.12695.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> Message-ID: On Mon, 9 Mar 2009, Arkadiusz Miskiewicz wrote: > I'm considering dropping athlon architecture since I see no real gain > over i686. athlon would be deleted from ftp and athlon->i686 symlink > created. Bad idea this way. It will destroy many systems (look at perl dirs). poldek:/all-avail> rsearch -f /i686/ Przeszukiwanie pakiet?w..........................................zrobione. [...] 367 package(s) found. Anyway - at least /etc/rpm/platform has to be fixed. In athlon dir should stay only rpm package which will make all the required changes: - /etc/rpm/platform - poldek sources fixes - something with patckages arch-dependant (paths, some hardcoded things). If we will make some nice way to do arch-switch it will be prepared for future moves -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From arekm at maven.pl Tue Mar 10 10:12:04 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 10 Mar 2009 10:12:04 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> Message-ID: <200903101012.04595.arekm@maven.pl> On Tuesday 10 of March 2009, Pawel Golaszewski wrote: > On Mon, 9 Mar 2009, Arkadiusz Miskiewicz wrote: > > I'm considering dropping athlon architecture since I see no real gain > > over i686. athlon would be deleted from ftp and athlon->i686 symlink > > created. > > Bad idea this way. It will destroy many systems (look at perl dirs). "destroy", how so? > In athlon dir should stay only rpm package which will make all the > required changes: > - /etc/rpm/platform > - poldek sources fixes > - something with patckages arch-dependant (paths, some hardcoded things). That's way works for me, too. Of course that rpm will be unmaintained later. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From blues at pld-linux.org Tue Mar 10 10:28:18 2009 From: blues at pld-linux.org (Pawel Golaszewski) Date: Tue, 10 Mar 2009 10:28:18 +0100 (CET) Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903101012.04595.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> <200903101012.04595.arekm@maven.pl> Message-ID: On Tue, 10 Mar 2009, Arkadiusz Miskiewicz wrote: > > > I'm considering dropping athlon architecture since I see no real > > > gain over i686. athlon would be deleted from ftp and athlon->i686 > > > symlink created. > > Bad idea this way. It will destroy many systems (look at perl dirs). > "destroy", how so? poldek --upgrade ...few perl modules upgraded and system is not working > > In athlon dir should stay only rpm package which will make all the > > required changes: > > - /etc/rpm/platform > > - poldek sources fixes > > - something with patckages arch-dependant (paths, some hardcoded things). > That's way works for me, too. Of course that rpm will be unmaintained later. Sure - what for to maintain it later? It will be used on next arch-switch (how many years? :) ). -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From arekm at maven.pl Tue Mar 10 10:32:24 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 10 Mar 2009 10:32:24 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> <200903101012.04595.arekm@maven.pl> Message-ID: <200903101032.24294.arekm@maven.pl> On Tuesday 10 of March 2009, Pawel Golaszewski wrote: > On Tue, 10 Mar 2009, Arkadiusz Miskiewicz wrote: > > > > I'm considering dropping athlon architecture since I see no real > > > > gain over i686. athlon would be deleted from ftp and athlon->i686 > > > > symlink created. > > > > > > Bad idea this way. It will destroy many systems (look at perl dirs). > > > > "destroy", how so? > > poldek --upgrade > > ...few perl modules upgraded and system is not working How is that possible? There are dependencies that won't allow random upgrading of architecture dependant parts. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From gotar at polanet.pl Tue Mar 10 10:44:09 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 10 Mar 2009 10:44:09 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903101032.24294.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> <200903101012.04595.arekm@maven.pl> <200903101032.24294.arekm@maven.pl> Message-ID: <20090310094409.GA22597@polanet.pl> On Tue, Mar 10, 2009 at 10:32:24 +0100, Arkadiusz Miskiewicz wrote: > How is that possible? There are dependencies that won't allow random upgrading > of architecture dependant parts. These dependencies either don't allow upgrading at all (are not met and one has to use --nodeps), or simply doesn't work. I've had such problems many times, ending up with clean (as for deps) but not working system. Don't forget that i686 is a subset of athlon. Don't ask me how, I didn't care, but it IS PITA. I'm not sure if I want to do this on my own workstation this way (absolutely not prepared nor tested). And remember: such painful upgrade -> less users and developers. Some people are tired of neverending chasing for working system, personally I know already 3 persons who dumped PLD and more standing in a queue. Partial solution: create symlinks for all /*athlon*/ directories to i686 that are used. -- Tomasz Pala From arekm at maven.pl Tue Mar 10 11:09:12 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 10 Mar 2009 11:09:12 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090310094409.GA22597@polanet.pl> References: <200903092241.12695.arekm@maven.pl> <200903101032.24294.arekm@maven.pl> <20090310094409.GA22597@polanet.pl> Message-ID: <200903101109.12968.arekm@maven.pl> On Tuesday 10 of March 2009, Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 10:32:24 +0100, Arkadiusz Miskiewicz wrote: > > How is that possible? There are dependencies that won't allow random > > upgrading of architecture dependant parts. > > These dependencies either don't allow upgrading at all (are not met and > one has to use --nodeps), or simply doesn't work. I've had such problems > many times, ending up with clean (as for deps) but not working system. > Don't forget that i686 is a subset of athlon. That's because i686 and athlon had the same version-revisions. Upgrade should work fine if i686 will have bigger revisions than athlon AFAIK (untested of course). -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Tue Mar 10 11:15:59 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 10 Mar 2009 12:15:59 +0200 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090310085954.GB14277@polanet.pl> References: <200903092241.12695.arekm@maven.pl> <200903100819.45094.arekm@maven.pl> <20090310085954.GB14277@polanet.pl> Message-ID: <200903101215.59792.glen@pld-linux.org> On Tuesday 10 March 2009 10:59:58 Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely > > handled in poldek (as amd64->x86_64 is for example) ? yes, some recent fixes in poldek (with me & patrys: poldek-upgrade-dist.patch) actually allow such upgrade (no more platform name used in depsolving, but pkg colour bits) > Upgrading rpms in one thing, upgrading packages having sth in > */athlon-pld-linux/* (like perl) is another. if it's just to get "32bit" dep, like glibc(?) had, then it should be used as glibc(%{_target_base_arch}), not glibc(%{_target_arch}) but indeed, gcc, and perl have platform name in module paths. should we just change it to use lib vs lib64? -- glen From glen at pld-linux.org Tue Mar 10 11:18:21 2009 From: glen at pld-linux.org (Elan =?iso-8859-15?q?Ruusam=E4e?=) Date: Tue, 10 Mar 2009 12:18:21 +0200 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> Message-ID: <200903101218.21713.glen@pld-linux.org> On Tuesday 10 March 2009 11:02:30 Pawel Golaszewski wrote: > Bad idea this way. It will destroy many systems (look at perl dirs). > poldek:/all-avail> rsearch -f /i686/ > Przeszukiwanie pakiet?w..........................................zrobione. > [...] > 367 package(s) found. could do something like metapackage-X11 exists, which provides the dir, but requires new dir. err, and conflicts all perl packages from old arch (<- sounds already bad idea) -- glen From glen at pld-linux.org Tue Mar 10 11:18:58 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 10 Mar 2009 12:18:58 +0200 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090310094409.GA22597@polanet.pl> References: <200903092241.12695.arekm@maven.pl> <200903101032.24294.arekm@maven.pl> <20090310094409.GA22597@polanet.pl> Message-ID: <200903101218.58491.glen@pld-linux.org> On Tuesday 10 March 2009 11:44:09 Tomasz Pala wrote: > Partial solution: create symlinks for all /*athlon*/ directories to i686 > that are used. symlinks (afaik?) won't solve deps problem, the symlinks are not provided as directory deps. -- glen From baggins at sith.mimuw.edu.pl Tue Mar 10 11:20:50 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Tue, 10 Mar 2009 11:20:50 +0100 Subject: Bug #336742 in PLD =?utf-8?Q?Linux=3A_?= =?utf-8?Q?=E2=80=9Cgconv-modules=2Ecache_invalid_for_32bit_apps_on_multil?= =?utf-8?B?aWLigJ0=?= In-Reply-To: <200903100107.09565.glen@pld-linux.org> References: <200903100107.09565.glen@pld-linux.org> Message-ID: <20090310102050.GB22006@sith.mimuw.edu.pl> On Tue, 10 Mar 2009, Elan Ruusam?e wrote: > https://bugs.launchpad.net/pld-linux/+bug/336742 > > plz somebody answer on comment #1 That fix won't do anything. You need to fix the %post iconv section. 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 gotar at polanet.pl Tue Mar 10 11:40:40 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 10 Mar 2009 11:40:40 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903101218.58491.glen@pld-linux.org> References: <200903092241.12695.arekm@maven.pl> <200903101032.24294.arekm@maven.pl> <20090310094409.GA22597@polanet.pl> <200903101218.58491.glen@pld-linux.org> Message-ID: <20090310104040.GB22597@polanet.pl> On Tue, Mar 10, 2009 at 12:18:58 +0200, Elan Ruusam?e wrote: >> Partial solution: create symlinks for all /*athlon*/ directories to i686 >> that are used. > > symlinks (afaik?) won't solve deps problem, the symlinks are not provided as > directory deps. Read carefully - deps are not problem as they are met. It's the different physical location of modules that cause problems. -- Tomasz Pala From glen at pld-linux.org Tue Mar 10 14:12:49 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Tue, 10 Mar 2009 15:12:49 +0200 Subject: Bug #336742 in PLD Linux: =?utf-8?q?=E2=80=9Cgconv-modules=2Ecache_invalid_for_32bit_apps_on?= =?utf-8?q?_multilib=E2=80=9D?= In-Reply-To: <20090310102050.GB22006@sith.mimuw.edu.pl> References: <200903100107.09565.glen@pld-linux.org> <20090310102050.GB22006@sith.mimuw.edu.pl> Message-ID: <200903101512.49189.glen@pld-linux.org> On Tuesday 10 March 2009 12:20:50 Jan Rekorajski wrote: > On Tue, 10 Mar 2009, Elan Ruusam?e wrote: > > https://bugs.launchpad.net/pld-linux/+bug/336742 > > > > plz somebody answer on comment #1 > > That fix won't do anything. > You need to fix the %post iconv section. i tested and it did contain proper paths in /usr/lib/gconv/gconv-modules.cache (from file provided by rpm) and if i ran the iconvconfig in %post (so it write 32bit cache), the file is binary identical, so, there's no real need to run iconvconfig in %post ... or is there? you can grab the test pkgs from here and see yourself: http://carme.pld-linux.org/~glen/th/i686/ iconv-2.9-3.1.i686.rpm -- glen From glen at pld-linux.org Tue Mar 10 14:15:10 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Tue, 10 Mar 2009 15:15:10 +0200 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090310104040.GB22597@polanet.pl> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> Message-ID: <200903101515.10455.glen@pld-linux.org> On Tuesday 10 March 2009 12:40:40 Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 12:18:58 +0200, Elan Ruusam?e wrote: > >> Partial solution: create symlinks for all /*athlon*/ directories to i686 > >> that are used. > > > > symlinks (afaik?) won't solve deps problem, the symlinks are not provided > > as directory deps. > > Read carefully - deps are not problem as they are met. It's the > different physical location of modules that cause problems. i suppose you wanted to make symlink: /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi -> /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi but that will not fix such rpm dependency errors: error: /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is required by installed perl-Date-Calc-5.4-1.i686 as /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is dirdep, and symlinkdep will not satisfy it (didn't test but i'm almost sure of this as /etc/httpd/httpd.conf dirdep was not solved by symlink in apache-base) -- glen From gotar at polanet.pl Tue Mar 10 14:24:05 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 10 Mar 2009 14:24:05 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903101515.10455.glen@pld-linux.org> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> Message-ID: <20090310132405.GC22597@polanet.pl> On Tue, Mar 10, 2009 at 15:15:10 +0200, Elan Ruusam?e wrote: > i suppose you wanted to make symlink: > /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi -> /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi Yes. > but that will not fix such rpm dependency errors: > error: /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is required by installed perl-Date-Calc-5.4-1.i686 One last time: I don't care about these deps. Directory belongs to perl-dirs and I can install dozen of these. > as /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is dirdep, > and symlinkdep will not satisfy it (didn't test but i'm almost sure of this Who cares? I want to make perl working not rpm not-complaining. -- Tomasz Pala From baggins at sith.mimuw.edu.pl Tue Mar 10 14:48:39 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Tue, 10 Mar 2009 14:48:39 +0100 Subject: Bug #336742 in PLD =?utf-8?Q?Linux=3A_?= =?utf-8?Q?=E2=80=9Cgconv-modules=2Ecache_invalid_for_32bit_apps_on_multil?= =?utf-8?B?aWLigJ0=?= In-Reply-To: <200903101512.49189.glen@pld-linux.org> References: <200903100107.09565.glen@pld-linux.org> <20090310102050.GB22006@sith.mimuw.edu.pl> <200903101512.49189.glen@pld-linux.org> Message-ID: <20090310134839.GA29711@sith.mimuw.edu.pl> On Tue, 10 Mar 2009, Elan Ruusam?e wrote: > On Tuesday 10 March 2009 12:20:50 Jan Rekorajski wrote: > > On Tue, 10 Mar 2009, Elan Ruusam?e wrote: > > > https://bugs.launchpad.net/pld-linux/+bug/336742 > > > > > > plz somebody answer on comment #1 > > > > That fix won't do anything. > > You need to fix the %post iconv section. > > i tested and it did contain proper paths in /usr/lib/gconv/gconv-modules.cache > (from file provided by rpm) > > and if i ran the iconvconfig in %post (so it write 32bit cache), the file is > binary identical, so, there's no real need to run iconvconfig in %post ... or > is there? This is the question for a person that added it :) I see no need for it too. > you can grab the test pkgs from here and see yourself: > http://carme.pld-linux.org/~glen/th/i686/ > iconv-2.9-3.1.i686.rpm Tested, looks good, rel 4 and to builders with it :) 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 pld-linux.org Tue Mar 10 19:10:06 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Tue, 10 Mar 2009 20:10:06 +0200 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090310132405.GC22597@polanet.pl> References: <200903092241.12695.arekm@maven.pl> <200903101515.10455.glen@pld-linux.org> <20090310132405.GC22597@polanet.pl> Message-ID: <200903102010.06859.glen@pld-linux.org> On Tuesday 10 March 2009 15:24:05 Tomasz Pala wrote: > > as /usr/lib/perl5/vendor_perl/5.8.0/i686-pld-linux-thread-multi is > > dirdep, and symlinkdep will not satisfy it (didn't test but i'm almost > > sure of this > > Who cares? I want to make perl working not rpm not-complaining. i'm just explaining. daaa! -- glen From glen at pld-linux.org Tue Mar 10 19:14:32 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Tue, 10 Mar 2009 20:14:32 +0200 Subject: Bug #336742 in PLD Linux: =?utf-8?q?=E2=80=9Cgconv-modules=2Ecache_invalid_for_32bit_apps_on?= =?utf-8?q?_multilib=E2=80=9D?= In-Reply-To: <20090310134839.GA29711@sith.mimuw.edu.pl> References: <200903100107.09565.glen@pld-linux.org> <200903101512.49189.glen@pld-linux.org> <20090310134839.GA29711@sith.mimuw.edu.pl> Message-ID: <200903102014.33019.glen@pld-linux.org> On Tuesday 10 March 2009 15:48:39 Jan Rekorajski wrote: > > and if i ran the iconvconfig in %post (so it write 32bit cache), the file > > is binary identical, so, there's no real need to run iconvconfig in %post > > ... or is there? > > This is the question for a person that added it :) > I see no need for it too. the situation is not the same, at that point when it was added, the gconv-modules.cache was not packaged. and it was like 7 years ago ;) but ok, as no reason given why need to regen it in %post, removing regen in %post. -- glen From blues at pld-linux.org Tue Mar 10 21:58:18 2009 From: blues at pld-linux.org (Pawel Golaszewski) Date: Tue, 10 Mar 2009 21:58:18 +0100 (CET) Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903101515.10455.glen@pld-linux.org> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> Message-ID: On Tue, 10 Mar 2009, Elan Ruusam?e wrote: > /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi I'm wondering if we _really_ need to have that dir in this form? If I'll put perl module to that directory from i386 it'll simply work (or I'm wrong?). Why not try change it to something less problematic, for whole line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or maybe just "arch-pld-linux-thread-multi" (what about multilib in this moment?) I don't know how difficult is it, but it seems that rpm macros change and rebuild perl will be enough (...and modules rebuild, of course :) ). -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From arekm at maven.pl Wed Mar 11 09:56:54 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 11 Mar 2009 09:56:54 +0100 Subject: Th: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... Message-ID: <200903110956.54789.arekm@maven.pl> Th users: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... then please look at new directory "obsolete" on ftp in th tree. Main tree uses 2.6.28, xserver 1.6 and kde4 now. ps. "obsolete" in this case means "on a way to /dev/null in a few months" -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From gotar at polanet.pl Wed Mar 11 10:03:35 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 11 Mar 2009 10:03:35 +0100 Subject: Th: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... In-Reply-To: <200903110956.54789.arekm@maven.pl> References: <200903110956.54789.arekm@maven.pl> Message-ID: <20090311090335.GA18202@polanet.pl> On Wed, Mar 11, 2009 at 09:56:54 +0100, Arkadiusz Miskiewicz wrote: > Th users: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... then > please look at new directory "obsolete" on ftp in th tree. > > Main tree uses 2.6.28, xserver 1.6 and kde4 now. > > ps. "obsolete" in this case means "on a way to /dev/null in a few months" KDE3 was supposed to stay there...:/ In such case (removing athlon and kde3) I'd like to know is it possible to get rsync access? -- Tomasz Pala From gotar at polanet.pl Wed Mar 11 10:07:41 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 11 Mar 2009 10:07:41 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> Message-ID: <20090311090741.GB18202@polanet.pl> On Tue, Mar 10, 2009 at 21:58:18 +0100, Pawel Golaszewski wrote: > I'm wondering if we _really_ need to have that dir in this form? If I'll > put perl module to that directory from i386 it'll simply work (or I'm > wrong?). Why not try change it to something less problematic, for whole > line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or +1 > maybe just "arch-pld-linux-thread-multi" (what about multilib in this > moment?) > > I don't know how difficult is it, but it seems that rpm macros change and > rebuild perl will be enough (...and modules rebuild, of course :) ). ...and creating appropriate dir symlinks, as there's no way to upgrade all perl modules in many cases (like me). -- Tomasz Pala From arekm at maven.pl Wed Mar 11 10:10:05 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 11 Mar 2009 10:10:05 +0100 Subject: Th: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... In-Reply-To: <20090311090335.GA18202@polanet.pl> References: <200903110956.54789.arekm@maven.pl> <20090311090335.GA18202@polanet.pl> Message-ID: <200903111010.05674.arekm@maven.pl> On Wednesday 11 of March 2009, Tomasz Pala wrote: > On Wed, Mar 11, 2009 at 09:56:54 +0100, Arkadiusz Miskiewicz wrote: > > Th users: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... > > then please look at new directory "obsolete" on ftp in th tree. > > > > Main tree uses 2.6.28, xserver 1.6 and kde4 now. > > > > ps. "obsolete" in this case means "on a way to /dev/null in a few months" > > KDE3 was supposed to stay there...:/ It stays there. I have no intention to delete it but I'm trying to say that obsolete dir won't be maintained by me, so it will probably become useles in few months (unless someone steps up). > In such case (removing athlon and kde3) I'd like to know is it possible > to get rsync access? AFAIK mailto:rsync at pld-linux.org -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From michal at michal.waw.pl Wed Mar 11 12:28:32 2009 From: michal at michal.waw.pl (Michal Kochanowicz) Date: Wed, 11 Mar 2009 12:28:32 +0100 Subject: Th: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... In-Reply-To: <200903110956.54789.arekm@maven.pl> References: <200903110956.54789.arekm@maven.pl> Message-ID: <20090311112832.GC10352@woland.michal.waw.pl> On Wed, Mar 11, 2009 at 09:56:54AM +0100, Arkadiusz Miskiewicz wrote: > > Th users: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... then > please look at new directory "obsolete" on ftp in th tree. > > Main tree uses 2.6.28, xserver 1.6 and kde4 now. Are you aware that this config (2.6.28 + 1.6) is not usable on Intel video adapters? I've seen threads on "pl" groups and I've tried this on laptop with "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)". The result is random mess on screen and deadlock (magick sysrq doesn't work). -- --= Michal Kochanowicz =--==--==BOFH==--==--= michal at michal.waw.pl =-- --= finger me for PGP public key or visit http://michal.waw.pl/PGP =-- --==--==--==--==--==-- Vodka. Connecting people.--==--==--==--==--==-- A chodzenie po g?rach SSIE!!! From arekm at maven.pl Wed Mar 11 12:44:17 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 11 Mar 2009 12:44:17 +0100 Subject: Th: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... In-Reply-To: <20090311112832.GC10352@woland.michal.waw.pl> References: <200903110956.54789.arekm@maven.pl> <20090311112832.GC10352@woland.michal.waw.pl> Message-ID: <200903111244.17217.arekm@maven.pl> On Wednesday 11 of March 2009, Michal Kochanowicz wrote: > On Wed, Mar 11, 2009 at 09:56:54AM +0100, Arkadiusz Miskiewicz wrote: > > Th users: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... > > then please look at new directory "obsolete" on ftp in th tree. > > > > Main tree uses 2.6.28, xserver 1.6 and kde4 now. > > Are you aware that this config (2.6.28 + 1.6) is not usable on Intel > video adapters? I'm aware of some problems but I also know about working configurations (like one 2m away from my desk). > I've seen threads on "pl" groups and I've tried this on > laptop with "Intel Corporation Mobile 945GM/GMS, 943/940GML Express > Integrated Graphics Controller (rev 03)". The result is random mess on > screen and deadlock (magick sysrq doesn't work). This needs to be fixed then. Unfortunately I don't own intel GPU (yet, should change soon, like in 3 weeks) so can do nothing about it. Are there upstream bugreports about these? -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From qboosh at pld-linux.org Wed Mar 11 22:29:23 2009 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 11 Mar 2009 22:29:23 +0100 Subject: recent java changes (enforcing gcj) Message-ID: <20090311212923.GA11718@stranger.qboosh.pl> There should be a way to build packages using jdk - without need to uninstall java-sun and replace it with gcj - e.g. by %bcond_with jdk. Also, removing versioned jre Requires doesn't look good to me - the required versions were put not without reason. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Wed Mar 11 22:38:29 2009 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 11 Mar 2009 22:38:29 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> Message-ID: <20090311213829.GB11718@stranger.qboosh.pl> On Tue, Mar 10, 2009 at 09:58:18PM +0100, Pawel Golaszewski wrote: > On Tue, 10 Mar 2009, Elan Ruusam?e wrote: > > /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi > > I'm wondering if we _really_ need to have that dir in this form? If I'll > put perl module to that directory from i386 it'll simply work (or I'm > wrong?). Why not try change it to something less problematic, for whole > line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or > maybe just "arch-pld-linux-thread-multi" (what about multilib in this > moment?) Whatever, but please don't invent some yet again "base" architecture prefixes (there is %{_target_base_arch} already). Anyway there is no need to use architecture name in %{_libdir} subdirectory (multilib is already handled by different %{_libdir} value). BTW, Debian doesn't use this part of path at all - just perl version number. -- Jakub Bogusz http://qboosh.pl/ From patrys at pld-linux.org Wed Mar 11 23:16:44 2009 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Wed, 11 Mar 2009 23:16:44 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090311213829.GB11718@stranger.qboosh.pl> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> <20090311213829.GB11718@stranger.qboosh.pl> Message-ID: <89b6ba3a0903111516i3e02c793k2dc97fbf870d5236@mail.gmail.com> On Wed, Mar 11, 2009 at 10:38 PM, Jakub Bogusz wrote: > Whatever, but please don't invent some yet again "base" architecture > prefixes (there is %{_target_base_arch} already). > > Anyway there is no need to use architecture name in %{_libdir} > subdirectory (multilib is already handled by different %{_libdir} value). > > BTW, Debian doesn't use this part of path at all - just perl version number. Just like we do with Python arch-specific packages. -- Patryk Zawadzki From blues at pld-linux.org Thu Mar 12 09:50:18 2009 From: blues at pld-linux.org (Pawel Golaszewski) Date: Thu, 12 Mar 2009 09:50:18 +0100 (CET) Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090311213829.GB11718@stranger.qboosh.pl> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> <20090311213829.GB11718@stranger.qboosh.pl> Message-ID: On Wed, 11 Mar 2009, Jakub Bogusz wrote: > > > /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi > > > > I'm wondering if we _really_ need to have that dir in this form? If I'll > > put perl module to that directory from i386 it'll simply work (or I'm > > wrong?). Why not try change it to something less problematic, for whole > > line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or > > maybe just "arch-pld-linux-thread-multi" (what about multilib in this > > moment?) > Whatever, but please don't invent some yet again "base" architecture > prefixes (there is %{_target_base_arch} already). Anyway there is no > need to use architecture name in %{_libdir} subdirectory (multilib is > already handled by different %{_libdir} value). Simple: /usr/lib/perl5/vendor_perl/5.8.0/ I like that. > BTW, Debian doesn't use this part of path at all - just perl version > number. ...and we should follow that... -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From radek at pld-linux.org Thu Mar 12 12:11:35 2009 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Thu, 12 Mar 2009 12:11:35 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> Message-ID: <20090312111135.GA5738@bzium.google.pl> Pawel Golaszewski [10-03-2009 21:58]: > On Tue, 10 Mar 2009, Elan Ruusam?e wrote: >> /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi > I'm wondering if we _really_ need to have that dir in this form? If I'll Probably not. > put perl module to that directory from i386 it'll simply work (or I'm > wrong?). I'm not sure if it'll always be correct, but likely yes. > Why not try change it to something less problematic, for whole > line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or > maybe just "arch-pld-linux-thread-multi" (what about multilib in this > moment?) -1: it's a major change and I can't see a good reason to warrant it. The pain will be much bigger, than the gain [1]. $ perl -le 'map print, @INC' | grep /lib/ /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi If we touch the first one, we'll screw over everyone who installed something using CPAN.pm. People do that on production, a lot. We *might* consider doing a mv in a %trigger*, but that would violate the "packages do not touch /usr/local" rule. 2nd one... custom-built packages without directory dependencies will cause trouble, but that's probably not many people. I'm not sure if trees built with "perl Makefile.PL LIB=~/.lib" would be affected; if they were -- ouch, that's major. > I don't know how difficult is it, but it seems that rpm macros change and > rebuild perl will be enough (...and modules rebuild, of course :) ). Easy, no need to change the macros; just a couple of %defines in perl.spec. But do not do it without a *really* good reason and thinking it over. [1] If we were to push this pain through (forcing everyone to rebuild their custom-built perl stuff), it might be worth to consider disabling ithreads, to get two gains in one go. That's about 10% performance gain, and I have yet to encounter an application which uses these. It would be useful to talk to other distributors first, though. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From radek at pld-linux.org Thu Mar 12 12:13:29 2009 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Thu, 12 Mar 2009 12:13:29 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> <20090311213829.GB11718@stranger.qboosh.pl> Message-ID: <20090312111329.GB5738@bzium.google.pl> Pawel Golaszewski [12-03-2009 09:50]: > On Wed, 11 Mar 2009, Jakub Bogusz wrote: [...] >> Whatever, but please don't invent some yet again "base" architecture >> prefixes (there is %{_target_base_arch} already). Anyway there is no >> need to use architecture name in %{_libdir} subdirectory (multilib is >> already handled by different %{_libdir} value). > Simple: > /usr/lib/perl5/vendor_perl/5.8.0/ /usr/lib/perl5/vendor_perl/5.10/ would do. [...] >> BTW, Debian doesn't use this part of path at all - just perl version >> number. > ...and we should follow that... No, we have no obligation to follow Debian about this. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From radek at pld-linux.org Thu Mar 12 12:16:17 2009 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Thu, 12 Mar 2009 12:16:17 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903092241.12695.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> Message-ID: <20090312111617.GC5738@bzium.google.pl> Arkadiusz Miskiewicz [09-03-2009 22:41]: [...] > Opinions? Current plan is to do this on a incoming weekend. 1 week notice for deprecating an architecture is *harsh*, IMO. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From patrys at pld-linux.org Thu Mar 12 12:25:49 2009 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Thu, 12 Mar 2009 12:25:49 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090312111329.GB5738@bzium.google.pl> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> <20090311213829.GB11718@stranger.qboosh.pl> <20090312111329.GB5738@bzium.google.pl> Message-ID: <89b6ba3a0903120425y74baf431t9d413d3a28a6b3da@mail.gmail.com> 2009/3/12 Radoslaw Zielinski : > Pawel Golaszewski [12-03-2009 09:50]: >> On Wed, 11 Mar 2009, Jakub Bogusz wrote: >>> BTW, Debian doesn't use this part of path at all - just perl version >>> number. >> ...and we should follow that... > No, we have no obligation to follow Debian about this. No, we should have obligations to follow ourselves - see ruby and python in PLD. -- Patryk Zawadzki From arekm at maven.pl Thu Mar 12 12:26:24 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 12 Mar 2009 12:26:24 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090312111617.GC5738@bzium.google.pl> References: <200903092241.12695.arekm@maven.pl> <20090312111617.GC5738@bzium.google.pl> Message-ID: <200903121226.24335.arekm@maven.pl> On Thursday 12 of March 2009, Radoslaw Zielinski wrote: > Arkadiusz Miskiewicz [09-03-2009 22:41]: > [...] > > > Opinions? Current plan is to do this on a incoming weekend. > > 1 week notice for deprecating an architecture is *harsh*, IMO. Current plan is to move maintainership of ppc to other person (sparky) and disconnect ppc from th. It won't disappear. Compat symlinks will be there in th ftp for some time. Weekend deadline is no longer valid. New date will be announced some time later. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From witek.firlej at gmail.com Thu Mar 12 12:28:43 2009 From: witek.firlej at gmail.com (Witek Firlej) Date: Thu, 12 Mar 2009 12:28:43 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903121226.24335.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> <20090312111617.GC5738@bzium.google.pl> <200903121226.24335.arekm@maven.pl> Message-ID: On Thu, Mar 12, 2009 at 12:26 PM, Arkadiusz Miskiewicz wrote: > > On Thursday 12 of March 2009, Radoslaw Zielinski wrote: > > Arkadiusz Miskiewicz [09-03-2009 22:41]: > > [...] > > > > > Opinions? Current plan is to do this on a incoming weekend. > > > > 1 week notice for deprecating an architecture is *harsh*, IMO. > > Current plan is to move maintainership of ppc to other person (sparky) and > disconnect ppc from th. It won't disappear. And what about athlon and i486? -- :: ?Witek Firlej ?:: :: Studencka wyprawa do Chin http://chiny2009.pl :: :: ?http://grizz.pl ?:: ?http://galeria.firlej.org ?:: ?jid: grizz//jabster.pl ?:: From glen at pld-linux.org Thu Mar 12 13:00:30 2009 From: glen at pld-linux.org (Elan =?iso-8859-15?q?Ruusam=E4e?=) Date: Thu, 12 Mar 2009 14:00:30 +0200 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> <20090311213829.GB11718@stranger.qboosh.pl> Message-ID: <200903121400.30121.glen@pld-linux.org> On Thursday 12 March 2009 10:50:18 Pawel Golaszewski wrote: > > Whatever, but please don't invent some yet again "base" architecture > > prefixes (there is %{_target_base_arch} already). Anyway there is no > > need to use architecture name in %{_libdir} subdirectory (multilib is > > already handled by different %{_libdir} value). > > Simple: > /usr/lib/perl5/vendor_perl/5.8.0/ > > I like that. > > > BTW, Debian doesn't use this part of path at all - just perl version > > number. > > ...and we should follow that... ++++1 from me (altho i already said it out :)) -- glen From z at xatka.net Thu Mar 12 15:49:54 2009 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Thu, 12 Mar 2009 15:49:54 +0100 Subject: recent java changes (enforcing gcj) In-Reply-To: <20090311212923.GA11718@stranger.qboosh.pl> References: <20090311212923.GA11718@stranger.qboosh.pl> Message-ID: <20090312144954.GA8459@davabel.touk.pl> On Wed, 11 Mar 2009, Jakub Bogusz wrote: > There should be a way to build packages using jdk - without need to > uninstall java-sun and replace it with gcj - e.g. by %bcond_with jdk. IMO we should enforce a specified implemetation of jdk even for packages that can be build using both jdks, because package built with java-sun differ from the same package built with java-gcj-compat-devel. Main differences are: 1. default ClassDataVersion for sun's javac is 50. That means it is not compatibile with gij JVM. Default ClassDataVersion for gcj is 49. Such .class file can be run with both gij and sun JVM. 2. javadoc generated by gjdoc and one generated by sun javadoc are different. Even list of generated files differ. We do not want our packages to depend from the build environment. I prefer gcj because gcj works on all archs supported in th. BTW there should be a simple way to install a few versions of java (or at least java-sun{,-jre} and java-gcj-compat{,-devel}). By "simple" I mean without --relocate, --excludedocs, --oldpackage etc In debian it is handled by "alternatives" (/usr/bin/* files are not packaged, so different jvm/jdk packages do not conflicts. /usr/bin/* files are symlinks generated in post scriptlets). Mayby we should move conflicting files to subpackage. In such case to set a default version of java, one can install this subpackage. To use other versions one have to set JAVA_HOME variable (or define %java_home macro) > Also, removing versioned jre Requires doesn't look good to me - the > required versions were put not without reason. This dependency should be autogenerated and it should look like that: R: java(ClassDataVersion) = n There is a bug in "file" command, that results in wrong classification of java class files. It is fixed in PLD by patch added in file-4.26-4, so now java dependencies are generated correctly. -- Pawe? From blues at pld-linux.org Thu Mar 12 15:12:22 2009 From: blues at pld-linux.org (Pawel Golaszewski) Date: Thu, 12 Mar 2009 15:12:22 +0100 (CET) Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090312111329.GB5738@bzium.google.pl> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> <20090311213829.GB11718@stranger.qboosh.pl> <20090312111329.GB5738@bzium.google.pl> Message-ID: On Thu, 12 Mar 2009, Radoslaw Zielinski wrote: > >> Whatever, but please don't invent some yet again "base" architecture > >> prefixes (there is %{_target_base_arch} already). Anyway there is no > >> need to use architecture name in %{_libdir} subdirectory (multilib is > >> already handled by different %{_libdir} value). > > Simple: /usr/lib/perl5/vendor_perl/5.8.0/ > /usr/lib/perl5/vendor_perl/5.10/ would do. > [...] > >> BTW, Debian doesn't use this part of path at all - just perl version > >> number. > > ...and we should follow that... > No, we have no obligation to follow Debian about this. Sure, but this is good thing. -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From blues at pld-linux.org Thu Mar 12 15:18:56 2009 From: blues at pld-linux.org (Pawel Golaszewski) Date: Thu, 12 Mar 2009 15:18:56 +0100 (CET) Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090312111135.GA5738@bzium.google.pl> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> <20090312111135.GA5738@bzium.google.pl> Message-ID: On Thu, 12 Mar 2009, Radoslaw Zielinski wrote: > > Why not try change it to something less problematic, for whole line: > > x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or maybe > > just "arch-pld-linux-thread-multi" (what about multilib in this > > moment?) > -1: it's a major change and I can't see a good reason to warrant it. > The pain will be much bigger, than the gain [1]. > > $ perl -le 'map print, @INC' | grep /lib/ > /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi > /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi We don't have to do it right now but on next bigger perl update? Why not? > If we touch the first one, we'll screw over everyone who installed > something using CPAN.pm. Who cares /usr/local entry? It can stay in that form. Anyway - can we add more paths to @INC? It will fix all the problems. -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From radek at pld-linux.org Thu Mar 12 15:43:54 2009 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Thu, 12 Mar 2009 15:43:54 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> <20090312111135.GA5738@bzium.google.pl> Message-ID: <20090312144354.GA8701@bzium.google.pl> Pawel Golaszewski [12-03-2009 15:18]: > On Thu, 12 Mar 2009, Radoslaw Zielinski wrote: [...] >> -1: it's a major change and I can't see a good reason to warrant it. >> The pain will be much bigger, than the gain [1]. >> $ perl -le 'map print, @INC' | grep /lib/ >> /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi >> /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi >> /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi > We don't have to do it right now but on next bigger perl update? Why not? I'm cool with that. The thing I want to avoid is another needless clusterfuck, like the premature 5.10 update was. >> If we touch the first one, we'll screw over everyone who installed >> something using CPAN.pm. > Who cares /usr/local entry? It can stay in that form. Well, consistency does. > Anyway - can we add more paths to @INC? > It will fix all the problems. We could. Some distros used to do that (eg. SuSe, IIRC), years ago; they had really long @INC... The cost is more stat() calls when loading modules (two calls per one entry; one, if we also get rid of *.pmc -- I've never seen it used). Ugly, though. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From glen at pld-linux.org Thu Mar 12 17:19:45 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Thu, 12 Mar 2009 18:19:45 +0200 Subject: SPECS: showconsole.spec - up to 1.09 - suse.patch dropped In-Reply-To: References: Message-ID: <200903121819.45253.glen@pld-linux.org> On Wednesday 11 March 2009 21:19:20 duddits wrote: > Author: duddits ? ? ? ? ? ? ? ? ? ? ?Date: Wed Mar 11 19:19:20 2009 GMT > Module: SPECS ? ? ? ? ? ? ? ? ? ? ? ? Tag: HEAD > ---- Log message: > - up to 1.09 > - suse.patch dropped and that is why? > ---- Files affected: > SPECS: > ? ?showconsole.spec (1.12 -> 1.13) -- glen From pawel at dlugosz.eu Thu Mar 12 20:03:38 2009 From: pawel at dlugosz.eu (Pawel Dlugosz) Date: Thu, 12 Mar 2009 20:03:38 +0100 Subject: SPECS: showconsole.spec - up to 1.09 - suse.patch dropped In-Reply-To: <200903121819.45253.glen@pld-linux.org> References: <200903121819.45253.glen@pld-linux.org> Message-ID: <49B95C8A.1000500@dlugosz.eu> Elan Ruusam?e pisze: > and that is why? Those changes are already there. -- Pawe? <@duddits> D?ugosz .::http://dlugosz.eu::. From glen at pld-linux.org Thu Mar 12 22:05:05 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Thu, 12 Mar 2009 23:05:05 +0200 Subject: Fwd: SPECS (UDEV-124): udev.spec - added -vol_id-cdrom.patch (for cdrom tray clo... Message-ID: <200903122305.05229.glen@pld-linux.org> can this be added to HEAD (th) too? as it's quite difficult to open tray to remove disc if it gets closed immediately again. ---------- Forwarded Message ---------- Subject: SPECS (UDEV-124): udev.spec - added -vol_id-cdrom.patch (for cdrom tray clo... Date: Thursday 12 March 2009 From: charles To: pld-cvs-commit at lists.pld-linux.org Cc: Author: charles Date: Thu Mar 12 21:02:03 2009 GMT Module: SPECS Tag: UDEV-124 ---- Log message: - added -vol_id-cdrom.patch (for cdrom tray close bug) - rel. up -- glen From arekm at maven.pl Thu Mar 12 22:10:11 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 12 Mar 2009 22:10:11 +0100 Subject: Fwd: SPECS (UDEV-124): udev.spec - added -vol_id-cdrom.patch (for cdrom tray clo... In-Reply-To: <200903122305.05229.glen@pld-linux.org> References: <200903122305.05229.glen@pld-linux.org> Message-ID: <200903122210.11989.arekm@maven.pl> On Thursday 12 of March 2009, Elan Ruusam?e wrote: > can this be added to HEAD (th) too? as it's quite difficult to open tray to > remove disc if it gets closed immediately again. Was it reported upstream? > > ---------- Forwarded Message ---------- > > Subject: SPECS (UDEV-124): udev.spec - added -vol_id-cdrom.patch (for cdrom > tray clo... > Date: Thursday 12 March 2009 > From: charles > To: pld-cvs-commit at lists.pld-linux.org > Cc: > > Author: charles Date: Thu Mar 12 21:02:03 2009 GMT > Module: SPECS Tag: UDEV-124 > ---- Log message: > - added -vol_id-cdrom.patch (for cdrom tray close bug) > - rel. up -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Thu Mar 12 22:48:02 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Thu, 12 Mar 2009 23:48:02 +0200 Subject: Fwd: SPECS (UDEV-124): udev.spec - added -vol_id-cdrom.patch (for cdrom tray clo... In-Reply-To: <200903122210.11989.arekm@maven.pl> References: <200903122305.05229.glen@pld-linux.org> <200903122210.11989.arekm@maven.pl> Message-ID: <200903122348.02358.glen@pld-linux.org> On Thursday 12 March 2009 23:10:11 Arkadiusz Miskiewicz wrote: > On Thursday 12 of March 2009, Elan Ruusam?e wrote: > > can this be added to HEAD (th) too? as it's quite difficult to open tray > > to remove disc if it gets closed immediately again. > > Was it reported upstream? no, i did not know what to blame, kde4 or anything else. but it has happened to me too, so tought these are related. -- glen From freetz at gmx.net Fri Mar 13 07:47:00 2009 From: freetz at gmx.net (Fryderyk Dziarmagowski) Date: Fri, 13 Mar 2009 07:47:00 +0100 Subject: Th: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... In-Reply-To: <200903111244.17217.arekm@maven.pl> References: <200903110956.54789.arekm@maven.pl> <20090311112832.GC10352@woland.michal.waw.pl> <200903111244.17217.arekm@maven.pl> Message-ID: <20090313074700.d1436375.freetz@gmx.net> On Wed, 11 Mar 2009 12:44:17 +0100 Arkadiusz Miskiewicz wrote: > On Wednesday 11 of March 2009, Michal Kochanowicz wrote: > > On Wed, Mar 11, 2009 at 09:56:54AM +0100, Arkadiusz Miskiewicz wrote: > > > Th users: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... > > > then please look at new directory "obsolete" on ftp in th tree. > > > > > > Main tree uses 2.6.28, xserver 1.6 and kde4 now. > > > > Are you aware that this config (2.6.28 + 1.6) is not usable on Intel > > video adapters? > > I'm aware of some problems but I also know about working configurations (like > one 2m away from my desk). True, I got two Intel adapters (one is same as Michal's) working without smallest problems (but I'm using patched kernel, see url I've attached) > > I've seen threads on "pl" groups and I've tried this on > > laptop with "Intel Corporation Mobile 945GM/GMS, 943/940GML Express > > Integrated Graphics Controller (rev 03)". The result is random mess on > > screen and deadlock (magick sysrq doesn't work). > > This needs to be fixed then. Unfortunately I don't own intel GPU (yet, should > change soon, like in 3 weeks) so can do nothing about it. Are there upstream > bugreports about these? Some issues are fixed here: http://intellinuxgraphics.org/download/2008Q4-rc4/2008q4-kernel-against-2.6.28.patch Patch requires minor adjusting (agp update is already merged upstream) -- Fryderyk Dziarmagowski From z at xatka.net Fri Mar 13 12:51:21 2009 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Fri, 13 Mar 2009 12:51:21 +0100 Subject: recent java changes (enforcing gcj) In-Reply-To: <20090312144954.GA8459@davabel.touk.pl> References: <20090311212923.GA11718@stranger.qboosh.pl> <20090312144954.GA8459@davabel.touk.pl> Message-ID: <20090313115121.GA5615@davabel.touk.pl> On Thu, 12 Mar 2009, Pawe? Zuzelski wrote: > > Also, removing versioned jre Requires doesn't look good to me - the > > required versions were put not without reason. "R: jre" means that application requires correct JAVA_HOME directory and bin/java command. In common cases it is required by standalone java applications like odtransform, fop, JXplorer or tomcat. Java libraries does not requires "jre". "jre" is required by an application that uses given library. Java libraries require only JVM that provides proper ABI (i.e. java(ClassDataVersion) >= n). It is possible, that there is a JVM installed, but there is not JRE. For example one can install gcc-java (that provides gij), but not java-gcj-compat. JVM (but nor JRE) can also be provided by firefox java plugin, or even by java application compiled to native code. > This dependency should be autogenerated and it should look like > that: R: java(ClassDataVersion) = n > There is a bug in "file" command, that results in wrong > classification of java class files. It is fixed in PLD by patch > added in file-4.26-4, so now java dependencies are generated > correctly. There was one more bug - in rpm scripts. It has been fixed yesterday (thx glen). Now it *really* works, but some java packages in th have to be rebuilt. -- Pawe? From gotar at polanet.pl Fri Mar 13 12:57:45 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 13 Mar 2009 12:57:45 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090312111135.GA5738@bzium.google.pl> References: <200903092241.12695.arekm@maven.pl> <200903101218.58491.glen@pld-linux.org> <20090310104040.GB22597@polanet.pl> <200903101515.10455.glen@pld-linux.org> <20090312111135.GA5738@bzium.google.pl> Message-ID: <20090313115745.GA20754@polanet.pl> On Thu, Mar 12, 2009 at 12:11:35 +0100, Radoslaw Zielinski wrote: > The pain will be much bigger, than the gain [1]. > > $ perl -le 'map print, @INC' | grep /lib/ > /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi > /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi > > If we touch the first one, we'll screw over everyone who installed > something using CPAN.pm. People do that on production, a lot. We Let's just create symlinks... > [1] If we were to push this pain through (forcing everyone to rebuild > their custom-built perl stuff), it might be worth to consider > disabling ithreads, to get two gains in one go. That's about 10% > performance gain, and I have yet to encounter an application which > uses these. +1 -- Tomasz Pala From gotar at polanet.pl Fri Mar 13 13:02:14 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 13 Mar 2009 13:02:14 +0100 Subject: Th: If you are looking for kde3, kernel 2.6.27 or xserver 1.5... In-Reply-To: <200903111244.17217.arekm@maven.pl> References: <200903110956.54789.arekm@maven.pl> <20090311112832.GC10352@woland.michal.waw.pl> <200903111244.17217.arekm@maven.pl> Message-ID: <20090313120214.GB20754@polanet.pl> On Wed, Mar 11, 2009 at 12:44:17 +0100, Arkadiusz Miskiewicz wrote: > This needs to be fixed then. Unfortunately I don't own intel GPU (yet, should > change soon, like in 3 weeks) Then you'll be unfortunate ;P -- Tomasz Pala From glen at pld-linux.org Fri Mar 13 16:04:38 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 13 Mar 2009 17:04:38 +0200 Subject: SPECS: odtransform.spec - why %{?without_ does not work? changed t... In-Reply-To: References: Message-ID: <200903131704.38844.glen@pld-linux.org> On Friday 13 March 2009 14:58:55 pawelz wrote: > Author: pawelz Date: Fri Mar 13 12:58:55 2009 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - why %{?without_ does not work? changed to %{!?with_ because with_ is %define (variable). but %{with } and %{without } are macros (functions) %with and %without macros go and evaluate with_ define and return the state. /usr/lib/rpm/macros: # Shorthand for %{defined with_...} %with() %{expand:%%{?with_%{1}:1}%%{!?with_%{1}:0}} %without() %{expand:%%{?with_%{1}:0}%%{!?with_%{1}:1}} -- glen From arekm at maven.pl Sat Mar 14 11:57:21 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 14 Mar 2009 11:57:21 +0100 Subject: SPECS: busybox.spec - 1.13.3 In-Reply-To: References: Message-ID: <200903141157.22135.arekm@maven.pl> On Friday 13 of March 2009, baggins wrote: > Author: baggins Date: Fri Mar 13 22:56:19 2009 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - 1.13.3 > > ---- Files affected: > SPECS: > busybox.spec (1.158 -> 1.159) Unstable versions belong to DEVEL branch unless there is some other reason to have it on HEAD. Please fix. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Sat Mar 14 11:58:27 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 14 Mar 2009 11:58:27 +0100 Subject: SPECS: uClibc.spec - 0.9.30.1 - epoch 3 - filter out -Wl, -z, combreloc and -... In-Reply-To: References: Message-ID: <200903141158.27974.arekm@maven.pl> On Saturday 14 of March 2009, baggins wrote: > Author: baggins Date: Sat Mar 14 01:42:03 2009 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - 0.9.30.1 > - epoch 3 > - filter out -Wl,-z,combreloc and -Wl,-z,relro in gcc wrapper > - use linker GNU hash style (fixes _stdio_openlist_use_count problem) > - fixed ppoll syscall (it has 5 args, not 4) Unfortunately doesn't build on ppc :-( (which is not yet deprecated, so there are 2 options, back to 0.9.28 or fix ppc) -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Sat Mar 14 12:00:53 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 14 Mar 2009 12:00:53 +0100 Subject: SPECS: busybox.spec - 1.13.3 In-Reply-To: <200903141157.22135.arekm@maven.pl> References: <200903141157.22135.arekm@maven.pl> Message-ID: <200903141200.53210.arekm@maven.pl> On Saturday 14 of March 2009, Arkadiusz Miskiewicz wrote: > On Friday 13 of March 2009, baggins wrote: > > Author: baggins Date: Fri Mar 13 22:56:19 2009 GMT > > Module: SPECS Tag: HEAD > > ---- Log message: > > - 1.13.3 > > > > ---- Files affected: > > SPECS: > > busybox.spec (1.158 -> 1.159) > > Unstable versions belong to DEVEL branch unless there is some other reason > to have it on HEAD. > > Please fix. Scratch this, it's marked stable now! -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From baggins at sith.mimuw.edu.pl Sat Mar 14 12:15:41 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Sat, 14 Mar 2009 12:15:41 +0100 Subject: SPECS: uClibc.spec - 0.9.30.1 - epoch 3 - filter out -Wl, -z, combreloc and -... In-Reply-To: <200903141158.27974.arekm@maven.pl> References: <200903141158.27974.arekm@maven.pl> Message-ID: <20090314111540.GA29010@sith.mimuw.edu.pl> On Sat, 14 Mar 2009, Arkadiusz Miskiewicz wrote: > On Saturday 14 of March 2009, baggins wrote: > > Author: baggins Date: Sat Mar 14 01:42:03 2009 GMT > > Module: SPECS Tag: HEAD > > ---- Log message: > > - 0.9.30.1 > > - epoch 3 > > - filter out -Wl,-z,combreloc and -Wl,-z,relro in gcc wrapper > > - use linker GNU hash style (fixes _stdio_openlist_use_count problem) > > - fixed ppoll syscall (it has 5 args, not 4) > > Unfortunately doesn't build on ppc :-( (which is not yet deprecated, so there > are 2 options, back to 0.9.28 or fix ppc) No, there is only one. Fix on ppc, cause busybox requires uClibc >= 0.9.30 :( 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 arekm at maven.pl Sat Mar 14 13:02:14 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 14 Mar 2009 13:02:14 +0100 Subject: perl - no target_arch in paths? In-Reply-To: <20090312144354.GA8701@bzium.google.pl> References: <200903092241.12695.arekm@maven.pl> <20090312144354.GA8701@bzium.google.pl> Message-ID: <200903141302.14375.arekm@maven.pl> On Thursday 12 of March 2009, Radoslaw Zielinski wrote: > Pawel Golaszewski [12-03-2009 15:18]: > > On Thu, 12 Mar 2009, Radoslaw Zielinski wrote: > > [...] > > >> -1: it's a major change and I can't see a good reason to warrant it. > >> The pain will be much bigger, than the gain [1]. > >> > >> $ perl -le 'map print, @INC' | grep /lib/ > >> /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi > >> /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi > >> /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi > > > > We don't have to do it right now but on next bigger perl update? Why not? > > I'm cool with that. The thing I want to avoid is another needless > clusterfuck, like the premature 5.10 update was. Radek, so what with that? I'll be doing every perl rebuild anyway (to be able to remove athlon) so it's good oportunity to make that change, too at the same time. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From kiesiu at kiesiu.com Sun Mar 15 15:22:35 2009 From: kiesiu at kiesiu.com (Lukasz Kies) Date: Sun, 15 Mar 2009 15:22:35 +0100 Subject: [Th] python-pynotify - object has no attribute attach_to_status_icon Message-ID: <1adc5bd30903150722q7606816ep7c1bd60dfa807960@mail.gmail.com> Dear All, When I try to use 'attach_to_status_icon' method from libnotify in python I receive: [kiesiu at beth Desktop]$ ./statusicon-notification.py Traceback (most recent call last): File "./statusicon-notification.py", line 17, in notification.attach_to_status_icon(icon) AttributeError: 'pynotify.Notification' object has no attribute 'attach_to_status_icon' I found that during build process of python-pynotify, pynotify.c is not regenerated. When I remove this file I received: gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"pynotify-python\" -DDATADIR=\"/usr/local/share\" -DLIBDIR=\"/usr/local/lib\" -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/python2.6 -g -O2 -MT pynotifymodule.lo -MD -MP -MF .deps/pynotifymodule.Tpo -c pynotifymodule.c -fPIC -DPIC -o .libs/pynotifymodule.o (cd . \ && /usr/bin/python /usr/share/pygobject/2.0/codegen/codegen.py \ --register /usr/share/pygtk/2.0/defs/gtk-types.defs \ --register /usr/share/pygtk/2.0/defs/gdk-types.defs \ --override pynotify.override \ --prefix pypynotify pynotify.defs) > gen-pynotify.c \ && cp gen-pynotify.c pynotify.c \ && rm -f gen-pynotify.c /usr/bin/python: can't open file '/usr/share/pygobject/2.0/codegen/codegen.py': [Errno 2] No such file or directory make[2]: *** [pynotify.c] Error 2 We don't add *.py files (only *.py[co]) to packages thus configure script cannot find correct file and pynotify.c cannot be regenerated. Please find attached patch to python-pynotify source and patch on SPEC file. It builds on i686 and works fine to me. Please someone with rw access to CVS add it and if possible STBR. Regards, Lukasz Kies -------------- next part -------------- A non-text attachment was scrubbed... Name: python-pynotify-codegen.patch Type: text/x-patch Size: 509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: python-pynotify.patch Type: text/x-patch Size: 965 bytes Desc: not available URL: From patrys at pld-linux.org Sun Mar 15 16:57:01 2009 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Sun, 15 Mar 2009 16:57:01 +0100 Subject: [Th] python-pynotify - object has no attribute attach_to_status_icon In-Reply-To: <1adc5bd30903150722q7606816ep7c1bd60dfa807960@mail.gmail.com> References: <1adc5bd30903150722q7606816ep7c1bd60dfa807960@mail.gmail.com> Message-ID: <89b6ba3a0903150857p1a9b0a3dha32922040b62e63d@mail.gmail.com> 2009/3/15 Lukasz Kies : > I found that during build process of python-pynotify, pynotify.c is > not regenerated. Thanks, commited and sent to builders. Please report bugs using Launchpad, it's easier to spot them there. -- Patryk Zawadzki From radek at pld-linux.org Mon Mar 16 11:58:02 2009 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 16 Mar 2009 11:58:02 +0100 Subject: perl - no target_arch in paths? In-Reply-To: <200903141302.14375.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> <20090312144354.GA8701@bzium.google.pl> <200903141302.14375.arekm@maven.pl> Message-ID: <20090316105802.GA6529@bzium> Arkadiusz Miskiewicz [14-03-2009 13:02]: > On Thursday 12 of March 2009, Radoslaw Zielinski wrote: > > Pawel Golaszewski [12-03-2009 15:18]: [...] >>> We don't have to do it right now but on next bigger perl update? Why not? >> I'm cool with that. The thing I want to avoid is another needless >> clusterfuck, like the premature 5.10 update was. > Radek, so what with that? Currently, ENOTIME. > I'll be doing every perl rebuild anyway (to be able to remove athlon) > so it's good oportunity to make that change, too at the same time. Whatever your plan is, please take RFC 1925 rule #1 into account. To sum it up, there are three changes to be made: 1) removing arch and from install{{vendor,site}arch,archlib}, so /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi becomes /usr/local/lib/perl5/5.10, 2) getting rid of *.pmc, 3) disabling ithreads. Impact: #1: symlink / mv will make it work, #2: harmless, #3: requires a full rebuild of everything. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From glen at pld-linux.org Tue Mar 17 17:30:45 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 17 Mar 2009 18:30:45 +0200 Subject: SOURCES: pdftk-libgcj-4.3.patch - readded with -kb (may someone please disa... In-Reply-To: References: Message-ID: <200903171830.45294.glen@pld-linux.org> On Tuesday 17 March 2009 17:01:50 hawk wrote: > Author: hawk Date: Tue Mar 17 15:01:50 2009 GMT > Module: SOURCES Tag: HEAD > ---- Log message: > - readded with -kb (may someone please disable this CRLF stupidity once > and for all?) undos the patched files (prior patching), don't keep msdos crap in patches. and there is nobody who will disable that stupidity, i've crying too several times. -- glen From gotar at polanet.pl Tue Mar 17 17:42:36 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 17 Mar 2009 17:42:36 +0100 Subject: SOURCES: pdftk-libgcj-4.3.patch - readded with -kb (may someone please disa... In-Reply-To: <200903171830.45294.glen@pld-linux.org> References: <200903171830.45294.glen@pld-linux.org> Message-ID: <20090317164236.GA1430@polanet.pl> On Tue, Mar 17, 2009 at 18:30:45 +0200, Elan Ruusam?e wrote: > undos the patched files (prior patching), What for? Meybe we should reformat and reflow every source too? > don't keep msdos crap in patches. Patches should apply cleanly on sources if we want them to be eventually included in mainstream. > and there is nobody who will disable that stupidity, i've crying too several > times. So one must add patches with -kb. -- Tomasz Pala From glen at pld-linux.org Tue Mar 17 18:02:14 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Tue, 17 Mar 2009 19:02:14 +0200 Subject: SOURCES: pdftk-libgcj-4.3.patch - readded with -kb (may someone please disa... In-Reply-To: <20090317164236.GA1430@polanet.pl> References: <200903171830.45294.glen@pld-linux.org> <20090317164236.GA1430@polanet.pl> Message-ID: <200903171902.14294.glen@pld-linux.org> On Tuesday 17 March 2009 18:42:36 Tomasz Pala wrote: > So one must add patches with -kb. this is no solution. drawback is missing diff oppurtunity in cvsweb. -- glen From z at xatka.net Wed Mar 18 17:47:50 2009 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Wed, 18 Mar 2009 17:47:50 +0100 Subject: Rename java specs Message-ID: <20090318164750.GA19638@davabel.touk.pl> Please, copy following files in SPECS directory: cp java_cup.spec,v java-cup.spec,v cp mx4j.spec,v java-mx4j.spec,v cp logging-log4j.spec,v java-log4j.spec,v cp qdox.spec,v java-qdox.spec,v cp javahelp.spec,v java-help.spec,v cp jta.spec,v java-jta.spec,v cp wsdl4j.spec,v java-wsdl4j.spec,v cp jakarta-oro.spec,v java-oro.spec,v cp httpunit.spec,v java-httpunit.spec,v cp junit.spec,v java-junit.spec,v cp axis.spec,v java-axis.spec,v Pawe? From glen at pld-linux.org Thu Mar 19 12:06:00 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Thu, 19 Mar 2009 13:06:00 +0200 Subject: Rename java specs In-Reply-To: <20090318164750.GA19638@davabel.touk.pl> References: <20090318164750.GA19638@davabel.touk.pl> Message-ID: <200903191306.00913.glen@pld-linux.org> On Wednesday 18 March 2009 18:47:50 Pawe? Zuzelski wrote: > Please, copy following files in SPECS directory: > > cp java_cup.spec,v java-cup.spec,v > cp mx4j.spec,v java-mx4j.spec,v > cp logging-log4j.spec,v java-log4j.spec,v > cp qdox.spec,v java-qdox.spec,v > cp javahelp.spec,v java-help.spec,v > cp jta.spec,v java-jta.spec,v > cp wsdl4j.spec,v java-wsdl4j.spec,v > cp jakarta-oro.spec,v java-oro.spec,v > cp httpunit.spec,v java-httpunit.spec,v > cp junit.spec,v java-junit.spec,v > cp axis.spec,v java-axis.spec,v copied, except this one already existed: # cp java_cup.spec,v java-cup.spec,v cp: overwrite `java-cup.spec,v'? plz verify this as default cp will blindly overwrite the files! thank god i had 'cp=cp -pi alias' (or better: next time paste cp -pi as command) -- glen From z at xatka.net Thu Mar 19 12:44:04 2009 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Thu, 19 Mar 2009 12:44:04 +0100 Subject: Rename java specs In-Reply-To: <200903191306.00913.glen@pld-linux.org> References: <20090318164750.GA19638@davabel.touk.pl> <200903191306.00913.glen@pld-linux.org> Message-ID: <20090319114404.GA3865@davabel.touk.pl> On Thu, 19 Mar 2009, Elan Ruusam?e wrote: > copied, except this one already existed: > > # cp java_cup.spec,v java-cup.spec,v > cp: overwrite `java-cup.spec,v'? Adam Nowotny had copied these files before you, and replied to me and to cvsadmin. Please, add yourself to cvsadmin mail alias. > plz verify this as default cp will blindly overwrite the files! > thank god i had 'cp=cp -pi alias' Noone commited to these files yet, so no data is lost. > (or better: next time paste cp -pi as command) ok. Thanks. -- Pawe? From glen at pld-linux.org Fri Mar 20 14:53:24 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 20 Mar 2009 15:53:24 +0200 Subject: dir for initrd progs In-Reply-To: <200804271215.29241.glen@pld-linux.org> References: <200804271215.29241.glen@pld-linux.org> Message-ID: <200903201553.24292.glen@pld-linux.org> On Sunday 27 April 2008 12:15:29 Elan Ruusam?e wrote: > how about putting programs that were compiled to be put to initrd into own > dir instead of filling up /sbin with them? > > %{_libdir}/initrd i'm still +1 for this. we would use just for binaries nothing %config is placed there. -- glen From baggins at sith.mimuw.edu.pl Fri Mar 20 15:47:01 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Fri, 20 Mar 2009 15:47:01 +0100 Subject: dir for initrd progs In-Reply-To: <200903201553.24292.glen@pld-linux.org> References: <200804271215.29241.glen@pld-linux.org> <200903201553.24292.glen@pld-linux.org> Message-ID: <20090320144701.GA2575@sith.mimuw.edu.pl> On Fri, 20 Mar 2009, Elan Ruusam?e wrote: > On Sunday 27 April 2008 12:15:29 Elan Ruusam?e wrote: > > how about putting programs that were compiled to be put to initrd into own > > dir instead of filling up /sbin with them? > > > > %{_libdir}/initrd > > i'm still +1 for this. > > we would use just for binaries nothing %config is placed there. I thought about it and /{%lib}/initrd may be a better place for this. Just one question - does geninitrd require programs from /usr/bin? Because if geninitrd does not need /usr then we should not make new dependency. And /usr may not be mounted (for any reason) when geninitrd is run. 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 pld-linux.org Fri Mar 20 17:06:07 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Fri, 20 Mar 2009 18:06:07 +0200 Subject: dir for initrd progs In-Reply-To: <20090320144701.GA2575@sith.mimuw.edu.pl> References: <200804271215.29241.glen@pld-linux.org> <200903201553.24292.glen@pld-linux.org> <20090320144701.GA2575@sith.mimuw.edu.pl> Message-ID: <200903201806.07410.glen@pld-linux.org> On Friday 20 March 2009 16:47:01 Jan Rekorajski wrote: > On Fri, 20 Mar 2009, Elan Ruusam?e wrote: > > On Sunday 27 April 2008 12:15:29 Elan Ruusam?e wrote: > > > how about putting programs that were compiled to be put to initrd into > > > own dir instead of filling up /sbin with them? > > > > > > %{_libdir}/initrd > > > > i'm still +1 for this. > > > > we would use just for binaries nothing %config is placed there. > > I thought about it and /{%lib}/initrd may be a better place for this. > Just one question - does geninitrd require programs from /usr/bin? > Because if geninitrd does not need /usr then we should not make new > dependency. And /usr may not be mounted (for any reason) when geninitrd > is run. yes, the tools it uses to detect code are not the same progs it put to initrd. $ grep -c /usr/ /sbin/geninitrd /lib/geninitrd/* /sbin/geninitrd:18 /lib/geninitrd/functions:0 /lib/geninitrd/mod-dmraid.sh:0 /lib/geninitrd/mod-ide.sh:3 /lib/geninitrd/mod-luks.sh:0 /lib/geninitrd/mod-lvm.sh:0 /lib/geninitrd/mod-multipath.sh:0 > Janek -- glen From baggins at sith.mimuw.edu.pl Fri Mar 20 17:36:05 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Fri, 20 Mar 2009 17:36:05 +0100 Subject: dir for initrd progs In-Reply-To: <200903201806.07410.glen@pld-linux.org> References: <200804271215.29241.glen@pld-linux.org> <200903201553.24292.glen@pld-linux.org> <20090320144701.GA2575@sith.mimuw.edu.pl> <200903201806.07410.glen@pld-linux.org> Message-ID: <20090320163605.GA4090@sith.mimuw.edu.pl> On Fri, 20 Mar 2009, Elan Ruusam?e wrote: > On Friday 20 March 2009 16:47:01 Jan Rekorajski wrote: > > On Fri, 20 Mar 2009, Elan Ruusam?e wrote: > > > On Sunday 27 April 2008 12:15:29 Elan Ruusam?e wrote: > > > > how about putting programs that were compiled to be put to initrd into > > > > own dir instead of filling up /sbin with them? > > > > > > > > %{_libdir}/initrd > > > > > > i'm still +1 for this. > > > > > > we would use just for binaries nothing %config is placed there. > > > > I thought about it and /{%lib}/initrd may be a better place for this. > > Just one question - does geninitrd require programs from /usr/bin? > > Because if geninitrd does not need /usr then we should not make new > > dependency. And /usr may not be mounted (for any reason) when geninitrd > > is run. > yes, the tools it uses to detect code are not the same progs it put to initrd. > > $ grep -c /usr/ /sbin/geninitrd /lib/geninitrd/* I see. So it's %{_libdir}/initrd then. Comments, anyone? 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 baggins at sith.mimuw.edu.pl Fri Mar 20 20:11:27 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Fri, 20 Mar 2009 20:11:27 +0100 Subject: dir for initrd progs In-Reply-To: <200903201553.24292.glen@pld-linux.org> References: <200804271215.29241.glen@pld-linux.org> <200903201553.24292.glen@pld-linux.org> Message-ID: <20090320191127.GA12373@sith.mimuw.edu.pl> On Fri, 20 Mar 2009, Elan Ruusam?e wrote: > On Sunday 27 April 2008 12:15:29 Elan Ruusam?e wrote: > > how about putting programs that were compiled to be put to initrd into own > > dir instead of filling up /sbin with them? > > > > %{_libdir}/initrd > > i'm still +1 for this. > > we would use just for binaries nothing %config is placed there. One more thing, what package should provide that dir? I'm inclined towards filesystem, because one may want to use the programs but do not want to have geninitrd around (initramfs-tools for example). 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 gotar at polanet.pl Sat Mar 21 16:38:27 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 21 Mar 2009 16:38:27 +0100 Subject: login seriously broken Message-ID: <20090321153827.GA17793@polanet.pl> I'm having difficulties during local logins. It manifests by long (about 6 seconds and longer, sometimes much longer) delays when logging in from tty5-tty8. After checking logs, PAM, stracing and other voodoo I've found that it's caused by ...DNS lookups of ttyX.domain which obviously would not work and timeout without network available. Name : login Relocations: (not relocatable) Version : 2.14.2 Vendor: (none) Release : 2 Build Date: Wed Feb 18 21:21:20 2009 Install Date: Fri Feb 27 16:36:42 2009 Build Host: pld-builders query.log.0:21-Mar-2009 14:34:36.561 client xx.xx.x.xx#32778: view public: query: tty8.xxxxxxxx.pl IN A + query.log.0:21-Mar-2009 14:34:36.562 client xx.xx.x.xx#32778: view public: query: tty8.xxxxxxxx.pl IN AAAA + Older login is even more fucked: Name : login Relocations: (not relocatable) Version : 2.12r Vendor: (none) Release : 10 Build Date: Wed Jul 23 00:49:57 2008 Install Date: Thu Nov 27 03:24:49 2008 Build Host: oberon-pld # last -d root tty2 111.163.13.0 Sat Mar 21 14:27 - 14:27 (00:00) gotar tty4 150.92.12.0 Sat Mar 21 14:25 - 14:27 (00:01) root tty3 softbank12603300 Sat Mar 21 14:25 - 14:27 (00:01) root tty1 135.137.14.0 Sat Mar 21 14:25 - 14:26 (00:01) root tty2 Sat Mar 21 14:24 - 14:27 (00:02) root tty2 243.156.8.0 Fri Mar 20 19:24 - 19:25 (00:00) root tty3 33.45.9.0 Fri Mar 20 19:18 - down (00:02) root tty2 192.156.3.0 Fri Mar 20 19:17 - 19:20 (00:02) reboot system boot 57.19.4.0 Fri Mar 20 19:16 (00:04) root tty1 38.18.15.0 Fri Mar 20 19:09 - down (00:00) root tty3 42.234.10.0 Fri Mar 20 19:09 - down (00:00) root tty2 248.45.5.0 Fri Mar 20 19:07 - 19:09 (00:02) reboot system boot 113.194.10.0 Fri Mar 20 18:39 (00:05) root tty1 170.253.7.0 Thu Mar 19 19:53 - down (22:33) reboot system boot 143.53.6.0 Thu Mar 19 11:45 (1+06:41) reboot system boot 111.240.8.0 Tue Mar 17 08:16 (3+10:10) having login delays and DNS lookups too... WTF? -- Tomasz Pala From gotar at polanet.pl Sat Mar 21 16:47:11 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 21 Mar 2009 16:47:11 +0100 Subject: geninitrd still/again totally damaged and useless Message-ID: <20090321154711.GB17793@polanet.pl> Name : geninitrd Relocations: (not relocatable) Version : 10000.3 Vendor: (none) Release : 2 Build Date: Sat Mar 14 23:32:18 2009 Install Date: Fri Mar 20 13:20:53 2009 Build Host: th-x86-64.pld-linux.org after reboot I've got: pivot_root: blabla NEW_ROOT or sth kernel panic hopefully I got -old kernel and geninitrd-7982-1 (dated 2006) which works with current kernel-2.6.28.8-1.x86_64. Who's responsible for heavily damaging such important packages? -- Tomasz Pala From gotar at polanet.pl Sat Mar 21 17:00:45 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 21 Mar 2009 17:00:45 +0100 Subject: kernel: where's my RTC gone? Message-ID: <20090321160045.GC17793@polanet.pl> Linux pepin 2.6.28.8-1 #1 SMP Tue Mar 17 12:41:34 CET 2009 x86_64 AMD_Athlon(tm)_64_X2_Dual_Core_Processor_6000+ PLD Linux # hwclock --debug hwclock from util-linux-2.12r hwclock: Open of /dev/rtc failed, errno=19: No such device. No usable clock interface found. Cannot access the Hardware Clock via any known method. hwclock from util-linux-ng 2.14.2 doesn't work either. # cat /proc/driver/rtc rtc_time : 16:00:00 rtc_date : 2009-03-21 alrm_time : 00:00:00 alrm_date : ****-**-** alarm_IRQ : no alrm_pending : no 24hr : yes periodic_IRQ : no update_IRQ : no HPET_emulated : yes DST_enable : no periodic_freq : 1024 batt_status : okay -- Tomasz Pala From arekm at maven.pl Sat Mar 21 17:26:11 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 21 Mar 2009 17:26:11 +0100 Subject: kernel: where's my RTC gone? In-Reply-To: <20090321160045.GC17793@polanet.pl> References: <20090321160045.GC17793@polanet.pl> Message-ID: <200903211726.11901.arekm@maven.pl> On Saturday 21 of March 2009, Tomasz Pala wrote: > Linux pepin 2.6.28.8-1 #1 SMP Tue Mar 17 12:41:34 CET 2009 x86_64 > AMD_Athlon(tm)_64_X2_Dual_Core_Processor_6000+ PLD Linux > > # hwclock --debug > hwclock from util-linux-2.12r > hwclock: Open of /dev/rtc failed, errno=19: No such device. > No usable clock interface found. > Cannot access the Hardware Clock via any known method. You seem to not use udev-core which is a problem. Create crw-rw---- 1 root root 254, 0 03-20 19:27 /dev/rtc0 with rtc major from /proc/devices -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Sat Mar 21 17:27:23 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 21 Mar 2009 17:27:23 +0100 Subject: geninitrd still/again totally damaged and useless In-Reply-To: <20090321154711.GB17793@polanet.pl> References: <20090321154711.GB17793@polanet.pl> Message-ID: <200903211727.23303.arekm@maven.pl> On Saturday 21 of March 2009, Tomasz Pala wrote: > Name : geninitrd Relocations: (not relocatable) > Version : 10000.3 Vendor: (none) > Release : 2 Build Date: Sat Mar 14 23:32:18 > 2009 Install Date: Fri Mar 20 13:20:53 2009 Build Host: > th-x86-64.pld-linux.org > > after reboot I've got: > > pivot_root: blabla NEW_ROOT or sth > kernel panic > > > hopefully I got -old kernel and geninitrd-7982-1 (dated 2006) which > works with current kernel-2.6.28.8-1.x86_64. > > Who's responsible for heavily damaging such important packages? Check commit log. Unfortunately this report is useless ;/ -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From gotar at polanet.pl Sat Mar 21 20:26:02 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 21 Mar 2009 20:26:02 +0100 Subject: kernel: where's my RTC gone? In-Reply-To: <200903211726.11901.arekm@maven.pl> References: <20090321160045.GC17793@polanet.pl> <200903211726.11901.arekm@maven.pl> Message-ID: <20090321192602.GA28307@polanet.pl> On Sat, Mar 21, 2009 at 17:26:11 +0100, Arkadiusz Miskiewicz wrote: >> # hwclock --debug >> hwclock from util-linux-2.12r >> hwclock: Open of /dev/rtc failed, errno=19: No such device. >> No usable clock interface found. >> Cannot access the Hardware Clock via any known method. > > You seem to not use udev-core which is a problem. Yes, it's production system and I cannot aford using such unreliable solutions. > Create > > crw-rw---- 1 root root 254, 0 03-20 19:27 /dev/rtc0 0 crw-r--r-- 1 root root 254, 0 Mar 21 20:12 /dev/rtc0 > with rtc major from /proc/devices # grep rtc /proc/devices 254 rtc Thnx, I've added it to dev-list, but I'm not sure what permissions are suitable, you've got 660 while /dev/rtc already has 664. # hwclock --debug hwclock from util-linux-2.12r hwclock: Open of /dev/rtc failed, errno=19: No such device. No usable clock interface found. Cannot access the Hardware Clock via any known method. however: # ./hwclock --debug hwclock from util-linux-ng 2.14.2 Using /dev interface to clock. Last drift adjustment done at 1237570798 seconds after 1969 Last calibration done at 1237570798 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2009/03/21 19:17:23 Hw clock time : 2009/03/21 19:17:23 = 1237663043 seconds since 1969 Sat Mar 21 20:17:23 2009 -0.519839 seconds is it enough to give kernel C: util-linux < 2.14 ? -- Tomasz Pala From arekm at maven.pl Sat Mar 21 20:37:00 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 21 Mar 2009 20:37:00 +0100 Subject: SOURCES: dev-list - added /dev/rtc0 In-Reply-To: References: Message-ID: <200903212037.00587.arekm@maven.pl> On Saturday 21 of March 2009, gotar wrote: > Author: gotar Date: Sat Mar 21 19:23:52 2009 GMT > Module: SOURCES Tag: HEAD > ---- Log message: > - added /dev/rtc0 > > ---- Files affected: > SOURCES: > dev-list (1.46 -> 1.47) > > ---- Diffs: > > ================================================================ > Index: SOURCES/dev-list > diff -u SOURCES/dev-list:1.46 SOURCES/dev-list:1.47 > --- SOURCES/dev-list:1.46 Sun Mar 1 17:25:20 2009 > +++ SOURCES/dev-list Sat Mar 21 20:23:46 2009 > @@ -7254,6 +7254,7 @@ > %dev(c,12,6) %attr(660,root,disk) /dev/rmt8 > %dev(c,36,0) %attr(644,root,root) /dev/route > %dev(c,10,135) %attr(664,root,root) /dev/rtc > +%dev(c,254,0) %attr(664,root,root) /dev/rtc0 This is _very_ wong. 254 is dynamicly alocated major number. There can be different devices using 254 depending on kernel modules load order. The correct solution for such non-udev systems would be probably init.d/dev script that would parse /proc/devices and setup /dev/ files properly. Not sure if MAKEDEV.spec is able to do the parsing on it's own but if it is then init.d/dev script calling MAKEDEV for some devices like rtc0 should be enough. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Sat Mar 21 20:37:56 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 21 Mar 2009 20:37:56 +0100 Subject: kernel: where's my RTC gone? In-Reply-To: <20090321192602.GA28307@polanet.pl> References: <20090321160045.GC17793@polanet.pl> <200903211726.11901.arekm@maven.pl> <20090321192602.GA28307@polanet.pl> Message-ID: <200903212037.56511.arekm@maven.pl> On Saturday 21 of March 2009, Tomasz Pala wrote: > Thnx, I've added it to dev-list, but I'm not sure what permissions are > suitable, you've got 660 while /dev/rtc already has 664. Too bad because this solution is invalid - see other mail. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Sun Mar 22 03:43:19 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Sun, 22 Mar 2009 04:43:19 +0200 Subject: dir for initrd progs In-Reply-To: <20090320191127.GA12373@sith.mimuw.edu.pl> References: <200804271215.29241.glen@pld-linux.org> <200903201553.24292.glen@pld-linux.org> <20090320191127.GA12373@sith.mimuw.edu.pl> Message-ID: <200903220443.19955.glen@pld-linux.org> On Friday 20 March 2009 21:11:27 Jan Rekorajski wrote: > On Fri, 20 Mar 2009, Elan Ruusam?e wrote: > > On Sunday 27 April 2008 12:15:29 Elan Ruusam?e wrote: > > > how about putting programs that were compiled to be put to initrd into > > > own dir instead of filling up /sbin with them? > > > > > > %{_libdir}/initrd > > > > i'm still +1 for this. > > > > we would use just for binaries nothing %config is placed there. > > One more thing, what package should provide that dir? > I'm inclined towards filesystem, because one may want to use the > programs but do not want to have geninitrd around (initramfs-tools for > example). indeed "filesystem" if the other alternative would had been geninitrd... -- glen From mmazur at kernel.pl Sun Mar 22 23:27:28 2009 From: mmazur at kernel.pl (Mariusz Mazur) Date: Sun, 22 Mar 2009 23:27:28 +0100 Subject: Jabber going down Message-ID: <200903222327.28917.mmazur@kernel.pl> Maintenance. Sorry, but our current jabberd is a few years old and started to segfault when someone tries to connect with the newest version of telepathy. I'm hoping this shouldn't take longer than few hours, but there are no guarantees. From mmazur at kernel.pl Mon Mar 23 03:20:39 2009 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 23 Mar 2009 03:20:39 +0100 Subject: Jabber going down In-Reply-To: <200903222327.28917.mmazur@kernel.pl> References: <200903222327.28917.mmazur@kernel.pl> Message-ID: <200903230320.39289.mmazur@kernel.pl> Jabber is back up again with gg transport working fine. Everything seems to be in order and the new server seems stable, at least for now. Well, allmost. The previous jabberd had a complete mess in the database wrt character encoding. I did a mysqldump and this: ep09.pld-linux.org/~mmazur/misc/l is supposed to be the following string: " ? \n" (that's ?), which means that '?' is encoded as: c3 85 e2 80 9a I have absolutely no fscking idea how to convert something like that to a normal '?' in utf8 and I've been trying for the past few hours. For the time being I've patched the new jabberd to behave just like the old one and it helped -- I'm seeing normal national characters in my jabber client, but that's a short-term solution, since it'll make upgrading jabberd harder. Does anyone have any idea how to fix this? From mmazur at kernel.pl Mon Mar 23 03:25:19 2009 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 23 Mar 2009 03:25:19 +0100 Subject: Jabber going down In-Reply-To: <200903230320.39289.mmazur@kernel.pl> References: <200903222327.28917.mmazur@kernel.pl> <200903230320.39289.mmazur@kernel.pl> Message-ID: <200903230325.19373.mmazur@kernel.pl> > Does anyone have any idea how to fix this? Ok, never mind, mysqldump is stupid and so am I. From glen at pld-linux.org Mon Mar 23 13:16:04 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Mon, 23 Mar 2009 14:16:04 +0200 Subject: Jabber going down In-Reply-To: <200903230320.39289.mmazur@kernel.pl> References: <200903222327.28917.mmazur@kernel.pl> <200903230320.39289.mmazur@kernel.pl> Message-ID: <200903231416.04438.glen@pld-linux.org> On Monday 23 March 2009 04:20:39 Mariusz Mazur wrote: > ep09.pld-linux.org/~mmazur/misc/l is supposed to be the following string: > " ? \n" (that's ?), which means that '?' is encoded > as: c3 85 e2 80 9a double encoded from cp1257 or sth? $ iconv -futf8 -tcp1257 and mysqldump is not stupid unless you manually edit it (like removing SET CHARSET lines)... -- glen From arekm at maven.pl Mon Mar 23 13:19:57 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 23 Mar 2009 13:19:57 +0100 Subject: Jabber going down In-Reply-To: <200903231416.04438.glen@pld-linux.org> References: <200903222327.28917.mmazur@kernel.pl> <200903230320.39289.mmazur@kernel.pl> <200903231416.04438.glen@pld-linux.org> Message-ID: <200903231319.58073.arekm@maven.pl> On Monday 23 of March 2009, Elan Ruusam?e wrote: > and mysqldump is not stupid unless you manually edit it (like removing SET > CHARSET lines)... mysqldump is not stupid, users usually are (aka they don't know how these things are handled in mysql). -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From mmazur at kernel.pl Mon Mar 23 13:54:33 2009 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 23 Mar 2009 13:54:33 +0100 Subject: Jabber going down In-Reply-To: <200903231319.58073.arekm@maven.pl> References: <200903222327.28917.mmazur@kernel.pl> <200903231416.04438.glen@pld-linux.org> <200903231319.58073.arekm@maven.pl> Message-ID: <200903231354.33614.mmazur@kernel.pl> Dnia poniedzia?ek, 23 marca 2009, Arkadiusz Miskiewicz napisa?: > On Monday 23 of March 2009, Elan Ruusam?e wrote: > > and mysqldump is not stupid unless you manually edit it (like removing > > SET CHARSET lines)... > > mysqldump is not stupid, users usually are (aka they don't know how these > things are handled in mysql). If you can figure out how to transform what mysqldump dumped into something usable using iconv, I'm all ears. If not, I'm sticking to my version, that mysqldump is stupid for producing something this weird. From arekm at maven.pl Mon Mar 23 13:58:53 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 23 Mar 2009 13:58:53 +0100 Subject: Jabber going down In-Reply-To: <200903231354.33614.mmazur@kernel.pl> References: <200903222327.28917.mmazur@kernel.pl> <200903231319.58073.arekm@maven.pl> <200903231354.33614.mmazur@kernel.pl> Message-ID: <200903231358.53805.arekm@maven.pl> On Monday 23 of March 2009, Mariusz Mazur wrote: > Dnia poniedzia?ek, 23 marca 2009, Arkadiusz Miskiewicz napisa?: > > On Monday 23 of March 2009, Elan Ruusam?e wrote: > > > and mysqldump is not stupid unless you manually edit it (like removing > > > SET CHARSET lines)... > > > > mysqldump is not stupid, users usually are (aka they don't know how these > > things are handled in mysql). > > If you can figure out how to transform what mysqldump dumped into something > usable using iconv, I'm all ears. If not, I'm sticking to my version, that > mysqldump is stupid for producing something this weird. This means that your database was broken initially. There are ways to fix this if you have working old mysql setup and _then_ do dump. Still, user fault, not mysqldump. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From mmazur at kernel.pl Mon Mar 23 15:41:24 2009 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 23 Mar 2009 15:41:24 +0100 Subject: Jabber going down In-Reply-To: <200903231358.53805.arekm@maven.pl> References: <200903222327.28917.mmazur@kernel.pl> <200903231354.33614.mmazur@kernel.pl> <200903231358.53805.arekm@maven.pl> Message-ID: <200903231541.24842.mmazur@kernel.pl> Dnia poniedzia?ek, 23 marca 2009, Arkadiusz Miskiewicz napisa?: > This means that your database was broken initially. There are ways to fix > this if you have working old mysql setup and _then_ do dump. To fix it, it was enough to tell mysqldump to use utf8 instead of latin1 for dumping. The resulting file was perfectly normal utf8, even though the dump said CHARSET=latin1 on all tables. It was enough to modify those CHARSETs to utf8 and reimport the whole db using mysql (also set to utf8). It works fine now. I have no problem with it working this way, it's quite normal. The me being an idiot part is that I missed this functionality. What I *do* have a problem with however is that I have absolutely no idea what exactly mysqldump did to those characters when it thought it was converting them to latin1. Seriously, what kind of encoding conversion produces such garbage as its output and doesn't complain that, hey, maybe there's something wrong in here. From patrys at pld-linux.org Mon Mar 23 15:45:40 2009 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Mon, 23 Mar 2009 15:45:40 +0100 Subject: Jabber going down In-Reply-To: <200903231541.24842.mmazur@kernel.pl> References: <200903222327.28917.mmazur@kernel.pl> <200903231354.33614.mmazur@kernel.pl> <200903231358.53805.arekm@maven.pl> <200903231541.24842.mmazur@kernel.pl> Message-ID: <89b6ba3a0903230745t5332e0c0p3c2784afd13b0323@mail.gmail.com> 2009/3/23 Mariusz Mazur : > Dnia poniedzia?ek, 23 marca 2009, Arkadiusz Miskiewicz napisa?: >> This means that your database was broken initially. ?There are ways to fix >> this if you have working old mysql setup and _then_ do dump. > To fix it, it was enough to tell mysqldump to use utf8 instead of latin1 for > dumping. The resulting file was perfectly normal utf8, even though the dump > said CHARSET=latin1 on all tables. It was enough to modify those CHARSETs to > utf8 and reimport the whole db using mysql (also set to utf8). It works fine > now. > > I have no problem with it working this way, it's quite normal. The me being an > idiot part is that I missed this functionality. It's not normal. It's caused by broken collation settings. -- Patryk Zawadzki From arekm at maven.pl Mon Mar 23 15:52:39 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 23 Mar 2009 15:52:39 +0100 Subject: Jabber going down In-Reply-To: <200903231541.24842.mmazur@kernel.pl> References: <200903222327.28917.mmazur@kernel.pl> <200903231358.53805.arekm@maven.pl> <200903231541.24842.mmazur@kernel.pl> Message-ID: <200903231552.39378.arekm@maven.pl> On Monday 23 of March 2009, Mariusz Mazur wrote: > Dnia poniedzia?ek, 23 marca 2009, Arkadiusz Miskiewicz napisa?: > > This means that your database was broken initially. There are ways to > > fix this if you have working old mysql setup and _then_ do dump. > > To fix it, it was enough to tell mysqldump to use utf8 instead of latin1 > for dumping. The resulting file was perfectly normal utf8, even though the > dump said CHARSET=latin1 on all tables. It was enough to modify those > CHARSETs to utf8 and reimport the whole db using mysql (also set to utf8). > It works fine now. So someone imported utf8 to latin1 created tables? Looks like that. mysql does conversion on the fly, so if it has bad data or bad information about the data it will fail if conversion is going to be applied. > What I *do* have a problem with however is that I have absolutely no idea > what exactly mysqldump did to those characters when it thought it was > converting them to latin1. Seriously, what kind of encoding conversion > produces such garbage as its output and doesn't complain that, hey, maybe > there's something wrong in here. The thing is that convesion succeeded, so that part was fine. Ie. chars in A were fully convertable to B (but of course that was crap from user point of view). -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Mon Mar 23 15:57:40 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 23 Mar 2009 15:57:40 +0100 Subject: Jabber going down In-Reply-To: <200903231552.39378.arekm@maven.pl> References: <200903222327.28917.mmazur@kernel.pl> <200903231541.24842.mmazur@kernel.pl> <200903231552.39378.arekm@maven.pl> Message-ID: <200903231557.40867.arekm@maven.pl> On Monday 23 of March 2009, Arkadiusz Miskiewicz wrote: > On Monday 23 of March 2009, Mariusz Mazur wrote: > > Dnia poniedzia?ek, 23 marca 2009, Arkadiusz Miskiewicz napisa?: > > > This means that your database was broken initially. There are ways to > > > fix this if you have working old mysql setup and _then_ do dump. > > > > To fix it, it was enough to tell mysqldump to use utf8 instead of latin1 > > for dumping. The resulting file was perfectly normal utf8, even though > > the dump said CHARSET=latin1 on all tables. It was enough to modify those > > CHARSETs to utf8 and reimport the whole db using mysql (also set to > > utf8). It works fine now. > > So someone imported utf8 to latin1 created tables? Looks like that. mysql > does conversion on the fly, so if it has bad data or bad information about > the data it will fail if conversion is going to be applied. s/fail/produce unexpected but totally correct result/ -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Mon Mar 23 16:09:46 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Mon, 23 Mar 2009 17:09:46 +0200 Subject: SPECS: busybox.spec, cryptsetup-luks.spec, dmraid.spec, e2fsprogs.spec, lvm... In-Reply-To: References: Message-ID: <200903231709.46429.glen@pld-linux.org> On Monday 23 March 2009 15:03:20 you wrote: > -Conflicts:?????geninitrd < 3075 > +Conflicts:?????geninitrd <= 10000.3 > ? (arhj), not again! do not use <= comparision! -- glen From baggins at sith.mimuw.edu.pl Mon Mar 23 16:18:16 2009 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 23 Mar 2009 16:18:16 +0100 Subject: SPECS: busybox.spec, cryptsetup-luks.spec, dmraid.spec, e2fsprogs.spec, lvm... In-Reply-To: <200903231709.46429.glen@pld-linux.org> References: <200903231709.46429.glen@pld-linux.org> Message-ID: <20090323151816.GA22018@sith.mimuw.edu.pl> On Mon, 23 Mar 2009, Elan Ruusam?e wrote: > On Monday 23 March 2009 15:03:20 you wrote: > > -Conflicts:?????geninitrd < 3075 > > +Conflicts:?????geninitrd <= 10000.3 > > ? > > (arhj), not again! > > do not use <= comparision! Now I don't get it. For me it means 'conflict with geninitrd LESS OR EQUAL 10000.3'. What's wrong here? 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 arekm at maven.pl Mon Mar 23 17:26:42 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 23 Mar 2009 17:26:42 +0100 Subject: SPECS: busybox.spec, cryptsetup-luks.spec, dmraid.spec, e2fsprogs.spec, lvm... In-Reply-To: <200903231709.46429.glen@pld-linux.org> References: <200903231709.46429.glen@pld-linux.org> Message-ID: <200903231726.43027.arekm@maven.pl> On Monday 23 of March 2009, Elan Ruusam?e wrote: > On Monday 23 March 2009 15:03:20 you wrote: > > -Conflicts: geninitrd < 3075 > > +Conflicts: geninitrd <= 10000.3 > > > > (arhj), not again! > > do not use <= comparision! Could you update adapter to handle and fix such things? -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Mon Mar 23 18:29:09 2009 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Mon, 23 Mar 2009 19:29:09 +0200 Subject: SPECS: busybox.spec, cryptsetup-luks.spec, dmraid.spec, e2fsprogs.spec, lvm... In-Reply-To: <20090323151816.GA22018@sith.mimuw.edu.pl> References: <200903231709.46429.glen@pld-linux.org> <20090323151816.GA22018@sith.mimuw.edu.pl> Message-ID: <200903231929.09712.glen@pld-linux.org> On Monday 23 March 2009 17:18, Jan Rekorajski wrote: > On Mon, 23 Mar 2009, Elan Ruusam?e wrote: > > On Monday 23 March 2009 15:03:20 you wrote: > > > -Conflicts: geninitrd < 3075 > > > +Conflicts: geninitrd <= 10000.3 > > > > > > > (arhj), not again! > > > > do not use <= comparision! > > Now I don't get it. For me it means 'conflict with geninitrd LESS OR > EQUAL 10000.3'. What's wrong here? i don't recall details, but i remember such comparision fired event whatever the %{release} is, even if you do specify %{release} in comparision (or even worse, it matched whatever the %{version} or %{release} was) it was especially painful with %triggerpostun events. as i don't have notes nor have reproducer, i'd say better safe than sorry. _maybe_ the actual cause was what was solved by -namespace-probe.patch [1] patch. don't know and hard to check the timeline. [1] http://cvs.pld-linux.org:80/cgi-bin/cvsweb.cgi/SOURCES/Attic/rpm- namespace-probe.patch -- glen From qboosh at pld-linux.org Mon Mar 23 22:16:28 2009 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 23 Mar 2009 22:16:28 +0100 Subject: recent java changes (enforcing gcj) In-Reply-To: <20090312144954.GA8459@davabel.touk.pl> References: <20090311212923.GA11718@stranger.qboosh.pl> <20090312144954.GA8459@davabel.touk.pl> Message-ID: <20090323211628.GA17509@stranger.qboosh.pl> On Thu, Mar 12, 2009 at 03:49:54PM +0100, Pawe? Zuzelski wrote: > On Wed, 11 Mar 2009, Jakub Bogusz wrote: > > > There should be a way to build packages using jdk - without need to > > uninstall java-sun and replace it with gcj - e.g. by %bcond_with jdk. > > IMO we should enforce a specified implemetation of jdk even > for packages that can be build using both jdks, because package > built with java-sun differ from the same package built with > java-gcj-compat-devel. By default - yes. But it should be possible to build using java-sun by (explicitly) using some bcond. [...] > > Also, removing versioned jre Requires doesn't look good to me - the > > required versions were put not without reason. > > This dependency should be autogenerated and it should look like > that: R: java(ClassDataVersion) = n (+further explanation in next posting) This is jvm. But particular version of jre contains also set of libraries with matching versions - and it can be something that versioned jre dependencies could cover. -- Jakub Bogusz http://qboosh.pl/ From z at xatka.net Tue Mar 24 07:08:58 2009 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Tue, 24 Mar 2009 07:08:58 +0100 Subject: recent java changes (enforcing gcj) In-Reply-To: <20090323211628.GA17509@stranger.qboosh.pl> References: <20090311212923.GA11718@stranger.qboosh.pl> <20090312144954.GA8459@davabel.touk.pl> <20090323211628.GA17509@stranger.qboosh.pl> Message-ID: <20090324060858.GA8559@davabel.touk.pl> On Mon, 23 Mar 2009, Jakub Bogusz wrote: > On Thu, Mar 12, 2009 at 03:49:54PM +0100, Pawe? Zuzelski wrote: > > On Wed, 11 Mar 2009, Jakub Bogusz wrote: > > > > > There should be a way to build packages using jdk - without need to > > > uninstall java-sun and replace it with gcj - e.g. by %bcond_with jdk. > > > > IMO we should enforce a specified implemetation of jdk even > > for packages that can be build using both jdks, because package > > built with java-sun differ from the same package built with > > java-gcj-compat-devel. > > By default - yes. > But it should be possible to build using java-sun by (explicitly) using > some bcond. Yes, that is true. I have added such bcond to some java packages and I will add it to all of them. > [...] > > > Also, removing versioned jre Requires doesn't look good to me - the > > > required versions were put not without reason. > > > > This dependency should be autogenerated and it should look like > > that: R: java(ClassDataVersion) = n > (+further explanation in next posting) > > This is jvm. > But particular version of jre contains also set of libraries with > matching versions - and it can be something that versioned jre > dependencies could cover. OK. I'll check it out. BTW thanks for comments. -- Pawe? From glen at pld-linux.org Fri Mar 27 10:43:20 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 27 Mar 2009 11:43:20 +0200 Subject: SPECS: bosh.spec (NEW) - added to PLD In-Reply-To: References: Message-ID: <200903271143.20318.glen@pld-linux.org> On Friday 27 March 2009 11:19:09 lisu wrote: > +%prep > +%setup -q > +%{__sed} -i 's at ncurses.h@ncurses/ncurses.h@' configure.in *.c we add -I/usr/include/ncurses to CPPFLAGS/CFLAGS usually instead in pld. -- glen From blues at pld-linux.org Fri Mar 27 17:26:57 2009 From: blues at pld-linux.org (Pawel Golaszewski) Date: Fri, 27 Mar 2009 17:26:57 +0100 (CET) Subject: SOURCES: iptables.init, ip6tables.init - do nothing in vserver In-Reply-To: References: Message-ID: On Fri, 27 Mar 2009, glen wrote: > Author: glen Date: Fri Mar 27 15:11:44 2009 GMT > Module: SOURCES Tag: HEAD > ---- Log message: > - do nothing in vserver > > ---- Files affected: > SOURCES: > iptables.init (1.8 -> 1.9) , ip6tables.init (1.12 -> 1.13) > ================================================================ > Index: SOURCES/iptables.init > diff -u SOURCES/iptables.init:1.8 SOURCES/iptables.init:1.9 > --- SOURCES/iptables.init:1.8 Sat Mar 3 11:48:09 2007 > +++ SOURCES/iptables.init Fri Mar 27 16:11:38 2009 > @@ -26,6 +26,11 @@ > # Source 'em up > . /etc/rc.d/init.d/functions > > +# Not supported in vserver > +if is_yes "$VSERVER"; then > + exit 0 > +fi > + > if [ "$(kernelver)" -lt "002003000" ]; then > exit 0 > fi > > ================================================================ > Index: SOURCES/ip6tables.init > diff -u SOURCES/ip6tables.init:1.12 SOURCES/ip6tables.init:1.13 > --- SOURCES/ip6tables.init:1.12 Sat Mar 3 11:53:32 2007 > +++ SOURCES/ip6tables.init Fri Mar 27 16:11:39 2009 > @@ -27,6 +27,11 @@ > # Source 'em up > . /etc/rc.d/init.d/functions > > +# Not supported in vserver > +if is_yes "$VSERVER"; then > + exit 0 > +fi > + > if [ "$(kernelver)" -lt "002003000" ]; then > exit 0 > fi Wrong, please revert. You can add proper CAP and play with iptables. It's not-so-rare. -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From gotar at polanet.pl Sat Mar 28 15:38:24 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 28 Mar 2009 15:38:24 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <200903100819.45094.arekm@maven.pl> References: <200903092241.12695.arekm@maven.pl> <20090309231052.GA29014@pld-linux.org> <200903100819.45094.arekm@maven.pl> Message-ID: <20090328143824.GA9938@polanet.pl> On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely handled > in poldek (as amd64->x86_64 is for example) ? Since when amd64->x86_64 is handled by poldek anyway? -- Tomasz Pala From arekm at maven.pl Sat Mar 28 16:00:51 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 28 Mar 2009 16:00:51 +0100 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090328143824.GA9938@polanet.pl> References: <200903092241.12695.arekm@maven.pl> <200903100819.45094.arekm@maven.pl> <20090328143824.GA9938@polanet.pl> Message-ID: <200903281600.51872.arekm@maven.pl> On Saturday 28 of March 2009, Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely > > handled in poldek (as amd64->x86_64 is for example) ? > > Since when amd64->x86_64 is handled by poldek anyway? Look at th poldek changelog, I don't remember. You need to install poldek th and then other packages will be handled nicely. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Sat Mar 28 20:31:06 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Sat, 28 Mar 2009 21:31:06 +0200 Subject: Th: dropping athlon and maybe deprecating ppc? In-Reply-To: <20090328143824.GA9938@polanet.pl> References: <200903092241.12695.arekm@maven.pl> <200903100819.45094.arekm@maven.pl> <20090328143824.GA9938@polanet.pl> Message-ID: <200903282131.06914.glen@pld-linux.org> On Saturday 28 March 2009 16:38:24 Tomasz Pala wrote: > On Tue, Mar 10, 2009 at 08:19:44 +0100, Arkadiusz Miskiewicz wrote: > > Could some athlon*rpm owner see if upgrading athlon->i686 is nicely > > handled in poldek (as amd64->x86_64 is for example) ? > > Since when amd64->x86_64 is handled by poldek anyway? see <200903101215.59792.glen at pld-linux.org> -- glen From gotar at polanet.pl Sun Mar 29 22:58:02 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 29 Mar 2009 22:58:02 +0200 Subject: geninitrd still/again totally damaged and useless In-Reply-To: <200903211727.23303.arekm@maven.pl> References: <20090321154711.GB17793@polanet.pl> <200903211727.23303.arekm@maven.pl> Message-ID: <20090329205802.GA30515@polanet.pl> On Sat, Mar 21, 2009 at 17:27:23 +0100, Arkadiusz Miskiewicz wrote: >> Version : 10000.3 Vendor: (none) >> Release : 2 Build Date: Sat Mar 14 23:32:18 >> >> pivot_root: blabla NEW_ROOT or sth >> kernel panic > > Check commit log. Unfortunately this report is useless ;/ There's nothing to check... I've mounted this cpio.gz image and there's only /init script which may fail at exec switch_root /newroot $init. So the problem remains: it just don't work. Maybe there were some changes in busybox since 1.00-4? I've just checked its commit log and: 1.102.2.2 Sun Mar 23 21:10:19 2008 by adamg, auto-ac-busybox-1_00-4 - introduce switch_root (be comaptible with recent recent busybox versions) it's first version having this, so it can be too old version (in R). However... # grep switch_root =initrd-busybox Binary file /bin/initrd-busybox matches -- Tomasz Pala From gotar at polanet.pl Sun Mar 29 23:00:12 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 29 Mar 2009 23:00:12 +0200 Subject: SOURCES: pdftk-libgcj-4.3.patch - readded with -kb (may someone please disa... In-Reply-To: <200903171902.14294.glen@pld-linux.org> References: <200903171830.45294.glen@pld-linux.org> <20090317164236.GA1430@polanet.pl> <200903171902.14294.glen@pld-linux.org> Message-ID: <20090329210012.GA8389@polanet.pl> On Tue, Mar 17, 2009 at 19:02:14 +0200, Elan Ruusam?e wrote: >> So one must add patches with -kb. > > this is no solution. drawback is missing diff oppurtunity in cvsweb. Well, fixing CVS server is the solution. Any other is just a solution. -- Tomasz Pala From gotar at polanet.pl Sun Mar 29 23:19:30 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 29 Mar 2009 23:19:30 +0200 Subject: kernel: where's my RTC gone? In-Reply-To: <200903212037.56511.arekm@maven.pl> References: <20090321160045.GC17793@polanet.pl> <200903211726.11901.arekm@maven.pl> <20090321192602.GA28307@polanet.pl> <200903212037.56511.arekm@maven.pl> Message-ID: <20090329211930.GB8389@polanet.pl> On Sat, Mar 21, 2009 at 20:37:56 +0100, Arkadiusz Miskiewicz wrote: >> Thnx, I've added it to dev-list, but I'm not sure what permissions are >> suitable, you've got 660 while /dev/rtc already has 664. > > Too bad because this solution is invalid - see other mail. I've commented this out as I can't find a way to make this number 'stable'. For example ipmi_devintf module has ipmi_major parameter: ipmi_major:Sets the major number of the IPMI device. By default, or if you set it to zero, it will choose the next available device. Setting it to -1 will disable the interface. Other values will set the major device number to that value. and thus can be bind forever, but I don't see any parameters for rtc_cmos driver. BTW why is it build into kernel not module? 1.1.2.75 Thu Dec 4 10:12:40 2008 by pluto - built-in rtc cmos driver. -- Tomasz Pala From gotar at polanet.pl Sun Mar 29 23:25:11 2009 From: gotar at polanet.pl (Tomasz Pala) Date: Sun, 29 Mar 2009 23:25:11 +0200 Subject: SOURCES: dev-list - added /dev/rtc0 In-Reply-To: <200903212037.00587.arekm@maven.pl> References: <200903212037.00587.arekm@maven.pl> Message-ID: <20090329212511.GC8389@polanet.pl> On Sat, Mar 21, 2009 at 20:37:00 +0100, Arkadiusz Miskiewicz wrote: > This is _very_ wong. 254 is dynamicly alocated major number. There can be > different devices using 254 depending on kernel modules load order. Yep, unless the module provides a way to set it up (as said in last mail). > The correct solution for such non-udev systems would be probably init.d/dev > script that would parse /proc/devices and setup /dev/ files properly. Not sure > if MAKEDEV.spec is able to do the parsing on it's own but if it is then > init.d/dev script calling MAKEDEV for some devices like rtc0 should be enough. First of all I doubt we should build into kernel any drivers creating: 240-254 char LOCAL/EXPERIMENTAL USE 240-254 block LOCAL/EXPERIMENTAL USE Allocated for local/experimental use. For devices not assigned official numbers, these ranges should be used in order to avoid conflicting with future assignments. this way allowing system administrator to take care in any way (either some script as you proposed or simply by strict loading order or sth). -- Tomasz Pala From arekm at maven.pl Sun Mar 29 23:24:59 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sun, 29 Mar 2009 22:24:59 +0100 Subject: geninitrd still/again totally damaged and useless In-Reply-To: <20090329205802.GA30515@polanet.pl> References: <20090321154711.GB17793@polanet.pl> <200903211727.23303.arekm@maven.pl> <20090329205802.GA30515@polanet.pl> Message-ID: <200903292324.59817.arekm@maven.pl> On Sunday 29 of March 2009, Tomasz Pala wrote: > On Sat, Mar 21, 2009 at 17:27:23 +0100, Arkadiusz Miskiewicz wrote: > >> Version : 10000.3 Vendor: (none) > >> Release : 2 Build Date: Sat Mar 14 > >> 23:32:18 > >> > >> pivot_root: blabla NEW_ROOT or sth > >> kernel panic > > > > Check commit log. Unfortunately this report is useless ;/ > > There's nothing to check... I've mounted this cpio.gz image and there's > only /init script which may fail at exec switch_root /newroot $init. So > the problem remains: it just don't work. It could ALWAYS fail, for ages. The question is WHY it did fail this time. If it fails you are doomed anyway. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Sun Mar 29 23:25:39 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sun, 29 Mar 2009 22:25:39 +0100 Subject: kernel: where's my RTC gone? In-Reply-To: <20090329211930.GB8389@polanet.pl> References: <20090321160045.GC17793@polanet.pl> <200903212037.56511.arekm@maven.pl> <20090329211930.GB8389@polanet.pl> Message-ID: <200903292325.40262.arekm@maven.pl> On Sunday 29 of March 2009, Tomasz Pala wrote: > BTW why is it build into kernel not module? > > 1.1.2.75 Thu Dec 4 10:12:40 2008 by pluto > - built-in rtc cmos driver. Because it's always used and there is no point of having it in module. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Sun Mar 29 23:30:05 2009 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sun, 29 Mar 2009 22:30:05 +0100 Subject: SOURCES: dev-list - added /dev/rtc0 In-Reply-To: <20090329212511.GC8389@polanet.pl> References: <200903212037.00587.arekm@maven.pl> <20090329212511.GC8389@polanet.pl> Message-ID: <200903292330.06113.arekm@maven.pl> On Sunday 29 of March 2009, Tomasz Pala wrote: > First of all I doubt we should build into kernel any drivers creating: > > 240-254 char LOCAL/EXPERIMENTAL USE > 240-254 block LOCAL/EXPERIMENTAL USE > Allocated for local/experimental use. For devices not > assigned official numbers, these ranges should be > used in order to avoid conflicting with future assignments. This doc is probably outdated. Dynamic majors is recommended thing for drivers in kernel currently. > this way allowing system administrator to take care in any way (either > some script as you proposed or simply by strict loading order or sth). Or using udev. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Mon Mar 30 13:15:27 2009 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Mon, 30 Mar 2009 13:15:27 +0200 Subject: SPECS: collectd.spec - added curl, libesmtp, mysql, notify, ping, psql, rrd... In-Reply-To: References: Message-ID: <200903301415.27424.glen@pld-linux.org> On Monday 30 March 2009 04:02:20 gotar wrote: > -%module_scripts rrdtool > -%module_scripts sensors > +%{?with_rrd:%module_scripts rrdtool} > +%{?with_sensors:%module_scripts sensors} why are you making %post scriptlets conditional? to disable package build ONLY %files section should be made conditional, nothing else. -- glen From gotar at pld-linux.org Mon Mar 30 13:37:51 2009 From: gotar at pld-linux.org (gotar) Date: Mon, 30 Mar 2009 13:37:51 +0200 Subject: SPECS: collectd.spec - added curl, libesmtp, mysql, notify, ping, psql, rrd... In-Reply-To: <200903301415.27424.glen@pld-linux.org> References: <200903301415.27424.glen@pld-linux.org> Message-ID: <20090330113751.GA23468@polanet.pl> On Mon, Mar 30, 2009 at 13:15:27 +0200, Elan Ruusam?e wrote: >> -%module_scripts rrdtool >> -%module_scripts sensors >> +%{?with_rrd:%module_scripts rrdtool} >> +%{?with_sensors:%module_scripts sensors} > > why are you making %post scriptlets conditional? Because other were disabled this way already. Personally, I don't see any reason for creating subpackages with plugins not carrying outer dependencies neither. It saves virtually no space and cause problems when one wants to enable something that was not installed. -- Tomasz Pala From glen at pld-linux.org Mon Mar 30 14:01:12 2009 From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Mon, 30 Mar 2009 14:01:12 +0200 Subject: SPECS: collectd.spec - added curl, libesmtp, mysql, notify, ping, psql, rrd... In-Reply-To: <20090330113751.GA23468@polanet.pl> References: <200903301415.27424.glen@pld-linux.org> <20090330113751.GA23468@polanet.pl> Message-ID: <200903301501.12812.glen@pld-linux.org> On Monday 30 March 2009 14:37:51 gotar wrote: > Personally, I don't see any reason for creating subpackages with plugins > not carrying outer dependencies neither. It saves virtually no space and > cause problems when one wants to enable something that was not installed. that's different topic. what i said was: "remove the bconds from scriptlets/preabmles, disabling subpkg by disabling %files is sufficent" and we (pld) take the sufficent as everything else is noise and wrong. -- glen From gotar at pld-linux.org Mon Mar 30 14:12:08 2009 From: gotar at pld-linux.org (gotar) Date: Mon, 30 Mar 2009 14:12:08 +0200 Subject: SPECS: collectd.spec - added curl, libesmtp, mysql, notify, ping, psql, rrd... In-Reply-To: <200903301501.12812.glen@pld-linux.org> References: <200903301415.27424.glen@pld-linux.org> <20090330113751.GA23468@polanet.pl> <200903301501.12812.glen@pld-linux.org> Message-ID: <20090330121208.GA3628@polanet.pl> On Mon, Mar 30, 2009 at 14:01:12 +0200, Elan Ruusam?e wrote: > that's different topic. what i said was: And I said "I don't really care, as there are more important things to discuss/do than cosmetics". > "remove the bconds from scriptlets/preabmles, disabling subpkg by > disabling %files is sufficent" and we (pld) take the sufficent as everything > else is noise and wrong. We, the community, say: DIY. Of course I'll try to remember this for future, but for now collectd is closed on my TODO list. I just wanted to have plugin for nf_conntrack count. Written, sent upstream, waiting. -- Tomasz Pala From gotar at pld-linux.org Tue Mar 31 13:49:40 2009 From: gotar at pld-linux.org (gotar) Date: Tue, 31 Mar 2009 13:49:40 +0200 Subject: SPECS: collectd.spec - added curl, libesmtp, mysql, notify, ping, psql, rrd... In-Reply-To: <20090330113751.GA23468@polanet.pl> References: <200903301415.27424.glen@pld-linux.org> <20090330113751.GA23468@polanet.pl> Message-ID: <20090331114940.GA10805@polanet.pl> On Mon, Mar 30, 2009 at 13:37:51 +0200, gotar wrote: >>> -%module_scripts rrdtool >>> -%module_scripts sensors >>> +%{?with_rrd:%module_scripts rrdtool} >>> +%{?with_sensors:%module_scripts sensors} >> >> why are you making %post scriptlets conditional? > > Because other were disabled this way already. I've cleaned this up - is there any way to fold it into some loop? -- Tomasz Pala