Re: [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?
Here are some wiki page to read about mentoring process: http://mageia.org/wiki/doku.php?id=packagings[]=mentor#packagers_organization http://mageia.org/wiki/doku.php?id=packagings[]=mentor#resources http://mageia.org/wiki/doku.php?id=packages_mentoring and http://mageia.org/wiki/doku.php?id=packager_start OK, thanks, je vais lire cela. You can apply here on -dev ML looking for a mentor Can I assume I just did that, or should I state Hey, I am looking for a mentor!? Also we have weekly meeting on IRC you can attend if you are around Uh, I suppose so. I never liked IRC in my whole life. Welcome on board (or in hell as you want) Everything is hell nowadays. Thx, R-C
Re: [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?
2011/6/22 Radu-Cristian FOTESCU beranger...@yahoo.ca Here are some wiki page to read about mentoring process: http://mageia.org/wiki/doku.php?id=packagings[]=mentor#packagers_organization http://mageia.org/wiki/doku.php?id=packagings[]=mentor#resources http://mageia.org/wiki/doku.php?id=packages_mentoring and http://mageia.org/wiki/doku.php?id=packager_start OK, thanks, je vais lire cela. You can apply here on -dev ML looking for a mentor Can I assume I just did that, or should I state Hey, I am looking for a mentor!? We can assume it I guess :) Just shout it again during tonight's meeting Also we have weekly meeting on IRC you can attend if you are around Uh, I suppose so. I never liked IRC in my whole life. Welcome on board (or in hell as you want) Everything is hell nowadays. Thx, R-C -- Anne http://www.mageia.org
Re: [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?
(ii) myself be accepted as a contributor / package maintainer for Mandriva? Mageia i guess :p OMFG. (Although, to be frank, MDV's story is a sad one. Now whatever is important seems to need to be done by Dodonov, and mdv 2011's release is sliding, and sliding, and sliding... so much that there is a risk that Mageia 2 is released and Mandriva 2011 is still not ready!) Welcome aboard, i do hope you can enjoy our open community :) Thanks, Angelo! R-C
Re: [Mageia-dev] How can I propose new packages and my involvement, i.e. maintaining them?
On Wed, Jun 22, 2011 at 3:17 PM, Radu-Cristian FOTESCU beranger...@yahoo.ca wrote: (ii) myself be accepted as a contributor / package maintainer for Mandriva? Mageia i guess :p OMFG. (Although, to be frank, MDV's story is a sad one. Now whatever is important seems to need to be done by Dodonov, and mdv 2011's release is sliding, and sliding, and sliding... so much that there is a risk that Mageia 2 is released and Mandriva 2011 is still not ready!) Welcome aboard, i do hope you can enjoy our open community :) Thanks, Angelo! R-C Hi, also from me a welcome on board. If you are looking for a mentor don't hesitate. If you aren't able to find one tell me or andre999 and we try to help you out with that. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
[Mageia-dev] gcc compiler error
hi, I have a compiler error in cauldron build system building scourge, which does not happen in my system (Mageia 1 i586). constants.cpp:749:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.mageia.org/ for instructions. I suppose it is a bug in gcc 4.6 . Should I fill a normal bug to mageia? http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110622075842.philippem.valstar.30809/log/botcmd.1308730266.ecosse.log
[Mageia-dev] libproxy vs biarch libexecdir
hi,
I'm trying to make sense of libproxy packaging. It consists of a regular
library and several modules. Currently, the library follows policy but the
module packages are named libproxy-foo, so they have the same name on x86
and x86-64:
i586x86-64 description
==
libproxy1 lib64proxy1 main library
libproxy-gnome libproxy-gnome gnome proxy config support
libproxy-webkit libproxy-webkit webkit pacrunner (?)
etc.
- modules are in /usr/lib(64)/libproxy/%{version}/modules/
- libproxy-gnome also has a binary /usr/lib(64)/pxgconf (in 0.4.6 for
gnome2) or /usr/lib(64)/pxgsettings (in 0.4.7 for gnome3).
This looks wrong because:
- on a biarch system, it is not possible to have e.g. gnome3 settings
support for both archs
- the helper app (?) pxgsettings is put in libexecdir by upstream, so
IMHO it should be in /usr/lib or /usr/libexec, not %{_libdir} which
%{_libexecdir} expands to.
The specfile I have locally changes this to:
i586x86-64 change
libproxy1 lib64proxy1 same
libproxy-gnome lib64proxy-gnomebiarch support
libproxy-webkit lib64proxy-webkit biarch support
libproxy-gxsettings libproxy-gxsettings new pkg
etc.
What should dependencies on these modules look like:
Requires: %mklibname proxy-gnome ?
Christiaan
Re: [Mageia-dev] gcc compiler error
I think gcc 4.6 hasn't landed yet. 2011/6/22 Listes (José Jorge) lists.jjo...@free.fr: hi, I have a compiler error in cauldron build system building scourge, which does not happen in my system (Mageia 1 i586). constants.cpp:749:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.mageia.org/ for instructions. I suppose it is a bug in gcc 4.6 . Should I fill a normal bug to mageia? http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110622075842.philippem.valstar.30809/log/botcmd.1308730266.ecosse.log
Re: [Mageia-dev] libproxy vs biarch libexecdir
2011/6/22 Christiaan Welvaart c...@daneel.dyndns.org:
- the helper app (?) pxgsettings is put in libexecdir by upstream, so
IMHO it should be in /usr/lib or /usr/libexec, not %{_libdir} which
%{_libexecdir} expands to.
%_libexecdir expands to %_libdir, for years since mandrake.
Re: [Mageia-dev] Firefox 5
Am 16.06.2011 17:14, schrieb Sander Lepik: 16.06.2011 17:18, Daniel Kreuter kirjutas: Ok Mozilla has the RC1 released. Final shall come on Tuesday 21st June so yeah we will include that in Mageia 2 I think (as least this one, maybe FF6 or 7 depending on which version will be available i think) Well, it's quite possible that we have to include that in Mageia 1 as well, as this will be security update for Firefox 4. If we don't want to patch every CVE then we have to include it into Mageia 1 as well.. -- Sander Would be nice to know, if this is planned? I have rebuild FF5 here locally for Mageia 1, and the only addons that i lost is Linkification, but that is merely due to it's developers who already messed up with FF4. They don't offer the proper update on Firefox Addons site. So, please, what about Firefox 5 for Mageia 1 as an update (backport?)
[Mageia-dev] Update of mesa to git version
I also disable the mesa glut build in the same change since (if i'm not wrong) we're supposed to move to freeglut instead. Thierry Vignaud is certainly the one that is aware about freeglut versus GLUT ! He is the one that may say if you are right or wrong to do so now ! Beware of the fact that freeglut is not a buildrequire nor a require for some rpms (their spec file need to be modified and they need to be rebuilt with freeglut instead of mesaglut) (the list is extracted from https://qa.mandriva.com/show_bug.cgi?id=47090 ... some rpms have not been yet imported) 3ddesktop 3dfb asteroids3D asymptote bullet-demo crack-attack cultivation enblend flightgear foobillard gl-117 glean glui-demos glxinfo gpac hugin jasper jasper kiki libmgl-glut5 libtiff-progs mesa-demos ocaml-glmlite ocaml-lablgl perl-OpenGL pfstools pymol qepcad ruby-rbogl smalltalk stormbaancoureur supertuxkart tesseracttrainer torcs torcs-robots-base tux_aqfh vegastrike wiiuse yabause-gtk yabause-qt
Re: [Mageia-dev] Update of mesa to git version
On 22 June 2011 19:54, Philippe DIDIER philippedid...@laposte.net wrote: I also disable the mesa glut build in the same change since (if i'm not wrong) we're supposed to move to freeglut instead. Thierry Vignaud is certainly the one that is aware about freeglut versus GLUT ! He is the one that may say if you are right or wrong to do so now ! Other distros (eg: fedora) have done the switch long time ago. Both projects are more or less dead (which is somewhat expected for projects implementing an API dead for a decade) FC has patches for the examples for killing warnings though. We would need to test GLUT a little bit As for gallium, I'm regularly testing r300 from git but I'ven't tested neither r600 nor nouveau (though my experience with nouveau on FC is that it regress quite a lot and is heavily dependant on the kernel/libdrm/mesa triplet). r300g is alreay the default in incoming mesa-7.11 (I think this was already the case on 7.10). r600g will be the default in 7.12 No bugs are accepted on r300c anymore (don't remember for r600c) As for nouveau, well we've no alternatives. As for swrast, the LLVM gallium driver is said to be faster but I'ven't tested it. Beware of the fact that freeglut is not a buildrequire nor a require for some rpms (their spec file need to be modified and they need to be rebuilt with freeglut instead of mesaglut) Indeed
Re: [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2
On Wed, 22 Jun 2011, Florian Hubold wrote: Am 22.06.2011 07:40, schrieb Ahmad Samir: On 20 June 2011 11:24, Thierry Vignaudthierry.vign...@gmail.com wrote: On 7 June 2011 16:10, Mageia Teambuildsystem-dae...@mageia.org wrote: dmorgandmorgan 3.6.1-3.mga1: + Revision: 101519 - Provide devel subpackage ( partial merge of mdv commit 659516) As always, when one moves files between subpackages or to a new subpackage, conflicts tags should be added in order to ensure urpmi will put both packages in the same transaction: Installation failed: file /usr/include/valgrind/memcheck.h from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 file /usr/lib64/pkgconfig/valgrind.pc from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 Done. Minor nitpick: BuildRequires for xulrunner were changed after the split, for firefox5 not. Is there any special reason for this? Just wondering ... Because the devel files are now in valgrind-devel.
[Mageia-dev] Tonight's meeting
Very late mail but here are the topics for tonight's meeting on #mageia-dev at 19h UTC - quick reminder about current brainstorms: release cycle, specs - incoming ARM port - review on secteam current work - reminder on QA needs - review on mentoring process Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] Update of mesa to git version
Philippe DIDIER a écrit : I also disable the mesa glut build in the same change since (if i'm not wrong) we're supposed to move to freeglut instead. Thierry Vignaud is certainly the one that is aware about freeglut versus GLUT ! He is the one that may say if you are right or wrong to do so now ! Beware of the fact that freeglut is not a buildrequire nor a require for some rpms (their spec file need to be modified and they need to be rebuilt with freeglut instead of mesaglut) (the list is extracted from https://qa.mandriva.com/show_bug.cgi?id=47090 ... some rpms have not been yet imported) 3ddesktop 3dfb asteroids3D asymptote bullet-demo crack-attack cultivation enblend flightgear foobillard gl-117 glean glui-demos glxinfo gpac hugin jasper jasper kiki libmgl-glut5 libtiff-progs mesa-demos ocaml-glmlite ocaml-lablgl perl-OpenGL pfstools pymol qepcad ruby-rbogl smalltalk stormbaancoureur supertuxkart tesseracttrainer torcs torcs-robots-base tux_aqfh vegastrike wiiuse yabause-gtk yabause-qt Just a question ... what would happen if freeglut has a provides glut ? If neither were installed, wouldn't one be given the option ? (as long as both are available in the repos) (as one sees often enough when installing packages) And if both glut and freeglut were installed, and glut were subsequently uninstalled, would packages requiring glut continue to work ? -- André
Re: [Mageia-dev] Update of mesa to git version
On Wed, 22 Jun 2011, andre999 wrote: Philippe DIDIER a écrit : I also disable the mesa glut build in the same change since (if i'm not wrong) we're supposed to move to freeglut instead. Thierry Vignaud is certainly the one that is aware about freeglut versus GLUT ! He is the one that may say if you are right or wrong to do so now ! Beware of the fact that freeglut is not a buildrequire nor a require for some rpms (their spec file need to be modified and they need to be rebuilt with freeglut instead of mesaglut) Just a question ... what would happen if freeglut has a provides glut ? If neither were installed, wouldn't one be given the option ? (as long as both are available in the repos) (as one sees often enough when installing packages) And if both glut and freeglut were installed, and glut were subsequently uninstalled, would packages requiring glut continue to work ? Freeglut (libfreeglut3) can already replace mesaglut (libmesaglut3). Christiaan
Re: [Mageia-dev] [RPM] cauldron core/release valgrind-3.6.1-3.mga2
On 22 June 2011 20:18, nicolas vigier bo...@mars-attacks.org wrote: On Wed, 22 Jun 2011, Florian Hubold wrote: Am 22.06.2011 07:40, schrieb Ahmad Samir: On 20 June 2011 11:24, Thierry Vignaudthierry.vign...@gmail.com wrote: On 7 June 2011 16:10, Mageia Teambuildsystem-dae...@mageia.org wrote: dmorgandmorgan 3.6.1-3.mga1: + Revision: 101519 - Provide devel subpackage ( partial merge of mdv commit 659516) As always, when one moves files between subpackages or to a new subpackage, conflicts tags should be added in order to ensure urpmi will put both packages in the same transaction: Installation failed: file /usr/include/valgrind/memcheck.h from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 file /usr/lib64/pkgconfig/valgrind.pc from install of valgrind-devel-3.6.1-3.mga2.x86_64 conflicts with file from package valgrind-3.6.0-2.mga1.x86_64 Done. Minor nitpick: BuildRequires for xulrunner were changed after the split, for firefox5 not. Is there any special reason for this? Just wondering ... Because the devel files are now in valgrind-devel. Yeah, there're two types of BR here, just 'valgrind' if the build requires only the binary (/usr/bin/valgrind) and valgrind-devel if the build requires the valgrind header files; AFAICS for firefox, it doesn't require the valgrind headers (i.e. I don't see any checks for the headers failing in the build log). -- Ahmad Samir
[Mageia-dev] Update of mesa to git version
/ And if both glut and freeglut were installed,/ Libfreeglut3.rpm and libmesaglut3.rpm can't be installed side by side : they install the same link glut.so.3 to glut.so.3.9.0 for the first or glut.so.3.7.0 for the second... fortunately libfreeglut3.rpm obsoletes libmesaglut3.rpm Libfreeglut-devel depends on libfreeglut3 ... there may not be any conflict if libfreeglut3.rpm is choosen libfreeglut-devel allows to build everything when it is substituted to libmesaglut-devel : it adds in /usr/include/GL : 1) glut.h which gives a link to freeglut_std.h (which is compatible with GLUT headers and program written for GLUT) 2) freeglut.h which gives a link to freeglut_std.h _and_ to freeglut_ext.h (which adds access to more functions : scroll button, joystick etc..) and allows to build programs needing strictly freeglut (written for it) In the spec files of programs needing GLUT now, freeglut-devel must be substituted to mesaglut-devel in BUILDREQUIRES if it is used ! (and libfreeglut3 to libmesglut3 in REQUIRES ...)
Re: [Mageia-dev] get-skype package for submission
Maybe more something like task-mageia-packaging? That sounds better :) It depend on what you want to put inside i believe, if only rpm stuff... then yes :) -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] [RPM] cauldron tainted/release transcode-1.1.5-5.mga2.tainted
On Wed, 22 Jun 2011 22:28:18 +0200 (CEST), Mageia Team wrote about [RPM] cauldron tainted/release transcode-1.1.5-5.mga2.tainted: Name: transcodeRelocations: (not relocatable) Version : 1.1.5 Vendor: Mageia.Org Release : 5.mga2.taintedBuild Date: Wed Jun 22 This package is in PLF as it could violate some patents. obgr_seneca obgr_seneca 1.1.5-5.mga2: + Revision: 112501 - added tainted to spec file Really in plf ? Or only in tainted repo? Thanks BFN, =Dick Gevers=
[Mageia-dev] Minimal patching vs. fixing the whole Universe
I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something. By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_. See comments 50 and downwards: https://bugs.mageia.org/show_bug.cgi?id=1659#c50 calibre-python2-env-fix.patch replaces '/usr/bin/env python2' with '/usr/bin/env python' The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default. Ahmad insists that '/usr/bin/python' should be used in Mageia. As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages! A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. Should Mageia try to fix something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works? You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. Perfect policies that would require the revision of hundreds of packages that actually work are not my cup of tea. Of course, I am _not_ a Mageia packager and this is not my package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to improve upstream's work, this can prove to be catastrophic in complex cases. Thank you, R-C aka beranger
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
2011/6/22 Radu-Cristian FOTESCU beranger...@yahoo.ca: I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something. By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_. See comments 50 and downwards: https://bugs.mageia.org/show_bug.cgi?id=1659#c50 calibre-python2-env-fix.patch replaces '/usr/bin/env python2' with '/usr/bin/env python' The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default. Ahmad insists that '/usr/bin/python' should be used in Mageia. As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages! A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. Should Mageia try to fix something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works? You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. Perfect policies that would require the revision of hundreds of packages that actually work are not my cup of tea. Of course, I am _not_ a Mageia packager and this is not my package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to improve upstream's work, this can prove to be catastrophic in complex cases. We don't have any python2 symlink or binary on mageia.
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
We don't have any python2 symlink or binary on mageia. That was not the question. The question was whether '/usr/bin/env python2' should be patched into '/usr/bin/env python' or into '/usr/bin/python'. The more general question was whether all the upstream packages should be optimized. When the upstream contained '/usr/bin/env python', nobody thought to fix it into '/usr/bin/python'. R-C aka beranger
Re: [Mageia-dev] [RPM] cauldron tainted/release transcode-1.1.5-5.mga2.tainted
Dick Gevers dvgev...@xs4all.nl schrieb am 22.06.2011 On Wed, 22 Jun 2011 22:28:18 +0200 (CEST), Mageia Team wrote about [RPM] cauldron tainted/release transcode-1.1.5-5.mga2.tainted: Name: transcodeRelocations: (not relocatable) Version : 1.1.5 Vendor: Mageia.Org Release : 5.mga2.tainted Build Date: Wed Jun 22 This package is in PLF as it could violate some patents. obgr_seneca obgr_seneca 1.1.5-5.mga2: + Revision: 112501 - added tainted to spec file Really in plf ? Or only in tainted repo? Oups!
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
On 22 June 2011 22:47, Radu-Cristian FOTESCU beranger...@yahoo.ca wrote: I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something. By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_. See comments 50 and downwards: https://bugs.mageia.org/show_bug.cgi?id=1659#c50 calibre-python2-env-fix.patch replaces '/usr/bin/env python2' with '/usr/bin/env python' The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default. Ahmad insists that '/usr/bin/python' should be used in Mageia. Actually, I said that the shebang should be removed altogether. Which is what was being done all those years calibre existed in the Mandriva repos (the same for Fedora, since they do remove the shebang, as the calibre spec was originally imported from Fedora, which I said in the report too). As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages! A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. Should Mageia try to fix something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works? You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. Perfect policies that would require the revision of hundreds of packages that actually work are not my cup of tea. Of course, I am _not_ a Mageia packager and this is not my package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to improve upstream's work, this can prove to be catastrophic in complex cases. Thank you, R-C aka beranger -- Ahmad Samir
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
On 22 June 2011 23:14, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 22 June 2011 22:47, Radu-Cristian FOTESCU beranger...@yahoo.ca wrote: I'm known to be grumpy and difficult, but I also believe in simplicity as a policy, therefore I'd like to ask you something. By no means I want to question Ahmad's judgment, however I strongly disagree with him on one point. As a _principle_. Otherwise, it's a tiny punctual question, but I'd like to know Mageia's patching _policy_. See comments 50 and downwards: https://bugs.mageia.org/show_bug.cgi?id=1659#c50 calibre-python2-env-fix.patch replaces '/usr/bin/env python2' with '/usr/bin/env python' The calibre developer has used '/usr/bin/env python' for ages, but relatively recently he has decided to switch to '/usr/bin/env python2' for fear that some distros would use Python 3 by default. Ahmad insists that '/usr/bin/python' should be used in Mageia. Actually, I said that the shebang should be removed altogether. Which is what was being done all those years calibre existed in the Mandriva repos (the same for Fedora, since they do remove the shebang, as the calibre spec was originally imported from Fedora, which I said in the report too). Of course, or just /usr/bin/python. The /usr/bin/env way may be useful for upstream when creating binary tarballs; but not for us we build the package, and we know which version of python exists in the release we're pushing it to. Also, /usr/bin/python2 doesn't exist to begin with, as mikala pointed out. As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages! A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. Should Mageia try to fix something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works? You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. Perfect policies that would require the revision of hundreds of packages that actually work are not my cup of tea. Of course, I am _not_ a Mageia packager and this is not my package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to improve upstream's work, this can prove to be catastrophic in complex cases. Thank you, R-C aka beranger -- Ahmad Samir -- Ahmad Samir
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
Actually, I said that the shebang should be removed altogether. Which is what was being done all those years calibre existed in the Mandriva repos (the same for Fedora, since they do remove the shebang, as the calibre spec was originally imported from Fedora, which I said in the report too). Yes, I noticed in the spec a set of sed lines supposed to remove all the shebangs. However, somehow, setup.py adds them back at some point, even replacing python with python2. As long as, in the end, replacing python2 with python makes the application work, why should _anyone_ care? Calibre's developer had his idiosyncrasies, why should the downstream take over his app? R-C aka beranger
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
Op woensdag 22 juni 2011 22:47:40 schreef Radu-Cristian FOTESCU: I would say that the general principle should be to apply a _minimal_ patching, not to try to rewrite the work of the developers of hundreds of packages! A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. Should Mageia try to fix something that is not actually broken? There might be hundreds of packages with thousands and thousands of questionable decisions taken by the upstream developers -- however, why fixing something that works? You see, I hate conflicts (although I seem to be a maestro in generating them), but I also need simplicity and clear policies. Also, policies that can be applied. Perfect policies that would require the revision of hundreds of packages that actually work are not my cup of tea. Of course, I am _not_ a Mageia packager and this is not my package, but I'd like to know Mageia's policy wrt building packages. Normally, patches are not meant to optimize but to fix breakages. If the packagers are compelled to improve upstream's work, this can prove to be catastrophic in complex cases. Thank you, R-C aka beranger imho, it's something like: as long as you're patching it anyway, make it python and possibly add a conflicts with python = 3.0 or something. besides, by the time we'll actually have python3, it's likely that the upstream will already have been ported to python3... or the buildsystem would fail anyway...
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
Also, /usr/bin/python2 doesn't exist to begin with, as mikala pointed out. As I repointed, the question was not that one. As long as calibre has used env with python, not python2, it worked. Now that the developer changed that, the least intrusive way would be to just remove the 2. I personally don't like a lot of decisions taken by Kovid Goyal, either wrt functionality, or to things hard-coded rather messy, but it is _his_ application. Either way, I would rather like to retire myself from this discussion. Sorry to have started it. Packagers are free to do whatever they feel like. Cheers, R-C aka beranger
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
On Wed, 22 Jun 2011, Radu-Cristian FOTESCU wrote: A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. But it's to integrate software, and apply common policy to all of them.
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. But it's to integrate software, and apply common policy to all of them. ok, say a distro has 200 packages that use python, for a total of 20,000 *.py files. now what, the limited resources of a distro should be used to patch optimally the first line of all those 20,000 *.py files, just because this would mean to use a common policy? _regardless_ of the fact that those files actually run? this is so crazy in practice that... I don't know what to say. I'm refraining myself from saying things I'd regret. R-C aka beranger
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
'Twas brillig, and David W. Hodgins at 22/06/11 22:51 did gyre and gimble: On Wed, 22 Jun 2011 16:47:40 -0400, Radu-Cristian FOTESCU beranger...@yahoo.ca wrote: As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. Excluding the calibre scripts, in /usr/bin of a Mageia 1 kde clean installation ... # grep -I python *|grep '#!'|grep env ebook-convert:#!/usr/bin/env python ebook-device:#!/usr/bin/env python ebook-meta:#!/usr/bin/env python ebook-viewer:#!/usr/bin/env python epub-fix:#!/usr/bin/env python fetch-ebook-metadata:#!/usr/bin/env python gsettings-schema-convert:#!/usr/bin/env python jack_control:#!/usr/bin/env python lrf2lrs:#!/usr/bin/env python lrfviewer:#!/usr/bin/env python lrs2lrf:#!/usr/bin/env python markdown-calibre:#!/usr/bin/env python pdfmanipulate:#!/usr/bin/env python pykdeuic4:#!/usr/bin/env python pykdeuic4:header = #!/usr/bin/env python web2disk:#!/usr/bin/env python In general, I agree with you. If it isn't broken, don't fix it. However, in this case, the python2 had to be changed to python. The environment is not being modified, so it is adding an unneeded process, which should be discouraged. Since you have to change the line anyway, I have to agree with Ahmad, that it should be changed to #!/usr/bin/python. I think it's relatively unimportant overall, but: 1) /usr/bin/python should be marginally faster 2) /usr/bin/python prevents you testing easily with a new python version (or just a new build) in a custom prefix). So 1) is a (very slight) pro for everyone, but 2) is a pretty big con for developers playing with python builds of course in that case a simple sudo mv /usr/bin/python /usr/bin/python.orig; ln -s /path/to/my/custom/build/of/python /usr/bin/python should allow said developer to test fine. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
Op woensdag 22 juni 2011 23:51:02 schreef David W. Hodgins: On Wed, 22 Jun 2011 16:47:40 -0400, Radu-Cristian FOTESCU beranger...@yahoo.ca wrote: As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. Excluding the calibre scripts, in /usr/bin of a Mageia 1 kde clean installation ... # grep -I python *|grep '#!'|grep env ebook-convert:#!/usr/bin/env python ebook-device:#!/usr/bin/env python ebook-meta:#!/usr/bin/env python ebook-viewer:#!/usr/bin/env python epub-fix:#!/usr/bin/env python fetch-ebook-metadata:#!/usr/bin/env python gsettings-schema-convert:#!/usr/bin/env python jack_control:#!/usr/bin/env python lrf2lrs:#!/usr/bin/env python lrfviewer:#!/usr/bin/env python lrs2lrf:#!/usr/bin/env python markdown-calibre:#!/usr/bin/env python pdfmanipulate:#!/usr/bin/env python pykdeuic4:#!/usr/bin/env python pykdeuic4:header = #!/usr/bin/env python web2disk:#!/usr/bin/env python In general, I agree with you. If it isn't broken, don't fix it. However, in this case, the python2 had to be changed to python. The environment is not being modified, so it is adding an unneeded process, which should be discouraged. Since you have to change the line anyway, I have to agree with Ahmad, that it should be changed to #!/usr/bin/python. Regards, Dave Hodgins that is exactly my sentiment, and i think this describes a good policy
Re: [Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2
2011/6/22 Mageia Team buildsystem-dae...@mageia.org: Name : telepathy-glib Relocations: (not relocatable) Version : 0.15.2 Vendor: Mageia.Org Release : 1.mga2 Build Date: Wed Jun 22 22:02:17 2011 Install Date: (not installed) Build Host: jonund Group : Networking/Instant messaging Source RPM: (none) Size : 3082790 License: LGPLv2+ Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://telepathy.freedesktop.org/wiki/ Summary : A glib utility library for the telepathy framework Description : telepathy-glib is a glib utility library for the telepathy framework. mikala mikala 0.15.2-1.mga2: + Revision: 112483 - Update tarball to 0.15.2 I made an error here while updating telepathy-glib. Bolkm has been kind enough to remove this file from repository. the 0.14.8 should be soon available on mirrors so could you please replace the lib(64)telepathy-glib0-0.15.2-1.mga2 from your installation by the new package in case you did upgrade during the 4 hours when this file was available on repository Regards, -- Balcaen John
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
On Wed, 22 Jun 2011 18:08:35 -0400, Colin Guthrie mag...@colin.guthr.ie wrote: 2) /usr/bin/python prevents you testing easily with a new python version (or just a new build) in a custom prefix). Running something like /usr/bin/python2.7 /usr/bin/calibre ignores the shebang, so it's still easy to test with a different python version. Regards, Dave Hodgins
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
Le mercredi 22 juin 2011 à 23:08 +0100, Colin Guthrie a écrit : 'Twas brillig, and David W. Hodgins at 22/06/11 22:51 did gyre and gimble: On Wed, 22 Jun 2011 16:47:40 -0400, Radu-Cristian FOTESCU beranger...@yahoo.ca wrote: As long as '/usr/bin/env python' _works_, I see no point in trying to rewrite other people's work. Excluding the calibre scripts, in /usr/bin of a Mageia 1 kde clean installation ... # grep -I python *|grep '#!'|grep env ebook-convert:#!/usr/bin/env python ebook-device:#!/usr/bin/env python ebook-meta:#!/usr/bin/env python ebook-viewer:#!/usr/bin/env python epub-fix:#!/usr/bin/env python fetch-ebook-metadata:#!/usr/bin/env python gsettings-schema-convert:#!/usr/bin/env python jack_control:#!/usr/bin/env python lrf2lrs:#!/usr/bin/env python lrfviewer:#!/usr/bin/env python lrs2lrf:#!/usr/bin/env python markdown-calibre:#!/usr/bin/env python pdfmanipulate:#!/usr/bin/env python pykdeuic4:#!/usr/bin/env python pykdeuic4:header = #!/usr/bin/env python web2disk:#!/usr/bin/env python In general, I agree with you. If it isn't broken, don't fix it. However, in this case, the python2 had to be changed to python. The environment is not being modified, so it is adding an unneeded process, which should be discouraged. Since you have to change the line anyway, I have to agree with Ahmad, that it should be changed to #!/usr/bin/python. I think it's relatively unimportant overall, but: 1) /usr/bin/python should be marginally faster 2) /usr/bin/python prevents you testing easily with a new python version (or just a new build) in a custom prefix). So 1) is a (very slight) pro for everyone, but 2) is a pretty big con for developers playing with python builds of course in that case a simple sudo mv /usr/bin/python /usr/bin/python.orig; ln -s /path/to/my/custom/build/of/python /usr/bin/python should allow said developer to test fine. If python point to a different version ( like some self compiled python 2.6, or python 3 ), I fear that using env will silently break lots of applications, since the library and modules would likely not be there. -- Michael Scherer
Re: [Mageia-dev] Minimal patching vs. fixing the whole Universe
Le mercredi 22 juin 2011 à 14:39 -0700, Radu-Cristian FOTESCU a écrit : A distro's job is not to judge the work of the _upstream_ developers as long as this is not a real bug. But it's to integrate software, and apply common policy to all of them. ok, say a distro has 200 packages that use python, for a total of 20,000 *.py files. now what, the limited resources of a distro should be used to patch optimally the first line of all those 20,000 *.py files, just because this would mean to use a common policy? _regardless_ of the fact that those files actually run? Technically, we can use scripts, like we do for stripping the 50 000 binaries that can be found in */bin/ Or like we do to have the same compression on the 85000 man pages, instead of patching every Makefile in order to use xz instead of nothing, gz, bz2. And we even manage to have the same C flags for compilation. So stripping env should be a big issue, if found desirable. After all, we already detect python to add a dependency on the interpreter in rpm, so the logic is already present. -- Michael Scherer
Re: [Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2
2011/6/23 John Balcaen mik...@mageia.org: 2011/6/22 Mageia Team buildsystem-dae...@mageia.org: Name : telepathy-glib Relocations: (not relocatable) Version : 0.15.2 Vendor: Mageia.Org Release : 1.mga2 Build Date: Wed Jun 22 22:02:17 2011 Install Date: (not installed) Build Host: jonund Group : Networking/Instant messaging Source RPM: (none) Size : 3082790 License: LGPLv2+ Signature : (none) Packager : Mageia Team http://www.mageia.org URL : http://telepathy.freedesktop.org/wiki/ Summary : A glib utility library for the telepathy framework Description : telepathy-glib is a glib utility library for the telepathy framework. mikala mikala 0.15.2-1.mga2: + Revision: 112483 - Update tarball to 0.15.2 I made an error here while updating telepathy-glib. Bolkm has been kind enough to remove this file from repository. the 0.14.8 should be soon available on mirrors so could you please replace the lib(64)telepathy-glib0-0.15.2-1.mga2 from your installation by the new package in case you did upgrade during the 4 hours when this file was available on repository I think would be better to just add epoch, that way nothing would be broke and no one would have to remove that version. Regards, -- Balcaen John -- Zé
Re: [Mageia-dev] libproxy vs biarch libexecdir
Le mercredi 22 juin 2011 à 23:54 +0800, Funda Wang a écrit :
2011/6/22 Christiaan Welvaart c...@daneel.dyndns.org:
- the helper app (?) pxgsettings is put in libexecdir by upstream, so
IMHO it should be in /usr/lib or /usr/libexec, not %{_libdir} which
%{_libexecdir} expands to.
%_libexecdir expands to %_libdir, for years since mandrake.
IIRC, /usr/libexec is not in FHS. While that would not cause a problem,
it also mean that some specific Fedora stuff, and so this may be
surprising to people.
--
Michael Scherer
Re: [Mageia-dev] Release cycles proposals, and discussion
andre999 a écrit : Michael Scherer a écrit : Le samedi 18 juin 2011 à 23:49 -0400, andre999 a écrit : Michael Scherer a écrit : Le samedi 18 juin 2011 à 03:38 -0400, andre999 a écrit : Michael Scherer a écrit : If people work the same amount of time, with work divided on 2 products, they must share their time, and usually work less than if they focused only on one product, unless there is twice the ressources. But I doubt this will happen for us, so let's assume that ressources are fixed. That was my assumption : resources fixed in terms of time spent. And why would that divide a contributor's focus more than now ? They would just have a choice. So before, the choice is between : - not doing anything - bugfixing - or doing something elsewhere. After your proposal, there is : - not doing anything - bugfixing - uploading new stuff to cauldron And you fail to see how it divert focus ? We have to remember that packager time is not an ubiquitous resource. If a packager cannot use their time efficiently during freeze, they have incentive to contribute their time elsewhere. It is just human nature. Admittedly this is more likely to affect packagers with less broad-based skills, but such packagers do not make insignificant contributions. As far as diverting focus, does the existance of many distros, providing much more choice, divert focus ? Likely to some extent, but not many packagers contribute to 4 to 6 distros and support in the order of 1000 packages. That's more the exception, for packagers with exceptional skills. Now during the freeze, someone that wants to contribute to cauldron, but can't or chooses not to contribute to pre-release bugfix, is not contributing. So in practice, we risk to have more time contributed during the freeze. My own experience tell the contrary, but maybe you should ask to Anne her opinion if you do not believe me, or to others people who did distribution releases ( and not software releases, which is slightly different, mainly because there is less ). Until we try it, we don't know how much effect it will have. To the best of my knowledge Mandrake/Mandriva and certainly Mageia has not tried this approach. We are both working on conjectures, and we can't know until we (or some other distro with similar resources) tries it. I find it difficult to believe that it will have a negative effect. And I think it would be useful to try it early in the development of Mageia. Even experienced programmers, who have to support different versions of the same software, run into cases where it is very convient -- and more efficient -- to do parallel updates for example. I run into that often enough myself. Now, of course, we can say what if people do not divide their work in 2 ? So let's call : - F the time spent on bugfix during the freeze - C the time spent on cauldron during the freeze We can assume that : C + F = Y So the equation become : C + ( X - Y ) + F = C + F - Y + X = X So no matter how you divide the time, you still have the same amount of time spent overall. As I assumed :) No. the cauldron cycle is extented by the time of the pre-release freeze. e.g. In a release cycle of 6 months and a pre-release freeze of 1 month, the cauldron cycle would be 7 months. Agreed. I've already said that. The cauldron cycle would be 7 months just on the calendar, but 6 months worth of work, as demonstrated. A 1-month pre-release freeze would add 1 month to cauldron development time. That's the same, you do not add real months, just months on the calendar. As I said, my basic assumption that the same number of packager hours are contributed. Certain factors suggest that one could expect somewhat more time contributed, and a number of others that the time would be used more efficiently. Nothing suggests that less time would be available. Now, the real important question is can we really exchange work done as part of C for work done as part of F. And so if I do regular packages updates on cauldron at the begining of the cycle, does it count as bugfixing for the release in the end of the cycle ? To me, the answer is clearly no. If it was somethig we could exchange, we would not have to make a freeze in the first place to make sure that only bugfixes are uploaded in cauldron. So the only way to maximize the time spent on bugfixes is to have F = Y, and so C = 0. Ie, do like we do now. I really don't follow this line of reasoning. The focus on bug fixes starts with the freeze. So a longer freeze would give more time to focus on bug fixes. The focus on bugfixing start with version freeze, since what introduce problem is various changes, and new versions of softwares usually bring new changes. Then we block all uploads except bug fixes, and then all uploads unless very serious bug fixes ( ie, release blocker ). So the focus start much before the last freeze, and you are quite unclear. It terms of freeze, I'm referring to the first freeze for the release.
Re: [Mageia-dev] Release cycles proposals, and discussion
sorry, I forgot to strip off everything at the beginning ... so if you could ignore the previous email andre999 a écrit : I'd like to consolidate and clarify my ideas regarding an amended freeze process, taking into account the critiques. That is, that for the freeze which leads to the release, that we 1) freeze cauldron 2) copy caudron to a pre-release branch, which remains frozen, and will become the release 3) then unfreeze cauldron. - this would be the first freeze, when the big focus starts on bug fixes. The sequence of freeze types would not (necessarily) change. - although cauldron would be unfrozen, the idea is to allow small contributions, such as new packages, new versions not accepted into pre-release, etc. But not to have major changes which could break cauldron, as the main contributors will be focused, as now, on pre-release, and major breaks in cauldron should be quickly fixed. So that cauldron would not be not totally blocked to all non-release contributions during the freeze period (which was about 6 weeks for mga1). - It would probably be very useful to have an explicit policy limiting the nature of contributions to cauldron during the pre-release period. We could even encourage the importing of new packages during this period. - Caudron unfrozen would also allow less experienced packagers to contribute to cauldron at times when they are unable to usefully contribute to pre-release. For instance, such packagers could depend heavily on the advice of others for bug fixes, but could be advanced enough to import new packages or new versions to cauldron on their own. (idea from comment on mageia1_postmortum wiki page.) - This process assumes that the freeze period would be extended (by maybe 2 weeks) to give more time to fix bugs, relieving some of the pressure. Those less able to efficiently contribute to pre-release could contribute to cauldron, so the extra time would be needed. - If this amended process allows us to more easily make the release, and thus keep the release cycle of 6 months, we would have the advantage of keeping in sync with upstream for major projects such as kde and gnome. But if not enough for keeping the 6-month release cycle, if it helps, let's use it if we go with a longer cycle. - In no way is the idea to produce parallel development streams as is now done by mozilla for firefox. Hopefully this summary helps. (BTW, it is still Wednesday in my time zone.) On the road to mga2 ... :) -- André
Re: [Mageia-dev] [RPM] cauldron core/release telepathy-glib-0.15.2-1.mga2
On 23 June 2011 03:54, Zé mmode...@gmail.com wrote: I made an error here while updating telepathy-glib. Bolkm has been kind enough to remove this file from repository. the 0.14.8 should be soon available on mirrors so could you please replace the lib(64)telepathy-glib0-0.15.2-1.mga2 from your installation by the new package in case you did upgrade during the 4 hours when this file was available on repository I think would be better to just add epoch, that way nothing would be broke and no one would have to remove that version. No, this is Cauldron.
Re: [Mageia-dev] Firefox 5
On 22 June 2011 19:41, Florian Hubold doktor5...@arcor.de wrote: Well, it's quite possible that we have to include that in Mageia 1 as well, as this will be security update for Firefox 4. If we don't want to patch every CVE then we have to include it into Mageia 1 as well.. Would be nice to know, if this is planned? I have rebuild FF5 here locally for Mageia 1, and the only addons that i lost is Linkification, but that is merely due to it's developers who already messed up with FF4. They don't offer the proper update on Firefox Addons site. So, please, what about Firefox 5 for Mageia 1 as an update (backport?) Humm, MGA is stricter than MDV and refuses to backport packages directly from cauldron: mgarepo submit --define section=core/backports -t 1 /dev/null Submitting xulrunner at revision 110647 URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package -t 1 --define sid=4845bffd-7f94-4c8c-931e-cfb746d01a0d --define section=core/backports -r 110647 svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner error: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner is not allowed for this target
Re: [Mageia-dev] Firefox 5
On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 22 June 2011 19:41, Florian Hubold doktor5...@arcor.de wrote: Well, it's quite possible that we have to include that in Mageia 1 as well, as this will be security update for Firefox 4. If we don't want to patch every CVE then we have to include it into Mageia 1 as well.. Would be nice to know, if this is planned? I have rebuild FF5 here locally for Mageia 1, and the only addons that i lost is Linkification, but that is merely due to it's developers who already messed up with FF4. They don't offer the proper update on Firefox Addons site. So, please, what about Firefox 5 for Mageia 1 as an update (backport?) Humm, MGA is stricter than MDV and refuses to backport packages directly from cauldron: mgarepo submit --define section=core/backports -t 1 /dev/null Submitting xulrunner at revision 110647 URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package -t 1 --define sid=4845bffd-7f94-4c8c-931e-cfb746d01a0d --define section=core/backports -r 110647 svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner error: svn+ssh://svn.mageia.org/svn/packages/cauldron/xulrunner is not allowed for this target yes it needs to go to backports_testing before iirc But i think sec team need to speak of FF5 first because i think this will be a candidate for updates regarding new firefox upstream policy
