[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
Hi, Nirbheek Chauhan nirbh...@gentoo.org: What needs to be done now is for someone with lots of CPU power to grab the list of packages[1], and build them one-by-one (all versions), adding to a new list all the ebuilds that fail. How to test: LDFLAGS=-Wl,--as-needed emerge -v1 $atom Once we have the list that fails with normal as-needed, we can fix them, get the fix upstreamed (if possible), and switch the flag on. This action should probably be accompanied by a news item informing users about the change, and encouraging them to report the (rare) bug which might hit them. And the stable tree should be safe, too. In general I like the idea. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, 28 Jun 2010 06:39:44 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: There's a tracker bug for this, and the problems still remaining are: http://bugs.gentoo.org/showdependencytree.cgi?id=129413hide_resolved=1 You've forgotten make --as-needed not break correct code by making the linker ignore explicit instructions from a program author to link two things together. Until you do that, --as-needed is in the same category as -ffast-math. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 06/28/2010 10:35 AM, Ciaran McCreesh wrote: On Mon, 28 Jun 2010 06:39:44 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: There's a tracker bug for this, and the problems still remaining are: http://bugs.gentoo.org/showdependencytree.cgi?id=129413hide_resolved=1 You've forgotten make --as-needed not break correct code by making the linker ignore explicit instructions from a program author to link two things together. Until you do that, --as-needed is in the same category as -ffast-math. And we can't be held hostage by few packages (marginal cases), that's why we have function called $(no-as-needed) in flag-o-matic.eclass to disable the behavior for these packages. I.e. your point is moot. - Samuli
Re: [gentoo-dev] Policy for late/slow stabilizations
Markos Chandras hwoar...@gentoo.org said: On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote: On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras hwoar...@gentoo.org wrote: What? I am talking about exotic arches and I didn't say to drop to entire stable tree. Just to shrink it in order to keep it up to date more easily But my question stands: what really is the advantage of having a stable tree, when you could better invest your time in keeping the testing tree up to date and working? Most production systems are running x86, right? Are stable versions of minority architecture installations really that much more stable than testing versions? Because a stable tree it is supposed to work. Testing tree on the other hand is vulnerable to breakages from time to time. We can't always ensure a working testing tree. We are people not machines. We tend to brake things and this is way we have the testing branch. also the stable tree implies security support (GLSAs etc). signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, 28 Jun 2010 10:44:54 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: You've forgotten make --as-needed not break correct code by making the linker ignore explicit instructions from a program author to link two things together. Until you do that, --as-needed is in the same category as -ffast-math. And we can't be held hostage by few packages (marginal cases), that's why we have function called $(no-as-needed) in flag-o-matic.eclass to disable the behavior for these packages. Will Gentoo be doing the same for -Ofast and its flags then? After all, most packages work with them, and you can't let the few packages that require standard-compliant behaviour from a compiler hold Gentoo hostage. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 06/28/2010 10:51 AM, Ciaran McCreesh wrote: On Mon, 28 Jun 2010 10:44:54 +0300 Samuli Suominenssuomi...@gentoo.org wrote: You've forgotten make --as-needed not break correct code by making the linker ignore explicit instructions from a program author to link two things together. Until you do that, --as-needed is in the same category as -ffast-math. And we can't be held hostage by few packages (marginal cases), that's why we have function called $(no-as-needed) in flag-o-matic.eclass to disable the behavior for these packages. Will Gentoo be doing the same for -Ofast and its flags then? After all, most packages work with them, and you can't let the few packages that require standard-compliant behaviour from a compiler hold Gentoo hostage. --as-needed is a flag that tries to solve a specific (and very annoying) problem. It deserves a bit of special treatment. It's not a ricer flag :-)
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 06/28/2010 10:51 AM, Ciaran McCreesh wrote: On Mon, 28 Jun 2010 10:44:54 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: You've forgotten make --as-needed not break correct code by making the linker ignore explicit instructions from a program author to link two things together. Until you do that, --as-needed is in the same category as -ffast-math. And we can't be held hostage by few packages (marginal cases), that's why we have function called $(no-as-needed) in flag-o-matic.eclass to disable the behavior for these packages. Will Gentoo be doing the same for -Ofast and its flags then? After all, most packages work with them, and you can't let the few packages that require standard-compliant behaviour from a compiler hold Gentoo hostage. This is not about optimizing but preventing clear breakage, the benefits of asneeded are not under debate here (like already stated in the original message this thread started from) So please stop trying to derail the thread - Samuli
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, Jun 28, 2010 at 1:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 06/28/2010 10:51 AM, Ciaran McCreesh wrote: Will Gentoo be doing the same for -Ofast and its flags then? After all, most packages work with them, and you can't let the few packages that require standard-compliant behaviour from a compiler hold Gentoo hostage. This is not about optimizing but preventing clear breakage, the benefits of asneeded are not under debate here (like already stated in the original message this thread started from) So please stop trying to derail the thread ++, all of this has been discussed to *death*. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, 28 Jun 2010 11:08:22 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: This is not about optimizing but preventing clear breakage, the benefits of asneeded are not under debate here (like already stated in the original message this thread started from) --as-needed does not prevent breakage. It shoves some breakages under the carpet so they're sometimes less visible, and sometimes easier to fix when they happen. However, it does absolutely nothing to address any of the root causes of the breakage, and it does introduce new breakages itself. Had one tenth of the effort that had been put into running around and adding in hacks to work around a deliberately broken toolchain instead been put into fixing libtool and delivering better slotting mechanisms, none of this would be an issue. Or is the policy we've started running towards the cliff and we've already debated the merits of jumping off it, so all you're allowed to discuss now is how we remove the fence? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, Jun 28, 2010 at 06:39:44AM +0530, Nirbheek Chauhan wrote: What needs to be done now is for someone with lots of CPU power to grab the list of packages[1], and build them one-by-one (all versions), adding to a new list all the ebuilds that fail. How to test: LDFLAGS=-Wl,--as-needed emerge -v1 $atom Let's try to make Gentoo less frustrating for our users. 1. http://dev.gentoo.org/~nirbheek/files/as-needed-failures.list -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team I have the CPU power so I will start building those packages and report back here -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgpCSgz0WuhUT.pgp Description: PGP signature
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
El lun, 28-06-2010 a las 06:39 +0530, Nirbheek Chauhan escribió: Hello everyone, I'm sure at least half of you are thinking Oh no, not this again..., and I agree. However, I'm /also/ thinking Why the heck haven't we done this yet? We've been discussing this since 2008, and probably waaay before that too. The entire discussion about whether we should do this or not has already passed, there is NO NEED to have that again. This email is about discussion on what all is *left* before we can do $SUBJECT. What prompted this email? libpng-1.4 and many other upgrades that have left gentoo systems very very broken. We have to resort to random scripts to fix breakage, which reflects very badly on us. Even worse, a lot of users just give up and reinstall their system, or don't upgrade, or just move away from Gentoo. I understand that these kind of breakages are inevitable, but with as-needed, we can reduce their effect *drastically*. Instead of having to rebuild almost their entire system, the user would only need to rebuild packages that directly link(ed) to libpng. I honestly think that we cannot afford to expose our users to any more such upgrades without as-needed in the default linux profile. There's a tracker bug for this, and the problems still remaining are: http://bugs.gentoo.org/showdependencytree.cgi?id=129413hide_resolved=1 *Most* of the problems listed there are forced-as-needed problems, which need to be fixed no doubt, but should NOT block addition of --as-needed to LDFLAGS in make.defaults which will not trigger those build failures. What needs to be done now is for someone with lots of CPU power to grab the list of packages[1], and build them one-by-one (all versions), adding to a new list all the ebuilds that fail. How to test: LDFLAGS=-Wl,--as-needed emerge -v1 $atom Once we have the list that fails with normal as-needed, we can fix them, get the fix upstreamed (if possible), and switch the flag on. This action should probably be accompanied by a news item informing users about the change, and encouraging them to report the (rare) bug which might hit them. Let's try to make Gentoo less frustrating for our users. 1. http://dev.gentoo.org/~nirbheek/files/as-needed-failures.list Thanks for taking care signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Policy for late/slow stabilizations
Ciaran McCreesh posted on Sun, 27 Jun 2010 18:43:30 +0100 as excerpted: On Sun, 27 Jun 2010 20:22:33 +0300 Markos Chandras hwoar...@gentoo.org wrote: Which does Gentoo care about more: slightly increased convenience for most developers, or considerably increased inconvenience for users of minority archs? I don't follow you. Increased convenience just for the devs? How? Not having to keep old versions around for a few archs is slightly more convenient for most people. Having to deal with dropped keywords is a huge inconvenience for users on minority archs. As already stated on the other sub-threads, that's not the point at all. Rather, it's a simple matter of letting an arch's stable tree dynamically and realistically adjust to the level of arch support they have. If the stable set gets small enough, it's probably time to officially reduce the arch status to testing tree support only, not security supported, etc. But well before that point, it's likely a core package set can be maintained at stable, with perhaps certain arch-usage specific area stable support as well, while still being unrealistic to try to keep a stable version of (nearly) all at-one-point-known-to-work packages available. If the arch support simply isn't there, it really is better to have that reflected in the size of the stable set, such that users actually know that and know what's being actively supported on their arch and what isn't, than to try to fake it, which is what's going on now. It's not a question of more convenience vs less, but of having arch keyword status reflect arch support reality. That said, if there's not already a simple way to get the info out of VCS (perhaps there is, I don't know), archs may wish to maintain a list of packages and versions that once were stable, along with comments on specific destabilization reason (it didn't work with gcc-vX on that arch, for instance) if known, so it'll be somewhat easier to expand stable coverage again if we happen to pickup a few new devs with a strong interest in the arch. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, Jun 28, 2010 at 1:47 PM, Markos Chandras hwoar...@gentoo.org wrote: On Mon, Jun 28, 2010 at 06:39:44AM +0530, Nirbheek Chauhan wrote: What needs to be done now is for someone with lots of CPU power to grab the list of packages[1], and build them one-by-one (all versions), adding to a new list all the ebuilds that fail. How to test: LDFLAGS=-Wl,--as-needed emerge -v1 $atom Let's try to make Gentoo less frustrating for our users. 1. http://dev.gentoo.org/~nirbheek/files/as-needed-failures.list I have the CPU power so I will start building those packages and report back here Thanks! My hardware currently consists of one (1) netbook, so I can't help much :) I'll be keeping a list of packages which are known to fail only in forced as-needed mode[1], as well as a list which is known to fail with normal as-needed[2] 1. http://dev.gentoo.org/~nirbheek/files/as-needed-forced-only.list 2. http://dev.gentoo.org/~nirbheek/files/as-needed-normal.list -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb: PHP and mplayer both have 100 USE flags. There's not enough CPU power in the world. We don't have to try *all* possible combinations, but only those differing in interfaces (eg. if some libfoo changes its exported interface on a userflag, the clients have to be built against that two versions). It involves some interface analysis and a bit of graph theory. Should be possible to do it incrementally. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
Ciaran McCreesh posted on Mon, 28 Jun 2010 09:16:32 +0100 as excerpted: --as-needed does not prevent breakage. It shoves some breakages under the carpet so they're sometimes less visible, and sometimes easier to fix when they happen. However, it does absolutely nothing to address any of the root causes of the breakage, and it does introduce new breakages itself. Had one tenth of the effort that had been put into running around and adding in hacks to work around a deliberately broken toolchain instead been put into fixing libtool and delivering better slotting mechanisms, none of this would be an issue. Or is the policy we've started running towards the cliff and we've already debated the merits of jumping off it, so all you're allowed to discuss now is how we remove the fence? OK, let's take that last analogy of yours, and expand it to better match rather more of the situation. The current situation is that we have a big mountain (with known unsafe cliffs) in the way of a journey we happen to make somewhat regularly. Now there's a 10 kilometer (or read mile, if you prefer) road over the mountain, with the next shortest alternative being a 110 km road around the mountain. Unfortunately, because the road over the mountain currently transits a particular cliff without tested guardrails, it's gated off (your fence) and marked with large warning signs, unguarded cliff ahead, proceed at your own risk. The 110 km road around the mountain is thus what most folks take now, with only a few deciding they can manage the risk if they go carefully (often after someone else points out the shortcut, and describes the problems so they can be careful at that cliff), and choosing to take that road. That's the current situation. Everyone seems to agree that we have the mountain, the 110 km long route around it that most folks take, and a potentially quite dangerous 10 km shortcut over it, that some few take instead. OK, as it so happens, a proposed guard rail along the dangerous parts has been surveyed, contracted, and is pretty much finished. Pretty much all that remains now is painting the stripes on the new section, and putting up the various curve left, curve right, etc, signage, and getting official sign-offs on the guard rails at an already listed set of particular sections of the cliff that need it. Except... There's a particular set of individuals that despite that almost finished section of road, only awaiting the paint, signage, and official signoffs, continues to argue that's not the /proper/ solution, that the /proper/ solution is to tunnel straight thru a particular section of the mountain, thereby bypassing the cliff entirely. In fact, not only do they claim that the tunnel is the proper solution and would in fact be less dangerous than transiting the cliff even with the guard rails is, they claim that the tunnel would have actually cost less to construct than the section of road transiting the cliff did. So here we are, playing politics at the meeting set to give the final go- ahead to complete the final inspections, the painting and the signage on the road transiting the cliff, a road that's all finished and actually in use by some already, save for that, and we still have this tunnel bloc of folks opposing it, continuing to argue that the tunnel is the /proper/ solution. Who knows at this point? The tunnel may in fact have been cheaper, and there's no question that it would have prevented the occasional careless driver still crashing thru the guard rails and going over the cliff. But the point is, we don't have that tunnel, but we do have the already basically finished road, well surveyed and already constructed, with only a bit of painting and certification left, yet the tunnel bloc is still opposing the road, arguing that the gate and warnings be maintained as they are, until that tunnel is properly finished, even at the cost of all those travelers having to take the 110 km long way around until that tunnel is completed and opened at some unpredictable time in the future, possibly a decade or more away. So yes, we ARE arguing that the final preparations be made and that the gate currently barring the way to that cliff come down. The fact of the matter is that yes, there is a cliff, but there's also a well constructed road with proper guard rails transiting that cliff, and pending the paint, signage, and final signoffs, it's ready to open and there's no reason other than the political opposition of the tunnel bloc not to make those last preparations, and then remove that gate and the warnings currently barring the way. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Policy for late/slow stabilizations
On E, 2010-06-28 at 09:49 +0200, Thilo Bangert wrote: Markos Chandras hwoar...@gentoo.org said: On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote: On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras hwoar...@gentoo.org wrote: What? I am talking about exotic arches and I didn't say to drop to entire stable tree. Just to shrink it in order to keep it up to date more easily But my question stands: what really is the advantage of having a stable tree, when you could better invest your time in keeping the testing tree up to date and working? Most production systems are running x86, right? Are stable versions of minority architecture installations really that much more stable than testing versions? Because a stable tree it is supposed to work. Testing tree on the other hand is vulnerable to breakages from time to time. We can't always ensure a working testing tree. We are people not machines. We tend to brake things and this is way we have the testing branch. also the stable tree implies security support (GLSAs etc). Stable tree does NOT imply security support. I can understand why users might think that, though. A few architectures that have a stable tree are not security supported (GLSAs waiting for them, etc), as can be seen from comparing the arches with stable trees to the security supported architectures list over at http://www.gentoo.org/security/en/vulnerability-policy.xml (at least arm, ia64 and sh by my quick comparison) -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://blogs.gentoo.org/leio
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, Jun 28, 2010 at 06:39:44AM +0530, Nirbheek Chauhan wrote: Hello everyone, ... What needs to be done now is for someone with lots of CPU power to grab the list of packages[1], and build them one-by-one (all versions), adding to a new list all the ebuilds that fail. How to test: LDFLAGS=-Wl,--as-needed emerge -v1 $atom Once we have the list that fails with normal as-needed, we can fix them, get the fix upstreamed (if possible), and switch the flag on. This action should probably be accompanied by a news item informing users about the change, and encouraging them to report the (rare) bug which might hit them. Let's try to make Gentoo less frustrating for our users. I'll help ;) Testing from the bottom up to avoid overlapping with hwoarang. 1. http://dev.gentoo.org/~nirbheek/files/as-needed-failures.list -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpiDYoSbYHWA.pgp Description: PGP signature
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, Jun 28, 2010 at 01:40:46PM +0530, Nirbheek Chauhan wrote: On Mon, Jun 28, 2010 at 1:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 06/28/2010 10:51 AM, Ciaran McCreesh wrote: Will Gentoo be doing the same for -Ofast and its flags then? After all, most packages work with them, and you can't let the few packages that require standard-compliant behaviour from a compiler hold Gentoo hostage. This is not about optimizing but preventing clear breakage, the benefits of asneeded are not under debate here (like already stated in the original message this thread started from) So please stop trying to derail the thread ++, all of this has been discussed to *death*. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team Not taking technical sides in this thread simply because I have no time to argue it at length, BUT: Simply because a topic has been discussed to *death* does not mean the correct answer was obtained, only that a majority agree it is what they want. And while consensus may be enough to be considered 'right' in social situations(politics, etc.), the second the discussion becomes technical the opinion of the masses becomes irrelevant. All that then matters is getting the technical part objectively right, which IS possible, despite what some may say. Regards, Thomas -- - ~Thomas Anderson~ -
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 2010.06.28 14:43, Thomas Anderson wrote: [snip] Not taking technical sides in this thread simply because I have no time to argue it at length, BUT: Simply because a topic has been discussed to *death* does not mean the correct answer was obtained, only that a majority agree it is what they want. And while consensus may be enough to be considered 'right' in social situations(politics, etc.), the second the discussion becomes technical the opinion of the masses becomes irrelevant. All that then matters is getting the technical part objectively right, which IS possible, despite what some may say. Regards, Thomas -- - ~Thomas Anderson~ - All of engineering involves compromise. There is no point in waiting for a perfect solution to an engineering issue if that solution is so far away nobody wants to wait. The compromises become political discussions and we have seen plenty of them already. As its 'the masses' that will implement the solution, not the idealists, its time to go with the compromise that has been hammered out elsewhere ... unless of course the idealists have a patch already. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, 28 Jun 2010 14:59:21 +0100 Roy Bamford neddyseag...@gentoo.org wrote: All of engineering involves compromise. It's not a question of compromise. It's a question of being right vs being wrong. If one person says that 2 + 2 = 4 and a loud mob screams that their prophet revealed to them in a blog post that 2 + 2 = 6, you don't compromise and say that 2 + 2 = 5. There is no point in waiting for a perfect solution to an engineering issue if that solution is so far away nobody wants to wait. The compromises become political discussions and we have seen plenty of them already. As its 'the masses' that will implement the solution, not the idealists, its time to go with the compromise that has been hammered out elsewhere ... unless of course the idealists have a patch already. You appear to be assuming that those pushing the --as-needed solution have it finished. This is far from the case. There's still a lot of work that would need to be done, and that work will have to be carried on by every developer indefinitely as new versions of packages come out. It's a case of the wrong thing requires quite a lot more work before it's ready, and once it's ready everyone will have to carry on working on it forever. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, Jun 28, 2010 at 12:46:53PM +0100, David Leverton wrote: This has been pointed out ever since the issue was first discussed, but some people like to stick their fingers in their ears and dismiss legitimate technical arguments as trolling and politics. The issue is some folk are trying to be pragmatic, and some folk are sticking to it's not the proper long term solution thus don't do it at all. The question shouldn't be is it long term the right or wrong solution, the question should be yes it's not perfect, but what is the gain of deploying it? Literally, do we break more by deploying it then we gain? Is the reduction in intermediate broken packages (and general linkage whonkyness) being mostly sorted worth the cost of some cranky packages breaking from it? That is the question. If the only correct answer is it must be the right technical solution always we'd theoretically be running hurd rather than linux after all, nor would the prefix project be in wide usage. Alternatively rather than arguing, someone needs to go out and get some data to back this change (and/or back the stance it causes more damage than it's worth). Personally, I've been running as-needed for a while- while not a fan of it, it's been an overall plus for my usage. The question is if it's an overall gain to deploy globally (iirc fedora/ubuntu are running this way now). ~harring pgpNqSGT0ZRpZ.pgp Description: PGP signature
[gentoo-dev] RFC: media-sound/xmms2/xmms2-0.7.ebuild
There is yet 'New Package' request:
https://bugs.gentoo.org/show_bug.cgi?id=93583
I think I've hacked more or less maintainable ebuild (attached)
and plan to maintain media-sound/xmms2 but one thing worries me:
package (and ebuild) has ruby, python and perl bindings.
I need help to check/fix current installation scheme as
I have zero experience in $forementioned-lang
bindings support in gentoo maintenance.
Other comments about ebuild issues are welcomed.
Thanks!
--
Sergei
xmms2-0.7.ebuild
Description: Binary data
commit 3bc7fbff50bfcb065fb89d020c1b3fb8de049b19
Author: Sergei Trofimovich s...@anti-virus.by
Date: Mon Apr 19 13:16:56 2010 +0300
OTHER: fix build failure on windres aware binutils (linux host, native build)
Trying to use windres under linux (native build) is worthless:
[ 26/269] winrc: pixmaps/xmms2.rc - _build_/default/pixmaps/xmms2.rc.o
/usr/bin/windres: can't get BFD_RELOC_RVA relocation type: No error
Waf: Leaving directory `/var/tmp/paludis/media-sound-xmms2--r3/work/xmms2-devel/_build_'
Build failed
- task failed (err #1):
{task: winrc xmms2.rc - xmms2.rc.o}
Signed-off-by: Sergei Trofimovich s...@anti-virus.by
diff --git a/wscript b/wscript
index 2a29016..1d73813 100644
--- a/wscript
+++ b/wscript
@@ -265,12 +265,6 @@ def configure(conf):
conf.check_tool('gcc')
conf.check_tool('g++')
-try:
-conf.check_tool('winres')
-conf.env['WINRCFLAGS'] = '-I' + os.path.abspath('pixmaps')
-conf.env['xmms_icon'] = True
-except Configure.ConfigurationError:
-conf.env['xmms_icon'] = False
if Options.options.target_platform:
Options.platform = Options.options.target_platform
@@ -412,6 +406,17 @@ def configure(conf):
else:
conf.env['socket_impl'] = 'posix'
+# platform does not support icons ...
+conf.env['xmms_icon'] = False
+# ... unless we target on windows
+if Options.platform == 'win32':
+try:
+conf.check_tool('winres')
+conf.env['WINRCFLAGS'] = '-I' + os.path.abspath('pixmaps')
+conf.env['xmms_icon'] = True
+except Configure.ConfigurationError:
+pass
+
# Glib is required by everyone, so check for it here and let them
# assume its presence.
conf.check_cfg(package='glib-2.0', atleast_version='2.8.0', uselib_store='glib2', args='--cflags --libs', mandatory=1)
signature.asc
Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/python-openid: python-openid-2.2.4.ebuild
On Mon, 28 Jun 2010 19:42:27 + (UTC), Arfrever Frehtes Taifersar
Arahesis (arfrever) arfre...@gentoo.org wrote:
arfrever10/06/28 19:42:27
Modified: python-openid-2.2.4.ebuild
Log:
Fix dependencies.
(Portage version: HEAD/cvs/Linux x86_64)
Is there any reason you are so non-verbose here? 'cvs log' or '$EDITOR
ChangeLog' equally give us no information about your commit. You are
making it hard on other devs in my opinion, I don't think intentionally,
but can't you just use the ChangeLog more?? At least, that is my small
request and I think others feel the same. If not, I will quietly go back
in my corner.
-Jeremy
Index: python-openid-2.2.4.ebuild
===
-EAPI=2
-
-NEED_PYTHON=2.5
+EAPI=3
+PYTHON_DEPEND=2:2.5
SUPPORT_PYTHON_ABIS=1
+RESTRICT_PYTHON_ABIS=2.4 3.*
inherit eutils distutils
@@ -22,7 +22,6 @@
postgres? ( dev-python/psycopg )
sqlite? ( || ( dev-lang/python[sqlite] =dev-python/pysqlite-2 ) )
DEPEND=${RDEPEND}
-RESTRICT_PYTHON_ABIS=3.*
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dns/bind: bind-9.7.0_p2-r1.ebuild metadata.xml Ch angeLog bind-9.7.1.ebuild bind-9.6.2 _p2.ebuild
On Mon, 28 Jun 2010 20:10:45 + (UTC), Christian Ruppert (idl0r) id...@gentoo.org wrote: snip lots + gssapi? ( || ( =app-crypt/heimdal-1.2.1-r4 =app-crypt/mit-krb5-1.6.3-r6 ) ) Christian, Any reason you aren't using virtual/krb5 ? -Jeremy
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/python-openid: python-openid-2.2.4.ebuild
2010-06-29 04:05:54 Jeremy Olexa napisał(a): On Mon, 28 Jun 2010 19:42:27 + (UTC), Arfrever Frehtes Taifersar Arahesis (arfrever) arfre...@gentoo.org wrote: arfrever10/06/28 19:42:27 Modified: python-openid-2.2.4.ebuild Log: Fix dependencies. (Portage version: HEAD/cvs/Linux x86_64) Is there any reason you are so non-verbose here? 'cvs log' or '$EDITOR ChangeLog' equally give us no information about your commit. You are making it hard on other devs in my opinion, I don't think intentionally, but can't you just use the ChangeLog more?? It was intermediate commit during my work on python-openid-2.2.5.ebuild. python-openid-2.2.4.ebuild has been mentioned in ChangeLog in final commit. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/python-openid: python-openid-2.2.4.ebuild
On Mon, 28 Jun 2010 22:26:17 +0200, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-06-29 04:05:54 Jeremy Olexa napisał(a): On Mon, 28 Jun 2010 19:42:27 + (UTC), Arfrever Frehtes Taifersar Arahesis (arfrever) arfre...@gentoo.org wrote: arfrever10/06/28 19:42:27 Modified: python-openid-2.2.4.ebuild Log: Fix dependencies. (Portage version: HEAD/cvs/Linux x86_64) Is there any reason you are so non-verbose here? 'cvs log' or '$EDITOR ChangeLog' equally give us no information about your commit. You are making it hard on other devs in my opinion, I don't think intentionally, but can't you just use the ChangeLog more?? It was intermediate commit during my work on python-openid-2.2.5.ebuild. python-openid-2.2.4.ebuild has been mentioned in ChangeLog in final commit. You are correct - 2.2.4 IS mentioned in the ChangeLog during the subsequent commit. So you think it is ok to hide the first commit under a ChangeLog entry of Version bump ? I don't see the logic. My issue with this is that other devs (or users) still don't know how or why the dependancies got in the 2.2.5 version or what deps were fixed. In this case, I would have committed a new 2.2.5 version with the ChangeLog entry of: Version bump, fix python dependancies that are incorrect in the old or somthing like that. This way commit #1 is not hidden and placed under a false entry of commit #2. -Jeremy
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dns/bind: bind-9.7.0_p2-r1.ebuild metadata.xml ChangeLog bind-9.7.1.ebuild bind-9.6.2_p2.ebuild
On 06/29/2010 04:22 AM, Jeremy Olexa wrote: On Mon, 28 Jun 2010 20:10:45 + (UTC), Christian Ruppert (idl0r) id...@gentoo.org wrote: snip lots +gssapi? ( || ( =app-crypt/heimdal-1.2.1-r4 =app-crypt/mit-krb5-1.6.3-r6 ) ) Christian, Any reason you aren't using virtual/krb5 ? -Jeremy Oops, no.. should be fixed now. Thanks :) -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: 9B50 01DF E873 A0E4 126D 6C16 8B17 B68E 7FAE 7D38 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/python-openid: python-openid-2.2.4.ebuild
Arfrever, On 06/28/10 22:26, Arfrever Frehtes Taifersar Arahesis wrote: Is there any reason you are so non-verbose here? 'cvs log' or '$EDITOR ChangeLog' equally give us no information about your commit. You are making it hard on other devs in my opinion, I don't think intentionally, but can't you just use the ChangeLog more?? It was intermediate commit during my work on python-openid-2.2.5.ebuild. Please take my vote on proper commit messages for any commit, including intermediate ones. Thanks! Best, Sebastian
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, 28 Jun 2010 15:05:19 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: You appear to be assuming that those pushing the --as-needed solution have it finished. This is far from the case. There's still a lot of work that would need to be done, and that work will have to be carried on by every developer indefinitely as new versions of packages come out. It's a case of the wrong thing requires quite a lot more work before it's ready, and once it's ready everyone will have to carry on working on it forever. Why do you care? Everybody intimately involved in Exherbo and caring about it tells me you forked. If you didn't and are still leeching off our ebuild tree, then please file --as-needed bugs like everyone else, or shut up. Kindest of kindest of regards, jer
