From sparky at pld-linux.org Thu May 3 13:26:32 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Thu, 3 May 2007 13:26:32 +0200 Subject: Idea - schematic information in %description Message-ID: <20070503112632.GA5722@pld-linux.org> My proposal it to add some schematic (with well known structure) information to %description in packages. That would allow to easyly find some suitable application using search in poldek, or grep in SPECS directory. Teoretically rpm groups should be used for that prupose, but there are very little different groups, and one application may not have more than one group at once. Additionally information I's like to be added would be mainly (only ?) useful for applications, so there is no sense to play with the groups. The structure should be described in some file found in CVS, in PLD-Doc or in SPECS directory, it should also contain as many translations as possible, and some descriptions of each category, it has to be human-readable. I think it would look like: openoffice.org-writer: (blabla, old %description) Edit: odt, ott, sxw, doc, (try to list all) Save: odt, ott, sxw, doc, pdf, (try to list all) gqview: Open: bmp, png, jpeg (try to list all) mplayer: Open: avi, mpeg, wmv, mp3, ac3 (try to list all) mencoder: Convert: avi, mpeg, wmv, dvd, vcd Save: avi, mpeg In some cases additional, optional plugins would be required to get some funcionality, that funcionality should be listed in main package anyway, but in parentesis plugin name should be specified. ImageMagick (convert): Convert: png (coder-png), jpeg (coder-jpeg), (...) Save: png (coder-png), jpeg (coder-jpeg), (...) Other things than file manipulation: quake3: Game: fps; network tremulous: Game: fps, strategy; multiplayer-only, network wesnoth: Game: strategy; turn-based; network, hot-chair My initial proposal of categories, it must be discussed, extended, and made easy to understand (human readable): [file types] [graphics] png - portable network graphics jpeg bmp xcf - gimp file [audio] mp3 ogg vorbis ac3 [video] ogg - theora + (optionally) vorbis avi - (should be split to divx, and others) mpeg [office] odt - OpenDocument ott - OpenDocument template sxw - star/open office writer file doc - m$ file pdf ... [categories] Edit, [ca] Edita, [es] Edita, [pl] Edytuje: (application is able to open file for editing and manipulation) keywords: (file types) Convert, [ca] Convertix, [es] Convierte, [pl] Konvertuje: (able to open file for saving it as annother file type) keywords: (file types) Open, [ca] Obri, [es] Abre, [pl] Otwiera: (application is able to open file for displaying or reproduction) keywords: (file types) Save, [ca] Desa, [es] Guarda, [pl] Zapisuje: (able to asve to that file type after manipulation or when converting) keywords: (file types) Game, [ca] Joc, [es] Juego, [pl] Gra: (application is a game with following specifications) keywords: fps - first-person shooter rpg - role-playing game straregy, [ca] estrategia, [es] estrategia, [pl] strategia cards, [ca] cartes, [es] cartas, [pl] karty (...) turn-based - turn based, if not specified it is real-time - cards implies turn-based, no need to specify multiplayer-only - there is no possibility for single game network, [ca] xarxa, [es] red, [pl] siec - network multiplayer game split-screen - each player has it's own part of the screen same-screen - both players are visible on the same screen hot-chair - available in turn based games, player should not know what the other is doing, if they are allowed to see use "same-screen" (tictactoe?) OK, that is only the proposal. Needs discussion. Similar categories must be developed for other kinds of applications. So, what do you think ? -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From n3npq at mac.com Thu May 3 14:57:40 2007 From: n3npq at mac.com (Jeff Johnson) Date: Thu, 3 May 2007 08:57:40 -0400 Subject: Idea - schematic information in %description In-Reply-To: <20070503112632.GA5722@pld-linux.org> References: <20070503112632.GA5722@pld-linux.org> Message-ID: <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> If you want package categories, please add as a separate tag, not by overloading description. What really needs to be done is to attach a category hierarchy with, but not in, packaging. Rebuilding a package to change hierarchy is too burdensome. I can/will add a header extension tag to rpm for any reasonably designed format for hierarchical categories of packages. I suggest as a representation language YAML, but XML will work too. The connections betweeen the categories and packages should be specific enough to tag a single unique instance of a package using pkgid or hdrid, as well as broad enough to match all packages with same name. The hierarchy identifiers should be internationalized as well. hth 73 de Jeff From patrys at pld-linux.org Thu May 3 17:40:10 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Thu, 3 May 2007 17:40:10 +0200 Subject: Idea - schematic information in %description In-Reply-To: <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> References: <20070503112632.GA5722@pld-linux.org> <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> Message-ID: <89b6ba3a0705030840g5120433v7abe61ca24d4562f@mail.gmail.com> On 5/3/07, Jeff Johnson wrote: > If you want package categories, please add as a separate tag, not by > overloading description. Additionally, there is little to no sense to list file extensions as *NIX has no concept of extensions. Systems operate on MIME types. > What really needs to be done is to attach a category hierarchy with, > but not in, > packaging. Rebuilding a package to change hierarchy is too burdensome. I agree but I see no real advantage of listing handled file types for each package. Expecially since package X might only support MIME type Y if Z is also installed or if manually configured to use V. -- Patryk Zawadzki Generated Content From sparky at pld-linux.org Thu May 3 17:56:12 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Thu, 3 May 2007 17:56:12 +0200 Subject: Idea - schematic information in %description In-Reply-To: <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> References: <20070503112632.GA5722@pld-linux.org> <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> Message-ID: <20070503155611.GA29748@pld-linux.org> On Thu, May 03, 2007 at 08:57:40AM -0400, Jeff Johnson wrote: > If you want package categories, please add as a separate tag, not by > overloading description. Yup, that would be a better idea. I was thinking about %description because it actually works. Adding new tag requires some work in rpm, as well as a decent support in poldek. But making a list of all possible categories and tags, and than adding it to packages is going to take a lot of time anyway. I don't really feel the idea of adding such information separatelly from building process. Of course it isn't wise to rebuild some big package just because of changes in summary, description or category, but in case of our automation a lot of work may be required to do it other way than rebuilding the package. -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From sparky at pld-linux.org Thu May 3 18:04:46 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Thu, 3 May 2007 18:04:46 +0200 Subject: Idea - schematic information in %description In-Reply-To: <89b6ba3a0705030840g5120433v7abe61ca24d4562f@mail.gmail.com> References: <20070503112632.GA5722@pld-linux.org> <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> <89b6ba3a0705030840g5120433v7abe61ca24d4562f@mail.gmail.com> Message-ID: <20070503160446.GB29748@pld-linux.org> On Thu, May 03, 2007 at 05:40:10PM +0200, Patryk Zawadzki wrote: > On 5/3/07, Jeff Johnson wrote: > > If you want package categories, please add as a separate tag, not by > > overloading description. > > Additionally, there is little to no sense to list file extensions as > *NIX has no concept of extensions. Systems operate on MIME types. I did not mean file extensions but some short names for its type. And for reproducing music noone is going to look for application with audio/mpeg support, but with mp3 support. File extensions suck, but everyone uses and knows them. > I agree but I see no real advantage of listing handled file types for > each package. Expecially since package X might only support MIME type > Y if Z is also installed or if manually configured to use V. " In some cases additional, optional plugins would be required to get some funcionality, that funcionality should be listed in main package anyway, but in parentesis plugin name should be specified. ImageMagick (convert): Convert: png (coder-png), jpeg (coder-jpeg), (...) Save: png (coder-png), jpeg (coder-jpeg), (...) " -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From n3npq at mac.com Thu May 3 19:27:02 2007 From: n3npq at mac.com (Jeff Johnson) Date: Thu, 3 May 2007 13:27:02 -0400 Subject: Idea - schematic information in %description In-Reply-To: <20070503155611.GA29748@pld-linux.org> References: <20070503112632.GA5722@pld-linux.org> <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> <20070503155611.GA29748@pld-linux.org> Message-ID: On May 3, 2007, at 11:56 AM, Przemyslaw Iskra wrote: > On Thu, May 03, 2007 at 08:57:40AM -0400, Jeff Johnson wrote: >> If you want package categories, please add as a separate tag, not by >> overloading description. > > Yup, that would be a better idea. I was thinking about %description > because it actually works. Adding new tag requires some work in > rpm, as > well as a decent support in poldek. But making a list of all possible > categories and tags, and than adding it to packages is going to take > a lot of time anyway. > I'll be happy to do the rpm work. There is little additional poldek work if categories are added as a header extension tag. > I don't really feel the idea of adding such information separatelly > from > building process. Of course it isn't wise to rebuild some big package > just because of changes in summary, description or category, but in > case > of our automation a lot of work may be required to do it other way > than > rebuilding the package. You may not see the difference, but I certainly do. Every month someone is suggesting a new package organization and wishes to use or change some hierarchy or values. Category information *must* be outside of packaging so that users may rearrange the tag values and hierarchy to taste. Your suggestion is the 4th this year that I am aware of. 73 de Jeff From apollotiger at panthalassa.net Fri May 4 07:51:07 2007 From: apollotiger at panthalassa.net (Joshua) Date: Thu, 03 May 2007 22:51:07 -0700 Subject: Pidgin in the tree ... Message-ID: <1178257868.6259.1.camel@localhost> Just wondering: is anybody else working on committing the pidgin 2.0beta7 release that obsoletes gaim to the build tree? Or are we holding off on that because of the weirdness with the .gaim directory? Or maybe holding off until the official pidgin-2.0 release? --Joshua From arekm at maven.pl Fri May 4 07:58:48 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Fri, 4 May 2007 07:58:48 +0200 Subject: Pidgin in the tree ... In-Reply-To: <1178257868.6259.1.camel@localhost> References: <1178257868.6259.1.camel@localhost> Message-ID: <200705040758.48948.arekm@maven.pl> On Friday 04 of May 2007, Joshua wrote: > Just wondering: is anybody else working on committing the pidgin > 2.0beta7 release that obsoletes gaim to the build tree? I guess no one is working on that. > Or are we > holding off on that because of the weirdness with the .gaim directory? > Or maybe holding off until the official pidgin-2.0 release? Simply no one did pidgin.spec. Such things that you talk about never had any significance for cvs commits - cvs is for developing. > --Joshua -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From deejay1 at srem.org Fri May 4 13:35:28 2007 From: deejay1 at srem.org (=?iso-8859-2?q?=A3ukasz_Jerna=B6?=) Date: Fri, 4 May 2007 13:35:28 +0200 Subject: Idea - schematic information in %description In-Reply-To: <20070503155611.GA29748@pld-linux.org> References: <20070503112632.GA5722@pld-linux.org> <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> <20070503155611.GA29748@pld-linux.org> Message-ID: <200705041335.52691.deejay1@srem.org> Dnia czwartek, 3 maja 2007, Przemyslaw Iskra napisa?: > On Thu, May 03, 2007 at 08:57:40AM -0400, Jeff Johnson wrote: > > If you want package categories, please add as a separate tag, not by > > overloading description. > > Yup, that would be a better idea. I was thinking about %description > because it actually works. Adding new tag requires some work in rpm, as > well as a decent support in poldek. But making a list of all possible > categories and tags, and than adding it to packages is going to take > a lot of time anyway. > > I don't really feel the idea of adding such information separatelly from > building process. Of course it isn't wise to rebuild some big package > just because of changes in summary, description or category, but in case > of our automation a lot of work may be required to do it other way than > rebuilding the package. Maybe something like Provides: SUPPORT_ which could be even autogenerated at build time from proper mime type description availible in most packages .desktop files? [deejay1 at betty ~]$ cat /usr/share/applications/gimp.desktop | grep MimeType MimeType=image/bmp;image/g3fax;image/gif;image/jpeg;image/jpg;image/pjpeg;image/png;image/tiff;image/x-bmp;image/x-compressed-xcf;image/x-fits;image/x-gray;image/x-pcx;image/x-png;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-psd;image/x-sgi;image/x-sun-raster;image/x-tga;image/x-xbitmap;image/x-xcf;image/x-xpixmap;image/x-xwindowdump; and the appopriate XDG mime search? This could be a pretty nifty freedesktop spec ;> Regards, -- ?ukasz [DeeJay1] Jerna? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From sparky at pld-linux.org Fri May 4 14:00:39 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Fri, 4 May 2007 14:00:39 +0200 Subject: Idea - schematic information in %description In-Reply-To: <200705041335.52691.deejay1@srem.org> References: <20070503112632.GA5722@pld-linux.org> <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> <20070503155611.GA29748@pld-linux.org> <200705041335.52691.deejay1@srem.org> Message-ID: <20070504120038.GA24856@pld-linux.org> On Fri, May 04, 2007 at 01:35:28PM +0200, ?ukasz Jerna? wrote: > > Maybe something like Provides: SUPPORT_ I'd say: no. This has to be primatly information for people, not scripts or for some automation. > which could be even > autogenerated at build time from proper mime type description availible in > most packages .desktop files? > [deejay1 at betty ~]$ cat /usr/share/applications/gimp.desktop | grep MimeType > MimeType=image/bmp;image/g3fax;image/gif;image/jpeg;image/jpg;... I was thinking about ripping information from .desktop files, but how about console applications without desktop file ? Like file converters and such. Or when some additional package is needed for that funcionality. Anyway MimeType from .desktop files should be useful to get preliminary information. And supported file types is not the only thing I'd like to be tagged this way, but for now only other use for it I've got in my head is describing game generes. So now, let's think where such tagging may be useful. Later we will think about the tags. And at the end about implementation. Because there is no sense to think about implementation of something that does not exist. -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From n3npq at mac.com Fri May 4 15:01:44 2007 From: n3npq at mac.com (Jeff Johnson) Date: Fri, 4 May 2007 09:01:44 -0400 Subject: Idea - schematic information in %description In-Reply-To: <20070504120038.GA24856@pld-linux.org> References: <20070503112632.GA5722@pld-linux.org> <975823ED-E5AF-401F-B89E-97AC191CE7CA@mac.com> <20070503155611.GA29748@pld-linux.org> <200705041335.52691.deejay1@srem.org> <20070504120038.GA24856@pld-linux.org> Message-ID: <0373EA10-DC4E-4C7E-ADE8-73B7BDDDBFE7@mac.com> On May 4, 2007, at 8:00 AM, Przemyslaw Iskra wrote: > On Fri, May 04, 2007 at 01:35:28PM +0200, ?ukasz Jerna? wrote: >> >> Maybe something like Provides: SUPPORT_ > > I'd say: no. This has to be primatly information for people, not > scripts > or for some automation. > >> which could be even >> autogenerated at build time from proper mime type description >> availible in >> most packages .desktop files? >> [deejay1 at betty ~]$ cat /usr/share/applications/gimp.desktop | grep >> MimeType >> MimeType=image/bmp;image/g3fax;image/gif;image/jpeg;image/jpg;... > > I was thinking about ripping information from .desktop files, but how > about console applications without desktop file ? Like file converters > and such. Or when some additional package is needed for that > funcionality. > If you just want a marker for mime-type handlers that are currently resident in a MimeType tag, then overloading dependencies with, say Provides: desktop(image/bmp;image/g3fax) makes a lot of sense. My previous comments where wrto Group: tag analogues. There's a new suggestion for a Category: hierarchy monthly. > Anyway MimeType from .desktop files should be useful to get > preliminary information. > Look at existing libtool(...) or pkgconfig(...) automagic dependency extraction scripts for examples. > > And supported file types is not the only thing I'd like to be tagged > this way, but for now only other use for it I've got in my head is > describing game generes. > FYI, rpm already classifies files using libmagic. It would not be hard to run libmagic to automagically generate the mime-type associated with every file, filter, and save in metadata. What would be needed for a useful implementation is some thought about where the mime-types for each file should be installed. An rpmdb is rather too much work for most applications to retrieve data. > So now, let's think where such tagging may be useful. Later we will > think about the tags. And at the end about implementation. Because > there > is no sense to think about implementation of something that does not > exist. > > -- > ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... > LANG...Pl..Ca..Es..En > /____) ___ ___ _ _ || Iskra | | _ \| | | : > WWW........ppcrcd.pld-linux.org > \____\| -_)'___| ||^'||//\\// < | _/| | | : > JID......sparkyjabberes.org > (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : > Mail....sparkypld-linux.org > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From arekm at maven.pl Sat May 5 19:21:10 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 5 May 2007 19:21:10 +0200 Subject: th, radeon and www.festiwalmotoryzacji.pl Message-ID: <200705051921.10617.arekm@maven.pl> Th radeon users who use opensource ati driver - please try to open www.festiwalmotoryzacji.pl under konqueror or opera and report back what's happening :-) Here when I try to open this page Xorg process eats 100% resources, X are unkillable and frozen, I can't switch to txt console, machine is still alive because I can ssh in. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From kabasny at gmail.com Wed May 9 00:26:47 2007 From: kabasny at gmail.com (Piotr Maciej Kabata) Date: Wed, 09 May 2007 00:26:47 +0200 Subject: enlightenment-module*.spec need update Message-ID: <1178663207.31181.6.camel@localhost> Hello, I have one question, Is there a possibility to change BR and Requires in all enlightenment modules specs so that it requires enlightenment-devel instead of enlightenmentDR17-devel and enlightenment instead of enlightenmentDR17 ? Or shall I do it by myself and send a patch? best greetings kabasny From sparky at pld-linux.org Tue May 8 23:35:07 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Tue, 8 May 2007 23:35:07 +0200 Subject: enlightenment-module*.spec need update In-Reply-To: <1178663207.31181.6.camel@localhost> References: <1178663207.31181.6.camel@localhost> Message-ID: <20070508213506.GA10211@pld-linux.org> On Wed, May 09, 2007 at 12:26:47AM +0200, Piotr Maciej Kabata wrote: > Hello, I have one question, Is there a possibility to change BR and > Requires in all enlightenment modules specs so that it requires > enlightenment-devel instead of enlightenmentDR17-devel and enlightenment > instead of enlightenmentDR17 ? > Or shall I do it by myself and send a patch? You may send a patch if you wish. But most of those won't work or even build without updating, so there is on real point in doing it. -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From kabasny at gmail.com Wed May 9 21:23:26 2007 From: kabasny at gmail.com (Piotr Maciej Kabata) Date: Wed, 09 May 2007 21:23:26 +0200 Subject: enlightenment-module*.spec need update In-Reply-To: <20070508213506.GA10211@pld-linux.org> References: <1178663207.31181.6.camel@localhost> <20070508213506.GA10211@pld-linux.org> Message-ID: <1178738606.23978.6.camel@localhost> Dnia 08-05-2007, wto o godzinie 23:35 +0200, Przemyslaw Iskra napisa?(a): > On Wed, May 09, 2007 at 12:26:47AM +0200, Piotr Maciej Kabata wrote: > > Hello, I have one question, Is there a possibility to change BR and > > Requires in all enlightenment modules specs so that it requires > > enlightenment-devel instead of enlightenmentDR17-devel and enlightenment > > instead of enlightenmentDR17 ? > > Or shall I do it by myself and send a patch? > > You may send a patch if you wish. But most of those won't work or even > build without updating, so there is on real point in doing it. > I have already noticed that. As I am rather new to development (though not to PLD - user since RA) I would like to know if there is some easy way I could update them or is it something that involves some more skills then I possess? Because as for now, build fails at : Wykonywanie(%build): /bin/sh -e /home/users/kabasny/tmp/rpm-tmp.40330 + umask 022 + cd /home/users/kabasny/rpm/BUILD + cd wlan + export LC_ALL=C + export LANG=C + unset LINGUAS + : + unset LANGUAGE + unset LC_MESSAGES + unset DISPLAY + : + libtoolize --copy --force You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'. + aclocal + autoconf + autoheader + automake -a -c -f --foreign configure.in:23: required file `./config.rpath' not found ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I guess here is the problem configure.in:10: installing `./missing' configure.in:10: installing `./install-sh' Makefile.am: installing `./depcomp' b??d: B??dny status wyj?cia z /home/users/kabasny/tmp/rpm-tmp.40330 (% build) B??dy budowania RPM-a: B??dny status wyj?cia z /home/users/kabasny/tmp/rpm-tmp.40330 (% build) Error: package build failed. (no more info) best greetings kabasny From arekm at maven.pl Fri May 11 08:51:00 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Fri, 11 May 2007 08:51:00 +0200 Subject: INFO: carme-ac.pld-linux.org - AC amd64 developer enviroment Message-ID: <200705110851.00876.arekm@maven.pl> Hello, I've just finished setting up AC developer enviroment on carme-ac.pld-linux.org. It's clean AC for amd64 architecture. Everyone has access to sudo poldek so installation of required packages can be made easily. Accounts from carme were also added on carme-ac. /home/users is shared accross Th and Ac enviroments. Reminder: every pld developer with rw rights in cvs can get shell account on Th (carme) and Ac (carme-ac) developer enviroments. [arekm at carme-pld ~]$ linux_logo -g Linux wersja 2.6.20.4-1, skompilowany #1 SMP Wed Mar 28 08:50:12 CEST 2007 Osiem procesory Intel Genuine Intel(R) CPU @ 2.13GHz 2,12GHz, 2GB RAM, ??cznie 34059 bogomips carme-pld (odmiana skopana w linux_logo) -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From baggins at sith.mimuw.edu.pl Sun May 13 20:20:09 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Sun, 13 May 2007 20:20:09 +0200 Subject: [RFC] Repository layout =?utf-8?Q?change_?= =?utf-8?Q?=2F_Zmiana_uk=C5=82adu?= repo Message-ID: <20070513182009.GA26511@sith.mimuw.edu.pl> EN: We all know that CVS sucks, less for some (me included) and more for others. But, if we want to switch to anything else, we have to change the repository layout from flat SPECS/SOURCES to dir-per-package, because any other CMS won't handle such layout (you can imagine how would SVN repo look like - a ~milion directories, and GIT just doesn't scale - I did a test on SPECS and got a monstrosity). I have script to rebuild repo to dir-per-package, I did basic support in builder script and did some testing (converted a local copy, worked a while with new repo), so we can do the switch anytime. Any thoughts? Comments? PL: Jak wiemy CVS ssie, dla jednych mniej (w tym dla mnie) dla innych bardziej. Ale je?li chcemy przej?? na cokolwiek innego najpierw musimy przerobi? repo z p?askiego SPECS/SOURCES na katalog-per-pakiet, poniewa? ?aden inny CMS sobie z tym nie poradzi (SVN mo?ecie sobie wyobrazi? - ~milion katalog?w, sprawdzi?em te? GIT na samym SPECS i wyszed? gigantyczny potworek). Mam gotowy skrypt do przebudowania repo, dorobi?em podstawowe wsparcie w skrypcie builder i troche to przetestowa?em (przebudowa?em lokaln? kopi? repo, troch? z tym popracowa?em), wi?c przer?bke mo?emy zrobi? w ka?dej chwili. Uwagi? Komentarze? 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 piotr.budny at gmail.com Sun May 13 20:38:13 2007 From: piotr.budny at gmail.com (Piotr Budny) Date: Sun, 13 May 2007 20:38:13 +0200 Subject: [RFC] Repository layout change / Zmiana =?utf-8?q?uk=C5=82adu?= repo In-Reply-To: <20070513182009.GA26511@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> Message-ID: <200705132038.13556.piotr.budny@gmail.com> Dnia niedziela, 13 maja 2007, Jan Rekorajski napisa?: > EN: > [...] > would SVN repo look like - a ~milion directories, and GIT just doesn't Wouldn't CVS have milion dirs too? Maybe the /dir-per-package/...? or /dir-per-package/...? should be considered? [...] > Any thoughts? Comments? Is that script available somewhere? It will help to see/test new layout in action. > PL: > [...] > ~milion katalog?w, sprawdzi?em te? GIT na samym SPECS i wyszed? A w CVS nie b?dzie te? miliona katalog?w? Mo?e lepsza b?dzie struktura /katalog-per-pakiet/... albo /katalog-per-pakiet/...? [...] > Uwagi? Komentarze? Czy ten skrypt jest gdzie? dost?pny by lokalnie zobaczy? nowy uk?ad w akcji? Regards || Pozdrawiam, vip; From patrys at pld-linux.org Sun May 13 21:10:39 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Sun, 13 May 2007 21:10:39 +0200 Subject: =?UTF-8?Q?Re:_[RFC]_Repository_layout_change_/_Zmiana_uk=C5=82adu_repo?= In-Reply-To: <20070513182009.GA26511@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> Message-ID: <89b6ba3a0705131210v247d4bc2je550c5bee026a3f5@mail.gmail.com> On 5/13/07, Jan Rekorajski wrote: > We all know that CVS sucks, less for some (me included) and more for > others. But, if we want to switch to anything else, we have to change > the repository layout from flat SPECS/SOURCES to dir-per-package, > because any other CMS won't handle such layout (you can imagine how > would SVN repo look like - a ~milion directories, and GIT just doesn't > scale - I did a test on SPECS and got a monstrosity). It should work perfectly the same way it does now except that each spec file gets replaced by a directory with the same name. > I have script to rebuild repo to dir-per-package, I did basic support in > builder script and did some testing (converted a local copy, worked a > while with new repo), so we can do the switch anytime. > Any thoughts? Comments? +1 for pushing for the move. I suggest having specs sorted by their first letter so it is more scalable in the future. We also need a script that syncs the RCS repo with a directory mirroring the current SPECS behaviour (symlinks to all SPEC files currently checked out) - for these rare times when you need to grep through the whole repo and mass-commit your changes. -- Patryk Zawadzki Generated Content From radek at pld-linux.org Sun May 13 21:35:37 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Sun, 13 May 2007 21:35:37 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513182009.GA26511@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> Message-ID: <20070513193537.GA4170@bzium> Jan Rekorajski [13-05-2007 20:20]: > We all know that CVS sucks, less for some (me included) and more for All version control systems suck. CVS just sucks least for this kind of repository. > others. But, if we want to switch to anything else, we have to change > the repository layout from flat SPECS/SOURCES to dir-per-package, > because any other CMS won't handle such layout (you can imagine how > would SVN repo look like - a ~milion directories, and GIT just doesn't > scale - I did a test on SPECS and got a monstrosity). This clearly shows problems with *other* VC systems. There is no point in switching. It would create more problems than it'd solve. -1 FUT: -en -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From patrys at pld-linux.org Sun May 13 21:58:06 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Sun, 13 May 2007 21:58:06 +0200 Subject: =?UTF-8?Q?Re:_[RFC]_Repository_layout_change_/_Zmiana_uk=C5=82adu_repo?= In-Reply-To: <20070513193537.GA4170@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> Message-ID: <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> On 5/13/07, Radoslaw Zielinski wrote: > Jan Rekorajski [13-05-2007 20:20]: > > We all know that CVS sucks, less for some (me included) and more for > All version control systems suck. CVS just sucks least for this kind of > repository. Why? > > others. But, if we want to switch to anything else, we have to change > > the repository layout from flat SPECS/SOURCES to dir-per-package, > > because any other CMS won't handle such layout (you can imagine how > > would SVN repo look like - a ~milion directories, and GIT just doesn't > > scale - I did a test on SPECS and got a monstrosity). > This clearly shows problems with *other* VC systems. There is no point > in switching. It would create more problems than it'd solve. What are the problems? The so called "problems" are the rare situations where you need to grep through ALL the spec files. This could easily be solved by a tool like adapter, builder, recompile, repackage and other scripts that are there just to help you in certain situations. -- Patryk Zawadzki Generated Content From wrobell at pld-linux.org Sun May 13 22:28:52 2007 From: wrobell at pld-linux.org (wrobell) Date: Sun, 13 May 2007 21:28:52 +0100 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> Message-ID: <20070513202852.GA4042@borg> On Sun, May 13, 2007 at 09:58:06PM +0200, Patryk Zawadzki wrote: [...] > What are the problems? The so called "problems" are the rare > situations where you need to grep through ALL the spec files. This > could easily be solved by a tool like adapter, builder, recompile, > repackage and other scripts that are there just to help you in certain > situations. grep -r ? :) wrobell From n3npq at mac.com Sun May 13 22:58:39 2007 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 13 May 2007 16:58:39 -0400 Subject: =?UTF-8?Q?Re:_[RFC]_Repository_layout_change_/_Zmiana_uk=C5=82ad?= =?UTF-8?Q?u_repo?= In-Reply-To: <20070513182009.GA26511@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> Message-ID: <1C1DE9B3-AA25-4B1A-BA28-3BFD132E74E1@mac.com> On May 13, 2007, at 2:20 PM, Jan Rekorajski wrote: > EN: > > We all know that CVS sucks, less for some (me included) and more for > others. But, if we want to switch to anything else, we have to change > the repository layout from flat SPECS/SOURCES to dir-per-package, > because any other CMS won't handle such layout (you can imagine how > would SVN repo look like - a ~milion directories, and GIT just doesn't > scale - I did a test on SPECS and got a monstrosity). > > I have script to rebuild repo to dir-per-package, I did basic > support in > builder script and did some testing (converted a local copy, worked a > while with new repo), so we can do the switch anytime. > > Any thoughts? Comments? > I build using rpmrc, macros, xrpm from http://wraptastic.org/pub/jbj for many years now. The lazy mkdirs on rpm -Uvh foo*.src.rpm with %{name} extracted from the installed header have been in rpm forever (note rpm -ta foo*.tar don't work. ) How the nuild element repository is organized is a separate question, per-pkg directory containers makes lots of sense to me, as well as to most other CMS source code repositores, although each has to organize the gook slightly differently, sigh. 73 de Jeff From radek at pld-linux.org Sun May 13 23:02:41 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Sun, 13 May 2007 23:02:41 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> Message-ID: <20070513210241.GA4317@bzium> Patryk Zawadzki [13-05-2007 21:58]: > On 5/13/07, Radoslaw Zielinski wrote: > > Jan Rekorajski [13-05-2007 20:20]: > > > We all know that CVS sucks, less for some (me included) and more for > > All version control systems suck. CVS just sucks least for this kind of > > repository. > Why? Why what? > > > others. But, if we want to switch to anything else, we have to change > > > the repository layout from flat SPECS/SOURCES to dir-per-package, > > > because any other CMS won't handle such layout (you can imagine how > > > would SVN repo look like - a ~milion directories, and GIT just doesn't > > > scale - I did a test on SPECS and got a monstrosity). > > This clearly shows problems with *other* VC systems. There is no point > > in switching. It would create more problems than it'd solve. > What are the problems? Off the top of my head: - excessive metadata (CVS/Entries is just a few dozen bytes per file) - $Log$ - existing tools / macros / aliases / one liners / whatever We have tamed CVS over the years and know how to deal with its shortcomings. The only real unsolved problem is lack of "cvs mv", but this could be changed with far less work than changing VCS, if someone cared enough. > The so called "problems" are the rare > situations where you need to grep through ALL the spec files. This [...] If you know the answer (or so you think), what's the point of asking? -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From patrys at pld-linux.org Sun May 13 23:09:30 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Sun, 13 May 2007 23:09:30 +0200 Subject: =?UTF-8?Q?Re:_[RFC]_Repository_layout_change_/_Zmiana_uk=C5=82adu_repo?= In-Reply-To: <20070513210241.GA4317@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> Message-ID: <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> On 5/13/07, Radoslaw Zielinski wrote: > Patryk Zawadzki [13-05-2007 21:58]: > > Why? > Why what? Why do you believe all RCS tools suck? > > What are the problems? > Off the top of my head: > - excessive metadata (CVS/Entries is just a few dozen bytes per file) Disk space is cheap. > - $Log$ No need for it as rpm can build the log from the SVN log output. > - existing tools / macros / aliases / one liners / whatever Which ones? Builder was reported as already adapted. > We have tamed CVS over the years and know how to deal with its > shortcomings. The only real unsolved problem is lack of "cvs mv", but > this could be changed with far less work than changing VCS, if someone > cared enough. What about atomic commits? Having the spec and ALL related files from SOURCES tagged with the same revision? > If you know the answer (or so you think), what's the point of asking? You didn't provide any real life issues and all that were raised on this list could easily be solved with a small potion of bash magic. -- Patryk Zawadzki Generated Content From wrobell at pld-linux.org Sun May 13 23:22:18 2007 From: wrobell at pld-linux.org (wrobell) Date: Sun, 13 May 2007 22:22:18 +0100 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513210241.GA4317@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> Message-ID: <20070513212218.GB4042@borg> On Sun, May 13, 2007 at 11:02:41PM +0200, Radoslaw Zielinski wrote: > Patryk Zawadzki [13-05-2007 21:58]: [...] > > > > > others. But, if we want to switch to anything else, we have to change > > > > the repository layout from flat SPECS/SOURCES to dir-per-package, > > > > because any other CMS won't handle such layout (you can imagine how > > > > would SVN repo look like - a ~milion directories, and GIT just doesn't > > > > scale - I did a test on SPECS and got a monstrosity). > > > This clearly shows problems with *other* VC systems. There is no point > > > in switching. It would create more problems than it'd solve. > > What are the problems? > > Off the top of my head: > > - excessive metadata (CVS/Entries is just a few dozen bytes per file) > - $Log$ > - existing tools / macros / aliases / one liners / whatever > > We have tamed CVS over the years and know how to deal with its > shortcomings. The only real unsolved problem is lack of "cvs mv", but > this could be changed with far less work than changing VCS, if someone > cared enough. lack of mv... and also - off-line diff - revert (on-line/off-line) - atomic commit - lack of something like svk for svn (or i am just not aware) anyway, it was all discussed several times, so... eot? :) wrobell From radek at pld-linux.org Sun May 13 23:54:42 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Sun, 13 May 2007 23:54:42 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> Message-ID: <20070513215442.GA4451@bzium> Patryk Zawadzki [13-05-2007 23:09]: > On 5/13/07, Radoslaw Zielinski wrote: > > Patryk Zawadzki [13-05-2007 21:58]: > > > Why? > > Why what? > Why do you believe all RCS tools suck? Because I haven't seen one that doesn't. > > > What are the problems? > > Off the top of my head: > > - excessive metadata (CVS/Entries is just a few dozen bytes per file) > Disk space is cheap. That's no reason for wasting it. Two copies + metadata in case of SVN is over the line (one copy with SVK). > > - $Log$ > No need for it as rpm can build the log from the SVN log output. svn log is an online operation. And there is no point in removing %changelog in the first place. > > - existing tools / macros / aliases / one liners / whatever > Which ones? Builder was reported as already adapted. df/request-handler.pl. CVSROOT/*. My ~/bin contains two. No, I don't claim these are hard to update. But *what for*? > > We have tamed CVS over the years and know how to deal with its > > shortcomings. The only real unsolved problem is lack of "cvs mv", but > > this could be changed with far less work than changing VCS, if someone > > cared enough. > What about atomic commits? Having the spec and ALL related files from > SOURCES tagged with the same revision? Really, I don't see a need for that. Yeah, eliminating the race condition would be nice... but AFAIK it has never happened. Tags just do the trick. > > If you know the answer (or so you think), what's the point of asking? > You didn't provide any real life issues and all that were raised on > this list could easily be solved with a small potion of bash magic. I'll wait for the proponents of the change to provide the `real life issues' which would disappear. I mean, the ones which can't be solved with bash magic. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From radek at pld-linux.org Mon May 14 00:07:01 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 14 May 2007 00:07:01 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513212218.GB4042@borg> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <20070513212218.GB4042@borg> Message-ID: <20070513220701.GB4451@bzium> wrobell [13-05-2007 23:22]: > On Sun, May 13, 2007 at 11:02:41PM +0200, Radoslaw Zielinski wrote: [...] > > We have tamed CVS over the years and know how to deal with its > > shortcomings. The only real unsolved problem is lack of "cvs mv", but > > this could be changed with far less work than changing VCS, if someone > > cared enough. > lack of mv... and also > - off-line diff > - revert (on-line/off-line) rm && cvs up; you can't do much being offline anyway. > - atomic commit Blah. > - lack of something like svk for svn (or i am just not aware) You mean "for CVS" (as svk with svn Just Works)? According to "svk h mi|grep cvs" it's supported, but I couldn't get it to work last time I tried... That would also fix the online diff issue. > anyway, it was all discussed several times, so... eot? :) Probably... -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wrobell at pld-linux.org Mon May 14 00:24:16 2007 From: wrobell at pld-linux.org (wrobell) Date: Sun, 13 May 2007 23:24:16 +0100 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513220701.GB4451@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <20070513212218.GB4042@borg> <20070513220701.GB4451@bzium> Message-ID: <20070513222416.GC4042@borg> On Mon, May 14, 2007 at 12:07:01AM +0200, Radoslaw Zielinski wrote: > wrobell [13-05-2007 23:22]: > > On Sun, May 13, 2007 at 11:02:41PM +0200, Radoslaw Zielinski wrote: > [...] > > > We have tamed CVS over the years and know how to deal with its > > > shortcomings. The only real unsolved problem is lack of "cvs mv", but > > > this could be changed with far less work than changing VCS, if someone > > > cared enough. > > lack of mv... and also > > - off-line diff > > - revert (on-line/off-line) > > rm && cvs up; you can't do much being offline anyway. i can: diff and revert. that's what would be nice to have, so please... > > - atomic commit > > Blah. nice answer for pro cvs arguments, thanks ;) :P > > - lack of something like svk for svn (or i am just not aware) > > You mean "for CVS" (as svk with svn Just Works)? According to "svk h svk with svn just works. > mi|grep cvs" it's supported, but I couldn't get it to work last time I > tried... That would also fix the online diff issue. no one cares about cvs, now. this is the main issue for me. wrobell From baggins at sith.mimuw.edu.pl Mon May 14 00:30:03 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 00:30:03 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <200705132038.13556.piotr.budny@gmail.com> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705132038.13556.piotr.budny@gmail.com> Message-ID: <20070513223003.GA27934@sith.mimuw.edu.pl> On Sun, 13 May 2007, Piotr Budny wrote: > Dnia niedziela, 13 maja 2007, Jan Rekorajski napisa?: > > EN: > > > [...] > > > would SVN repo look like - a ~milion directories, and GIT just doesn't > > Wouldn't CVS have milion dirs too? Just ~12000, remember that SVN creates a directory for every tag/branch > Maybe the > /dir-per-package/...? > or /dir-per-package/...? > should be considered? Personally, I hate it. I sometimes look for something in debian/pool and it pisses me off. > [...] > > > Any thoughts? Comments? > > Is that script available somewhere? It will help to see/test new layout in > action. Nope, it has to be run server-side, if someone try to hack it for remote operation the that someone can expect GBH[1] from RMF ;) [1] Grave Bodily Harm > > PL: > > > [...] > > ~milion katalog?w, sprawdzi?em te? GIT na samym SPECS i wyszed? > > A w CVS nie b?dzie te? miliona katalog?w? Tylko ~12000, pami?taj ?e SVN robi katalogi dla wszystkich ag?w/branchy > Mo?e lepsza b?dzie struktura > /katalog-per-pakiet/... > albo /katalog-per-pakiet/...? Mnie to wkurza niesamowicie jak czasem przegl?dam debian/pool > [...] > > > Uwagi? Komentarze? > > Czy ten skrypt jest gdzie? dost?pny by lokalnie zobaczy? nowy uk?ad w akcji? Nie, skrypt musi by? uruchamiany po stronie serwera, a jak go kto? zhackuje ?eby dzia?a? zdalnie to mu RMF zrobi powa?n? krzywd? ;) 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 Mon May 14 00:34:53 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 00:34:53 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <46475F01.2020203@toya.net.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <46475F01.2020203@toya.net.pl> Message-ID: <20070513223453.GB27934@sith.mimuw.edu.pl> To: proper language list On Sun, 13 May 2007, Jakub Piotr C?apa wrote: > Jan Rekorajski wrote: > > Any thoughts? Comments? > > Yup. It was discussed to death. It doesn't fit to PLD. It was always discussed in context of switching to SVN, never by itself. And the oposition was against a screwed tag/branch design in SVN. > And even more important is that qboosh doesn't like it. If he won't > commit than we're all doomed so better don't mess with this stuff. (or > invent something clever) I'd like to see _his_ comments, not what _you_ think he thinks. > Btw. I think we could get the required parameters from a custom system > (possibly based on Mercurial since it's nice and in Python but it could > be some other system) and that the off-the-shelf VCS are not for us. IMO GIT is good (full disconnected operation), and _maybe_ SVN if it wasn't screwed by design wrt tags. 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 Mon May 14 00:38:17 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 00:38:17 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <89b6ba3a0705131210v247d4bc2je550c5bee026a3f5@mail.gmail.com> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <89b6ba3a0705131210v247d4bc2je550c5bee026a3f5@mail.gmail.com> Message-ID: <20070513223817.GC27934@sith.mimuw.edu.pl> On Sun, 13 May 2007, Patryk Zawadzki wrote: > I suggest having specs sorted by their first letter so it is more > scalable in the future. But it makes work with more packages very awkward. > We also need a script that syncs the RCS repo with a directory > mirroring the current SPECS behaviour (symlinks to all SPEC files > currently checked out) - for these rare times when you need to grep > through the whole repo and mass-commit your changes. My script does just this. One interesting thing that came out is ~900 files in SOURCES that do not belong to any package... 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 Mon May 14 00:41:28 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 00:41:28 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513193537.GA4170@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> Message-ID: <20070513224128.GD27934@sith.mimuw.edu.pl> On Sun, 13 May 2007, Radoslaw Zielinski wrote: > Jan Rekorajski [13-05-2007 20:20]: > > We all know that CVS sucks, less for some (me included) and more for > > All version control systems suck. CVS just sucks least for this kind of > repository. > > > others. But, if we want to switch to anything else, we have to change > > the repository layout from flat SPECS/SOURCES to dir-per-package, > > because any other CMS won't handle such layout (you can imagine how > > would SVN repo look like - a ~milion directories, and GIT just doesn't > > scale - I did a test on SPECS and got a monstrosity). > > This clearly shows problems with *other* VC systems. There is no point > in switching. It would create more problems than it'd solve. I don't think you understood, I'm not proposing VCS change, that's for the future. I'm proposing layout change to make it _possible_ to even consider a VCS change. 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 radek at pld-linux.org Mon May 14 00:47:59 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 14 May 2007 00:47:59 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513224128.GD27934@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <20070513224128.GD27934@sith.mimuw.edu.pl> Message-ID: <20070513224759.GA4793@bzium> Jan Rekorajski [14-05-2007 00:41]: > On Sun, 13 May 2007, Radoslaw Zielinski wrote: > > Jan Rekorajski [13-05-2007 20:20]: [...] > > > others. But, if we want to switch to anything else, we have to change > > > the repository layout from flat SPECS/SOURCES to dir-per-package, > > > because any other CMS won't handle such layout (you can imagine how > > > would SVN repo look like - a ~milion directories, and GIT just doesn't > > > scale - I did a test on SPECS and got a monstrosity). > > This clearly shows problems with *other* VC systems. There is no point > > in switching. It would create more problems than it'd solve. > I don't think you understood, I'm not proposing VCS change, that's for > the future. I'm proposing layout change to make it _possible_ to even > consider a VCS change. I'm sure I did. I just see it differently: changing layout to a *worse* one so it's possible to switch to a *worse* (for this purpose) VCS. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From baggins at sith.mimuw.edu.pl Mon May 14 00:55:32 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 00:55:32 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513215442.GA4451@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> <20070513215442.GA4451@bzium> Message-ID: <20070513225532.GE27934@sith.mimuw.edu.pl> On Sun, 13 May 2007, Radoslaw Zielinski wrote: > Patryk Zawadzki [13-05-2007 23:09]: > > On 5/13/07, Radoslaw Zielinski wrote: > > > Patryk Zawadzki [13-05-2007 21:58]: > > > > Why? > > > Why what? > > Why do you believe all RCS tools suck? > > Because I haven't seen one that doesn't. I agree here, they just do it diffrent ways ;) > > > > What are the problems? > > > Off the top of my head: > > > - excessive metadata (CVS/Entries is just a few dozen bytes per file) > > Disk space is cheap. > > That's no reason for wasting it. Two copies + metadata in case of > SVN is over the line (one copy with SVK). Come on, the repo will not magically grow by enormous amounts, [baggins at sith repo]$ du -hsc SOURCES SPECS ; du -hs packages 183M SOURCES 64M SPECS 246M total 436M packages And the size increase is mainly because of 1) below. > > > - $Log$ > > No need for it as rpm can build the log from the SVN log output. > > svn log is an online operation. Yeah, svn sucks here. But VCS change is for another time. > > > If you know the answer (or so you think), what's the point of asking? > > You didn't provide any real life issues and all that were raised on > > this list could easily be solved with a small potion of bash magic. > > I'll wait for the proponents of the change to provide the `real life > issues' which would disappear. I mean, the ones which can't be solved > with bash magic. 1) files that belong to more than one package, you either have to _know_ the involved packages and keep them synchronized or you will have a mess 2) orphans, we have ~900 files in SOURCES that don't belong to any package currently 3) guesswork in case you work with more packages at once or with the whole repo - hmm, file adfgasdfgda.patch does belong to what package? And those were just everyday, common issues. 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 Mon May 14 01:05:35 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 01:05:35 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513224759.GA4793@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <20070513224128.GD27934@sith.mimuw.edu.pl> <20070513224759.GA4793@bzium> Message-ID: <20070513230535.GA28299@sith.mimuw.edu.pl> On Mon, 14 May 2007, Radoslaw Zielinski wrote: > Jan Rekorajski [14-05-2007 00:41]: > > On Sun, 13 May 2007, Radoslaw Zielinski wrote: > > > Jan Rekorajski [13-05-2007 20:20]: > [...] > > > > others. But, if we want to switch to anything else, we have to change > > > > the repository layout from flat SPECS/SOURCES to dir-per-package, > > > > because any other CMS won't handle such layout (you can imagine how > > > > would SVN repo look like - a ~milion directories, and GIT just doesn't > > > > scale - I did a test on SPECS and got a monstrosity). > > > This clearly shows problems with *other* VC systems. There is no point > > > in switching. It would create more problems than it'd solve. > > I don't think you understood, I'm not proposing VCS change, that's for > > the future. I'm proposing layout change to make it _possible_ to even > > consider a VCS change. > > I'm sure I did. I just see it differently: changing layout to a *worse* Why worse? Sorry, but the only real problem you stated is that scripts will stop working, and that can be easily fixed. > one so it's possible to switch to a *worse* (for this purpose) VCS. Anything to back up this statement? There are more VCSs than just CVS or SVN. 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 dhubleizh at o2.pl Mon May 14 09:33:42 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Mon, 14 May 2007 09:33:42 +0200 Subject: Console service for non-breakable fbsplash Message-ID: <1179128022.3540.9.camel@ipv6-localnet> Hi. I've been toying around fbsplash for some time now. I've been searching of a way to make the fbsplash's splash non-stop visible during boot. The problem I've found is console service from kbd. Is it really needed to switch to every console in every /sbin/open and even do manual /sbin/switchto from time to time?? I'm attaching a patch witch throws out all the console switching stuff to make the silent splash stay on top as long as possible. After applying it gets much better. There's just the: run_cmd "Loading keyboard table" loadkeys $KEYTABLE < /dev/tty0 > /dev/tty0 stuff left, which changes to a verbose console. I'm not sure what the run_cmd "foo" bar < /dev/tty0 > /dev/tty0 is supposed to do? Why inputting from tty? Why forcing output to tty? After removing the < > stuff the splash stays almost perfectly on top all the time. Only for a blink of an eye it turns to some console (not sure what other command in /etc/init.d/console does that, but it's definitely this service). Oh - and with initng running mingetty changes to the just runned console, not sure bout normal init boot, because I can't find mingetty in rc-scripts. Please comment on the patch. I'd like to commit it in some time. Cz at rny -------------- next part -------------- A non-text attachment was scrubbed... Name: kbd.init.patch Type: text/x-patch Size: 1234 bytes Desc: not available URL: From jajcus at jajcus.net Mon May 14 09:49:41 2007 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 14 May 2007 09:49:41 +0200 Subject: Console service for non-breakable fbsplash In-Reply-To: <1179128022.3540.9.camel@ipv6-localnet> References: <1179128022.3540.9.camel@ipv6-localnet> Message-ID: <20070514074941.GA27766@jajo.eggsoft.pl> On Mon, May 14, 2007 at 09:33:42AM +0200, Cezary Krzyzanowski wrote: > The problem I've found is console service from kbd. Is it really needed > to switch to every console in every /sbin/open and even do > manual /sbin/switchto from time to time?? I'm attaching a patch witch > throws out all the console switching stuff to make the silent splash > stay on top as long as possible. > > After applying it gets much better. And fonts and keyboard input are set right on all the text consoles? I doubt. > stuff left, which changes to a verbose console. I'm not sure what the > run_cmd "foo" bar < /dev/tty0 > /dev/tty0 is supposed to do? Why > inputting from tty? Why forcing output to tty? Terminal configuration commands operate on the controlling terminal or the standard input. I guess the redirections are to set the terminal right even if script is run from e.g. ssh. Greets, Jacek From dhubleizh at o2.pl Mon May 14 10:29:29 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Mon, 14 May 2007 10:29:29 +0200 Subject: Console service for non-breakable fbsplash In-Reply-To: <20070514074941.GA27766@jajo.eggsoft.pl> References: <1179128022.3540.9.camel@ipv6-localnet> <20070514074941.GA27766@jajo.eggsoft.pl> Message-ID: <1179131369.3451.2.camel@ipv6-localnet> Dnia 14-05-2007, pon o godzinie 09:49 +0200, Jacek Konieczny napisa?(a): > And fonts and keyboard input are set right on all the text consoles? I > doubt. Hm - I haven't spotted any problems. What to look for?? I've got utf-8 polish terminals and all get set properly - I can read and write polish signs. I've only removed the switches, all console magic is still there. > > Terminal configuration commands operate on the controlling terminal or > the standard input. I guess the redirections are to set the terminal > right even if script is run from e.g. ssh. Ok - I get the idea. Still, there's only one command issued that way and the service has many console manipulation commands. Thx Cz at rny From radek at pld-linux.org Mon May 14 12:45:33 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 14 May 2007 12:45:33 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513225532.GE27934@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> <20070513215442.GA4451@bzium> <20070513225532.GE27934@sith.mimuw.edu.pl> Message-ID: <20070514104532.GA3332@bzium> Jan Rekorajski [14-05-2007 00:55]: > On Sun, 13 May 2007, Radoslaw Zielinski wrote: >> Patryk Zawadzki [13-05-2007 23:09]: >>> On 5/13/07, Radoslaw Zielinski wrote: >>>> Patryk Zawadzki [13-05-2007 21:58]: [...] >>>>> What are the problems? >>>> Off the top of my head: >>>> - excessive metadata (CVS/Entries is just a few dozen bytes per file) >>> Disk space is cheap. >> That's no reason for wasting it. Two copies + metadata in case of >> SVN is over the line (one copy with SVK). > Come on, the repo will not magically grow by enormous amounts, [...] Now (for SPECS): 12k files. With new layout: 12k files + 12k directories + 12k CVS/ + 3x12k CVS/*. SVN: 12k files + 12k directories + 12k .svn/ +7x12k .svn/* + copies. On my (laptop) hardware[1] I see a performance difference. Big enough to see it as an issue. [1] No, I can't build OO and large packages do take time. But usually it's just good enough. [...] >> I'll wait for the proponents of the change to provide the `real life >> issues' which would disappear. I mean, the ones which can't be solved >> with bash magic. > 1) files that belong to more than one package, you either have to _know_ > the involved packages and keep them synchronized or you will have a mess It's just a couple of packages, isn't it? Only relevant for SourceX, which are fetched from DF anyway. Files stored in VCS (patches, scripts or whatever) are (or should be) named as %{name}*. > 2) orphans, we have ~900 files in SOURCES that don't belong to any > package currently I might be guilty of forgetting to remove some of these myself... But then, is it really an issue? If so, a daily or weekly cronjob can fix it, can't it? > 3) guesswork in case you work with more packages at once or with the > whole repo - hmm, file adfgasdfgda.patch does belong to what package? Why would you care? It's being looked up the other way: package -> *.patch. > And those were just everyday, common issues. Honestly: I can't see these as issues. And certainly not as everyday ones. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jajcus at jajcus.net Mon May 14 13:06:50 2007 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 14 May 2007 13:06:50 +0200 Subject: Console service for non-breakable fbsplash In-Reply-To: <1179131369.3451.2.camel@ipv6-localnet> References: <1179128022.3540.9.camel@ipv6-localnet> <20070514074941.GA27766@jajo.eggsoft.pl> <1179131369.3451.2.camel@ipv6-localnet> Message-ID: <20070514110650.GA29307@jajo.eggsoft.pl> On Mon, May 14, 2007 at 10:29:29AM +0200, Cezary Krzyzanowski wrote: > Dnia 14-05-2007, pon o godzinie 09:49 +0200, Jacek Konieczny napisa?(a): > > > And fonts and keyboard input are set right on all the text consoles? I > > doubt. > > Hm - I haven't spotted any problems. What to look for?? I've got utf-8 > polish terminals and all get set properly - I can read and write polish > signs. Sounds good. > I've only removed the switches, all console magic is still there. If the switches were not needed, then it is good they were removed. Maybe they were required some time ago, but now the problem is fixed somewhere else (newer kernel). > Ok - I get the idea. Still, there's only one command issued that way and > the service has many console manipulation commands. Have you tried removing the redirections? Have you tried the script when booting with serial port as default console? Greets, Jacek From dhubleizh at o2.pl Mon May 14 13:26:04 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Mon, 14 May 2007 13:26:04 +0200 Subject: Console service for non-breakable fbsplash In-Reply-To: <20070514110650.GA29307@jajo.eggsoft.pl> References: <1179128022.3540.9.camel@ipv6-localnet> <20070514074941.GA27766@jajo.eggsoft.pl> <1179131369.3451.2.camel@ipv6-localnet> <20070514110650.GA29307@jajo.eggsoft.pl> Message-ID: <1179141964.3451.24.camel@ipv6-localnet> Dnia 14-05-2007, pon o godzinie 13:06 +0200, Jacek Konieczny napisa?(a): > If the switches were not needed, then it is good they were removed. > Maybe they were required some time ago, but now the problem is fixed > somewhere else (newer kernel). Well - after answering You I've found some more magic regarding bootsplash (former implementation of splashes) in rc-scripts. It's in 99% made to be able to show percentage of work in the silent output. I'm trying to make it usable with fbsplash as well. > Have you tried removing the redirections? Yes. It boots. The "Loading..." line isn't shown on the default tty (I haven't checked if it is on the redirected one, as I deliberately use an empty tty for silent splash and I output all the stuff to tty12 via the kernel option console=tty12, because otherwise it'd screw up the splash with debug messages). > Have you tried the script > when booting with serial port as default console? I don't have any machine with serial console - sorry. Can't test that out. On the other hand I could try to make my laptop a serial terminal for my desktop, or the other way around, but I haven't used serial terminal. Thx 4 the discussion Cz at rny From baggins at sith.mimuw.edu.pl Mon May 14 13:41:42 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 13:41:42 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070514104532.GA3332@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> <20070513215442.GA4451@bzium> <20070513225532.GE27934@sith.mimuw.edu.pl> <20070514104532.GA3332@bzium> Message-ID: <20070514114142.GA10843@sith.mimuw.edu.pl> On Mon, 14 May 2007, Radoslaw Zielinski wrote: > Jan Rekorajski [14-05-2007 00:55]: > > On Sun, 13 May 2007, Radoslaw Zielinski wrote: > >> Patryk Zawadzki [13-05-2007 23:09]: > >>> On 5/13/07, Radoslaw Zielinski wrote: > >>>> Patryk Zawadzki [13-05-2007 21:58]: > [...] > >>>>> What are the problems? > >>>> Off the top of my head: > >>>> - excessive metadata (CVS/Entries is just a few dozen bytes per file) > >>> Disk space is cheap. > >> That's no reason for wasting it. Two copies + metadata in case of > >> SVN is over the line (one copy with SVK). > > Come on, the repo will not magically grow by enormous amounts, > [...] > > Now (for SPECS): 12k files. > With new layout: 12k files + 12k directories + 12k CVS/ + 3x12k CVS/*. > SVN: 12k files + 12k directories + 12k .svn/ +7x12k .svn/* + copies. > > On my (laptop) hardware[1] I see a performance difference. Big enough > to see it as an issue. Do you work with the whole repo? If yes, then how often do you _really_ need to cvs up the whole thing? > [1] No, I can't build OO and large packages do take time. But usually > it's just good enough. > > [...] > >> I'll wait for the proponents of the change to provide the `real life > >> issues' which would disappear. I mean, the ones which can't be solved > >> with bash magic. > > > 1) files that belong to more than one package, you either have to _know_ > > the involved packages and keep them synchronized or you will have a mess > > It's just a couple of packages, isn't it? Only relevant for SourceX, > which are fetched from DF anyway. Files stored in VCS (patches, scripts > or whatever) are (or should be) named as %{name}*. Dream on... Why do you thing the repo grew by 200MB after split? > > 2) orphans, we have ~900 files in SOURCES that don't belong to any > > package currently > > I might be guilty of forgetting to remove some of these myself... But > then, is it really an issue? If so, a daily or weekly cronjob can fix > it, can't it? Dream on... A ~7 hours cron job effectively killing access to CVS? > > 3) guesswork in case you work with more packages at once or with the > > whole repo - hmm, file adfgasdfgda.patch does belong to what package? > > Why would you care? It's being looked up the other way: package -> *.patch. I care because I have to work with the whole repo. > > And those were just everyday, common issues. > > Honestly: I can't see these as issues. And certainly not as everyday ones. Can I assume then that status quo is best for you? 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 radek at pld-linux.org Mon May 14 13:46:15 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 14 May 2007 13:46:15 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070513230535.GA28299@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <20070513224128.GD27934@sith.mimuw.edu.pl> <20070513224759.GA4793@bzium> <20070513230535.GA28299@sith.mimuw.edu.pl> Message-ID: <20070514114615.GB3332@bzium> Jan Rekorajski [14-05-2007 01:05]: > On Mon, 14 May 2007, Radoslaw Zielinski wrote: >> Jan Rekorajski [14-05-2007 00:41]: [...] >>> I don't think you understood, I'm not proposing VCS change, that's for >>> the future. I'm proposing layout change to make it _possible_ to even >>> consider a VCS change. >> I'm sure I did. I just see it differently: changing layout to a *worse* > Why worse? To avoid making up reasons (and repeating ourselves about excessive metadata): I would find this structure more annoying. Longer paths, the need for mkdir. > Sorry, but the only real problem you stated is that scripts will stop > working, and that can be easily fixed. That was, as I wrote, `off the top of my head', not an analysis. Alright, a weak argument. ;-) >> one so it's possible to switch to a *worse* (for this purpose) VCS. > Anything to back up this statement? There are more VCSs than just CVS > or SVN. Widely used (in OSS world)? Come on... Everything (?) else features and focuses on distributed repositories, which we don't need. If there existed a better VCS for our needs, someone would outline the gains and we'd have switched already. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From radek at pld-linux.org Mon May 14 13:56:46 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 14 May 2007 13:56:46 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070514114142.GA10843@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> <20070513215442.GA4451@bzium> <20070513225532.GE27934@sith.mimuw.edu.pl> <20070514104532.GA3332@bzium> <20070514114142.GA10843@sith.mimuw.edu.pl> Message-ID: <20070514115646.GA4122@bzium> Jan Rekorajski [14-05-2007 13:41]: > On Mon, 14 May 2007, Radoslaw Zielinski wrote: >> Jan Rekorajski [14-05-2007 00:55]: [...] >>> Come on, the repo will not magically grow by enormous amounts, >> [...] >> Now (for SPECS): 12k files. >> With new layout: 12k files + 12k directories + 12k CVS/ + 3x12k CVS/*. >> SVN: 12k files + 12k directories + 12k .svn/ +7x12k .svn/* + copies. >> On my (laptop) hardware[1] I see a performance difference. Big enough >> to see it as an issue. > Do you work with the whole repo? > If yes, then how often do you _really_ need to cvs up the whole > thing? Recently: very rarely. But I do it from time to time. [...] >>> 1) files that belong to more than one package, you either have to _know_ >>> the involved packages and keep them synchronized or you will have a mess >> It's just a couple of packages, isn't it? Only relevant for SourceX, >> which are fetched from DF anyway. Files stored in VCS (patches, scripts >> or whatever) are (or should be) named as %{name}*. > Dream on... > Why do you thing the repo grew by 200MB after split? Did it? Well, why? >>> 2) orphans, we have ~900 files in SOURCES that don't belong to any >>> package currently >> I might be guilty of forgetting to remove some of these myself... But >> then, is it really an issue? If so, a daily or weekly cronjob can fix >> it, can't it? > Dream on... > A ~7 hours cron job effectively killing access to CVS? Mostly read-only operation would kill the access? Even on a rsynced, off-line copy? Whoa. Yes, there are a few issues with this cronjob. All *solvable*, so let's not get started, alright? ;-) >>> 3) guesswork in case you work with more packages at once or with the >>> whole repo - hmm, file adfgasdfgda.patch does belong to what package? >> Why would you care? It's being looked up the other way: package -> *.patch. > I care because I have to work with the whole repo. Can you show the use case? >>> And those were just everyday, common issues. >> Honestly: I can't see these as issues. And certainly not as everyday ones. > Can I assume then that status quo is best for you? Yes. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From patrys at pld-linux.org Mon May 14 14:39:34 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Mon, 14 May 2007 14:39:34 +0200 Subject: =?UTF-8?Q?Re:_[RFC]_Repository_layout_change_/_Zmiana_uk=C5=82adu_repo?= In-Reply-To: <20070514114615.GB3332@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <20070513224128.GD27934@sith.mimuw.edu.pl> <20070513224759.GA4793@bzium> <20070513230535.GA28299@sith.mimuw.edu.pl> <20070514114615.GB3332@bzium> Message-ID: <89b6ba3a0705140539w23749d2ao89404152ad8fdfa6@mail.gmail.com> On 5/14/07, Radoslaw Zielinski wrote: > Jan Rekorajski [14-05-2007 01:05]: > > Why worse? > To avoid making up reasons (and repeating ourselves about excessive > metadata): I would find this structure more annoying. Longer paths, > the need for mkdir. Is there any real problem? The one outlined above involves creating *one* directory each time you add a *new* spec file to the repo. I hardly see this as an issue. > > Anything to back up this statement? There are more VCSs than just CVS > > or SVN. > Widely used (in OSS world)? Come on... Everything (?) else features > and focuses on distributed repositories, which we don't need. we don't use !== (we don't need && we can't take advantage of) > If there existed a better VCS for our needs, someone would outline the > gains and we'd have switched already. This thread is about reorganizing the repo to make it more usable to people who have lots of files checked out and would really appreciate some structure to keep them bound together. This thread is not about SVN/GIT/name-your-RCS-of-choice. Anyway, I like the proposed structure and I really feel it gives us more than it takes away (SOURCES as a flat directory is just a huge mess, I don't recall doing "cvs ci SOURCES" as a whole. Ever). -- Patryk Zawadzki Generated Content From mmazur at kernel.pl Mon May 14 15:39:35 2007 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 14 May 2007 15:39:35 +0200 Subject: [RFC] Repository layout change / Zmiana =?iso-8859-2?q?uk=B3adu?= repo In-Reply-To: <20070513182009.GA26511@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> Message-ID: <200705141539.35170.mmazur@kernel.pl> Dnia niedziela, 13 maja 2007, Jan Rekorajski napisa?: > EN: > > We all know that CVS sucks, less for some (me included) and more for > others. But, if we want to switch to anything else, we have to change > the repository layout from flat SPECS/SOURCES to dir-per-package, > because any other CMS won't handle such layout (you can imagine how > would SVN repo look like - a ~milion directories, and GIT just doesn't > scale - I did a test on SPECS and got a monstrosity). > > I have script to rebuild repo to dir-per-package, I did basic support in > builder script and did some testing (converted a local copy, worked a > while with new repo), so we can do the switch anytime. > > Any thoughts? Comments? Small easy steps is what I propose. Actually setting up a dual solution (current structure + a 'packages' modules) should be quite trivial in CVS. It's just a matter of running a script to generate the 'packages' module server side with lots of links (whether soft or hard) and adding appropriate triggers for cvs rm/add operations (to generate/remove those links when appropriate and bail out on conflicts). It's a few hours worth of work tops. Don't know about locking, but that should also be doable. This way we'll be able to actually more or less test this, before making major changes (like completely switching to svn, which btw probably wouldn't allow something like this server side) and it'll be flexible. And who knows, maybe after a couple of months we'll see people actually switching to this solution on their own, thereby freeing us from having to support the old structure. And even if not, we can always look for some scm with better merging and branching, that would also allow this (which svn most likely does not). But not sooner then in a few months. Any takers? Baggins? -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde From baggins at sith.mimuw.edu.pl Mon May 14 16:48:53 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 16:48:53 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <200705141539.35170.mmazur@kernel.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705141539.35170.mmazur@kernel.pl> Message-ID: <20070514144853.GA17496@sith.mimuw.edu.pl> On Mon, 14 May 2007, Mariusz Mazur wrote: > Small easy steps is what I propose. Actually setting up a dual solution > (current structure + a 'packages' modules) should be quite trivial in CVS. > It's just a matter of running a script to generate the 'packages' module > server side with lots of links (whether soft or hard) and adding appropriate That's what I did, just the other way, files copied to packages/* and symlinked to SPECS/ and SOURCES/. Easy to make the script do it the other way. > triggers for cvs rm/add operations (to generate/remove those links when > appropriate and bail out on conflicts). That will not work? How will you tell which package file X added to SOURCES belongs to? Some kind of lazy linking on spec commit? > It's a few hours worth of work tops. Don't know about locking, but that should > also be doable. The conversion takes approximately 7 hours on P4 2.8GHz and idle system. > This way we'll be able to actually more or less test this, before making major > changes (like completely switching to svn, which btw probably wouldn't allow > something like this server side) and it'll be flexible. And who knows, maybe > after a couple of months we'll see people actually switching to this solution > on their own, thereby freeing us from having to support the old structure. > > And even if not, we can always look for some scm with better merging and > branching, that would also allow this (which svn most likely does not). But > not sooner then in a few months. That was my intent behind this RFC. Do a non invasive change now, switch to more ordered repo and then look for the best scm for it. > Any takers? Baggins? Converter is ready, what is missing is a script to handle cvs rm/add operation, I can do a parser/symlinker but someone more experienced in CVS internals will have to glue it into CVS. BTW. such a script will require rpm-build package on the server. 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 Mon May 14 16:55:43 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Mon, 14 May 2007 16:55:43 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070514115646.GA4122@bzium> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> <20070513215442.GA4451@bzium> <20070513225532.GE27934@sith.mimuw.edu.pl> <20070514104532.GA3332@bzium> <20070514114142.GA10843@sith.mimuw.edu.pl> <20070514115646.GA4122@bzium> Message-ID: <20070514145543.GB17496@sith.mimuw.edu.pl> On Mon, 14 May 2007, Radoslaw Zielinski wrote: > Jan Rekorajski [14-05-2007 13:41]: > > Do you work with the whole repo? > > If yes, then how often do you _really_ need to cvs up the whole > > thing? > > Recently: very rarely. But I do it from time to time. Me too, and I think we can live with that operation taking longer than now. > [...] > >>> 1) files that belong to more than one package, you either have to _know_ > >>> the involved packages and keep them synchronized or you will have a mess > >> It's just a couple of packages, isn't it? Only relevant for SourceX, > >> which are fetched from DF anyway. Files stored in VCS (patches, scripts > >> or whatever) are (or should be) named as %{name}*. > > Dream on... > > Why do you thing the repo grew by 200MB after split? > > Did it? Well, why? Look above, because of files in SOURCES that belong to more than one package. [...] > >>> 3) guesswork in case you work with more packages at once or with the > >>> whole repo - hmm, file adfgasdfgda.patch does belong to what package? > >> Why would you care? It's being looked up the other way: package -> *.patch. > > I care because I have to work with the whole repo. > > Can you show the use case? ls -l SOURCES/ ;) Seriously, I sometimes have to build a package with big dependency tree, and then just delete some of the files but I have problems with recognizing which ones I shouldn't. 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 radek at pld-linux.org Mon May 14 17:03:08 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 14 May 2007 17:03:08 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070514145543.GB17496@sith.mimuw.edu.pl> References: <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513210241.GA4317@bzium> <89b6ba3a0705131409j6bf51610xa77f0e1361e8bf2c@mail.gmail.com> <20070513215442.GA4451@bzium> <20070513225532.GE27934@sith.mimuw.edu.pl> <20070514104532.GA3332@bzium> <20070514114142.GA10843@sith.mimuw.edu.pl> <20070514115646.GA4122@bzium> <20070514145543.GB17496@sith.mimuw.edu.pl> Message-ID: <20070514150308.GA4594@bzium> Jan Rekorajski [14-05-2007 16:55]: > On Mon, 14 May 2007, Radoslaw Zielinski wrote: > > Jan Rekorajski [14-05-2007 13:41]: [...] >>>>> 3) guesswork in case you work with more packages at once or with the >>>>> whole repo - hmm, file adfgasdfgda.patch does belong to what package? >>>> Why would you care? It's being looked up the other way: package -> *.patch. >>> I care because I have to work with the whole repo. >> Can you show the use case? > ls -l SOURCES/ ;) This leads nowhere... EOT. > Seriously, I sometimes have to build a package with big dependency tree, > and then just delete some of the files but I have problems with > recognizing which ones I shouldn't. Fixable with grep ~/.*history* (or a shell function, or little logging in builder) and SPECS/specparser.pl --asf. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmazur at kernel.pl Mon May 14 18:07:32 2007 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 14 May 2007 18:07:32 +0200 Subject: [RFC] Repository layout change / Zmiana =?iso-8859-2?q?uk=B3adu?= repo In-Reply-To: <20070514144853.GA17496@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705141539.35170.mmazur@kernel.pl> <20070514144853.GA17496@sith.mimuw.edu.pl> Message-ID: <200705141807.32452.mmazur@kernel.pl> Dnia poniedzia?ek, 14 maja 2007, Jan Rekorajski napisa?: > That's what I did, just the other way, files copied to packages/* and > symlinked to SPECS/ and SOURCES/. Easy to make the script do it the > other way. Do it the other way then. Until we figure out a permanent packages/* structure, the old specs/sources tree should be the main one. Btw: not sure if hardlinks aren't a bad idea. How would cvsadmins handle renaming packages with the new stuff? > > triggers for cvs rm/add operations (to generate/remove those links when > > appropriate and bail out on conflicts). > > That will not work? How will you tell which package file X added to SOURCES > belongs to? Some kind of lazy linking on spec commit? Easy. Most of the content of sources is in the form %name-something. Let the script simply match the %name part (trying to match it from the longest possible string) with a package named like that. If it's there, that's the package, if not, we bail out and tell the commiter, that with non-standard naming, he needs to use the 'packages' module. (we frown upon non-standard naming anyways, so this shouldn't be much of an issue; maybe for some init scripts, nothing much) There will be corner cases of course, but we can probably decide later what the preferred behavior should be (bail out if the script isn't sure, try the best guess or something). > > It's a few hours worth of work tops. Don't know about locking, but that > > should also be doable. > > The conversion takes approximately 7 hours on P4 2.8GHz and idle system. I was talking about writing the necessary code, not the conversion itself. However 7 hours ain't bad. We run it over a night and have everything working in the morning. Alternatively we can just start with a subset of all the packages. Maybe k*.spec? Considering that we'd have to test the scripts before making a full deployment, that sounds ok, right? > That was my intent behind this RFC. > Do a non invasive change now, switch to more ordered repo and then look > for the best scm for it. Yup. Best option. > Converter is ready, what is missing is a script to handle cvs rm/add > operation, I can do a parser/symlinker but someone more experienced in > CVS internals will have to glue it into CVS. Last I've tried, it wasn't that bad. You just read the docs, write the script and add it to the 'commitinfo' file in CVSROOT. Unless there are other takers? (python preferred, however, due to lack of manpower, will settle on perl if available :) > BTW. such a script will > require rpm-build package on the server. Only the converter, right? -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde From mmazur at kernel.pl Mon May 14 18:15:59 2007 From: mmazur at kernel.pl (Mariusz Mazur) Date: Mon, 14 May 2007 18:15:59 +0200 Subject: [RFC] Repository layout change / Zmiana =?iso-8859-2?q?uk=B3adu?= repo In-Reply-To: <200705141807.32452.mmazur@kernel.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070514144853.GA17496@sith.mimuw.edu.pl> <200705141807.32452.mmazur@kernel.pl> Message-ID: <200705141815.59827.mmazur@kernel.pl> Dnia poniedzia?ek, 14 maja 2007, Mariusz Mazur napisa?: > Easy. Most of the content of sources is in the form %name-something. Let > the script simply match the %name part (trying to match it from the longest > possible string) with a package named like that. If it's there, that's the > package, if not, we bail out and tell the commiter, that with non-standard > naming, he needs to use the 'packages' module. (we frown upon non-standard > naming anyways, so this shouldn't be much of an issue; maybe for some init > scripts, nothing much) Of course the other side is that when committing through 'packages' the script will check the spec file name whether it matches the module name and the sources names, whether something of that name doesn't already exist in sources. There's probably a thing or two I forgot about, but we'll get to that eventually. -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde From qboosh at pld-linux.org Mon May 14 23:14:38 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 14 May 2007 23:14:38 +0200 Subject: [RFC] Repository =?iso-8859-2?Q?layout?= =?iso-8859-2?Q?_change_=2F_Zmiana_uk=B3adu?= repo In-Reply-To: <200705141807.32452.mmazur@kernel.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705141539.35170.mmazur@kernel.pl> <20070514144853.GA17496@sith.mimuw.edu.pl> <200705141807.32452.mmazur@kernel.pl> Message-ID: <20070514211438.GB32125@stranger.qboosh.pl> On Mon, May 14, 2007 at 06:07:32PM +0200, Mariusz Mazur wrote: > Dnia poniedzia?ek, 14 maja 2007, Jan Rekorajski napisa?: > > That's what I did, just the other way, files copied to packages/* and > > symlinked to SPECS/ and SOURCES/. Easy to make the script do it the > > other way. > > Do it the other way then. Until we figure out a permanent packages/* > structure, the old specs/sources tree should be the main one. > > Btw: not sure if hardlinks aren't a bad idea. How would cvsadmins handle > renaming packages with the new stuff? hardlinks probably are. I bet cvs won't handle them and just will leave two different files. server-side symlinks generally work with cvs. [...] > Alternatively we can just start with a subset of all the packages. Maybe > k*.spec? Considering that we'd have to test the scripts before making a full > deployment, that sounds ok, right? p* ;P (to check scalability and check when perl/php/python* interested developers go mad when updating packages in 1k dirs ;>) -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Tue May 15 00:13:36 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 15 May 2007 00:13:36 +0200 Subject: [RFC] Repository =?iso-8859-2?Q?layout?= =?iso-8859-2?Q?_change_=2F_Zmiana_uk=B3adu?= repo In-Reply-To: <20070513202852.GA4042@borg> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513202852.GA4042@borg> Message-ID: <20070514221336.GC32125@stranger.qboosh.pl> On Sun, May 13, 2007 at 09:28:52PM +0100, wrobell wrote: > On Sun, May 13, 2007 at 09:58:06PM +0200, Patryk Zawadzki wrote: > [...] > > What are the problems? The so called "problems" are the rare > > situations where you need to grep through ALL the spec files. This > > could easily be solved by a tool like adapter, builder, recompile, > > repackage and other scripts that are there just to help you in certain > > situations. > > grep -r > > ? Wrong, it will grep not only specs, but also sources and whole overgrown metadata, taking more time and returning some junk matches outside specs. Per-package layout is acceptable to me _as long_ as there will be flat SPECS dir with symlinked spec files. Server-side symlinks should work well with CVS (with little server-side overhead?), don't know about other VCSs. One more disadvantage: more work when adding new package (1 or 3 mkdirs + cvs adds depending on layout - is it going to be package/{package.spec,package*.patch} or package/{SPECS/package.spec,SOURCES/package*.patch} ? -- Jakub Bogusz http://qboosh.pl/ From baggins at sith.mimuw.edu.pl Tue May 15 00:25:25 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Tue, 15 May 2007 00:25:25 +0200 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070514221336.GC32125@stranger.qboosh.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513202852.GA4042@borg> <20070514221336.GC32125@stranger.qboosh.pl> Message-ID: <20070514222525.GA23956@sith.mimuw.edu.pl> On Tue, 15 May 2007, Jakub Bogusz wrote: > On Sun, May 13, 2007 at 09:28:52PM +0100, wrobell wrote: > > > > grep -r > > > > ? > > Wrong, it will grep not only specs, but also sources and whole overgrown > metadata, taking more time and returning some junk matches outside specs. find -depth 1 -name *.spec | xargs grep ? > Per-package layout is acceptable to me _as long_ as there will be flat > SPECS dir with symlinked spec files. Server-side symlinks should work > well with CVS (with little server-side overhead?), don't know about > other VCSs. It will be, don't worry. And if/when we decide to change VCS we'll try to keep it. > One more disadvantage: more work when adding new package (1 or 3 mkdirs > + cvs adds depending on layout - is it going to be > package/{package.spec,package*.patch} or That's what I want to do, adding directories just to separate one file (package.spec) is pointless waste IMO. 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 wrobell at pld-linux.org Tue May 15 00:25:31 2007 From: wrobell at pld-linux.org (wrobell) Date: Mon, 14 May 2007 23:25:31 +0100 Subject: [RFC] Repository layout =?utf-8?Q?chan?= =?utf-8?Q?ge_=2F_Zmiana_uk=C5=82adu?= repo In-Reply-To: <20070514221336.GC32125@stranger.qboosh.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513202852.GA4042@borg> <20070514221336.GC32125@stranger.qboosh.pl> Message-ID: <20070514222531.GD4042@borg> On Tue, May 15, 2007 at 12:13:36AM +0200, Jakub Bogusz wrote: > On Sun, May 13, 2007 at 09:28:52PM +0100, wrobell wrote: > > On Sun, May 13, 2007 at 09:58:06PM +0200, Patryk Zawadzki wrote: > > [...] > > > What are the problems? The so called "problems" are the rare > > > situations where you need to grep through ALL the spec files. This > > > could easily be solved by a tool like adapter, builder, recompile, > > > repackage and other scripts that are there just to help you in certain > > > situations. > > > > grep -r > > > > ? > > Wrong, it will grep not only specs, but also sources and whole overgrown > metadata, taking more time and returning some junk matches outside specs. grep -r --include \*.spec regex . [...] wrobell From mmazur at kernel.pl Tue May 15 01:30:38 2007 From: mmazur at kernel.pl (Mariusz Mazur) Date: Tue, 15 May 2007 01:30:38 +0200 Subject: [RFC] Repository layout change -- status update In-Reply-To: <200705141815.59827.mmazur@kernel.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705141807.32452.mmazur@kernel.pl> <200705141815.59827.mmazur@kernel.pl> Message-ID: <200705150130.38723.mmazur@kernel.pl> Ok, after some talks on irc, this is how (the first version of) this solution is going to look like: 'packages' module in our current CVS repo with a flat structure underneath consisting of package '%{name}'s. Like this: 'packages/glibc' or 'packages/kernel'. The idea is also to force having spec file names equal to %{name}. Afaik there are a few instances where such is not the case. Afterwards we can have the glob 'packages/%{name}/%{name}.spec' being true 100% of the time (might come in handy some day). The question is how should the dir structure look like for each package. Now the most obvious solution is to copy the standard rpm structure and have both SOURCES and SPECS in there, however that's a waste of inodes simply because the SPECS dir would always contain only one file and only force unneeded 'cd's on developers' part. And since either way, in order to use this new structure one needs to redefine some rpm macros in ~/.rpmmacros, we're free to choose any layout we like. Now baggins wants to have a flat structure, meaning no subdirs -- all files just land under 'packages/somename'. This does make sense for a package with like two sources and one patch file, but I'd argue, that with the packages that have more of those (and we do have a fair share of them), it makes a lot more sense to have the traditional content of SOURCES (patches, tarballs, etc) under some subdir. My proposal goes like this: have 'packages/%{name}' containt (a) the spec file, (b) a 'files' subdir, that contains the traditional 'SOURCES' content and (c) any other files containing metadata. Off the top of my head -- the 'tag->revision' file we've discussed wrt to svn migration. And in the future -- any other metadata that might prove usefull (with the ability to just add a file with some interesting info regarding a package, the possibilities are quite big; sooner or later someone's bound to use it for builder/ftp/bugzilla/somethingelse integration). (Yes, for those who noticed, that is exactly how gentoo has this organized. First, I think it makes sense, and secondly -- I'd like to try out some kind of gentoo 'integration' (like, dunno, maybe automatic fetching of their metadata, so we don't have to maintain it ourselves, or sth) some time in the future.) So the basic question goes like this: are there any proponents of the flat structure (the way darth baggins, dark lord of sith likes it), or maybe a more organized structure (the way m. 'skywalker' mazur, great jedi master suggests) is preferred? -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde From gotar at polanet.pl Tue May 15 01:39:33 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 15 May 2007 01:39:33 +0200 Subject: [RFC] Repository =?iso-8859-2?Q?layout?= =?iso-8859-2?Q?_change_=2F_Zmiana_uk=B3adu?= repo In-Reply-To: <20070513182009.GA26511@sith.mimuw.edu.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> Message-ID: <20070514233933.GA13343@pepin.polanet.pl> On Sun, May 13, 2007 at 08:20:09PM +0200, Jan Rekorajski wrote: > > others. But, if we want to switch to anything else, we have to change > the repository layout from flat SPECS/SOURCES to dir-per-package, 1. I hate common SOURCES (and removing these files I don't need anymore). For now I'm creating a SOURCES- directory symlinked as SOURCES to keep all that clean. 2. However - I would hate separated spec files too. Why? 1. It's hard to group SOURCES files together (especially if not all of them are -*). 2. There's only one spec in SPECS, and sometimes spec files ARE bound together somehow (to ease diff, use of template* or sth). So I'd vote for: 1. decomposition of SOURCES, 2. keeping SPECS intact. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From qboosh at pld-linux.org Tue May 15 07:43:32 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 15 May 2007 07:43:32 +0200 Subject: [RFC] Repository =?iso-8859-2?Q?layout?= =?iso-8859-2?Q?_change_=2F_Zmiana_uk=B3adu?= repo In-Reply-To: <20070514221336.GC32125@stranger.qboosh.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513202852.GA4042@borg> <20070514221336.GC32125@stranger.qboosh.pl> Message-ID: <20070515054332.GD32125@stranger.qboosh.pl> One more thing: non-specs and template specs need to be moved to some other place (scripts/ and templates/ dirs? mirrors and additional-md5sums are used by scripts, so they can be together with scripts). -- Jakub Bogusz http://qboosh.pl/ From patrys at pld-linux.org Tue May 15 12:51:48 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 15 May 2007 12:51:48 +0200 Subject: [RFC] Repository layout change -- status update In-Reply-To: <200705150130.38723.mmazur@kernel.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705141807.32452.mmazur@kernel.pl> <200705141815.59827.mmazur@kernel.pl> <200705150130.38723.mmazur@kernel.pl> Message-ID: <89b6ba3a0705150351m7ec77f0en21099be3f539e235@mail.gmail.com> On 5/15/07, Mariusz Mazur wrote: > Ok, after some talks on irc, this is how (the first version of) this solution > is going to look like: > > 'packages' module in our current CVS repo with a flat structure underneath > consisting of package '%{name}'s. Like this: 'packages/glibc' > or 'packages/kernel'. > > The idea is also to force having spec file names equal to %{name}. Afaik there > are a few instances where such is not the case. > > Afterwards we can have the glob 'packages/%{name}/%{name}.spec' being true > 100% of the time (might come in handy some day). AFAIK this is true for all non-kernel packages. Kernel module specs tend to be named after their tarballs but produce kernel-* packages. > My proposal goes like this: > > have 'packages/%{name}' containt (a) the spec file, (b) a 'files' subdir, that > contains the traditional 'SOURCES' content and (c) any other files containing > metadata. Off the top of my head -- the 'tag->revision' file we've discussed > wrt to svn migration. And in the future -- any other metadata that might > prove usefull (with the ability to just add a file with some interesting info > regarding a package, the possibilities are quite big; sooner or later > someone's bound to use it for builder/ftp/bugzilla/somethingelse > integration). +1 for a data subdirectory (the name can be anything from SOURCES to pink-thongs). -- Patryk Zawadzki Generated Content From patrys at pld-linux.org Tue May 15 13:04:38 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 15 May 2007 13:04:38 +0200 Subject: =?UTF-8?Q?Re:_[RFC]_Repository_layout_change_/_Zmiana_uk=C5=82adu_repo?= In-Reply-To: <20070514221336.GC32125@stranger.qboosh.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513202852.GA4042@borg> <20070514221336.GC32125@stranger.qboosh.pl> Message-ID: <89b6ba3a0705150404m6e00aab7ue069deeb106a50f2@mail.gmail.com> On 5/15/07, Jakub Bogusz wrote: > One more disadvantage: more work when adding new package (1 or 3 mkdirs > + cvs adds depending on layout - is it going to be > package/{package.spec,package*.patch} or > package/{SPECS/package.spec,SOURCES/package*.patch} ? SOURCES shoud stay, probably with a shorter name (mmazur proposed data). I'd prefer a script to setup the package structure and I'd expect CVS to issue a post-commit warning if there are files not mentioned in the SPEC as either Patch or SourceX. -- Patryk Zawadzki Generated Content From pluto at agmk.net Tue May 15 20:48:27 2007 From: pluto at agmk.net (=?utf-8?q?Pawe=C5=82_Sikora?=) Date: Tue, 15 May 2007 20:48:27 +0200 Subject: [RFC] Repository layout change -- status update In-Reply-To: <89b6ba3a0705150351m7ec77f0en21099be3f539e235@mail.gmail.com> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705150130.38723.mmazur@kernel.pl> <89b6ba3a0705150351m7ec77f0en21099be3f539e235@mail.gmail.com> Message-ID: <200705152048.27355.pluto@agmk.net> On Tuesday 15 of May 2007 12:51:48 Patryk Zawadzki wrote: > On 5/15/07, Mariusz Mazur wrote: > > Ok, after some talks on irc, this is how (the first version of) this > > solution is going to look like: > > > > 'packages' module in our current CVS repo with a flat structure > > underneath consisting of package '%{name}'s. Like this: 'packages/glibc' > > or 'packages/kernel'. > > > > The idea is also to force having spec file names equal to %{name}. Afaik > > there are a few instances where such is not the case. > > > > Afterwards we can have the glob 'packages/%{name}/%{name}.spec' being > > true 100% of the time (might come in handy some day). > > AFAIK this is true for all non-kernel packages. Kernel module specs > tend to be named after their tarballs but produce kernel-* packages. maybe we should change convention and produce subpackage *-kernel similiar to *-libs, *-devel, etc. ? From aredridel at nbtsc.org Tue May 15 22:09:58 2007 From: aredridel at nbtsc.org (Aredridel) Date: Tue, 15 May 2007 14:09:58 -0600 Subject: [RFC] Repository layout change -- status update In-Reply-To: <200705150130.38723.mmazur@kernel.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705141807.32452.mmazur@kernel.pl> <200705141815.59827.mmazur@kernel.pl> <200705150130.38723.mmazur@kernel.pl> Message-ID: <464A1396.4010405@nbtsc.org> > have 'packages/%{name}' containt (a) the spec file, (b) a 'files' subdir, that > contains the traditional 'SOURCES' content and (c) any other files containing > metadata. Off the top of my head -- the 'tag->revision' file we've discussed > wrt to svn migration. And in the future -- any other metadata that might > prove usefull (with the ability to just add a file with some interesting info > regarding a package, the possibilities are quite big; sooner or later > someone's bound to use it for builder/ftp/bugzilla/somethingelse > integration). > This or flat makes the most sense to me. If we're reorganizing on this scale, though, any reason not to move to SVN in the process? From aredridel at nbtsc.org Tue May 15 22:13:56 2007 From: aredridel at nbtsc.org (Aredridel) Date: Tue, 15 May 2007 14:13:56 -0600 Subject: [RFC] Repository layout change / Zmiana =?UTF-8?B?dWvFgmFkdSA=?= =?UTF-8?B?cmVwbw==?= In-Reply-To: <20070515054332.GD32125@stranger.qboosh.pl> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <20070513193537.GA4170@bzium> <89b6ba3a0705131258i51e4f583sf79fb4e830ad6902@mail.gmail.com> <20070513202852.GA4042@borg> <20070514221336.GC32125@stranger.qboosh.pl> <20070515054332.GD32125@stranger.qboosh.pl> Message-ID: <464A1484.9070002@nbtsc.org> Jakub Bogusz wrote: > One more thing: non-specs and template specs need to be moved to some > other place (scripts/ and templates/ dirs? mirrors and > additional-md5sums are used by scripts, so they can be together with > scripts). > > Call it bin/ and templates/? It's a good change. Aria From patrys at pld-linux.org Tue May 15 22:33:53 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 15 May 2007 22:33:53 +0200 Subject: Thank you geninitrd for screwing my evening Message-ID: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> Dear PLD devs, Please stop changing geninitrd to your liking without performing sanity checks FIRST. To your notice: - geninitrd generates initromfs images by default (why isbeyond my imagination, I can only think about bootsplash bling bling here) - initromfs uses the following magic to determine the device (copy-pasted for your entertainment): BEGIN { num_pattern_short = "[0-9][0-9][0-9]"; num_pattern = "[0-9]" num_pattern_short; dev_pattern = "[hms][a-z][a-z]([0-9])+"; partition = "no_partition_found"; min = -1; maj = -1; gsub(/.*root=/,NIL,c); gsub(/ .*/,NIL,c); sub("^0x", "", c); if (c ~ "^" num_pattern_short "$") sub("^", "0", c); if (c ~ "^" num_pattern "$") { maj = sprintf("%d",substr(c,1,2)); min = sprintf("%d",substr(c,3)); } if (c ~ "^\/dev\/" dev_pattern "$") sub("^/dev/","", c); if (c ~ "^" dev_pattern "$") partition = c; } - /dev/vgsys/* does not seem to match any of these clever rules, but lo and behold as we have an alternative way... - root=fe00 does not match any of these either, what a clever coincidence as THE FUCKING LVM2 DEVICE HAPPENS TO BE (major, minor) exactly 254, 0 - either return to romfs my default or provide us with a barrel of beer for debugging your mistakes -- Patryk Zawadzki Generated Content From patrys at pld-linux.org Tue May 15 22:59:26 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Tue, 15 May 2007 22:59:26 +0200 Subject: Thank you geninitrd for screwing my evening In-Reply-To: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> References: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> Message-ID: <89b6ba3a0705151359o13da7211l1383a6f61bc07cf9@mail.gmail.com> On 5/15/07, Patryk Zawadzki wrote: [...] Too little coffe, too much stress, s/initromfs/initramfs/ - romfs works fine. -- Patryk Zawadzki Generated Content From aredridel at nbtsc.org Tue May 15 23:04:44 2007 From: aredridel at nbtsc.org (Aredridel) Date: Tue, 15 May 2007 15:04:44 -0600 Subject: Thank you geninitrd for screwing my evening In-Reply-To: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> References: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> Message-ID: <464A206C.8000707@nbtsc.org> > - /dev/vgsys/* does not seem to match any of these clever rules, but > lo and behold as we have an alternative way.. For the record, I got bit by this too. Root on LVM got toasted, hard. Still not working on one machine, just haven't had time to fix it yet. Aria From arekm at maven.pl Tue May 15 23:06:21 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 15 May 2007 23:06:21 +0200 Subject: Thank you geninitrd for screwing my evening In-Reply-To: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> References: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> Message-ID: <200705152306.22183.arekm@maven.pl> On Tuesday 15 of May 2007, Patryk Zawadzki wrote: > Dear PLD devs, > > Please stop changing geninitrd to your liking without performing > sanity checks FIRST. > > To your notice: > > - geninitrd generates initromfs images by default (why isbeyond my > imagination, I can only think about bootsplash bling bling here) AC defaults to sane romfs, Th defaults to initramfs to get things tested on users. Now we wait for initramfs related patches. Happy hacking. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From loc at toya.net.pl Tue May 15 23:10:34 2007 From: loc at toya.net.pl (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=) Date: Tue, 15 May 2007 23:10:34 +0200 Subject: Thank you geninitrd for screwing my evening In-Reply-To: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> References: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> Message-ID: <464A21CA.30802@toya.net.pl> Patryk Zawadzki wrote: > - geninitrd generates initromfs images by default (why isbeyond my > imagination, I can only think about bootsplash bling bling here) Why should it not? -- regards, Jakub Piotr C?apa From qboosh at pld-linux.org Tue May 15 23:13:19 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 15 May 2007 23:13:19 +0200 Subject: SOURCES: ulogd-mysql.patch (NEW) - fixed `mysql_config --libs` out... In-Reply-To: <200705152246.51825.tomasz.wittner@gmail.com> References: <20070515160849.GA19978@stranger.qboosh.pl> <200705152246.51825.tomasz.wittner@gmail.com> Message-ID: <20070515211319.GA15876@stranger.qboosh.pl> On Tue, May 15, 2007 at 10:46:51PM +0200, Tomasz Wittner wrote: > On Tue 15. of May 2007, 18:08, Jakub Bogusz wrote: > > On Tue, May 15, 2007 at 03:30:20PM +0200, gotar wrote: > > > Author: gotar Date: Tue May 15 13:30:17 2007 GMT > > > Module: SOURCES Tag: HEAD > > > ---- Log message: > > > - fixed `mysql_config --libs` output handling for strings and linker > > > > > > +- MYSQLLIBS=`$d/mysql_config --libs` > > > ++ MYSQLLIBS=`$d/mysql_config --libs | sed 's/-Wl,--as-needed //'` Not here. These -Wl,* or -s must disappear from --libs output. > > > +- MYSQL_FUNCTION_TEST=`strings ${MYSQLLIBS}/libmysqlclient.so | grep > > > mysql_real_escape_string` ++ MYSQL_FUNCTION_TEST=`strings $(echo > > > ${MYSQLLIBS} | grep -m 1 -o -- '-L/[[^ ]]*/ ' | sed 's/[[-L > > > ]]//g')/libmysqlclient.so | grep mysql_real_escape_string` Oh #@%@%. They don't know about AC_CHECK_LIB? > AFAIR Gotar wypisa? si? z pld-devel-pl po jakim? tam flejmie. Za to > subskrybuje pld-devel-en . So trying on -devel-en. -- Jakub Bogusz http://qboosh.pl/ From baggins at sith.mimuw.edu.pl Wed May 16 00:05:50 2007 From: baggins at sith.mimuw.edu.pl (Jan Rekorajski) Date: Wed, 16 May 2007 00:05:50 +0200 Subject: [RFC] Repository layout change -- status update In-Reply-To: <464A1396.4010405@nbtsc.org> References: <20070513182009.GA26511@sith.mimuw.edu.pl> <200705141807.32452.mmazur@kernel.pl> <200705141815.59827.mmazur@kernel.pl> <200705150130.38723.mmazur@kernel.pl> <464A1396.4010405@nbtsc.org> Message-ID: <20070515220549.GA19225@sith.mimuw.edu.pl> On Tue, 15 May 2007, Aredridel wrote: > > > have 'packages/%{name}' containt (a) the spec file, (b) a 'files' subdir, that > > contains the traditional 'SOURCES' content and (c) any other files containing > > metadata. Off the top of my head -- the 'tag->revision' file we've discussed > > wrt to svn migration. And in the future -- any other metadata that might > > prove usefull (with the ability to just add a file with some interesting info > > regarding a package, the possibilities are quite big; sooner or later > > someone's bound to use it for builder/ftp/bugzilla/somethingelse > > integration). > > > This or flat makes the most sense to me. > > If we're reorganizing on this scale, though, any reason not to move to > SVN in the process? Yes, SVN sucks a lot more than CVS. Where CVS only lacks 'mv' command, SVN is broken by design wrt tags and branches. Let's leave that issue for later and do one thing at a time. 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 Wed May 16 01:29:05 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 16 May 2007 01:29:05 +0200 Subject: cairo, xorg-lib-libXft: LCD In-Reply-To: <1173641831.19503.3.camel@qrnik> References: <20070309135552.GA11838@pepin.polanet.pl> <1173476634.21049.11.camel@qrnik> <20070310082635.GA18793@pepin.polanet.pl> <1173552549.21257.22.camel@qrnik> <20070310192917.GA7263@pepin.polanet.pl> <1173623884.18904.14.camel@qrnik> <20070311180424.GA10846@pepin.polanet.pl> <1173641831.19503.3.camel@qrnik> Message-ID: <20070515232905.GA19710@pepin.polanet.pl> On Sun, Mar 11, 2007 at 08:37:11PM +0100, Marcin 'Qrczak' Kowalczyk wrote: > > A bit of blurring is good. Antialiased fonts are more blurred than > non-antialiased. Please read: http://www.nabble.com/New-FreeType-proofing-tool:-ftdiff-p9754631.html -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From gotar at polanet.pl Wed May 16 01:55:37 2007 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 16 May 2007 01:55:37 +0200 Subject: SOURCES: ulogd-mysql.patch (NEW) - fixed `mysql_config --libs` out... In-Reply-To: <20070515211319.GA15876@stranger.qboosh.pl> References: <20070515160849.GA19978@stranger.qboosh.pl> <200705152246.51825.tomasz.wittner@gmail.com> <20070515211319.GA15876@stranger.qboosh.pl> Message-ID: <20070515235537.GA21153@pepin.polanet.pl> On Tue, May 15, 2007 at 11:13:19PM +0200, Jakub Bogusz wrote: > > > > > > > > +- MYSQLLIBS=`$d/mysql_config --libs` > > > > ++ MYSQLLIBS=`$d/mysql_config --libs | sed 's/-Wl,--as-needed //'` > > Not here. These -Wl,* or -s must disappear from --libs output. I thought so, but didn't want to touch mysql and break sth else. If so it's enough to remove $ldflags - I've commited but not tested this (no place to rebuild mysql). > > > > +- MYSQL_FUNCTION_TEST=`strings ${MYSQLLIBS}/libmysqlclient.so | grep > > > > mysql_real_escape_string` ++ MYSQL_FUNCTION_TEST=`strings $(echo > > > > ${MYSQLLIBS} | grep -m 1 -o -- '-L/[[^ ]]*/ ' | sed 's/[[-L > > > > ]]//g')/libmysqlclient.so | grep mysql_real_escape_string` > > Oh #@%@%. They don't know about AC_CHECK_LIB? Me neither;] However there is AC_CHECK_LIB(dl, dlopen), so maybe they are aware. Are or were, as ulogd 1.x is dead for 16 months now. -- Tom Pala http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ From dhubleizh at o2.pl Wed May 16 08:33:24 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Wed, 16 May 2007 08:33:24 +0200 Subject: Thank you geninitrd for screwing my evening In-Reply-To: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> References: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> Message-ID: <1179297204.3608.12.camel@ipv6-localnet> Dnia 15-05-2007, wto o godzinie 22:33 +0200, Patryk Zawadzki napisa?(a): > Please stop changing geninitrd to your liking without performing > sanity checks FIRST. > A the initramfs was my idea in the first place I feel responsible to respond. I'm sorry for You screwed up evening. Nevertheless there's nothing I could do to prevent it. http://www.mail-archive.com/pld-devel-en at lists.pld-linux.org/msg02492.html http://www.mail-archive.com/pld-devel-en at lists.pld-linux.org/msg02508.html As You see I've asked for some checkups of the scripts and the checkups and rewrites have been done. > - geninitrd generates initromfs images by default (why isbeyond my > imagination, I can only think about bootsplash bling bling here) As it supposed to do in TH (the development version - totally not meant for server usage). AC defaults to romfs. Bootsplash doesn't need initramfs - fbsplash needs. And initramfs is the way to do booting up in upstream. Look it up on i.e. kernel lists if You please. > - initromfs uses the following magic to determine the device > (copy-pasted for your entertainment): > > BEGIN { > num_pattern_short = "[0-9][0-9][0-9]"; > num_pattern = "[0-9]" num_pattern_short; > dev_pattern = "[hms][a-z][a-z]([0-9])+"; > partition = "no_partition_found"; > min = -1; maj = -1; > > gsub(/.*root=/,NIL,c); > gsub(/ .*/,NIL,c); > > sub("^0x", "", c); > if (c ~ "^" num_pattern_short "$") sub("^", "0", c); > if (c ~ "^" num_pattern "$") { > maj = sprintf("%d",substr(c,1,2)); > min = sprintf("%d",substr(c,3)); > } > if (c ~ "^\/dev\/" dev_pattern "$") sub("^/dev/","", c); > if (c ~ "^" dev_pattern "$") partition = c; > } > > - /dev/vgsys/* does not seem to match any of these clever rules, but > lo and behold as we have an alternative way... > > - root=fe00 does not match any of these either, what a clever > coincidence as THE FUCKING LVM2 DEVICE HAPPENS TO BE (major, minor) > exactly 254, 0 Well, since You obviously have the equipment to test it, as I didn't and don't have now as well, I suggest, for You as a PLD developer, to add some other 'magic' rules that would match Your equipment. P.S. I'd guess that UUID recognizing would be great here, as It'd solve the numbers and devices magic. Once more sorry for Your last time. Cz at rny From arekm at maven.pl Wed May 16 08:45:19 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 16 May 2007 08:45:19 +0200 Subject: Thank you geninitrd for screwing my evening In-Reply-To: <1179297204.3608.12.camel@ipv6-localnet> References: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> <1179297204.3608.12.camel@ipv6-localnet> Message-ID: <200705160845.19623.arekm@maven.pl> On Wednesday 16 of May 2007, Cezary Krzyzanowski wrote: > > - geninitrd generates initromfs images by default (why isbeyond my > > imagination, I can only think about bootsplash bling bling here) > > As it supposed to do in TH That's true. Someone has to test new things. > (the development version - totally not meant > for server usage). That's false - Th works perfectly on servers - it's just not so easy and straightforward as Ac. DON'T use ,,th is development'' as excuse for such things please. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From dhubleizh at o2.pl Wed May 16 08:57:48 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Wed, 16 May 2007 08:57:48 +0200 Subject: Thank you geninitrd for screwing my evening In-Reply-To: <200705160845.19623.arekm@maven.pl> References: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> <1179297204.3608.12.camel@ipv6-localnet> <200705160845.19623.arekm@maven.pl> Message-ID: <1179298668.3608.18.camel@ipv6-localnet> Dnia 16-05-2007, ?ro o godzinie 08:45 +0200, Arkadiusz Miskiewicz napisa?(a): > > DON'T use ,,th is development'' as excuse for such things please. > Yea, maybe You're right. Nevertheless I couldn't have tested it in the first place, that's why I've asked the RFC. http://svn.pld-linux.org/cgi-bin/viewsvn/geninitrd/trunk/geninitrd?r1=8409&r2=8560&p1=geninitrd/trunk/geninitrd&p2=geninitrd/trunk/geninitrd I hope it helps. As for the devices paths way (like /dev/something/even_futher) I can't imagine all the variations of the path to actually make it work, but I'll think bout it. Cz at rny From patrys at pld-linux.org Wed May 16 12:10:25 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Wed, 16 May 2007 12:10:25 +0200 Subject: Thank you geninitrd for screwing my evening In-Reply-To: <1179298668.3608.18.camel@ipv6-localnet> References: <89b6ba3a0705151333ne357758y45501e6e538f1854@mail.gmail.com> <1179297204.3608.12.camel@ipv6-localnet> <200705160845.19623.arekm@maven.pl> <1179298668.3608.18.camel@ipv6-localnet> Message-ID: <89b6ba3a0705160310o6d486940sa1f49aba00191328@mail.gmail.com> On 5/16/07, Cezary Krzyzanowski wrote: > Dnia 16-05-2007, ?ro o godzinie 08:45 +0200, Arkadiusz Miskiewicz > napisa?(a): > > DON'T use ,,th is development'' as excuse for such things please. > Yea, maybe You're right. Nevertheless I couldn't have tested it in the > first place, that's why I've asked the RFC. "TH is not development! That's SPARTAAAAAA!" > http://svn.pld-linux.org/cgi-bin/viewsvn/geninitrd/trunk/geninitrd?r1=8409&r2=8560&p1=geninitrd/trunk/geninitrd&p2=geninitrd/trunk/geninitrd Looks nice. > I hope it helps. As for the devices paths way > (like /dev/something/even_futher) I can't imagine all the variations of > the path to actually make it work, but I'll think bout it. Too bad there is no HAL at boot time ;) -- Patryk Zawadzki Generated Content From kornet at camk.edu.pl Fri May 18 04:38:22 2007 From: kornet at camk.edu.pl (Kacper Kornet) Date: Fri, 18 May 2007 04:38:22 +0200 Subject: xscreensaver-5.02 and Ac Message-ID: <20070518023822.GB12688@virgo.camk.edu.pl> Maybe xscreensaver-5.02 from HEAD should go to Ac? Previous versions are vulnerably to CVE-2007-1859. Best wishes, -- Kacper Kornet From arekm at maven.pl Sat May 19 23:26:41 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sat, 19 May 2007 23:26:41 +0200 Subject: official rpm replacements for our SourceX-md5 Message-ID: <200705192326.41623.arekm@maven.pl> Hello, Jeff is cooking official support for digest verification in rpm 4.4.9, see: https://lists.dulug.duke.edu/pipermail/rpm-devel/attachments/20070519/46672e48/rpm-frpm.obj That thing is going to replace our home-made SourceX-md5 support. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From n3npq at mac.com Sat May 19 23:52:10 2007 From: n3npq at mac.com (Jeff Johnson) Date: Sat, 19 May 2007 17:52:10 -0400 Subject: official rpm replacements for our SourceX-md5 In-Reply-To: <200705192326.41623.arekm@maven.pl> References: <200705192326.41623.arekm@maven.pl> Message-ID: <2F4EF627-7EDD-49FA-9444-EF7A1F25D24D@mac.com> On May 19, 2007, at 5:26 PM, Arkadiusz Miskiewicz wrote: > > Hello, > > Jeff is cooking official support for digest verification in rpm > 4.4.9, see: > https://lists.dulug.duke.edu/pipermail/rpm-devel/attachments/ > 20070519/46672e48/rpm-frpm.obj > > That thing is going to replace our home-made SourceX-md5 support. Here's the proof-of-concept announcement, feel free to break ;-) https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-May/ 002701.html Adding non-rpmio external transport, multiple digest algorithms, and refactoring the goop out of *.spec (by appending info to spec file from external YAML/ XML) are all planned soonishly. 73 de Jeff From tomasz.wittner at gmail.com Sun May 20 12:41:18 2007 From: tomasz.wittner at gmail.com (Tomasz Wittner) Date: Sun, 20 May 2007 12:41:18 +0200 Subject: [Th] Re: upgrade failed OK: espeak.spec In-Reply-To: References: <8fb45b8c-742e-4934-a956-2fadceaf58ba@pld.src.builder> Message-ID: <200705201241.18984.tomasz.wittner@gmail.com> On Sun 20. of May 2007, 12:31, PLD th-ppc builder wrote: > espeak.spec (HEAD): OK [...] > error: Failed dependencies: > /usr/lib/libespeak.so.1 is needed by espeak-devel-1.25-1.ppc > package upgrade failed This error occurs only on Th. Of curse, /usr/lib/libespeak.so.1 is not packaged but only created in %post by ldconfig. Does anyone know, how to fix this? [...] -- Tomasz Wittner From ankry at green.mif.pg.gda.pl Sun May 20 13:33:14 2007 From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz) Date: Sun, 20 May 2007 13:33:14 +0200 (CEST) Subject: [Th] Re: upgrade failed OK: espeak.spec In-Reply-To: <200705201241.18984.tomasz.wittner@gmail.com> from "Tomasz Wittner" at May 20, 2007 12:41:18 PM Message-ID: <200705201133.l4KBXEsW023800@green.mif.pg.gda.pl> Tomasz Wittner wrote: > > On Sun 20. of May 2007, 12:31, PLD th-ppc builder wrote: > > espeak.spec (HEAD): OK > [...] > > error: Failed dependencies: > > /usr/lib/libespeak.so.1 is needed by espeak-devel-1.25-1.ppc > > package upgrade failed > This error occurs only on Th. Of curse, /usr/lib/libespeak.so.1 is not > packaged but only created in %post by ldconfig. Does anyone know, how to fix > this? > [...] Package the file /usr/lib/libespeak.so.1 as %ghost ? -- ======================================================================= Andrzej M. Krzysztofowicz ankry at mif.pg.gda.pl phone (48)(58) 347 19 36 Faculty of Applied Phys. & Math., Gdansk University of Technology From patrys at pld-linux.org Sun May 20 17:08:29 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Sun, 20 May 2007 17:08:29 +0200 Subject: official rpm replacements for our SourceX-md5 In-Reply-To: <2F4EF627-7EDD-49FA-9444-EF7A1F25D24D@mac.com> References: <200705192326.41623.arekm@maven.pl> <2F4EF627-7EDD-49FA-9444-EF7A1F25D24D@mac.com> Message-ID: <89b6ba3a0705200808u20db1a54j7cc86a541c03393d@mail.gmail.com> On 5/19/07, Jeff Johnson wrote: > Here's the proof-of-concept announcement, feel free to break ;-) > > https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-May/ > 002701.html > > Adding non-rpmio external transport, multiple digest algorithms, and > refactoring the > goop out of *.spec (by appending info to spec file from external YAML/ > XML) > are all planned soonishly. Any chances for a shorthand macro that expands to said constructs? -- Patryk Zawadzki Generated Content From n3npq at mac.com Sun May 20 17:17:56 2007 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 20 May 2007 11:17:56 -0400 Subject: official rpm replacements for our SourceX-md5 In-Reply-To: <89b6ba3a0705200808u20db1a54j7cc86a541c03393d@mail.gmail.com> References: <200705192326.41623.arekm@maven.pl> <2F4EF627-7EDD-49FA-9444-EF7A1F25D24D@mac.com> <89b6ba3a0705200808u20db1a54j7cc86a541c03393d@mail.gmail.com> Message-ID: On May 20, 2007, at 11:08 AM, Patryk Zawadzki wrote: > On 5/19/07, Jeff Johnson wrote: >> Here's the proof-of-concept announcement, feel free to break ;-) >> >> https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-May/ >> 002701.html >> >> Adding non-rpmio external transport, multiple digest algorithms, and >> refactoring the >> goop out of *.spec (by appending info to spec file from external >> YAML/ >> XML) >> are all planned soonishly. > > Any chances for a shorthand macro that expands to said constructs? > What part of BuildRequires: digest(%{SOURCE0}) = 4ee21e9dcc9b5b6012c23038734e1632 can be hidden in a shorthand macro? Getting digests out of spec files into a different, automagically generated, location that is appended to a spec file when building is likely a better approach than macros. Manually typing digests is annoying. 73 de Jeff From jajcus at jajcus.net Tue May 22 15:11:06 2007 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 22 May 2007 15:11:06 +0200 Subject: geninitrd 8385 patches and comments Message-ID: <20070522131106.GA16290@jajo.eggsoft.pl> Hello, I was working several hours to make my PLD-derived system to boot with our geninitrd generated initrd. I had a few problems: 1. my busybox included other shell, which couldn't handle $((...)) Ok, this is my own problem, nothing about PLD 2. the initrd (initramfs in fact) was unable to mount my root device, which was an LVM volume. I made two patches (attached) to address the second problem: 1. geninitrd-rootdev.patch This didn't fix the problem for me, but seems a good fallback: if the device provided by the "root=" kernel parameter cannot be found, then use the 'compile time default' (root device known when geninitrd ran) 2. geninitrd-lvm_initramfs.patch This one disables mounting tmpfs on /dev when initramfs is used. Using tmpfs inside of initramfs makes no sense, as initramfs is already a volatile read/write filesystem. TODO: disable mounting tmpfs on /tmp too (used for LVM stuff) Also "--mknodes" is added to vgscan invocation -- it should not hurt in any case, but makes the LVM devices available for mount before switch_root. Other comments: - There are a few "set +x" lines in the generated 'init' scripts which make initrd/initramfs debugging very hard. 'debuginitrd' option (which calls 'set -s') won't help, as after the first "set +x" the trace output is deactivated. - Do we still need non-initramfs initrd images? Dropping the legacy would make things much simpler: writtable filesystem (no need for temporary tmpfs mounts), the image could be generated with no mknode/mount/chown privileges. Functionality of the initramfs image could be easily extended by appending other cpio archives to it. Greets, Jacek -------------- next part -------------- diff -dur geninitrd-8385.orig/geninitrd geninitrd-8385/geninitrd --- geninitrd-8385.orig/geninitrd 2007-05-22 10:45:56.000000000 +0000 +++ geninitrd-8385/geninitrd 2007-05-22 10:47:53.000000000 +0000 @@ -1393,11 +1393,15 @@ partition, maj, min); } ' /proc/partitions)" -if [ ! -b $device ]; then +if [ "$device" != '/dev/no_partition_found' -a ! -b $device ]; then mknod $device b $maj $min fi EOF cat << EOF >> "$s" +if [ "\$device" = '/dev/no_partition_found' ] ; then + device="$rootdev" +fi + mount -t $rootFs -r \$device /newroot init="\$(busybox awk ' /init=\// { gsub(/.*init=/,NIL,\$0); gsub(/ .*/,NIL,\$0); print \$0; } ' /proc/cmdline )" if [ -z "\$init" -o ! -x "/newroot\$init" ]; then -------------- next part -------------- diff -dur geninitrd-8385.orig/geninitrd geninitrd-8385/geninitrd --- geninitrd-8385.orig/geninitrd 2007-05-22 11:18:39.000000000 +0000 +++ geninitrd-8385/geninitrd 2007-05-22 12:37:41.000000000 +0000 @@ -978,6 +978,8 @@ mknod "$MNTIMAGE/dev/console" c 5 1 mknod "$MNTIMAGE/dev/null" c 1 3 mknod "$MNTIMAGE/dev/zero" c 1 5 +mkdir "$MNTIMAGE/dev/pts" +mkdir "$MNTIMAGE/dev/shm" s="$RCFILE" ln -s /linuxrc $MNTIMAGE/init @@ -1049,6 +1051,10 @@ } initrd_gen_tmpfs_dev() { + if [ "$INITRDFS" = "initramfs" ]; then + # initramfs is read-write filesystem, no need for tmpfs + return + fi tmpfs_dev=yes cat <<-EOF : 'Creating /dev' @@ -1090,7 +1096,7 @@ cat >> "$s" <<- 'EOF' killall udevd umount /proc - umount /dev + umount /dev 2>/dev/null umount /sys EOF fi @@ -1250,7 +1256,7 @@ echo "lvm vgchange -T -a y $VGVOLUME" >> "$s" echo "umount /tmp" >> "$s" # fail to umount - echo "umount /dev" >> "$s" + echo "umount /dev 2>/dev/null" >> "$s" echo "umount /proc" >> "$s" else echo "cat /etc/lvm.conf > /tmp/lvm.conf" >> "$s" @@ -1281,7 +1287,7 @@ echo 0 > /proc/sys/kernel/printk : 'Scanning for Volume Groups' - LVM_SYSTEM_DIR=/tmp lvm vgscan --ignorelockingfailure 2>/dev/null + LVM_SYSTEM_DIR=/tmp lvm vgscan --mknodes --ignorelockingfailure 2>/dev/null : 'Activating Volume Groups' LVM_SYSTEM_DIR=/tmp lvm vgchange --ignorelockingfailure -a y $VGVOLUME 2>/dev/null @@ -1298,7 +1304,7 @@ val=\`expr 256 '*' \$major '+' \$minor\` echo \$val > /proc/sys/kernel/real-root-dev umount /tmp - umount /dev + umount /dev 2>/dev/null umount /proc EOF fi From sparky at pld-linux.org Tue May 22 18:42:34 2007 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Tue, 22 May 2007 18:42:34 +0200 Subject: rpm: qt4-qt_copy.patch (NEW) - some fixes from KDE's svn In-Reply-To: References: Message-ID: <20070522164234.GA1962@pld-linux.org> On Tue, May 22, 2007 at 06:25:35PM +0200, deejay1 wrote: > Author: deejay1 Date: Tue May 22 16:25:35 2007 GMT > Module: rpm Tag: HEAD > ---- Log message: > - some fixes from KDE's svn > +++ rpm/qt4-qt_copy.patch Tue May 22 18:25:30 2007 wrong location ? mv rpm/qt4-qt_copy.patch,v SOURCES/qt4-qt_copy.patch,v -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From deejay1 at srem.org Tue May 22 19:43:25 2007 From: deejay1 at srem.org (=?iso-8859-2?q?=A3ukasz_Jerna=B6?=) Date: Tue, 22 May 2007 19:43:25 +0200 Subject: rpm: qt4-qt_copy.patch (NEW) - some fixes from KDE's svn In-Reply-To: <20070522164234.GA1962@pld-linux.org> References: <20070522164234.GA1962@pld-linux.org> Message-ID: <200705221943.27335.deejay1@srem.org> Dnia wtorek, 22 maja 2007, Przemyslaw Iskra napisa?: > On Tue, May 22, 2007 at 06:25:35PM +0200, deejay1 wrote: > > Author: deejay1 Date: Tue May 22 16:25:35 2007 GMT > > Module: rpm Tag: HEAD > > ---- Log message: > > - some fixes from KDE's svn > > > > +++ rpm/qt4-qt_copy.patch Tue May 22 18:25:30 2007 > > wrong location ? > > mv rpm/qt4-qt_copy.patch,v SOURCES/qt4-qt_copy.patch,v Ooooops, PEBKAC :/ Swoj? drog? commit checki mog?yby sprawdza? czy tam kto? nie commituje do pliku innego ni? groups... -- ?ukasz [DeeJay1] Jerna? From deejay1 at srem.org Tue May 22 19:45:45 2007 From: deejay1 at srem.org (=?iso-8859-2?q?=A3ukasz_Jerna=B6?=) Date: Tue, 22 May 2007 19:45:45 +0200 Subject: rpm: qt4-qt_copy.patch (NEW) - some fixes from KDE's svn In-Reply-To: <200705221943.27335.deejay1@srem.org> References: <20070522164234.GA1962@pld-linux.org> <200705221943.27335.deejay1@srem.org> Message-ID: <200705221945.49511.deejay1@srem.org> Dnia wtorek, 22 maja 2007, ?ukasz Jerna? napisa?: > Ooooops, PEBKAC :/ > Swoj? drog? commit checki mog?yby sprawdza? czy tam kto? nie commituje do > pliku innego ni? groups... EN: BTW, those commit hooks could check that no one's commiting to any other file than groups in there... -- ?ukasz [DeeJay1] Jerna? From patrys at pld-linux.org Wed May 23 15:05:31 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Wed, 23 May 2007 15:05:31 +0200 Subject: Help with rpm anyone? Message-ID: <89b6ba3a0705230605s39a09b7cr9af8ae4ae70a22f3@mail.gmail.com> I was thinking about adding yum to the set of supported package managers. As opposed to poldek, it is still maintained and currently allows a nice setup where a system daemon syncs with repos in the background while notifying possible clients over DBUS that there are updates available. This certainly fits a desktop installation. The problem I currently have is yum 3.2.0 gives me the following: [patrys at meaw ~]$ yum --help error: Unable to open /usr/lib/rpm/rpmrc for reading: No such file or directory. error: cannot open Packages database in /var/lib/rpm Traceback (most recent call last): File "/usr/bin/yum", line 29, in yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 82, in main base.getOptionsConfig(args) File "/usr/share/yum-cli/cli.py", line 146, in getOptionsConfig errorlevel=opts.errorlevel) File "/usr/share/python2.5/site-packages/../site-packages/yum/__init__.py", line 153, in _getConfig File "/usr/share/python2.5/site-packages/../site-packages/yum/config.py", line 601, in readMainConfig File "/usr/share/python2.5/site-packages/../site-packages/yum/config.py", line 664, in _getsysver TypeError: rpmdb open failed The first two messages seem to be produced by either python-rpm or librpm. I am not sure how to debug that (strace does not show anything obvious and I'd like to refrain from debugging a library using gdb). Please help :) -- Patryk Zawadzki Generated Content From patrys at pld-linux.org Wed May 23 15:21:55 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Wed, 23 May 2007 15:21:55 +0200 Subject: Help with rpm anyone? In-Reply-To: <89b6ba3a0705230605s39a09b7cr9af8ae4ae70a22f3@mail.gmail.com> References: <89b6ba3a0705230605s39a09b7cr9af8ae4ae70a22f3@mail.gmail.com> Message-ID: <89b6ba3a0705230621j45239d28jaaca3c11f91ca077@mail.gmail.com> On 5/23/07, Patryk Zawadzki wrote: > [...] Jeff, maybe you could help here? At least to confirm that this is not rpm-related, please? -- Patryk Zawadzki Generated Content From patrys at pld-linux.org Wed May 23 15:50:19 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Wed, 23 May 2007 15:50:19 +0200 Subject: Help with rpm anyone? In-Reply-To: <1938DCBE-7070-423D-A6FE-D8A959921EB8@mac.com> References: <89b6ba3a0705230605s39a09b7cr9af8ae4ae70a22f3@mail.gmail.com> <89b6ba3a0705230621j45239d28jaaca3c11f91ca077@mail.gmail.com> <1938DCBE-7070-423D-A6FE-D8A959921EB8@mac.com> Message-ID: <89b6ba3a0705230650t5adc2098w779533efd8744d89@mail.gmail.com> On 5/23/07, Jeff Johnson wrote: > On May 23, 2007, at 9:21 AM, Patryk Zawadzki wrote: > What is in /usr/lib/rpm/? I don't think that's related. All files are intact and /var/lib/rpm seems fine too. > Check your rpm installation with > rpm -V rpm [patrys at meaw ~]$ rpm -V rpm [patrys at meaw ~]$ rpm -q rpm rpm-4.4.8-0.4.i686 [patrys at meaw ~]$ What I discovered after a little while of digging into python-rpm API (comes from ipython): In [1]: import rpm error: Unable to open /usr/lib/rpm/rpmrc for reading: No such file or directory. In [2]: ts = rpm.TransactionSet() In [3]: db = ts.openDB() error: cannot open Packages database in /var/lib/rpm So it seems that python bindings are not up-to-date (first error is related to a file that is no longer part of rpm) and doing something weird (the second error). Help appreciated. -- Patryk Zawadzki Generated Content From qboosh at pld-linux.org Wed May 23 22:32:41 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 23 May 2007 22:32:41 +0200 Subject: SPECS: myspell.spec - revert again; rel 5 In-Reply-To: References: Message-ID: <20070523203240.GB12686@stranger.qboosh.pl> Moving to proper list... (please remove -devel-pl when replying) On Tue, May 22, 2007 at 11:02:17PM +0200, Pawel Golaszewski wrote: > On Tue, 22 May 2007, glen wrote: > > Author: glen Date: Tue May 22 20:53:04 2007 GMT > > Module: SPECS Tag: HEAD > > ---- Log message: > > - revert again; rel 5 > [...] > > myspell.spec (1.12 -> 1.13) > [...] > > -%define _rel 4 > > +%define _rel 5 > [...] > > -Requires: myspell-common > > why? The directory _is_ requred with new rpm. For which package? Not myspell, containing only library, which itself doesn't refer to /usr/share/myspell path. > I was thinking about moving the directory to main package, but why to keep > it in two places? -- Jakub Bogusz http://qboosh.pl/ From blues at pld-linux.org Wed May 23 23:10:09 2007 From: blues at pld-linux.org (Pawel Golaszewski) Date: Wed, 23 May 2007 23:10:09 +0200 (CEST) Subject: SPECS: myspell.spec - revert again; rel 5 In-Reply-To: <20070523203240.GB12686@stranger.qboosh.pl> References: <20070523203240.GB12686@stranger.qboosh.pl> Message-ID: On Wed, 23 May 2007, Jakub Bogusz wrote: > Moving to proper list... (please remove -devel-pl when replying) It was move to priv with glen. And explained with him :) > > > Author: glen Date: Tue May 22 20:53:04 2007 GMT > > > Module: SPECS Tag: HEAD > > > ---- Log message: > > > - revert again; rel 5 > > [...] > > > myspell.spec (1.12 -> 1.13) > > [...] > > > -%define _rel 4 > > > +%define _rel 5 > > [...] > > > -Requires: myspell-common > > why? The directory _is_ requred with new rpm. > For which package? Not myspell, containing only library, which itself > doesn't refer to /usr/share/myspell path. well - I didn't seen that package from Th is a bit outdated and the directory is not needed now. -- pozdr. Pawel Golaszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From patrys at pld-linux.org Thu May 24 14:36:57 2007 From: patrys at pld-linux.org (Patryk Zawadzki) Date: Thu, 24 May 2007 14:36:57 +0200 Subject: Yum repodata in PLD Message-ID: <89b6ba3a0705240536r429b49e4sf2313a473963979c@mail.gmail.com> I'd like PLD to ship XML repodata for its repositories aside from poldek's pndir format. XML metadata can be used with multiple tools like yum which seems to be a nice candidate for poldek replacement on desktop machines. Especially as it already has usable GUI tools. Is there anything against running createrepo along with poldek's mkidxz? -- Patryk Zawadzki Generated Content From glen at delfi.ee Thu May 24 16:43:42 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Thu, 24 May 2007 17:43:42 +0300 Subject: Yum repodata in PLD In-Reply-To: <89b6ba3a0705240536r429b49e4sf2313a473963979c@mail.gmail.com> References: <89b6ba3a0705240536r429b49e4sf2313a473963979c@mail.gmail.com> Message-ID: <200705241743.42580.glen@delfi.ee> On Thursday 24 May 2007 15:36:57 Patryk Zawadzki wrote: > I'd like PLD to ship XML repodata for its repositories aside from > poldek's pndir format. XML metadata can be used with multiple tools > like yum which seems to be a nice candidate for poldek replacement on > desktop machines. Especially as it already has usable GUI tools. > > Is there anything against running createrepo along with poldek's mkidxz? i'm +1 is poldek able to generate repodata (it can read that i'm almost sure) -- glen From wiget at pld-linux.org Thu May 24 16:49:50 2007 From: wiget at pld-linux.org (Artur Frysiak) Date: Thu, 24 May 2007 16:49:50 +0200 Subject: Yum repodata in PLD In-Reply-To: <200705241743.42580.glen@delfi.ee> References: <89b6ba3a0705240536r429b49e4sf2313a473963979c@mail.gmail.com> <200705241743.42580.glen@delfi.ee> Message-ID: 2007/5/24, Elan Ruusam?e : > > is poldek able to generate repodata (it can read that i'm almost sure) poldek --stl -- Artur Frysiak From beorn at alpha.pl Fri May 25 12:44:33 2007 From: beorn at alpha.pl (Daniel =?utf-8?q?Mr=C3=B3z?=) Date: Fri, 25 May 2007 12:44:33 +0200 Subject: SPECS: python-pyparsing.spec - up to 1.4.6 In-Reply-To: References: Message-ID: <200705251244.33694.beorn@alpha.pl> On Friday 25 of May 2007, beorn wrote: > python-pyparsing.spec (1.11 -> 1.12) Can anyone check this with Python 2.5? It should work, but it's better to check than cry ;) Regards Beorn -- Daniel 'Beorn' Mr?z http://127.0.0.1/beorn [GIT d s:- a-@ C++++ UL++++$ P+ L++++ E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] From dhubleizh at o2.pl Fri May 25 13:35:58 2007 From: dhubleizh at o2.pl (Cezary Krzyzanowski) Date: Fri, 25 May 2007 13:35:58 +0200 Subject: Yum repodata in PLD In-Reply-To: <200705241743.42580.glen@delfi.ee> References: <89b6ba3a0705240536r429b49e4sf2313a473963979c@mail.gmail.com> <200705241743.42580.glen@delfi.ee> Message-ID: <1180092958.3884.6.camel@ipv6-localnet> Dnia 24-05-2007, czw o godzinie 17:43 +0300, Elan Ruusam?e napisa?(a): > i'm +1 > +1 - especially as poldek can make use of Suggest macro. Cz at rny From glen at delfi.ee Fri May 25 16:23:02 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 25 May 2007 17:23:02 +0300 Subject: mysql-5.0.41 moved back to ready Message-ID: <200705251723.02529.glen@delfi.ee> [pldac at ep09-pld .metadata]$ mvpkg updates ready mysql-5.0.41-1.src.rpm.info it's due nasty bug: mysql> select a.category_id from album a where exists (select album_id from image where album_id=a.id); +-------------+ | category_id | +-------------+ | 5 | | 10 | | 3 | | 8 | | 10 | +-------------+ 5 rows in set (0.00 sec) mysql> select a.category_id,count(*) from album a where exists (select album_id from image where album_id=a.id) group by 1; Empty set (0.00 sec) mysql> select version(); +-----------+ | version() | +-----------+ | 5.0.41 | +-----------+ 1 row in set (0.01 sec) ---- mysql> select a.category_id from album a where exists (select album_id from image where album_id=a.id); +-------------+ | category_id | +-------------+ | 5 | | 10 | | 3 | | 8 | | 10 | +-------------+ 5 rows in set (0.00 sec) mysql> select a.category_id,count(*) from album a where exists (select album_id from image where album_id=a.id) group by 1; +-------------+----------+ | category_id | count(*) | +-------------+----------+ | 3 | 1 | | 5 | 1 | | 8 | 1 | | 10 | 2 | +-------------+----------+ 4 rows in set (0.01 sec) mysql> select version(); +-----------+ | version() | +-----------+ | 5.0.37 | +-----------+ 1 row in set (0.00 sec) -- glen From glen at delfi.ee Fri May 25 16:25:26 2007 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Fri, 25 May 2007 17:25:26 +0300 Subject: mysql-5.0.41 moved back to ready In-Reply-To: <200705251723.02529.glen@delfi.ee> References: <200705251723.02529.glen@delfi.ee> Message-ID: <200705251725.26077.glen@delfi.ee> and bug_id http://bugs.mysql.com/bug.php?id=28337 -- glen From qboosh at pld-linux.org Fri May 25 18:42:41 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 25 May 2007 18:42:41 +0200 Subject: Yum repodata in PLD In-Reply-To: <1180092958.3884.6.camel@ipv6-localnet> References: <89b6ba3a0705240536r429b49e4sf2313a473963979c@mail.gmail.com> <200705241743.42580.glen@delfi.ee> <1180092958.3884.6.camel@ipv6-localnet> Message-ID: <20070525164241.GA16905@stranger.qboosh.pl> On Fri, May 25, 2007 at 01:35:58PM +0200, Cezary Krzyzanowski wrote: > Dnia 24-05-2007, czw o godzinie 17:43 +0300, Elan Ruusam?e napisa?(a): > > > i'm +1 > > > > +1 - especially as poldek can make use of Suggest macro. YPB? Does poldek support suggests? With pndir or yum repodata? Does yum support suggests? Has anyone verified it? Suggests was really merged in rpm 4.4.3 and AFAIK Fedora/RH didn't go beyond 4.4.2. And I don't see RPMSENSE_MISSINGOK or RPMTAG_SUGGESTS* in rpm python bindings or poldek sources. -- Jakub Bogusz http://qboosh.pl/ From n3npq at mac.com Fri May 25 19:02:30 2007 From: n3npq at mac.com (Jeff Johnson) Date: Fri, 25 May 2007 13:02:30 -0400 Subject: Yum repodata in PLD In-Reply-To: <20070525164241.GA16905@stranger.qboosh.pl> References: <89b6ba3a0705240536r429b49e4sf2313a473963979c@mail.gmail.com> <200705241743.42580.glen@delfi.ee> <1180092958.3884.6.camel@ipv6-localnet> <20070525164241.GA16905@stranger.qboosh.pl> Message-ID: <39FE6E27-317D-44E1-AF01-C183256239E0@mac.com> On May 25, 2007, at 12:42 PM, Jakub Bogusz wrote: > On Fri, May 25, 2007 at 01:35:58PM +0200, Cezary Krzyzanowski wrote: >> Dnia 24-05-2007, czw o godzinie 17:43 +0300, Elan Ruusam?e napisa? >> (a): >> >>> i'm +1 >>> >> >> +1 - especially as poldek can make use of Suggest macro. > > YPB? > Does poldek support suggests? With pndir or yum repodata? > Does yum support suggests? > Has anyone verified it? > Resistance to Suggests: was quite terrifying to yum developers, and, in fact, is one of the reasons for the rpm fork. > Suggests was really merged in rpm 4.4.3 and AFAIK Fedora/RH didn't go > beyond 4.4.2. > And I don't see RPMSENSE_MISSINGOK or RPMTAG_SUGGESTS* in rpm python > bindings or poldek sources. > Many flags are not defined within python. Easy hacking in python/ rpmmodule.c Meanwhile the value is a problem, as I cannot gurantee that the value is invariant in *.rpm packaging. I'm actively devising a way to include attributes by "missingok" string rather than (1 << 19) value. The suggests tag is likely implicitly available as h['suggests'] even if RPMTAG_SUGGESTS* is not explicitly in rpm-python. ANd what *REALLY* needs doing is to figger a clearly defined semantic, as in WTF is a depsolver supposed to do with Suggests:?!? What dpkg./apt does is print the Suggests: to stdout, not exactly the most useful or powerful semantic. BTW, Enhances: should be renamed to Recommends: I got the name wrong. I don't use apt ;-) 73 de Jeff > > -- > Jakub Bogusz http://qboosh.pl/ > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From radek at pld-linux.org Mon May 28 12:29:48 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 28 May 2007 12:29:48 +0200 Subject: mysql-5.0.41 moved back to ready In-Reply-To: <200705251723.02529.glen@delfi.ee> References: <200705251723.02529.glen@delfi.ee> Message-ID: <20070528102948.GA3410@bzium> Elan Ruusam?e [25-05-2007 16:23]: [...] > mysql> select a.category_id,count(*) from album a where exists (select album_id from image where album_id=a.id) group by 1; > Empty set (0.00 sec) This query makes little sense and is not ANSI SQL compliant (category_id not used in aggregate statement or GROUP BY), so both behaviours are incorrect -- it should return an error. If you want to count the number of albums in a given category which have images, that would be the proper query (exists vs join: depending on the amount of data): select a.category_id, count(*) from album a join image i on i.album_id=a.id group by a.category_id; -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From radek at pld-linux.org Mon May 28 15:25:03 2007 From: radek at pld-linux.org (Radoslaw Zielinski) Date: Mon, 28 May 2007 15:25:03 +0200 Subject: mysql-5.0.41 moved back to ready In-Reply-To: <20070528102948.GA3410@bzium> References: <200705251723.02529.glen@delfi.ee> <20070528102948.GA3410@bzium> Message-ID: <20070528132502.GA8398@bzium> Radoslaw Zielinski [28-05-2007 12:29]: > Elan Ruusam?e [25-05-2007 16:23]: > [...] >> mysql> select a.category_id,count(*) from album a where exists (select album_id from image where album_id=a.id) group by 1; >> Empty set (0.00 sec) > This query makes little sense and is not ANSI SQL compliant (category_id Correction: I'm just plain wrong. I didn't know about this syntax. -- Rados?aw Zieli?ski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wiget at pld-linux.org Mon May 28 22:57:00 2007 From: wiget at pld-linux.org (Artur Frysiak) Date: Mon, 28 May 2007 22:57:00 +0200 Subject: SPECS: yum.spec - %{_datadir}/yum-plugins for noarch plugins - R: ... In-Reply-To: References: Message-ID: 2007/5/28, czarny : > Author: czarny Date: Mon May 28 13:43:58 2007 GMT > Module: SPECS Tag: HEAD > ---- Log message: > - %{_datadir}/yum-plugins for noarch plugins > - R: python-sqlite1 for repos created with createrepo > > ---- Files affected: > SPECS: > yum.spec (1.31 -> 1.32) BTW: this package can't be noarch because its contains arch-dependend dir (%{_libdir}). Regards -- Artur Frysiak From mlukaszek at gmail.com Tue May 29 12:36:45 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Tue, 29 May 2007 12:36:45 +0200 Subject: RescueCD repository? Message-ID: Is there any repository that I could get access to? I'd like to see more how things work (I'll need to prepare my own stripped-down version of something similar to RescueCD soon)... I only found PPRCD repo. -- regards, Micha? ?ukaszek prism at pld-linux.org From arekm at maven.pl Wed May 30 08:29:00 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 30 May 2007 08:29:00 +0200 Subject: INFO: carme-ac.pld-linux.org - Th i686 developer enviroment In-Reply-To: <200705110851.00876.arekm@maven.pl> References: <200705110851.00876.arekm@maven.pl> Message-ID: <200705300829.00969.arekm@maven.pl> On Friday 11 of May 2007, Arkadiusz Miskiewicz wrote: > Hello, > > I've just finished setting up AC developer enviroment on > carme-ac.pld-linux.org. Third vserver has been setup. It contains TH i686 environment. Available at your_account at carme-i686.pld-linux.org. This means that every developer can now access: - Th x86_64 - Th i686 - Ac amd64 environments (poldek access included). $HOME is shared accross these tree. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From deejay1 at srem.org Wed May 30 15:56:46 2007 From: deejay1 at srem.org (=?iso-8859-2?q?=A3ukasz_Jerna=B6?=) Date: Wed, 30 May 2007 15:56:46 +0200 Subject: INFO: carme-ac.pld-linux.org - Th i686 developer enviroment In-Reply-To: <200705300829.00969.arekm@maven.pl> References: <200705110851.00876.arekm@maven.pl> <200705300829.00969.arekm@maven.pl> Message-ID: <200705301556.47526.deejay1@srem.org> Dnia ?roda, 30 maja 2007, Arkadiusz Miskiewicz napisa?: > On Friday 11 of May 2007, Arkadiusz Miskiewicz wrote: > > Hello, > > > > I've just finished setting up AC developer enviroment on > > carme-ac.pld-linux.org. > > Third vserver has been setup. It contains TH i686 environment. Available at > your_account at carme-i686.pld-linux.org. Great, THX! I could you right now ;) -- ?ukasz [DeeJay1] Jerna? From qboosh at pld-linux.org Thu May 31 07:38:54 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 31 May 2007 07:38:54 +0200 Subject: SPECS (DEVEL): qt4.spec - since 4.3.0 QtUiTools is just static, so... In-Reply-To: References: Message-ID: <20070531053854.GB6180@stranger.qboosh.pl> On Thu, May 31, 2007 at 02:15:07AM +0200, shadzik wrote: > Author: shadzik Date: Thu May 31 00:15:07 2007 GMT > Module: SPECS Tag: DEVEL > ---- Log message: > - since 4.3.0 QtUiTools is just static, so remove QtUiTools subpackage qt4.spec:HEAD is patched to provide shared QtUiTools. -- Jakub Bogusz http://qboosh.pl/ From mlukaszek at gmail.com Thu May 31 10:19:56 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Thu, 31 May 2007 10:19:56 +0200 Subject: [th] nspluginwrapper - how to build it? Message-ID: My arch is x86_64. I've got glibc and glibc-devel installed from th-i686. I've rebuilt gcc with multilib. But I still cannot find out what package could provide the required: BuildRequires: gcc-c++32 I've grepped through all specs, and found no other package that requires it. Can someone tell me how it is possible to build the package? -- regards, Micha? ?ukaszek prism at pld-linux.org From glen at delfi.ee Thu May 31 11:04:28 2007 From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Thu, 31 May 2007 12:04:28 +0300 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: References: Message-ID: <200705311204.28970.glen@delfi.ee> On Thursday 31 May 2007 11:19:56 Micha? ?ukaszek wrote: > My arch is x86_64. > I've got glibc and glibc-devel installed from th-i686. I've rebuilt > gcc with multilib. > > But I still cannot find out what package could provide the required: > BuildRequires: gcc-c++32 it's 32bit gcc-c++, no idea what's the package on th-x86_64 called, try just from th-i686, maybe adjust dep to use /usr/lib/somelib.a to fill the dependency. > I've grepped through all specs, and found no other package that requires > it. Can someone tell me how it is possible to build the package? -- glen From pluto at agmk.net Thu May 31 11:16:57 2007 From: pluto at agmk.net (=?ISO-8859-2?Q?Pawe=B3_Sikora?=) Date: Thu, 31 May 2007 11:16:57 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <200705311204.28970.glen@delfi.ee> References: <200705311204.28970.glen@delfi.ee> Message-ID: <465E9289.4040202@agmk.net> Elan Ruusam?e pisze: > On Thursday 31 May 2007 11:19:56 Micha? ?ukaszek wrote: >> My arch is x86_64. >> I've got glibc and glibc-devel installed from th-i686. I've rebuilt >> gcc with multilib. >> >> But I still cannot find out what package could provide the required: >> BuildRequires: gcc-c++32 > it's 32bit gcc-c++, no idea what's the package on th-x86_64 called, in th-x86_64, gcc provides 'gcc(multilib)' but currently multilib is switched off (bcond multilib) due to poldek's problems with installing/upgrading multilib glibc. if someone fix the poldek then we will build/keep multlib glibc/gcc on th-x86_64 builders/ftp. From mlukaszek at gmail.com Thu May 31 11:21:20 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Thu, 31 May 2007 11:21:20 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <200705311204.28970.glen@delfi.ee> References: <200705311204.28970.glen@delfi.ee> Message-ID: On 5/31/07, Elan Ruusam?e wrote: > > gcc with multilib. > > BuildRequires: gcc-c++32 > it's 32bit gcc-c++, no idea what's the package on th-x86_64 called, try just > from th-i686, maybe adjust dep to use /usr/lib/somelib.a to fill the > dependency. I thought that's where the multilib gcc comes in? I did something else though: built with --nodeps (just to see what happens). And, as a result, I got: $ file npviewer.bin npviewer.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.12, dynamically linked (uses shared libs), stripped But: $ LC_ALL=C sudo rpm -Uhv rpm/RPMS/nspluginwrapper-0.9.91.4-1.x86_64.rpm error: Failed dependencies: libX11.so.6 is needed by nspluginwrapper-0.9.91.4-1.x86_64 libXt.so.6 is needed by nspluginwrapper-0.9.91.4-1.x86_64 libgdk-x11-2.0.so.0 is needed by nspluginwrapper-0.9.91.4-1.x86_64 libglib-2.0.so.0 is needed by nspluginwrapper-0.9.91.4-1.x86_64 libgobject-2.0.so.0 is needed by nspluginwrapper-0.9.91.4-1.x86_64 libgtk-x11-2.0.so.0 is needed by nspluginwrapper-0.9.91.4-1.x86_64 And: $ ldd npviewer.bin linux-gate.so.1 => (0xffffe000) libgtk-x11-2.0.so.0 => not found libgdk-x11-2.0.so.0 => not found libgobject-2.0.so.0 => not found libdl.so.2 => /lib/libdl.so.2 (0xf7f37000) libglib-2.0.so.0 => not found libX11.so.6 => not found libXt.so.6 => not found libpthread.so.0 => /lib/libpthread.so.0 (0xf7f1f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7f14000) libc.so.6 => /lib/libc.so.6 (0xf7ddf000) /lib/ld-linux.so.2 (0xf7f4f000) Any idea how to do it right? I guess the reason it works like this is because it tries to locate 32-bit versions of the missing libraries (and I only have 64bit versions installed)? -- regards, Micha? ?ukaszek prism at pld-linux.org From arekm at maven.pl Thu May 31 11:32:01 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 31 May 2007 11:32:01 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <465E9289.4040202@agmk.net> References: <200705311204.28970.glen@delfi.ee> <465E9289.4040202@agmk.net> Message-ID: <200705311132.02221.arekm@maven.pl> On Thursday 31 of May 2007, Pawe? Sikora wrote: > Elan Ruusam?e pisze: > > On Thursday 31 May 2007 11:19:56 Micha? ?ukaszek wrote: > >> My arch is x86_64. > >> I've got glibc and glibc-devel installed from th-i686. I've rebuilt > >> gcc with multilib. > >> > >> But I still cannot find out what package could provide the required: > >> BuildRequires: gcc-c++32 > > > > it's 32bit gcc-c++, no idea what's the package on th-x86_64 called, > > in th-x86_64, gcc provides 'gcc(multilib)' but currently multilib > is switched off (bcond multilib) due to poldek's problems with > installing/upgrading multilib glibc. > > if someone fix the poldek then we will build/keep multlib glibc/gcc > on th-x86_64 builders/ftp. ps. I'm afraid that I won't agree for gcc to become multilib in th in the current form. Right now using such multilib gcc REQUIRES to have glibc 32 bit install where I want to have ability to install pure 64bit environment (including gcc). -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From pluto at agmk.net Thu May 31 11:36:21 2007 From: pluto at agmk.net (=?ISO-8859-2?Q?Pawe=B3_Sikora?=) Date: Thu, 31 May 2007 11:36:21 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <200705311132.02221.arekm@maven.pl> References: <200705311204.28970.glen@delfi.ee> <465E9289.4040202@agmk.net> <200705311132.02221.arekm@maven.pl> Message-ID: <465E9715.409@agmk.net> Arkadiusz Miskiewicz pisze: > On Thursday 31 of May 2007, Pawe? Sikora wrote: >> Elan Ruusam?e pisze: >>> On Thursday 31 May 2007 11:19:56 Micha? ?ukaszek wrote: >>>> My arch is x86_64. >>>> I've got glibc and glibc-devel installed from th-i686. I've rebuilt >>>> gcc with multilib. >>>> >>>> But I still cannot find out what package could provide the required: >>>> BuildRequires: gcc-c++32 >>> it's 32bit gcc-c++, no idea what's the package on th-x86_64 called, >> in th-x86_64, gcc provides 'gcc(multilib)' but currently multilib >> is switched off (bcond multilib) due to poldek's problems with >> installing/upgrading multilib glibc. >> >> if someone fix the poldek then we will build/keep multlib glibc/gcc >> on th-x86_64 builders/ftp. > > ps. > I'm afraid that I won't agree for gcc to become multilib in th in the current > form. Right now using such multilib gcc REQUIRES to have glibc 32 bit install > where I want to have ability to install pure 64bit environment (including > gcc). can we use _noautoreq for glibc32 deps in gcc64? From arekm at maven.pl Thu May 31 11:44:39 2007 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 31 May 2007 11:44:39 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <465E9715.409@agmk.net> References: <200705311132.02221.arekm@maven.pl> <465E9715.409@agmk.net> Message-ID: <200705311144.39939.arekm@maven.pl> On Thursday 31 of May 2007, Pawe? Sikora wrote: > > ps. > > I'm afraid that I won't agree for gcc to become multilib in th in the > > current form. Right now using such multilib gcc REQUIRES to have glibc 32 > > bit install where I want to have ability to install pure 64bit > > environment (including gcc). > > can we use _noautoreq for glibc32 deps in gcc64? Of course the answer is NO. You shouldn't even ask ;) -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From pluto at agmk.net Thu May 31 11:50:17 2007 From: pluto at agmk.net (=?ISO-8859-2?Q?Pawe=B3_Sikora?=) Date: Thu, 31 May 2007 11:50:17 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <200705311144.39939.arekm@maven.pl> References: <200705311132.02221.arekm@maven.pl> <465E9715.409@agmk.net> <200705311144.39939.arekm@maven.pl> Message-ID: <465E9A59.2040302@agmk.net> Arkadiusz Miskiewicz pisze: > On Thursday 31 of May 2007, Pawe? Sikora wrote: > >>> ps. >>> I'm afraid that I won't agree for gcc to become multilib in th in the >>> current form. Right now using such multilib gcc REQUIRES to have glibc 32 >>> bit install where I want to have ability to install pure 64bit >>> environment (including gcc). >> can we use _noautoreq for glibc32 deps in gcc64? > > Of course the answer is NO. You shouldn't even ask ;) i see one solution for nspluginwrapper - statically linked i686 binaries installed on x86-64. From mlukaszek at gmail.com Thu May 31 15:16:38 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Thu, 31 May 2007 15:16:38 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <465E9A59.2040302@agmk.net> References: <200705311132.02221.arekm@maven.pl> <465E9715.409@agmk.net> <200705311144.39939.arekm@maven.pl> <465E9A59.2040302@agmk.net> Message-ID: On 5/31/07, Pawe? Sikora wrote: > i see one solution for nspluginwrapper - statically linked > i686 binaries installed on x86-64. Yes, I agree that would be the best way to go - if I'd like to install all dependent dynamically linked libraries, I would end up with couple dozens of i686 libraries in my /usr/lib. The question is, how to build it statically with ease (on x86_64 host machine)? -- regards, Micha? ?ukaszek prism at pld-linux.org From glen at delfi.ee Thu May 31 15:28:56 2007 From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=) Date: Thu, 31 May 2007 16:28:56 +0300 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: References: <465E9A59.2040302@agmk.net> Message-ID: <200705311628.56745.glen@delfi.ee> On Thursday 31 May 2007 16:16:38 Micha? ?ukaszek wrote: > On 5/31/07, Pawe? Sikora wrote: > > i see one solution for nspluginwrapper - statically linked > > i686 binaries installed on x86-64. > > Yes, I agree that would be the best way to go - if I'd like to install > all dependent dynamically linked libraries, I would end up with couple > dozens of i686 libraries in my /usr/lib. > The question is, how to build it statically with ease (on x86_64 host > machine)? disagree, you'll need the shared 32bit ones anyway to run for example flash plugin $ q adobe-flash --requires [...] fontconfig-libs freetype glib2 glibc gtk+2 -- glen From qboosh at pld-linux.org Thu May 31 16:45:43 2007 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 31 May 2007 16:45:43 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <465E9A59.2040302@agmk.net> References: <200705311132.02221.arekm@maven.pl> <465E9715.409@agmk.net> <200705311144.39939.arekm@maven.pl> <465E9A59.2040302@agmk.net> Message-ID: <20070531144543.GA25866@stranger.qboosh.pl> On Thu, May 31, 2007 at 11:50:17AM +0200, Pawe? Sikora wrote: > Arkadiusz Miskiewicz pisze: > > On Thursday 31 of May 2007, Pawe? Sikora wrote: > > > >>> ps. > >>> I'm afraid that I won't agree for gcc to become multilib in th in the > >>> current form. Right now using such multilib gcc REQUIRES to have glibc 32 > >>> bit install where I want to have ability to install pure 64bit > >>> environment (including gcc). It needs reverting to split scheme from 3.3.x spec. > >> can we use _noautoreq for glibc32 deps in gcc64? > > > > Of course the answer is NO. You shouldn't even ask ;) > > i see one solution for nspluginwrapper - statically linked > i686 binaries installed on x86-64. Forget about static linking. gtk+2 and pango dlopen modules. -- Jakub Bogusz http://qboosh.pl/ From mlukaszek at gmail.com Thu May 31 18:33:22 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Thu, 31 May 2007 18:33:22 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: <20070531144543.GA25866@stranger.qboosh.pl> References: <200705311132.02221.arekm@maven.pl> <465E9715.409@agmk.net> <200705311144.39939.arekm@maven.pl> <465E9A59.2040302@agmk.net> <20070531144543.GA25866@stranger.qboosh.pl> Message-ID: On 5/31/07, Jakub Bogusz wrote: > Forget about static linking. gtk+2 and pango dlopen modules. OK, I managed to run it, and I can confirm it indeed lets you use 32bit flash in 64bit browser (I have tested konqueror and firefox). Packages I had to install from th-i686: $ rpm -qa | grep i686 | sort atk-1.18.0-1.i686 cairo-1.4.6-1.i686 cups-lib-1.2.10-2.i686 expat-2.0.0-3.i686 fontconfig-libs-2.4.2-2.i686 freetype-2.3.4-1.i686 glib-1.2.10-14.i686 glib2-2.12.12-1.i686 glibc-2.6-1.i686 glibc-devel-2.6-1.i686 gtk+2-2.10.12-1.i686 libjpeg-6b-27.i686 libpng-1.2.16-1.i686 libtiff-3.8.2-4.i686 libxcb-1.0-4.i686 openssl-0.9.8e-4.i686 pango-1.16.4-1.i686 xcb-util-0.2-1.i686 xorg-lib-libICE-1.0.3-1.i686 xorg-lib-libSM-1.0.3-1.i686 xorg-lib-libX11-1.1.1-3.i686 xorg-lib-libXau-1.0.3-1.i686 xorg-lib-libXcursor-1.1.8-3.i686 xorg-lib-libXdmcp-1.0.2-4.i686 xorg-lib-libXext-1.0.3-1.i686 xorg-lib-libXfixes-4.0.3-3.i686 xorg-lib-libXft-2.1.12-2.i686 xorg-lib-libXi-1.1.0-3.i686 xorg-lib-libXinerama-1.0.2-1.i686 xorg-lib-libXrandr-1.2.1-1.i686 xorg-lib-libXrender-0.9.2-3.i686 xorg-lib-libXt-1.0.5-2.i686 zlib-1.2.3-4.i686 I did not manage to do the Flash plugin installation "the right way" though ;-) I just manually moved libflashplayer.so and flashplayer.xpt to /usr/lib/browser-plugins Then run nspluginwrapper -i /usr/lib/browser-plugins/libflashplayer.so That in turn created npwrapper.libflashplayer.so in ~/.mozilla/plugins/ which I moved to /usr/lib64/browser-plugins/. Chmod 755 *.so, 644 *.xpt, chown root:root, and voila! I'd be nice to see a kosher way to do this, but I can live without it ;-) -- regards, Micha? ?ukaszek prism at pld-linux.org From mlukaszek at gmail.com Thu May 31 19:03:03 2007 From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=) Date: Thu, 31 May 2007 19:03:03 +0200 Subject: [th] nspluginwrapper - how to build it? In-Reply-To: References: <200705311132.02221.arekm@maven.pl> <465E9715.409@agmk.net> <200705311144.39939.arekm@maven.pl> <465E9A59.2040302@agmk.net> <20070531144543.GA25866@stranger.qboosh.pl> Message-ID: > 32bit flash in 64bit browser (I have tested konqueror and firefox). > > Packages I had to install from th-i686: Ok, as a side note: if you want sound, you'll also need alsa-lib from th-i686. :-) -- regards, Micha? ?ukaszek prism at pld-linux.org