Re: [Mageia-dev] On the road to build urpmi
On 21 January 2011 00:11, Erwan Velu erwanalia...@gmail.com wrote: I've been trying to solve the deps to make urpmi passing the build-sytem. Looks like we are now only missing rpmtools (http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/rpmtools/trunk/) It requires BuildRequires: perl-MDV-Packdrakeng BuildRequires: perl-MDV-Distribconf What do we do with such packages ? The MDV thing is surely a problem. I disagree I'm not that aware of the policy for this particular packages. What's your opinions on it ? It's not a problem. It's the program name and we won't change program names just because they're owned by other people Else we would have to rename anything named: - *linux* (linux is owned by a foundation) - *firefox* (firefox is owned by the mozilla foundation) - ... Even rpm was originally Redhat Package Manager Last but not least, MDV isn't a trademark...
Re: [Mageia-dev] Java-Policy first draft published
On 21 January 2011 00:01, nicolas vigier bo...@mars-attacks.org wrote: Shipping binary jar given by upstream tarball cause trouble because you 1) cannot patch them in case of bug 2) cannot see how and what was compiled That's not very free software friendly, and I think we should refuse that. I've already seen while trying to package java apps, a jar being shipped, but sources not available anywhere on the internet, except after searching for a few hours on an old website on archive.org with broken link to the sources zip, and developers not aware of the issue, because they never tried to find the sources, and always used this binary .jar they found on a random web site. And they never though about security...
Re: [Mageia-dev] Packaging for Mageia
On 11/01/20 21:33 +0100, Erwan Velu wrote: PS: just pray not to fall into the jquelin massive submits :D sorry, i throttled a bit more between my packages. in fact, my throttling is ok except when people submit big packages! :-) i guess this'll be mitigated when: a) more build nodes will be added to bs b) bs will be updated to allow priorities, queue per submitter, etc. (and i want a pony too) jérôme -- jque...@gmail.com
Re: [Mageia-dev] On the road to build urpmi
On Fri, Jan 21, 2011 at 12:11:42AM +0100, Erwan Velu wrote: I've been trying to solve the deps to make urpmi passing the build-sytem. Looks like we are now only missing rpmtools (http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/rpmtools/trunk/) It requires BuildRequires: perl-MDV-Packdrakeng BuildRequires: perl-MDV-Distribconf What do we do with such packages ? The MDV thing is surely a problem. I'm not that aware of the policy for this particular packages. What's your opinions on it ? same as 4 days ago : https://www.mageia.org/pipermail/mageia-dev/20110117/002188.html -- Michael Scherer
[Mageia-dev] undefined reference to `pow' even with -lm
Hi all, if any one have a clue to solve my build problem the build is ok on my mdv with bm, but not on the mageia bs :( see : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110121084807.philippem.valstar.23877/log/botcmd.1295599743.jonund.log thanks
Re: [Mageia-dev] undefined reference to `pow' even with -lm
I've committed a patch at mandriva's svn. You could grab it. The problem comes from two parts: 1. Since python 2.7.1 (especial in Mandriva), python-config will export the same LDFLAGS as how python was built. Which enforce every binary python module be linked with -lpython, so that it might be easier when migrate to python 3. 2. The -lm switch is actually a linker library, it is of no use if be passed as cflags, see here: http://www.gentoo.org/proj/en/qa/asneeded.xml 2011/1/21 philippe makowski makowski.mag...@gmail.com: Hi all, if any one have a clue to solve my build problem the build is ok on my mdv with bm, but not on the mageia bs :( see : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110121084807.philippem.valstar.23877/log/botcmd.1295599743.jonund.log thanks
Re: [Mageia-dev] undefined reference to `pow' even with -lm
On 21.01.2011 15:32, philippe makowski wrote: Hi all, if any one have a clue to solve my build problem In the command line, -lm has to be *after* the file that needs it, like the other -lfoo entries are on the below log. the build is ok on my mdv with bm, but not on the mageia bs :( see : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110121084807.philippem.valstar.23877/log/botcmd.1295599743.jonund.log thanks -- Anssi Hannula
Re: [Mageia-dev] undefined reference to `pow' even with -lm
2011/1/21 Funda Wang fundaw...@gmail.com: I've committed a patch at mandriva's svn. You could grab it. thanks I will also remove Requires: python-egenix-mx-base from the Mdv package too it is not needed
[Mageia-dev] Character encoding issue in Mageia identity manager?
Hi all,
I have created an account on identity-trunk.mageia.org. When I edit
the account parameters, the accents in my full name ('cn' attribute)
appear mangled, in the typical fashion of a UTF-8 string interpreted
as iso-8859-1, then re-encoded as UTF-8, or something of the sort.
It's probably an easy fix... for you guys who know what you are doing
:-)
Cheers,
Jérôme
Re: [Mageia-dev] Java-Policy first draft published
On Fri, Jan 21, 2011 at 10:06:21AM +0100, Thierry Vignaud wrote: On 21 January 2011 00:01, nicolas vigier bo...@mars-attacks.org wrote: Shipping binary jar given by upstream tarball cause trouble because you 1) cannot patch them in case of bug 2) cannot see how and what was compiled That's not very free software friendly, and I think we should refuse that. I've already seen while trying to package java apps, a jar being shipped, but sources not available anywhere on the internet, except after searching for a few hours on an old website on archive.org with broken link to the sources zip, and developers not aware of the issue, because they never tried to find the sources, and always used this binary .jar they found on a random web site. And they never though about security... Security is not a problem , it is java, no null pointer exception /o\. But that's not only security, there is simply bugs that happen, and API problem ( that IMHO happens more often than security issue ). -- Michael Scherer
Re: [Mageia-dev] Packaging for Mageia
On 11/01/21 16:03 +0100, Michael scherer wrote: i guess this'll be mitigated when: a) more build nodes will be added to bs Well, we do have a limited rack space at lost oasis so we cannot add much server for the moment, and for now, I think we are planning others stuff with potential server ( and as people will ask it, no, we still do not plan to let people run a buildnode if the sysadmin team is not the only group of people to access to it as admin for security reason ). uh? you mean mageia will run with 1 bs node of each type, and that's it? b) bs will be updated to allow priorities, queue per submitter, etc. (and i want a pony too) We do not have it ( except the pony ), but how should we be distribute build in a fair fashion ? I fear that having this would lead to some frustration ( while first in, first out is IMHO easy to understand and quite fair most of the time ). i don't know. stéphane télétchea wrote on cooker@ about a scheduler he's using in his job with lots of fancy features. i guess he'll be able to describe them in more details, and why we would want them. note to packagers: it's now very easy to throttle in an adaptive way (thanks to pascal terjean). just add the following before submitting a package: sleep $( HEAD http://pkgsubmit.mageia.org/ | perl -nE '/X-BS-Throttle: (\d+)/ print $1' ) jérôme -- jque...@gmail.com
Re: [Mageia-dev] Java-Policy first draft published
On 21 January 2011 16:14, Michael scherer m...@zarb.org wrote: And they never though about security... Security is not a problem , it is java, no null pointer exception /o\. But that's not only security, there is simply bugs that happen, and API problem ( that IMHO happens more often than security issue ). I've too often see java apps becoming very unstable once they got a null pointer exception until one restarts tomcat/jboss/whatever... More seriously when I was speaking about though about security, I meant people should got shot (twice) if they are OK with downloading a binary from some random site w/o any checks...
Re: [Mageia-dev] Packaging for Mageia
On Fri, Jan 21, 2011 at 15:03, Michael scherer m...@zarb.org wrote: On Fri, Jan 21, 2011 at 10:59:52AM +0100, Jerome Quelin wrote: On 11/01/20 21:33 +0100, Erwan Velu wrote: PS: just pray not to fall into the jquelin massive submits :D sorry, i throttled a bit more between my packages. in fact, my throttling is ok except when people submit big packages! :-) i guess this'll be mitigated when: a) more build nodes will be added to bs Well, we do have a limited rack space at lost oasis so we cannot add much server for the moment, and for now, I think we are planning others stuff with potential server ( and as people will ask it, no, we still do not plan to let people run a buildnode if the sysadmin team is not the only group of people to access to it as admin for security reason ). b) bs will be updated to allow priorities, queue per submitter, etc. (and i want a pony too) We do not have it ( except the pony ), but how should we be distribute build in a fair fashion ? I fear that having this would lead to some frustration ( while first in, first out is IMHO easy to understand and quite fair most of the time ). No frustration if the submitter can request low priority himself. For massive rebuild, you can then submit everything but other people (or your own other packages) don't have to wait.
Re: [Mageia-dev] Packaging for Mageia
On 21 January 2011 16:15, Jerome Quelin jque...@gmail.com wrote: note to packagers: it's now very easy to throttle in an adaptive way (thanks to pascal terjean). just add the following before submitting a package: sleep $( HEAD http://pkgsubmit.mageia.org/ | perl -nE '/X-BS-Throttle: (\d+)/ print $1' ) WOW! I'd use HEAD http://pkgsubmit.mageia.org/ | fgrep X-BS-Throttle | cut -d: -f 2 instead (less I/O thanks to not loading perl?) Too sad nobody did that back at mdv in the old days Hurra Pascal!
Re: [Mageia-dev] Packaging for Mageia
On Fri, Jan 21, 2011 at 04:15:59PM +0100, Jerome Quelin wrote: On 11/01/21 16:03 +0100, Michael scherer wrote: i guess this'll be mitigated when: a) more build nodes will be added to bs Well, we do have a limited rack space at lost oasis so we cannot add much server for the moment, and for now, I think we are planning others stuff with potential server ( and as people will ask it, no, we still do not plan to let people run a buildnode if the sysadmin team is not the only group of people to access to it as admin for security reason ). uh? you mean mageia will run with 1 bs node of each type, and that's it? We can set multiple built bots on each node. But with 2 nodes ( unless we decide to add some vm on the web server for building, or on the server used for iso building ), there isn't much variations to do. But our servers are quite fast, so this shouldn't be a problem before a long time. Of course, if we can manage to get more servers to rack, and once we will have fullfilled the needs that were expressed over the past months ( like at minima 1 backup server and 1 server for shell access ), we can start to add build nodes. Ideally, we should also think of integrating ports in the mix. I had a pandaboard for that purpose that I gave to a friend in the meantime, but I think there is more urgent thing to do for the moment :) -- Michael Scherer
Re: [Mageia-dev] Java-Policy first draft published
On Fri, Jan 21, 2011 at 08:22:26AM -0500, Frank Griffin wrote: nicolas vigier wrote: Nothing should be downloaded from remote maven repositories during RPM builds. All dependencies should be installed from rpm packages only. So you propose that we package every version of every maven plugin and dependency as RPMs and basically reinvent the entire Maven artifact architecture ? Technically, that's mavven reinventing rpm architecture. It's not a question of use the most current or fix it. POMs allow the author to specify the version of the artifact, and it doesn't matter whether it would work with a later version or not, because Maven will be no more tolerant of a version mismatch than RPM would be. It simply won't build unless you rewrite the POM, in which case you can kiss upstream support goodbye. Well, than, this is our support or the upstream one. If maven powered rpms are not supportable ( ie patchable by us, rebuildable by us, and inspectable by us, and anybody else ), then we should not ship it in core. If one solution is to take random binary packages without having built from the source code ourself and without being able to do so for whatever reason, non-free is for that. Sure, that's bad PR for java and maven. But we do some promises on what is in core, and I think using maven and taking various jar from the internet do not let us fullfill thees promises, this is a good enough reason to not ship them in core. -- Michael Scherer
