From z at xatka.net Mon Feb 1 10:49:55 2010 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Mon, 1 Feb 2010 10:49:55 +0100 Subject: PLD CVS statistics - January 2010 Message-ID: <20100201094955.GB4195@davabel.touk.pl> Hello, I was wondering how many active commiters do we have, so I have generated CVS statistics for January. (these stats do not include SVN commits). There was 2120 CVS commits in January and 50 commiters. Most active developers are: glen - 428 commits arekm - 411 commits sparky - 314 commits Note that, their commits are more than 50% all of commits in January. Congratulation! Commits per CVS module: 2049 packages 44 PLD-doc 12 pld-builder.new 8 firewall-init 5 template-specs 2 test Most actively developed specs was: 12 packages/phorum/phorum.spec 12 packages/icedove/icedove.spec 11 packages/nagios-plugin-check_bacula_log/nagios-plugin-check_bacula_log.spec 10 packages/dokuwiki/dokuwiki.spec 10 packages/asterisk/asterisk.spec 9 packages/kernel/kernel.spec 8 packages/virtuoso/virtuoso.spec 8 packages/cluster-glue/cluster-glue.spec 7 packages/zaptel-alt/zaptel-alt.spec 7 packages/xulrunner/xulrunner.spec 7 packages/phorum/paths.patch Number of commits per commiter (full list): 428 arekm 411 glen 314 sparky 128 megabajt 105 amateja 86 baggins 72 lisu 67 pawelz 58 shadzik 47 adamg 42 hawk 38 duddits 27 uzsolt 26 patrys 24 paszczus 22 qboosh 22 gotar 16 lkrotowski 15 dirdival 13 stivi 13 sls 13 charles 11 w.kier 10 pluto 9 lmasko 9 draenog 7 witekfl 7 wiget 7 jajcus 7 evil 7 dzeus 6 rotom 6 blues 5 marmarek 5 kosmo 5 cactus 5 ankry 4 zbyniu 4 zawadaa 3 vip 3 mguevara 3 matik 2 wolvverine 2 qwiat 1 tommat 1 secam 1 psz 1 pascalek 1 mmazur 1 marcus -- Pawe? Zuzelski From z at xatka.net Mon Feb 1 13:03:00 2010 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Mon, 1 Feb 2010 13:03:00 +0100 Subject: PLD CVS statistics - January 2010 In-Reply-To: <20100201094955.GB4195@davabel.touk.pl> References: <20100201094955.GB4195@davabel.touk.pl> Message-ID: <20100201120300.GC4195@davabel.touk.pl> On Mon, 01 Feb 2010, Pawe? Zuzelski wrote: > Hello, > > I was wondering how many active commiters do we have, so I have > generated CVS statistics for January. (these stats do not include > SVN commits). > > There was 2120 CVS commits in January and 50 commiters. > Most active developers are: > glen - 428 commits > arekm - 411 commits I copied data manually from terminal to mutt and there was a mistake. I'm sorry. correct values are: arekm - 428 commits glen - 411 commits I'm going to write some scripts to generate these stats, so I hope next month there will be better stats with no mistakes ;) -- Regards, Pawe? From glen at pld-linux.org Tue Feb 2 15:18:02 2010 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Tue, 2 Feb 2010 16:18:02 +0200 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: References: Message-ID: <201002021618.02853.glen@pld-linux.org> On Tuesday 02 February 2010 16:04:46 shadzik wrote: > Author: shadzik Date: Tue Feb 2 14:04:46 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - make it build on Titanium, try not to break build on Th - let's see if > that succeeded ... > +%if "%{pld_release}" != "ti" > %attr(755,root,root) %ghost /%{_lib}/libtinfow.so.6 > %attr(755,root,root) %{_libdir}/libncursesw.so.*.* > %attr(755,root,root) %ghost %{_libdir}/libncursesw.so.5 > %attr(755,root,root) %{_libdir}/libtinfow.so.*.* > %attr(755,root,root) %ghost %{_libdir}/libtinfow.so.5 > +%else > +%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.5 > +%attr(755,root,root) %ghost /%{_lib}/libncursesw.so.5 > +%endif this has exceeded sane amount of the nesting level of ifdefs, please move the branch specific spec to a dedicated branch, both branches be nicer and more easier to update. there isn't so much changes in a spec that such complexity of following the conditions (to verify nothing got broken after a change) pays off. same applies to openssl.spec -- glen From glen at pld-linux.org Tue Feb 2 16:35:16 2010 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Tue, 2 Feb 2010 17:35:16 +0200 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: References: <201002021618.02853.glen@pld-linux.org> Message-ID: <201002021735.16590.glen@pld-linux.org> On Tuesday 02 February 2010 16:23:41 Bartosz ?wi?tek wrote: > 2010/2/2 Elan Ruusam?e : > > On Tuesday 02 February 2010 16:04:46 shadzik wrote: > >> Author: shadzik ? ? ? ? ? ? ? ? ? ? ?Date: Tue Feb ?2 14:04:46 2010 GMT > >> Module: packages ? ? ? ? ? ? ? ? ? ? ?Tag: HEAD > >> ---- Log message: > >> - make it build on Titanium, try not to break build on Th - let's see if > >> that succeeded > > > > ... > > > >> +%if "%{pld_release}" != "ti" > >> ?%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.6 > >> ?%attr(755,root,root) %{_libdir}/libncursesw.so.*.* > >> ?%attr(755,root,root) %ghost %{_libdir}/libncursesw.so.5 > >> ?%attr(755,root,root) %{_libdir}/libtinfow.so.*.* > >> ?%attr(755,root,root) %ghost %{_libdir}/libtinfow.so.5 > >> +%else > >> +%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.5 > >> +%attr(755,root,root) %ghost /%{_lib}/libncursesw.so.5 > >> +%endif > > > > this has exceeded sane amount of the nesting level of ifdefs, please move > > the branch specific spec to a dedicated branch, both branches be nicer > > and more easier to update. there isn't so much changes in a spec that > > such complexity of following the conditions (to verify nothing got broken > > after a change) pays off. > > > > same applies to openssl.spec > > This is the way Hawk told me to deal with such problems - exactly not > to have dozens of branches - therefore I'm dealing with them that way. > Two or three more conditions doesn't make it less readable. Request > rejected. hawk: tell your intern?rs to reconsider trashing the HEAD, kernel.spec's are in branches, why can't this be, this is no longer a simple change. to shadzik: do not remove cc: when replying even if you post gets rejected. -- glen From glen at pld-linux.org Tue Feb 2 16:45:34 2010 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Tue, 2 Feb 2010 17:45:34 +0200 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <950d18961002020741w11e8270cr4df4a249a9d897d5@mail.gmail.com> References: <201002021735.16590.glen@pld-linux.org> <950d18961002020741w11e8270cr4df4a249a9d897d5@mail.gmail.com> Message-ID: <201002021745.34543.glen@pld-linux.org> On Tuesday 02 February 2010 17:41:40 Artur Wroblewski wrote: > 2010/2/2 Elan Ruusam?e : > > On Tuesday 02 February 2010 16:23:41 Bartosz ?wi?tek wrote: > >> 2010/2/2 Elan Ruusam?e : > >> > On Tuesday 02 February 2010 16:04:46 shadzik wrote: > >> >> Author: shadzik ? ? ? ? ? ? ? ? ? ? ?Date: Tue Feb ?2 14:04:46 2010 > >> >> GMT Module: packages ? ? ? ? ? ? ? ? ? ? ?Tag: HEAD > >> >> ---- Log message: > >> >> - make it build on Titanium, try not to break build on Th - let's see > >> >> if that succeeded > >> > > >> > ... > >> > > >> >> +%if "%{pld_release}" != "ti" > >> >> ?%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.6 > >> >> ?%attr(755,root,root) %{_libdir}/libncursesw.so.*.* > >> >> ?%attr(755,root,root) %ghost %{_libdir}/libncursesw.so.5 > >> >> ?%attr(755,root,root) %{_libdir}/libtinfow.so.*.* > >> >> ?%attr(755,root,root) %ghost %{_libdir}/libtinfow.so.5 > >> >> +%else > >> >> +%attr(755,root,root) %ghost /%{_lib}/libtinfow.so.5 > >> >> +%attr(755,root,root) %ghost /%{_lib}/libncursesw.so.5 > >> >> +%endif > >> > > >> > this has exceeded sane amount of the nesting level of ifdefs, please > >> > move the branch specific spec to a dedicated branch, both branches be > >> > nicer and more easier to update. there isn't so much changes in a spec > >> > that such complexity of following the conditions (to verify nothing > >> > got broken after a change) pays off. > >> > > >> > same applies to openssl.spec > >> > >> This is the way Hawk told me to deal with such problems - exactly not > >> to have dozens of branches - therefore I'm dealing with them that way. > >> Two or three more conditions doesn't make it less readable. Request > >> rejected. > > > > hawk: tell your intern?rs to reconsider trashing the HEAD, kernel.spec's > > are in branches, why can't this be, this is no longer a simple change. > > > > to shadzik: do not remove cc: when replying even if you post gets > > rejected. > > If I reckon well we had discussion about that in the past. And here goes > the mess. Enjoy cleaning it up. > > Best regards, > > w if you refer to the "%py_version" vs "%pld_release" comparision, then these are totally different, threads, large poritions conditioned out over the spec became headache to read eventually. especially if you need to update only one "condition branch", that's what is this email thread initiated. anyway, note sent to hawk who seems to control the decisions, so lets wait what he decides. -- glen From hawk at limanowa.net Tue Feb 2 17:02:45 2010 From: hawk at limanowa.net (Marcin Krol) Date: Tue, 02 Feb 2010 17:02:45 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <201002021735.16590.glen@pld-linux.org> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> Message-ID: <4B684CA5.7030904@limanowa.net> > hawk: tell your intern?rs to reconsider trashing the HEAD, kernel.spec's are > in branches, why can't this be, this is no longer a simple change. > > to shadzik: do not remove cc: when replying even if you post gets rejected. I don't think about it as trashing the HEAD. Being able to use same spec/branch for both Th and Titanium is very useful from my point of view - we don't need to merge changes between branches (both ways). Number of specs where %if "%{pld_release}" macros are used isn't that big and doesn't make modifying them that hard. I don't ask anyone to edit/adjust/fix Titanium part of such specs, just forget its there and focus on Th part. Arguments like "it makes spec unreadable / harder to edit" doesn't make any sense to me. I peronally don't find handling multi-distro specs any harder than regular specs. Not to mention that it also doesn't make any sense to keep separate branch when one BR or bcond is the only difference. Granted, there are more complex distro specific changes like in mentioned openssl.spec, but how many such specs are out there? 4, 5? Titanium specific kernels are on branches for completly different reasons and this shouldn't be compared. M. From wrobell at pld-linux.org Wed Feb 3 10:38:48 2010 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Wed, 3 Feb 2010 09:38:48 +0000 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <4B684CA5.7030904@limanowa.net> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> Message-ID: <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> 2010/2/2 Marcin Krol : >> hawk: tell your intern?rs to reconsider trashing the HEAD, kernel.spec's are >> in branches, why can't this be, this is no longer a simple change. >> >> to shadzik: do not remove cc: when replying even if you post gets rejected. > > I don't think about it as trashing the HEAD. Being able to use same > spec/branch for both Th and Titanium is very useful from my point of > view - we don't need to merge changes between branches (both ways). > > Number of specs where %if "%{pld_release}" macros are used isn't that > big and doesn't make modifying them that hard. I don't ask anyone to > edit/adjust/fix Titanium part of such specs, just forget its there and > focus on Th part. So what are exact rules at the moment? What if someone wants to create another branch of distro? w From hawk at limanowa.net Wed Feb 3 12:02:07 2010 From: hawk at limanowa.net (Marcin Krol) Date: Wed, 03 Feb 2010 12:02:07 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> Message-ID: <4B6957AF.1060702@limanowa.net> > So what are exact rules at the moment? > > What if someone wants to create another branch of distro? I'd like to know that too. When I've created Titanium I was keeping separate branches on some specs. That was baad, because I wasn't merging my changes/updates to HEAD. So I started using %if "%{pld_release}" macros instead and keeping my changes on HEAD. For over two years no one had problems with that. Now I guess if someone wants to create/maintain his branch of distro he will be forced to work on separate branch in case of even smallest differences in spec because Someone(tm) is too lazy to workout few %if macros. Nothing bad with that. Titanium is unofficial and I can't do anything about official PLD decisions except for my vote in CDG. I'm only afraid what next step will be. M. From wrobell at pld-linux.org Wed Feb 3 12:11:04 2010 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Wed, 3 Feb 2010 11:11:04 +0000 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <4B6957AF.1060702@limanowa.net> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> <4B6957AF.1060702@limanowa.net> Message-ID: <950d18961002030311o51a36d37pa2c8834ba4e51753@mail.gmail.com> On Wed, Feb 3, 2010 at 11:02 AM, Marcin Krol wrote: >> So what are exact rules at the moment? >> >> What if someone wants to create another branch of distro? > > I'd like to know that too. When I've created Titanium I was keeping > separate branches on some specs. That was baad, because I wasn't merging > my changes/updates to HEAD. But that's not our fault, is it? :) > So I started using %if "%{pld_release}" > macros instead and keeping my changes on HEAD. For over two years no one > had problems with that. If I reckon well, I had problems with that, because such laziness leads to situations like we have now. It was discusses twice or something in the past. My point is - in the past it was decided that distro branches are kept on separate branches and it worked in case of Ra, Ac and Th (aka nest) Now, if you want new rules then please state them. Or we will end up with mess on HEAD. Cheers, w From gotar at polanet.pl Wed Feb 3 12:20:05 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 3 Feb 2010 12:20:05 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <4B6957AF.1060702@limanowa.net> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> <4B6957AF.1060702@limanowa.net> Message-ID: <20100203112005.GB4379@polanet.pl> On Wed, Feb 03, 2010 at 12:02:07 +0100, Marcin Krol wrote: > my changes/updates to HEAD. So I started using %if "%{pld_release}" > macros instead and keeping my changes on HEAD. For over two years no one > had problems with that. I have a problem - assume I want to rebuild some package in Ti-way. How? > Now I guess if someone wants to create/maintain his branch of distro he > will be forced to work on separate branch in case of even smallest > differences in spec because Someone(tm) is too lazy to workout few %if > macros. Nothing bad with that. Titanium is unofficial and I can't do > anything about official PLD decisions except for my vote in CDG. > > I'm only afraid what next step will be. If all the %ifs would have to be removed, you can always switch bconds in rpmmacros of Ti builder. -- Tomasz Pala From gotar at polanet.pl Wed Feb 3 12:22:53 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 3 Feb 2010 12:22:53 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <950d18961002030311o51a36d37pa2c8834ba4e51753@mail.gmail.com> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> <4B6957AF.1060702@limanowa.net> <950d18961002030311o51a36d37pa2c8834ba4e51753@mail.gmail.com> Message-ID: <20100203112253.GC4379@polanet.pl> On Wed, Feb 03, 2010 at 11:11:04 +0000, Artur Wroblewski wrote: > Now, if you want new rules then please state them. Or we will end up > with mess on HEAD. Assuming these changes are irrevelant to all of Th us. Take a look at iceweasel.spec - that's the way it should be done and IMHO could. -- Tomasz Pala From hawk at limanowa.net Wed Feb 3 12:33:58 2010 From: hawk at limanowa.net (Marcin Krol) Date: Wed, 03 Feb 2010 12:33:58 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <20100203111357.GA2122@polanet.pl> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <20100203111357.GA2122@polanet.pl> Message-ID: <4B695F26.5030207@limanowa.net> >> Number of specs where %if "%{pld_release}" macros are used isn't that >> big and doesn't make modifying them that hard. I don't ask anyone to >> edit/adjust/fix Titanium part of such specs, just forget its there and >> focus on Th part. > > This is what bconds are for. Their state is the only thing that should > be TI-related. > Seems fine for me, but it will still be trashing HEAD for some people I'm afraid. The only thing that will change is %if. Instead of %if "%{pld_release}" == "ti" something %else something different %endif we will have %if %{with titanium} something %else something different %endif And again we will end in discussion that HEAD is unreadable, uneditable, messed up etc. etc. I'm thinking about branching those few specs and removing all Titanium changes from HEAD + adding single %if "%{pld_release}" macro with blocker to be sure that no one will be able to build HEAD version on Titanium. M. From glen at pld-linux.org Wed Feb 3 12:37:22 2010 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 3 Feb 2010 13:37:22 +0200 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <4B6957AF.1060702@limanowa.net> References: <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> <4B6957AF.1060702@limanowa.net> Message-ID: <201002031337.22535.glen@pld-linux.org> On Wednesday 03 February 2010 13:02:07 Marcin Krol wrote: > So I started using %if "%{pld_release}" > macros instead and keeping my changes on HEAD. For over two years no one > had problems with that. and there are no problems if the spec stays processible after that, it was reminder that it's maybe gone too far already... On Wednesday 03 February 2010 13:22:53 Tomasz Pala wrote: > > Now, if you want new rules then please state them. Or we will end up > > with mess on HEAD. > > Assuming these changes are irrevelant to all of Th us. Take a look at > iceweasel.spec - that's the way it should be done and IMHO could. i tend to agree here, distro specific differences accomplished with bconds, rest of the spec is like regular bconds, openssl.spec could be lead to same level if some FEATURE_dir macro is introduced.... and similar with_ncursesw added. just adding %if pld_brand and copying back block from previous spec reivision is what grinds my gears. -- glen From hawk at limanowa.net Wed Feb 3 12:51:51 2010 From: hawk at limanowa.net (Marcin Krol) Date: Wed, 03 Feb 2010 12:51:51 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <950d18961002030311o51a36d37pa2c8834ba4e51753@mail.gmail.com> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> <4B6957AF.1060702@limanowa.net> <950d18961002030311o51a36d37pa2c8834ba4e51753@mail.gmail.com> Message-ID: <4B696357.4060305@limanowa.net> >> I'd like to know that too. When I've created Titanium I was keeping >> separate branches on some specs. That was baad, because I wasn't merging >> my changes/updates to HEAD. > > But that's not our fault, is it? :) Yes it is. Hawk working on Titanium and not merging his changes because of -ENOTIME - bad, some developers are unhappy that they must merge to HEAD themselves. So Hawk starts working on HEAD separating Titanium specific changes - also bad, some developers are unhappy that Titanium stuff is on HEAD despite its separated and doesn't affect Th at all. Thats how it looks right now from my point of view. > My point is - in the past it was decided that distro branches are kept > on separate > branches and it worked in case of Ra, Ac and Th (aka nest) I'll be honest. Moving all specs to Titanium branch will mean death of my fork. I simply have no time to track each and every spec for changes to be merged or branch point to be moved. I don't have as much time as I had in the past to maintaint PLD. Thats my problem, I agree. > Now, if you want new rules then please state them. Or we will end up > with mess on > HEAD. Its either bconds as suggested and we will still have same mess on HEAD or branching few specs and adding Titanium blockers on HEAD. I'm fine with both solutions. M. From wrobell at pld-linux.org Wed Feb 3 13:00:32 2010 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Wed, 3 Feb 2010 12:00:32 +0000 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <4B696357.4060305@limanowa.net> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> <4B6957AF.1060702@limanowa.net> <950d18961002030311o51a36d37pa2c8834ba4e51753@mail.gmail.com> <4B696357.4060305@limanowa.net> Message-ID: <950d18961002030400r61b155acm13b2564ff1277606@mail.gmail.com> On Wed, Feb 3, 2010 at 11:51 AM, Marcin Krol wrote: >>> I'd like to know that too. When I've created Titanium I was keeping >>> separate branches on some specs. That was baad, because I wasn't merging >>> my changes/updates to HEAD. >> >> But that's not our fault, is it? :) > > Yes it is. Hawk working on Titanium and not merging his changes because > of -ENOTIME - bad, some developers are unhappy that they must merge to > HEAD themselves. So Hawk starts working on HEAD separating Titanium > specific changes - also bad, some developers are unhappy that Titanium > stuff is on HEAD despite its separated and doesn't affect Th at all. Well, until I had to clean up mess in some of the spec files and non-building packages. Not speaking about some stupid commit war around ac/ti/th/whatever changes, which would not happen if appropriate changes were kept on a branch. [...] >> My point is - in the past it was decided that distro branches are kept >> on separate >> branches and it worked in case of Ra, Ac and Th (aka nest) > > I'll be honest. Moving all specs to Titanium branch will mean death of > my fork. I simply have no time to track each and every spec for changes > to be merged or branch point to be moved. I don't have as much time as I > had in the past to maintaint PLD. Thats my problem, I agree. Probably I missed some discussion on irc or pld-devel-pl... but what is exact purpose of Titanium? Why it started in first place? w From hawk at limanowa.net Wed Feb 3 13:12:01 2010 From: hawk at limanowa.net (Marcin Krol) Date: Wed, 03 Feb 2010 13:12:01 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <950d18961002030400r61b155acm13b2564ff1277606@mail.gmail.com> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <950d18961002030138g679751c3v4d474f2c2bd682c4@mail.gmail.com> <4B6957AF.1060702@limanowa.net> <950d18961002030311o51a36d37pa2c8834ba4e51753@mail.gmail.com> <4B696357.4060305@limanowa.net> <950d18961002030400r61b155acm13b2564ff1277606@mail.gmail.com> Message-ID: <4B696811.2010105@limanowa.net> > Probably I missed some discussion on irc or pld-devel-pl... but what > is exact purpose of Titanium? Why it started in first place? There are two main reasons: 1. To have stable distro with actual software. Ac had and has too old software for me and Th is still light years away from being stable (in my terms of stability). 2. To have absolute freedom about deciding what is good and what is bad for distribution. It wasn't and still is not possible with official PLD I'm afraid. M. From gotar at polanet.pl Wed Feb 3 15:19:46 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 3 Feb 2010 15:19:46 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <4B695F26.5030207@limanowa.net> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <20100203111357.GA2122@polanet.pl> <4B695F26.5030207@limanowa.net> Message-ID: <20100203141946.GA5935@polanet.pl> On Wed, Feb 03, 2010 at 12:33:58 +0100, Marcin Krol wrote: > Seems fine for me, but it will still be trashing HEAD for some people > I'm afraid. The only thing that will change is %if. Instead of > > %if "%{pld_release}" == "ti" [...] > we will have > > %if %{with titanium} No, you didn't understand. It's not supposed to be '--with titanium' but '--with alternative_option_for_this_package', just like in iceweasel. -- Tomasz Pala From wrobell at pld-linux.org Wed Feb 3 15:26:51 2010 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Wed, 3 Feb 2010 14:26:51 +0000 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <20100203141946.GA5935@polanet.pl> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <20100203111357.GA2122@polanet.pl> <4B695F26.5030207@limanowa.net> <20100203141946.GA5935@polanet.pl> Message-ID: <950d18961002030626k5238e241j928a0caa13e16146@mail.gmail.com> On Wed, Feb 3, 2010 at 2:19 PM, Tomasz Pala wrote: > On Wed, Feb 03, 2010 at 12:33:58 +0100, Marcin Krol wrote: > >> Seems fine for me, but it will still be trashing HEAD for some people >> I'm afraid. The only thing that will change is %if. Instead of >> >> %if "%{pld_release}" == "ti" > [...] >> we will have >> >> %if %{with titanium} > > No, you didn't understand. It's not supposed to be '--with titanium' but > '--with alternative_option_for_this_package', just like in iceweasel. You mean system xulrunner, right? w From gotar at polanet.pl Wed Feb 3 16:14:26 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 3 Feb 2010 16:14:26 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <950d18961002030626k5238e241j928a0caa13e16146@mail.gmail.com> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <20100203111357.GA2122@polanet.pl> <4B695F26.5030207@limanowa.net> <20100203141946.GA5935@polanet.pl> <950d18961002030626k5238e241j928a0caa13e16146@mail.gmail.com> Message-ID: <20100203151426.GA24367@polanet.pl> On Wed, Feb 03, 2010 at 14:26:51 +0000, Artur Wroblewski wrote: >> No, you didn't understand. It's not supposed to be '--with titanium' but >> '--with alternative_option_for_this_package', just like in iceweasel. > > You mean system xulrunner, right? Yes. And there could be --without FHS for openssl and --without extcolors in ncurses. It happens that all the 3 cases are also my preferences, I'd like to keep them available regardles of some weird branch-specific macro. -- Tomasz Pala From hawk at limanowa.net Wed Feb 3 16:12:27 2010 From: hawk at limanowa.net (Marcin Krol) Date: Wed, 03 Feb 2010 16:12:27 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <20100203141946.GA5935@polanet.pl> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <20100203111357.GA2122@polanet.pl> <4B695F26.5030207@limanowa.net> <20100203141946.GA5935@polanet.pl> Message-ID: <4B69925B.3070407@limanowa.net> > No, you didn't understand. It's not supposed to be '--with titanium' but > '--with alternative_option_for_this_package', just like in iceweasel. It will look kind of funny... --with var_lib_openssl for openssl.spec? I think I prefer branches then for those few specs and blockers on HEAD. M. From gotar at polanet.pl Wed Feb 3 16:20:35 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 3 Feb 2010 16:20:35 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <4B69925B.3070407@limanowa.net> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <20100203111357.GA2122@polanet.pl> <4B695F26.5030207@limanowa.net> <20100203141946.GA5935@polanet.pl> <4B69925B.3070407@limanowa.net> Message-ID: <20100203152035.GB24367@polanet.pl> On Wed, Feb 03, 2010 at 16:12:27 +0100, Marcin Krol wrote: >> No, you didn't understand. It's not supposed to be '--with titanium' but >> '--with alternative_option_for_this_package', just like in iceweasel. > > It will look kind of funny... --with var_lib_openssl for openssl.spec? I If you prefer such a funny name... Just think what it is for and name it, I already proposed --without FHS but it can be sth like 'ac_compat'. > think I prefer branches then for those few specs and blockers on HEAD. ...then I'll restore these options as bconds, because I don't agree with Th-line either and you'll end up with not maintained branches. BTW any chances on iceweasel 3.6? -- Tomasz Pala From hawk at limanowa.net Wed Feb 3 20:58:33 2010 From: hawk at limanowa.net (Marcin Krol) Date: Wed, 03 Feb 2010 20:58:33 +0100 Subject: packages: ncurses/ncurses.spec - make it build on Titanium, try not to brea... In-Reply-To: <20100203152035.GB24367@polanet.pl> References: <201002021618.02853.glen@pld-linux.org> <201002021735.16590.glen@pld-linux.org> <4B684CA5.7030904@limanowa.net> <20100203111357.GA2122@polanet.pl> <4B695F26.5030207@limanowa.net> <20100203141946.GA5935@polanet.pl> <4B69925B.3070407@limanowa.net> <20100203152035.GB24367@polanet.pl> Message-ID: <4B69D569.7090402@limanowa.net> > BTW any chances on iceweasel 3.6? Yes. I'm working on Iceweasel, Icedove and Iceape upgrades, but my time for PLD is limited right now. M. From gotar at polanet.pl Sat Feb 6 10:10:46 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 6 Feb 2010 10:10:46 +0100 Subject: rpm: POSIX capabilities/ACLs? Message-ID: <20100206091045.GA4627@polanet.pl> Anyone knows if it is or is going to be possible in rpm to store xattrs? http://fedoraproject.org/wiki/Features/LowerProcessCapabilities http://www.mail-archive.com/fedora-devel-list at redhat.com/msg05425.html -- Tomasz Pala From zbyniu at geocarbon.pl Sat Feb 6 12:04:07 2010 From: zbyniu at geocarbon.pl (Zbyniu Krzystolik) Date: Sat, 6 Feb 2010 12:04:07 +0100 Subject: rpm: POSIX capabilities/ACLs? In-Reply-To: <20100206091045.GA4627@polanet.pl> References: <20100206091045.GA4627@polanet.pl> Message-ID: <20100206110407.GA15821@geocarbon.pl> Tomasz Pala napisa?(a): > Anyone knows if it is or is going to be possible in rpm to store xattrs? Not possible now. > http://fedoraproject.org/wiki/Features/LowerProcessCapabilities > http://www.mail-archive.com/fedora-devel-list at redhat.com/msg05425.html My note may be interested for you (pl); libcap-ng utils can simplify it. http://zz.iapt.pl/bez_root2.txt Zbyniu -- %% Absolutely nothing we trust %% From gotar at polanet.pl Sat Feb 6 17:56:35 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 6 Feb 2010 17:56:35 +0100 Subject: rpm: POSIX capabilities/ACLs? In-Reply-To: <20100206110407.GA15821@geocarbon.pl> References: <20100206091045.GA4627@polanet.pl> <20100206110407.GA15821@geocarbon.pl> Message-ID: <20100206165635.GA5233@polanet.pl> On Sat, Feb 06, 2010 at 12:04:07 +0100, Zbyniu Krzystolik wrote: >> Anyone knows if it is or is going to be possible in rpm to store xattrs? > > Not possible now. And how about The Other RPM? This is a must-be feature and sooner or later we must get rid of broken by design SUID/SGID... > My note may be interested for you (pl); libcap-ng utils can simplify it. > http://zz.iapt.pl/bez_root2.txt That's similar to thing I want to do. The difference is you drop capabilities, and I want to set some for regular users (either designated - for daemons having it's own files and secrets, or nobody for anything else, using start-stop-daemon --chuid). Like this: setcap cap_net_bind_service=ei =nc execcap cap_net_bind_service=i su - gotar -c 'nc -l -p 34' but this obviously requires tagging binaries. The problem is tracking all the xattrs (caps and ACLs). Especially if I need to restrict some accounts (i.e. give some permissions to normal accounts) more, than hardening daemons... -- Tomasz Pala From n3npq at mac.com Sun Feb 7 22:30:11 2010 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 07 Feb 2010 16:30:11 -0500 Subject: rpm: POSIX capabilities/ACLs? In-Reply-To: <20100206165635.GA5233@polanet.pl> References: <20100206091045.GA4627@polanet.pl> <20100206110407.GA15821@geocarbon.pl> <20100206165635.GA5233@polanet.pl> Message-ID: <450EF457-14ED-47F5-AD69-252B978F493B@mac.com> On Feb 6, 2010, at 11:56 AM, Tomasz Pala wrote: > On Sat, Feb 06, 2010 at 12:04:07 +0100, Zbyniu Krzystolik wrote: > >>> Anyone knows if it is or is going to be possible in rpm to store xattrs? >> >> Not possible now. > > And how about The Other RPM? This is a must-be feature and sooner or > later we must get rid of broken by design SUID/SGID... > You must mean rpm-5.0 as the "other rpm" ;-) Yes. rpm.org has a defined tag for capabilities, and perhaps for ACL's (of the linux persuasuoin, how to package ACl'l portably for *BSD and MacOSX is a nastier but solvable issue). When I looked at porting support for capabilities & ACL's, this reasoning mad me reluctant: There are > 300K files in a typical rpm distro. Out of that 300K files, perhaps 100-500 files would benefit (afaik) from adding support for capabilities/ACL's. Adding an additional per-file tag to benefit 500 of 300,000 files, with the additional download bandwidth needed to represent missing/unused info doesn't make much sense. Making the tag "optional", present iff explicitly added, while doable, creates a different sort of "missing" or "optional" problem. But if you want capabilities/ACL's ported to rpm-4.5, I can do that in an afternoon if you wish. >> My note may be interested for you (pl); libcap-ng utils can simplify it. >> http://zz.iapt.pl/bez_root2.txt > > That's similar to thing I want to do. The difference is you drop > capabilities, and I want to set some for regular users (either > designated - for daemons having it's own files and secrets, or nobody > for anything else, using start-stop-daemon --chuid). Like this: > > setcap cap_net_bind_service=ei =nc > execcap cap_net_bind_service=i su - gotar -c 'nc -l -p 34' > > but this obviously requires tagging binaries. The problem is tracking > all the xattrs (caps and ACLs). > Yes, tracking *all* the file paths is exactly the same as SElinux xattr's. Note that SELinux currently doesn't trust its means to "track" the xattrs across *all* file paths suufficiently that they have chosen to "package" SELinuc modular policy with Any SElinux attr that is installed is never removed. Similar issues will be seen with capabilities/ACL's tracked across *all* file paths in addition to the bloat I mentioned. No matter what: There's nothing stopping you from the applying capabilities/ACL's in %post, and removing same (if necessary) in %postun and verifying that indeed the correct capabilities/ACL's are applied using %verifyscript. hth 73 de Jeff From zbyniu at geocarbon.pl Mon Feb 8 22:24:30 2010 From: zbyniu at geocarbon.pl (Zbyniu Krzystolik) Date: Mon, 8 Feb 2010 22:24:30 +0100 Subject: rpm: POSIX capabilities/ACLs? In-Reply-To: <20100206165635.GA5233@polanet.pl> References: <20100206091045.GA4627@polanet.pl> <20100206110407.GA15821@geocarbon.pl> <20100206165635.GA5233@polanet.pl> Message-ID: <20100208212430.GI9317@geocarbon.pl> Tomasz Pala napisa?(a): > On Sat, Feb 06, 2010 at 12:04:07 +0100, Zbyniu Krzystolik wrote: > > > My note may be interested for you (pl); libcap-ng utils can simplify it. > > http://zz.iapt.pl/bez_root2.txt > > That's similar to thing I want to do. The difference is you drop > capabilities, and I want to set some for regular users (either > designated - for daemons having it's own files and secrets, or nobody > for anything else, using start-stop-daemon --chuid). Like this: > > setcap cap_net_bind_service=ei =nc > execcap cap_net_bind_service=i su - gotar -c 'nc -l -p 34' Like this? :) http://zz.iapt.pl/bez_root.txt > but this obviously requires tagging binaries. The problem is tracking > all the xattrs (caps and ACLs). Yep. > Especially if I need to restrict some accounts (i.e. give some > permissions to normal accounts) more, than hardening daemons... I want it too. :) Zbyniu -- %% Absolutely nothing we trust %% From gotar at polanet.pl Tue Feb 9 12:52:36 2010 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 9 Feb 2010 12:52:36 +0100 Subject: rpm: POSIX capabilities/ACLs? In-Reply-To: <20100208212430.GI9317@geocarbon.pl> References: <20100206091045.GA4627@polanet.pl> <20100206110407.GA15821@geocarbon.pl> <20100206165635.GA5233@polanet.pl> <20100208212430.GI9317@geocarbon.pl> Message-ID: <20100209115236.GA23166@polanet.pl> On Mon, Feb 08, 2010 at 22:24:30 +0100, Zbyniu Krzystolik wrote: >> setcap cap_net_bind_service=ei =nc >> execcap cap_net_bind_service=i su - gotar -c 'nc -l -p 34' > > Like this? :) > http://zz.iapt.pl/bez_root.txt Yes, you already gave me this link and that's how I started on caps :) >> but this obviously requires tagging binaries. The problem is tracking >> all the xattrs (caps and ACLs). > > Yep. That's why I've asked about rpm - we could easilty extend SUIDs with fP(+fE?) so that end user could make his choice using securebits. http://lwn.net/Articles/280279/ http://lwn.net/Articles/368600/ In short: I'd like to disable entire SUID/SGID mechanism in my systems (SECURE_NO_SETUID_FIXUP+SECURE_KEEP_CAPS or entire SECURE_NOROOT maybe). -- Tomasz Pala From kamil.listy at klecza.pl Sun Feb 14 16:50:30 2010 From: kamil.listy at klecza.pl (Kamil Dziedzic) Date: Sun, 14 Feb 2010 16:50:30 +0100 Subject: skype.spec 64 bit Message-ID: <201002141650.31270.kamil.listy@klecza.pl> > $Log: skype.spec,v $ >+Revision 1.82 2010/01/22 16:30:34 glen >+- 64bit skype >+ It's not 64 bit. Binary is still 32 bit. -- Regards, Kamil Dziedzic From z at xatka.net Mon Feb 15 08:28:26 2010 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Mon, 15 Feb 2010 08:28:26 +0100 Subject: http://en.docs.pld-linux.org Message-ID: <20100215072826.GA5912@davabel.touk.pl> English documentation is no longer available, or it just moved to new location and noone updated domain entry / link on our website? -- Regards, Pawe? From pld.lists at grizz.pl Mon Feb 15 10:37:40 2010 From: pld.lists at grizz.pl (Witold Firlej) Date: Mon, 15 Feb 2010 10:37:40 +0100 Subject: http://en.docs.pld-linux.org In-Reply-To: <20100215072826.GA5912@davabel.touk.pl> References: <20100215072826.GA5912@davabel.touk.pl> Message-ID: 2010/2/15 Pawe? Zuzelski : > English documentation is no longer available, or it just moved to > new location and noone updated domain entry / link on our website? > http://www.pld-linux.org/Docs/man -- :: Witek Firlej :: Voiceless it cries, Wingless flutters, Toothless bites, Mouthless mutters. :: http://grizz.pl :: http://firlej.org :: jid: grizz//jabster.pl :: From z at xatka.net Mon Feb 15 11:00:40 2010 From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Mon, 15 Feb 2010 11:00:40 +0100 Subject: http://en.docs.pld-linux.org In-Reply-To: References: <20100215072826.GA5912@davabel.touk.pl> Message-ID: <20100215100040.GB5912@davabel.touk.pl> On Mon, 15 Feb 2010, Witold Firlej wrote: > 2010/2/15 Pawe? Zuzelski : > > English documentation is no longer available, or it just moved to > > new location and noone updated domain entry / link on our website? > > > > http://www.pld-linux.org/Docs/man Is it the same manual? Is it synchonized with http://svn.pld-linux.org/svn/PLD-doc/book ? -- Pawe? Zuzelski From arekm at maven.pl Mon Feb 15 16:10:12 2010 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 15 Feb 2010 16:10:12 +0100 Subject: Th: fixes needed / potrzebne poprawki Message-ID: <201002151610.13120.arekm@maven.pl> Here is a list of currently needed fixes in Th repository, feel free to fix any package and commit or send patches here. Oto lista aktualnie potrzebnych poprawek dla Th. Prosz? ?mia?o naprawia? paczki w postaci commita lub wys?ania ?atek tutaj. http://ep09.pld-linux.org/~pldth/main.txt -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From sparky at pld-linux.org Mon Feb 15 17:26:01 2010 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Mon, 15 Feb 2010 17:26:01 +0100 Subject: Th: fixes needed / potrzebne poprawki In-Reply-To: <201002151610.13120.arekm@maven.pl> References: <201002151610.13120.arekm@maven.pl> Message-ID: <20100215162601.GA3987@pld-linux.org> On Mon, Feb 15, 2010 at 04:10:12PM +0100, Arkadiusz Miskiewicz wrote: > > Here is a list of currently needed fixes in Th repository, feel free to fix > any package and commit or send patches here. > > Oto lista aktualnie potrzebnych poprawek dla Th. Prosz? ?mia?o naprawia? > paczki w postaci commita lub wys?ania ?atek tutaj. > > http://ep09.pld-linux.org/~pldth/main.txt error: seamonkey-1.1.17-2: req libjpeg.so.7 not found error: seamonkey-1.1.17-2: req libjpeg.so.7(LIBJPEG_7.0) not found to be removed from Th -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From glen at pld-linux.org Wed Feb 17 12:30:43 2010 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Wed, 17 Feb 2010 13:30:43 +0200 Subject: skype.spec 64 bit In-Reply-To: <201002141650.31270.kamil.listy@klecza.pl> References: <201002141650.31270.kamil.listy@klecza.pl> Message-ID: <201002171330.43377.glen@pld-linux.org> On Sunday 14 February 2010 17:50:30 Kamil Dziedzic wrote: > > $Log: skype.spec,v $ > >+Revision 1.82 2010/01/22 16:30:34 glen > >+- 64bit skype > >+ > > It's not 64 bit. Binary is still 32 bit. oh, my mistake, i was likely so excited that i did not even think to test as i installed package and it worked on my 64bit workstation (as i already had 32bit libs present) however, it's convinient to include it in 64bit repo, so poldek -u skype (or poldek --upgrade-dist) would work more smoothly. arekm (as th maintainer) -- what you think? for example there exists gcc-multilib somewhy, it could be also installed from th-i686 repo not included in th repo. i see some inconsistency otherwise. or is gcc*multilib packages any way different than same packages from th-i686 repo? -- glen From arekm at maven.pl Wed Feb 17 13:06:34 2010 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 17 Feb 2010 13:06:34 +0100 Subject: skype.spec 64 bit In-Reply-To: <201002171330.43377.glen@pld-linux.org> References: <201002141650.31270.kamil.listy@klecza.pl> <201002171330.43377.glen@pld-linux.org> Message-ID: <201002171306.34395.arekm@maven.pl> On Wednesday 17 of February 2010, Elan Ruusam?e wrote: > On Sunday 14 February 2010 17:50:30 Kamil Dziedzic wrote: > > > $Log: skype.spec,v $ > > > > > >+Revision 1.82 2010/01/22 16:30:34 glen > > >+- 64bit skype > > >+ > > > > It's not 64 bit. Binary is still 32 bit. > > oh, my mistake, i was likely so excited that i did not even think to test > as i installed package and it worked on my 64bit workstation (as i already > had 32bit libs present) > > however, it's convinient to include it in 64bit repo, so poldek -u skype > (or poldek --upgrade-dist) would work more smoothly. > > arekm (as th maintainer) -- what you think? Makes no sensie if it's a 32bit program that needs tons of 32bit libs. > or is gcc*multilib packages any way different than same packages from > th-i686 repo? different -> afaik yes but not much -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From adamg at pld-linux.org Thu Feb 18 23:21:25 2010 From: adamg at pld-linux.org (Adam Golebiowski) Date: Thu, 18 Feb 2010 23:21:25 +0100 Subject: empty dirs in packages/ Message-ID: <20100218222124.GA1894@agmk.net> Hi, ankry noticed several empty dirs in packages/. Most likely Somebody [tm] did `cvs add $dir' but forgot to add revelant spec files. So, in case any of the following entries ring a bell for you, please add spec files. Otherwise I'll remove them in a couple of days. - Performous/ - apache-mod_passenger/ - ario/ - axeos-sounds-extra/ - fonts-OTF-Aegan/ - fonts-TTF-CRULP-Nafees_Tahrer_Naskh/ - freeipa/ - haskell-dataenc/ - html5lib/ - nekovm/ - pdfmod/ - perl-Authen-Krb5/ - psyced/ - rpmrebuild/ -- adamg From sparky at pld-linux.org Fri Feb 19 01:44:55 2010 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Fri, 19 Feb 2010 01:44:55 +0100 Subject: empty dirs in packages/ In-Reply-To: <20100218222124.GA1894@agmk.net> References: <20100218222124.GA1894@agmk.net> Message-ID: <20100219004455.GA4175@pld-linux.org> On Thu, Feb 18, 2010 at 11:21:25PM +0100, Adam Golebiowski wrote: > Hi, > > ankry noticed several empty dirs in packages/. Most likely Somebody [tm] did > `cvs add $dir' but forgot to add revelant spec files. So, in case any of > the following entries ring a bell for you, please add spec files. > Otherwise I'll remove them in a couple of days. Readding a dir isn't a problem, so just remove them. Plus someone could write a simple script run in cvs' cron, it would remove any empty dirs older than 24 hours (additional info sent to cvs commits list would be nice). -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From jajcus at jajcus.net Fri Feb 19 08:24:16 2010 From: jajcus at jajcus.net (Jacek Konieczny) Date: Fri, 19 Feb 2010 08:24:16 +0100 Subject: empty dirs in packages/ In-Reply-To: <20100218222124.GA1894@agmk.net> References: <20100218222124.GA1894@agmk.net> Message-ID: <20100219072416.GB15198@jajo.eggsoft> On Thu, Feb 18, 2010 at 11:21:25PM +0100, Adam Golebiowski wrote: > ankry noticed several empty dirs in packages/. Most likely Somebody [tm] did > `cvs add $dir' but forgot to add revelant spec files. Or, rather, added a package with wrong name, then noticed and fixed the mistake. Unfortunately CVS is too stupid? and keeps the wrong directory. Two directories from your list are results of such mistakes. And there is even no commit log for directories? Why the hell do we still use such a broken tool? Greets, Jacek From arekm at maven.pl Fri Feb 19 08:33:21 2010 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Fri, 19 Feb 2010 08:33:21 +0100 Subject: empty dirs in packages/ In-Reply-To: <20100219072416.GB15198@jajo.eggsoft> References: <20100218222124.GA1894@agmk.net> <20100219072416.GB15198@jajo.eggsoft> Message-ID: <201002190833.21494.arekm@maven.pl> On Friday 19 of February 2010, Jacek Konieczny wrote: > And there is even no commit log for directories? Why the hell do we > still use such a broken tool? Lack of migration choice, migration procedure, migration tools, updating our tools that use cvs and person to do all of that. > Greets, > Jacek -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From freetz at gmx.net Sun Feb 21 18:36:18 2010 From: freetz at gmx.net (Fryderyk Dziarmagowski) Date: Sun, 21 Feb 2010 18:36:18 +0100 Subject: packages: autoconf/autoconf.spec - lzma command is not compatible with xz f... In-Reply-To: References: Message-ID: <20100221183618.c5c8ca68.freetz@gmx.net> On Sun, 21 Feb 2010 17:38:00 +0100 sparky wrote: > Author: sparky Date: Sun Feb 21 16:38:00 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - lzma command is not compatible with xz format, changed lzma -> xz > > ---- Files affected: > packages/autoconf: > autoconf.spec (1.143 -> 1.144) > > ---- Diffs: > > ================================================================ > Index: packages/autoconf/autoconf.spec > diff -u packages/autoconf/autoconf.spec:1.143 packages/autoconf/autoconf.spec:1.144 > --- packages/autoconf/autoconf.spec:1.143 Sun Feb 21 17:30:06 2010 > +++ packages/autoconf/autoconf.spec Sun Feb 21 17:37:54 2010 > @@ -198,7 +198,7 @@ > > %prep > %setup -q -c -T > -lzma -dc %{SOURCE0} | tar xf - -C .. > +xz -dc %{SOURCE0} | tar xf - -C .. tar already got xz support, %setup alone will do the job -- Fryderyk Dziarmagowski From sparky at pld-linux.org Wed Feb 24 15:29:28 2010 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Wed, 24 Feb 2010 15:29:28 +0100 Subject: packages: jasper/jasper.spec - bumped OpenGL-glut version to 4.0 (3.7 does ... In-Reply-To: References: Message-ID: <20100224142928.GA5706@pld-linux.org> On Wed, Feb 24, 2010 at 03:10:48PM +0100, sparky wrote: > Author: sparky Date: Wed Feb 24 14:10:48 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - bumped OpenGL-glut version to 4.0 (3.7 does not have glutInit) I was wrong! Our glut.spec does not link correctly. Will fix that soon and also revise my OpenGL-glut changes. -- ____ Sparky{PI] -- Przemyslaw _ ___ _ _ ........... LANG...Pl..Ca..Es..En /____) ___ ___ _ _ || Iskra | | _ \| | | : WWW........ppcrcd.pld-linux.org \____\| -_)'___| ||^'||//\\// < | _/| | | : JID......sparkyjabberes.org (____/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mail....sparkypld-linux.org From glen at pld-linux.org Thu Feb 25 15:28:28 2010 From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Thu, 25 Feb 2010 16:28:28 +0200 Subject: packages: geninitrd/geninitrd.spec - force sync scan for scsi_mod in Titani... In-Reply-To: References: Message-ID: <201002251628.28671.glen@pld-linux.org> On Thursday 25 February 2010 15:19:02 hawk wrote: > $Log$ > +Revision 2.163 2010/02/25 13:18:56 hawk > +- force sync scan for scsi_mod in Titanium instead of using hack why this fix is not ok for other distros like th? -- glen From hawk at limanowa.net Thu Feb 25 15:42:52 2010 From: hawk at limanowa.net (Marcin Krol) Date: Thu, 25 Feb 2010 15:42:52 +0100 Subject: packages: geninitrd/geninitrd.spec - force sync scan for scsi_mod in Titani... In-Reply-To: <201002251628.28671.glen@pld-linux.org> References: <201002251628.28671.glen@pld-linux.org> Message-ID: <4B868C6C.9000206@limanowa.net> >> $Log$ >> +Revision 2.163 2010/02/25 13:18:56 hawk >> +- force sync scan for scsi_mod in Titanium instead of using hack > > why this fix is not ok for other distros like th? It completly disables scsi async scan at bootup which is enabled in all our kernels. Thus by including this fix in all distro lines we could as well drop it and disable async scanning directly in kernels. Not my decision so I've put it only for Titanium. M. From baggins at sith.mimuw.edu.pl Sat Feb 27 01:38:31 2010 From: baggins at sith.mimuw.edu.pl (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sat, 27 Feb 2010 01:38:31 +0100 Subject: cvs mv/cp? Message-ID: <20100227003831.GA4128@sith.mimuw.edu.pl> Hi, I'm going to clean up ruby packages, and as it involves a lot of renames, I wonder what is out current policy on 'cvs mv'. Are we still playing with server-side copy and client side remove? I'd much prefer to just 'mv' thing server side, like this: mv old-package-name new-package-name mv old-package-name/old-package-name.spec,v new-package-name/new-package-name.spec,v anyone against? -- Jan R?korajski | ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio From udvzsolt at gmail.com Sat Feb 27 19:52:49 2010 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Sat, 27 Feb 2010 19:52:49 +0100 Subject: cvs mv/cp? In-Reply-To: <20100227003831.GA4128@sith.mimuw.edu.pl> References: <20100227003831.GA4128@sith.mimuw.edu.pl> Message-ID: <760ece281002271052n6d45b0b3mf0ac4424ecda37b4@mail.gmail.com> Doesn't need "Provides: ruby-Package" into "ruby-package.spec"? Why? Because of many other package, that have ruby-Package BRs and Rs. Zsolt 2010/2/27 Jan R?korajski : > Hi, > I'm going to clean up ruby packages, and as it involves a lot of renames, > I wonder what is out current policy on 'cvs mv'. > > Are we still playing with server-side copy and client side remove? > > I'd much prefer to just 'mv' thing server side, like this: > mv old-package-name new-package-name > mv old-package-name/old-package-name.spec,v new-package-name/new-package-name.spec,v > > anyone against? > > -- > Jan R?korajski ? ? ? ? ? ?| ?ALL SUSPECTS ARE GUILTY. PERIOD! > bagginsmimuw.edu.pl ? | ?OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? > BOFH, MANIAC ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? -- TROOPS by Kevin Rubio > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > From baggins at sith.mimuw.edu.pl Sat Feb 27 20:22:28 2010 From: baggins at sith.mimuw.edu.pl (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sat, 27 Feb 2010 20:22:28 +0100 Subject: cvs mv/cp? In-Reply-To: <760ece281002271052n6d45b0b3mf0ac4424ecda37b4@mail.gmail.com> References: <20100227003831.GA4128@sith.mimuw.edu.pl> <760ece281002271052n6d45b0b3mf0ac4424ecda37b4@mail.gmail.com> Message-ID: <20100227192228.GA8406@sith.mimuw.edu.pl> On Sat, 27 Feb 2010, Zsolt Udvari wrote: > Doesn't need "Provides: ruby-Package" into "ruby-package.spec"? Why? > Because of many other package, that have ruby-Package BRs and Rs. I added Provides tag, couldn't get myself to look for all packages that have R:old-name ;) -- Jan R?korajski | ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio From glen at pld-linux.org Sun Feb 28 03:37:25 2010 From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=) Date: Sun, 28 Feb 2010 04:37:25 +0200 Subject: cvs mv/cp? In-Reply-To: <20100227003831.GA4128@sith.mimuw.edu.pl> References: <20100227003831.GA4128@sith.mimuw.edu.pl> Message-ID: <201002280437.25859.glen@pld-linux.org> On Saturday 27 February 2010 02:38:31 Jan R?korajski wrote: > I'd much prefer to just 'mv' thing server side, like this: > mv old-package-name new-package-name > mv old-package-name/old-package-name.spec,v > new-package-name/new-package-name.spec,v > > anyone against? so far, if the package is small, and not much tags on it, mv is fine by my opinion (i.e you do not need to rebuild using some old tag) -- glen