Re: Unclear Firefox situation
Dnia 19-09-2007, Śr o godzinie 22:22 +0200, Rafał Cygnarowski napisał(a): quotation If an individual or organization is creating a Community Edition of Mozilla Firefox or Thunderbird, it must use the names Firefox Community Edition or Thunderbird Community Edition to identify this software. These names may be further qualified to identify the software (e.g. Firefox Community Edition, French, Thunderbird Community Edition, Joe's optimized AMD Opteron build, etc.). Localizers may also translate the words Community Edition. /quotation So... Mozilla Firefox should be called just Firefox... isn't it true? Ehm -- and not 'Fierefox Community Edition' ?? [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Unclear Firefox situation
I think Debian does allow it, but I don't even remember those package names. BTW: iceweasel.spec contains obsolete version of package, with well known security bugs. Those Debian patches seems to simply replace logos and some texts in source. After removing debian specific chunks from patches it would be simple cp of current specs + one more patch + replacing software names in specs. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
BR-s and R-s policy
Patrys asked me to up evolution spec to 1.12 (corresponding with GNOME 2.20) and I've spotted, that during the GNOME packages update all the BR-s and R-s of gnome packages were upped to 2.20 line. The question is -- Is this necessary? I mean I've looked into evolution's configure.in and it seems it doesn't need half the newest packages that are listed in BR-s and R-s in evolution.spec (like it needs GConf2 = 2.0.0, not newest, shiniest 2.19). So is this some kind of policy, to require newest packages possible at the time of upping spec? [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
So is this some kind of policy, to require newest packages possible at the time of upping spec? It seems so. Its stupid IMO to bump version to highest possible ignoring real requirements. For example many specs from HEAD are building perfectly on Ac after dropping unecessary version requirements. In Ac case it leads to creating and maintaining unecessary Ac branch. But well, most of developers says thats good idea. I remember some discussion about it but unfortunatelly I don't remember any arguments why it is good solution to bump version everytime something gets updated. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
It's used to ensure that there are latest packages on the builders. That's the only reason I know. I always thought its RM job to maintain builders. But what do I know... :) M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
On Thursday 20 of September 2007, Marcin Król wrote: It's used to ensure that there are latest packages on the builders. That's the only reason I know. I always thought its RM job to maintain builders. But what do I know... :) Not only RM has rights to send packages to builders. M. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Unclear Firefox situation
Dnia czwartek, 20 września 2007, Cezary Krzyzanowski napisał: Dnia 19-09-2007, Śr o godzinie 22:22 +0200, Rafał Cygnarowski napisał(a): quotation If an individual or organization is creating a Community Edition of Mozilla Firefox or Thunderbird, it must use the names Firefox Community Edition or Thunderbird Community Edition to identify this software. These names may be further qualified to identify the software (e.g. Firefox Community Edition, French, Thunderbird Community Edition, Joe's optimized AMD Opteron build, etc.). Localizers may also translate the words Community Edition. /quotation So... Mozilla Firefox should be called just Firefox... isn't it true? Ehm -- and not 'Fierefox Community Edition' ?? Yes, I just shorted MFCE and FCE to MF and F... But it seems like Bon Echo name is illegal(?) int this case and we should use Firefox. Regards, -- Rafał Cygnarowski [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
Dnia 20-09-2007, Cz o godzinie 08:57 +0200, Arkadiusz Miskiewicz napisał(a): On Thursday 20 of September 2007, Marcin Król wrote: So is this some kind of policy, to require newest packages possible at the time of upping spec? It seems so. Its stupid IMO to bump version to highest possible ignoring real requirements. It's used to ensure that there are latest packages on the builders. That's the only reason I know. Ehm -- but wouldn't that be achieved just by installing packages on build? Every package needs to be build anyway, so it would be just logical to install it then. [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
Not only RM has rights to send packages to builders. I don't get it. If someone will send some package it will be automagically upgraded on builders. If such upgrade will fail on deps I'll usually know about it quite soon and will have to fix it manually anyway. If someone will send something that I'll reject from moving to main tree I'll have to downgrade it manually too. The only good thing from bumping version I see is that when upgrade on builders will fail user will be unable to build dependant stuff till I'll fix it. I had such situation only once since RMing Ra and Ac and it was piece of cake to fix (manual poldek upgra, rel++, stbr). I still don't see any advantage in bumping those versions. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
On Thursday 20 of September 2007, Marcin Król wrote: The only good thing from bumping version I see is that when upgrade on builders will fail user will be unable to build dependant stuff till I'll fix it. It happens from time to time and this is exactly the problem I was referring to. (and user can fix the problem himself and resend) M. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
The only good thing from bumping version I see is that when upgrade on builders will fail user will be unable to build dependant stuff till I'll fix it. It happens from time to time and this is exactly the problem I was referring to. (and user can fix the problem himself and resend) Correct me if I'm wrong, but users don't have access to send commands to builders (at least for Ac). How they're supposed to say builder to perform upgrade which has failed on dependencies? They are usually sending mails about failed upgrades and then RM has to fix problem manually. So fixing will look exactly the same way without dependecies. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
On Thu, Sep 20, 2007 at 08:33:09AM +0200, Cezary Krzyzanowski wrote: Patrys asked me to up evolution spec to 1.12 (corresponding with GNOME 2.20) and I've spotted, that during the GNOME packages update all the BR-s and R-s of gnome packages were upped to 2.20 line. The question is -- Is this necessary? I mean I've looked into evolution's configure.in and it seems it doesn't need half the newest packages that are listed in BR-s and R-s in evolution.spec (like it needs GConf2 = 2.0.0, not newest, shiniest 2.19). Bumping always to currently latest version is not necessary and sometimes annoying. But specifying versions of packages from the same GNOME release just in packages belonging to the same GNOME release (and similarly for KDE/XFCE/etc.) to get consistent package set is fine. It seems that at least some GNOME packages are not tested with older dependent packages and need some newer in fact. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
On Thursday 20 of September 2007, Marcin Król wrote: The only good thing from bumping version I see is that when upgrade on builders will fail user will be unable to build dependant stuff till I'll fix it. It happens from time to time and this is exactly the problem I was referring to. (and user can fix the problem himself and resend) Correct me if I'm wrong, but users don't have access to send commands to builders (at least for Ac). How they're supposed to say builder to perform upgrade which has failed on dependencies? They are usually sending mails about failed upgrades and then RM has to fix problem manually. So fixing will look exactly the same way without dependecies. User sends request for: libcrap, few seconds later for appX appY. libcrap installes fine on i386 but not i686. appX and appY on i386 rebuilds fine with new libcrap and with old libcrap on i686. Whoops. M. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
User sends request for: libcrap, few seconds later for appX appY. libcrap installes fine on i386 but not i686. appX and appY on i386 rebuilds fine with new libcrap and with old libcrap on i686. Whoops. True, but only difference is that RM will have to delete appX and appY for i686 and user or RM will need to resend it using auto- tag. I'd prefer to have correct version deps and fix such issues myself than doesn't have that issues but have to create and maintain additional branches where they aren't needed. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
On Thu, 20 Sep 2007, Jakub Bogusz wrote: On Thu, Sep 20, 2007 at 08:33:09AM +0200, Cezary Krzyzanowski wrote: Patrys asked me to up evolution spec to 1.12 (corresponding with GNOME 2.20) and I've spotted, that during the GNOME packages update all the BR-s and R-s of gnome packages were upped to 2.20 line. The question is -- Is this necessary? I mean I've looked into evolution's configure.in and it seems it doesn't need half the newest packages that are listed in BR-s and R-s in evolution.spec (like it needs GConf2 = 2.0.0, not newest, shiniest 2.19). Bumping always to currently latest version is not necessary and sometimes annoying. But specifying versions of packages from the same GNOME release just in packages belonging to the same GNOME release (and similarly for KDE/XFCE/etc.) to get consistent package set is fine. It seems that at least some GNOME packages are not tested with older dependent packages and need some newer in fact. That's exactly the reason. There were problems in the past with packages from different GNOME releases that did compile but didn't work. The current always latest BR in GNOME it's to ensure the entire environment is consistent. Janek -- Jan Rekorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
On Thursday 20 of September 2007, Marcin Król wrote: User sends request for: libcrap, few seconds later for appX appY. libcrap installes fine on i386 but not i686. appX and appY on i386 rebuilds fine with new libcrap and with old libcrap on i686. Whoops. True, but only difference is that RM will have to delete appX and appY for i686 and user or RM will need to resend it using auto- tag. I'd prefer to have correct version deps and fix such issues myself than doesn't have that issues but have to create and maintain additional branches where they aren't needed. While rising BR makes no need for any manual action on RM side and can be fixed immediately by user ;) M. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
On Thursday 20 September 2007 13:57:50 Arkadiusz Miskiewicz wrote: On Thursday 20 of September 2007, Marcin Król wrote: User sends request for: libcrap, few seconds later for appX appY. libcrap installes fine on i386 but not i686. appX and appY on i386 rebuilds fine with new libcrap and with old libcrap on i686. Whoops. True, but only difference is that RM will have to delete appX and appY for i686 and user or RM will need to resend it using auto- tag. I'd prefer to have correct version deps and fix such issues myself than doesn't have that issues but have to create and maintain additional branches where they aren't needed. While rising BR makes no need for any manual action on RM side and can be fixed immediately by user ;) one can trash specs in place called SPECS/test.spec:RPM [1] and send that one to builders. [1] http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/Attic/test.spec?only_with_tag=RPM -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
On Thu, 20 Sep 2007, Marcin Król wrote: So is this some kind of policy, to require newest packages possible at the time of upping spec? It seems so. no, it's not. It was done sometimes for things like KDE, gnome, etc to force the updates and ensure that libraries will be upgraded. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- 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.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
