[gentoo-dev] Re: Re: Re: Multislot dependencies
Ciaran McCreesh wrote: On Sat, 28 Jun 2008 23:41:17 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: := only makes sense when something is both a DEPEND and an RDEPEND. Actual behaviour, for Paludis, is that it rewrites := deps to :=blah when writing to VDB any time it can, and leaves anything it can't as := deps. Verifying sanity of := use is left to developers and the QA tool. ... and the spec. The spec's well defined. It just tells you how := works, not how to use it in a sensible manner. Pretty much the same as for everything else. Sorry, but I disagree. The only sensible thing you can do with multiple matches on := slots (and ||=, if that route is taken) is to take the slot of the best matching installed version, and require that ebuilds do that too. In real world cases, this works just fine. so, ebuilds should use best_version instead of has_version for example. That's what I meant and what I miss in the kdebuild-1 spec :-) Generally, it just works, because packages are usually fairly good at picking up the best installed version themselves anyway. But yes, if you have to pass a version manually to a package, best_version is the way to do it. And what about a function to tell the PM explicitly which slot of a dependency has been used (as an alternative)? Or should that decision always be left to the PM? (that's something I'd expect to be in the PMS) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Suggested default LDFLAGS+=-Wl,-O1,--hash-style=gnu,--sort-common
On 29-06-2008 20:28:39 -0700, Donnie Berkholz wrote: On 23:15 Sun 29 Jun , Fabian Groffen wrote: On 29-06-2008 07:29:57 -0400, Mike Frysinger wrote: On Saturday 28 June 2008, Petteri Räty wrote: Arfrever Frehtes Taifersar Arahesis kirjoitti: I would like to suggest that default LDFLAGS in Gentoo contain the following flags: -Wl,-O1,--hash-style=gnu,--sort-common. -O1 enables some basic optimizations. At least adding -O1 should not be problematic. I think vapier was already suggesting this quite a while ago. imo -Wl,-O1 should go into base I prefer not. Please only on profiles that use GNU binutils as linker. That's the rule, not the exception, so I think that profiles with non-gnu linkers should revert it. In the current world of gentoo-x86 it is the rule. But what will you do once Sun Studio becomes open source, and you want to allow people that like to have better performance to use it? What if Gentoo Prefix ever gets merged back into gentoo-x86? How can you easily revert it in a profile? Using strip-ldflags alike? That feels nasty to me. If it is trivial to remove it again, considering there may be more in LDFLAGS, then it is less of a problem to me. Maybe there is such a way, and I just missed it. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last rites: mail-client/claws-mail-pdf-viewer
Hi, # Christian Faulhammer [EMAIL PROTECTED] (30 Jun 2008) # Masked for removal for license issues, see bug 230157 mail-client/claws-mail-pdf-viewer 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
[gentoo-dev] Last rites: mail-client/claws-mail-pdf-viewer
Hi, # Christian Faulhammer [EMAIL PROTECTED] (30 Jun 2008) # Masked for removal for license issues, see bug 230157 mail-client/claws-mail-pdf-viewer 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] Suggested default LDFLAGS+=-Wl,-O1,--hash-style=gnu,--sort-common
2008-06-30 10:57:21 Fabian Groffen napisał(a): On 29-06-2008 20:28:39 -0700, Donnie Berkholz wrote: On 23:15 Sun 29 Jun , Fabian Groffen wrote: On 29-06-2008 07:29:57 -0400, Mike Frysinger wrote: On Saturday 28 June 2008, Petteri Räty wrote: Arfrever Frehtes Taifersar Arahesis kirjoitti: I would like to suggest that default LDFLAGS in Gentoo contain the following flags: -Wl,-O1,--hash-style=gnu,--sort-common. -O1 enables some basic optimizations. At least adding -O1 should not be problematic. I think vapier was already suggesting this quite a while ago. imo -Wl,-O1 should go into base I prefer not. Please only on profiles that use GNU binutils as linker. That's the rule, not the exception, so I think that profiles with non-gnu linkers should revert it. In the current world of gentoo-x86 it is the rule. But what will you do once Sun Studio becomes open source, and you want to allow people that like to have better performance to use it? What if Gentoo Prefix ever gets merged back into gentoo-x86? How can you easily revert it in a profile? You can set LDFLAGS= in a subprofiles's make.defaults. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: Multislot dependencies
big_snip Funny, how you all manage to make simple things complicated ;-o I guess nobody considered an trivial solutions like an useflag ... 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@lists.gentoo.org mailing list
Re: [gentoo-dev] Suggested default LDFLAGS+=-Wl,-O1,--hash-style=gnu,--sort-common
On 30-06-2008 17:35:08 +0200, Arfrever Frehtes Taifersar Arahesis wrote: How can you easily revert it in a profile? You can set LDFLAGS= in a subprofiles's make.defaults. How elegant... but I guess I'll have no choice. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Assigning bugs back to bug-wranglers@
To anyone (else) out there who thinks that bug wranglers should be punished when they make mistakes in the heap of unthankful work they perform on a more than daily basis, I would like you to know that if you reassign bugs (back) to bug-wranglers@ without properly communicating the reason you are doing so, I have no option but to close the bug as CANTFIX. The reasoning is that bug-wranglers is a waystation (or perhaps a reception desk) between users and developers - we cannot begin to fix your bugs for you. Kind regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
On Mon, Jun 30, 2008 at 12:27 PM, Jeroen Roovers [EMAIL PROTECTED] wrote: To anyone (else) out there who thinks that bug wranglers should be punished when they make mistakes in the heap of unthankful work they perform on a more than daily basis, I would like you to know that if you reassign bugs (back) to bug-wranglers@ without properly communicating the reason you are doing so, I have no option but to close the bug as CANTFIX. The reasoning is that bug-wranglers is a waystation (or perhaps a reception desk) between users and developers - we cannot begin to fix your bugs for you. Sounds reasonable to me. Can't be too hard to do Assigning back to b-w's because I don't maintain this package or similar. On a side note: How is the b-w SOP doc coming? It is obvious to me the b-w is tedious a time consuming so I would like to help every now and then but I really am not sure about the rules wrt assignment just by looking at metadata.xml. IMO, b-w'ing is something that anyone can do. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
Jeremy Olexa [EMAIL PROTECTED] said: On a side note: How is the b-w SOP doc coming? It is obvious to me the b-w is tedious a time consuming so I would like to help every now and then but I really am not sure about the rules wrt assignment just by looking at metadata.xml. IMO, b-w'ing is something that anyone can do. I'm hoping to work on it later this week. I have been getting absolutely buried with projects at work recently, which has eaten up a lot of my spare time. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpUmivu1sXLU.pgp Description: PGP signature
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
* Jeremy Olexa [EMAIL PROTECTED] [080630 19:53]: [...] IMO, b-w'ing is something that anyone can do. s/can/should ? I mean bug wrangling is a very important thing especially in the sight of users. I'm really willing to help on b-w'ing if it makes sense and is possible. g, mueli -- Michael Hammer|[EMAIL PROTECTED] | Graz, AT Gentoo Developer (Kerberos) | http://www.michael-hammer.at pgpM8FQ6Im2OR.pgp Description: PGP signature
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
On Monday 30 June 2008, Michael Hammer wrote: * Jeremy Olexa [EMAIL PROTECTED] [080630 19:53]: [...] IMO, b-w'ing is something that anyone can do. s/can/should ? I mean bug wrangling is a very important thing especially in the sight of users. I'm really willing to help on b-w'ing if it makes sense and is possible. It always makes sense, especially when both carlo and jer are away. The back log can become long at times. Your best friend is a couple of bugs.gentoo.org tabs open (for searching) and an IRC client with a chat window with jeeves or wilikins on freenode. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggested default LDFLAGS+=-Wl,-O1,--hash-style=gnu,--sort-common
Mike Frysinger kirjoitti: On Saturday 28 June 2008, Petteri Räty wrote: Arfrever Frehtes Taifersar Arahesis kirjoitti: I would like to suggest that default LDFLAGS in Gentoo contain the following flags: -Wl,-O1,--hash-style=gnu,--sort-common. -O1 enables some basic optimizations. At least adding -O1 should not be problematic. I think vapier was already suggesting this quite a while ago. imo -Wl,-O1 should go into base -mike So seems like we should just do it (tm). Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
On Mon, 30 Jun 2008 12:52:02 -0500 Jeremy Olexa [EMAIL PROTECTED] wrote: On a side note: How is the b-w SOP doc coming? It is obvious to me the b-w is tedious a time consuming so I would like to help every now and then but I really am not sure about the rules wrt assignment just by looking at metadata.xml. IMO, b-w'ing is something that anyone can do. I would be happy to give it a try if there is an SOP doc to follow. I may not be a dev, and I'm certainly not massively skilled technically, but if I can bw a few bugs, it's a few less for the good bw. :) Rob. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
Come on guys, bug wrangling isn't that difficult just read metadata.xml,
if it's not correct, it's not your fault, if it's you misread it, I dare
to except devs won't get angry at it and just reassign to whoever they
see fit with a proper message.
If you're so afraid to make errors, just reassign the package you know
the best. If everyone did a little part... ok I'm dreaming a bit :)
PS: I'd like to remind users reading here that assigning bugs directly
is _bad_ if you didn't perform the above checks. It is _not_ ok to
assign bugs just because you _think_ the package is owned by ${HERD}.
--
Gilles Dartiguelongue [EMAIL PROTECTED]
Gentoo
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] Re: Re: Multislot dependencies
Le lundi 30 juin 2008 à 19:01 +0200, Enrico Weigelt a écrit : big_snip Funny, how you all manage to make simple things complicated ;-o I guess nobody considered an trivial solutions like an useflag ... no, this is not the proper solution. Just consider how bad gtk/gtk2 useflag was and that was with only 1 package with 2 slots. Now think about say db (berkeleydb) or gtkhtml (and I'm still probably overlooking the most important point). -- Gilles Dartiguelongue [EMAIL PROTECTED] Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
[gentoo-dev] Re: Suggested default LDFLAGS+=-Wl,-O1,--hash-style=gnu,--sort-common
On Mon, 30 Jun 2008 21:42:49 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Mike Frysinger kirjoitti: On Saturday 28 June 2008, Petteri Räty wrote: Arfrever Frehtes Taifersar Arahesis kirjoitti: I would like to suggest that default LDFLAGS in Gentoo contain the following flags: -Wl,-O1,--hash-style=gnu,--sort-common. -O1 enables some basic optimizations. At least adding -O1 should not be problematic. I think vapier was already suggesting this quite a while ago. imo -Wl,-O1 should go into base -mike So seems like we should just do it (tm). Why not default/linux? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Re: Re: Multislot dependencies
Gilles Dartiguelongue wrote: Le lundi 30 juin 2008 à 19:01 +0200, Enrico Weigelt a écrit : big_snip Funny, how you all manage to make simple things complicated ;-o I guess nobody considered an trivial solutions like an useflag ... no, this is not the proper solution. Just consider how bad gtk/gtk2 useflag was and that was with only 1 package with 2 slots. Now think about say db (berkeleydb) or gtkhtml (and I'm still probably overlooking the most important point). Hehe, that'd be funny. With python it already gets messy: RDEPEND=python2.4? ( !python2.5 ( !python2.6? ( dev-lang/python:2.4 ) python2.6? ( dev-lang/python:2.6 ) ) python2.5? ( !python2.6? ( dev-lang/python:2.5 ) python2.6? ( dev-lang/python:2.6) ) ) python2.6? ( dev-lang/python:2.6 ) or something like that... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
On 22:04 Mon 30 Jun , Gilles Dartiguelongue wrote:
PS: I'd like to remind users reading here that assigning bugs directly
is _bad_ if you didn't perform the above checks. It is _not_ ok to
assign bugs just because you _think_ the package is owned by ${HERD}.
The standard user privileges don't allow assignment of bugs, only CC (at
least last time I checked).
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
On Mon, Jun 30, 2008 at 10:04:31PM +0200, Gilles Dartiguelongue wrote:
PS: I'd like to remind users reading here that assigning bugs directly
is _bad_ if you didn't perform the above checks. It is _not_ ok to
assign bugs just because you _think_ the package is owned by ${HERD}.
The same goes for developers doing their own assignment. I missed a few
bugs on dev-utils/git because they got assigned to only ferdy, and I
wasn't on the CC list at all.
I'm going to do a followup email to the past threads on auto-assignment
later this afternoon.
The last content post on it was:
http://thread.gmane.org/gmane.linux.gentoo.devel/49601
and I didn't integrate bangert's questions yet.
--
Robin Hugh Johnson
Gentoo Linux Developer Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpDUvzIGUbl2.pgp
Description: PGP signature
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
Le lundi 30 juin 2008 à 13:33 -0700, Donnie Berkholz a écrit :
On 22:04 Mon 30 Jun , Gilles Dartiguelongue wrote:
PS: I'd like to remind users reading here that assigning bugs directly
is _bad_ if you didn't perform the above checks. It is _not_ ok to
assign bugs just because you _think_ the package is owned by ${HERD}.
The standard user privileges don't allow assignment of bugs, only CC (at
least last time I checked).
well either it changed or I ate something that makes me see funny things
for some months :p They can't reassign existing bugs though.
--
Gilles Dartiguelongue [EMAIL PROTECTED]
Gentoo
signature.asc
Description: Ceci est une partie de message numériquement signée
[gentoo-dev] Patching of Makefile.in and configure (eautoreconf calls)
Hello,
Recently a big bunch of autotools related bugs were filed, of which
quite a few are quite obvious bugs that need to be fixed, but there are
a few of the kind that I can't agree with without given technical proof
it's a real problem.
So one of those is the changes both autotools source and result kind,
as seen from
https://bugs.gentoo.org/showdependencytree.cgi?id=226305maxdepth=1hide_resolved=0
The short summary of most/all of those is that the ebuilds in question
are either patching or sed'ing not only Makefile.am and/or
configure.{in,ac}, but also Makefile.in and/or configure and it is
claimed that this is a treatment [that] is usually reserved for a few
selected system packages that cannot have their autotool scripts
rebuilt., with a vague claim that it _could_ cause
maintainermode-driven rebuild of the autotools results.
In most cases stopping the patching of Makefile.in and/or configure
involves removing that from the patch AND adding eautoreconf to the
ebuild.
The reason why I'm bringing this up is:
Do we really need to inflict the users with a long eautoreconf step,
when patching Makefile.in and configure alongisde Makefile.am and
configure.in is working just fine when done right, by my some years of
experience doing it once in a while where it's easy to provide a clean
patch for the autotools results?
Some reasoning from my side:
1) maintainer-mode driven rebuild is supposed to only happen if
a) the package defaults to maintainer mode in its configure.in; and
b) the autotools source is newer than the result, which can happen if
you _forget_ (as opposed to doing it, which the bugs are trying to
remove) to patch all results together with sources or you seriously
screw up the timestamps
2) eautoreconf means a considerable amount of extra time inflicted on
all _users_ of that package, without a clear technical reasoning why
that is really necessary
3) Other distributions happily provide a metric ton length of autotools
patches and it works just fine, albeit constrained to only package
maintainers in most cases
So I personally request to hold off with fixing these bugs without a
clear reasoning on the extra (every) Gentoo users resources taken, until
a technically valid reason is given, and I believe the burden of proof
should be on those that want the eautoreconf calls as to justify the
extra time and resource requirements involved.
You as the maintainer of an affected package are free to make your own
decision on this of course right now.
Though if you are hitting the maintainer mode rebuild (missing --run
in build.log without quotes or something), then it's a real bug and you
could probably just as well fix it by patching the Makefile.in or
configure that you forgot to patch when you patched Makefile.am or
configure.{in,ac}.
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal
Hello again, Over a year or two ago, it was communicated that it supposedly a policy that USE=static should only control if a package installs static libraries INSTEAD of shared libraries, and never to be used to control if static libraries are installed in _addition_ to shared ones or not. Packages were coerced to stop using USE=static for controlling that, and most of them ended up unconditionally installing both static and shared libraries. What's worse - they were told that if a package can provide both shared libraries and static libraries at once, it just MUST (or SHOULD) install them both instead of choosing to not ship the static libraries. End result that affects me: GNOME does not fit on LiveCD installation media anymore. So I'm proposing a USE=static-libs or similar to get out of this problem, and a lifting of the supposed (I wasn't around as a dev that long ago to know for sure) policy of having to install both instead of choosing to never install static libraries. I am quite sure that absolutely nothing whatsoever uses about 97% of the static GNOME libraries we are now installing as an end result. How can I be sure? Because everything worked just fine when static libraries weren't installed in the past thanks to that not happening from USE=static missing on most systems for years, and you'd have to be quite crazy if you required static version of desktop libraries with well established and followed ABI guarantees. Those that aren't absolutely sure that there is no use case for static libraries, could then use a USE=static-libs or similar to not unnecessarily install static libraries that are not going to ever be used. And LiveCD media could avoid all these static libraries, that it currently has to ship just because the packages by default install that cruft for no real technical reason (and it has to follow that due to GRPs). I would use USE=static-libs on packages like gtkmm, that have good reasons to provide a static version - it allows Gentoo users that would like to do commercial or universal C++ based development against Gentoo system packages, as it avoids feared libstdc++ ABI breaks (there's even a request for it in bugzilla). There are packages in the tree that are required to install static libraries, or something else in the system breaks. So INSTALL_MASK=*.a is not a solution in my eyes. Useful comments, thoughts, agreements? I have had some additional ideas for handling static libraries better at a package manager level, but those still need to be fleshed out and put into writing. Things like possibility to rebuild all packages that link to a static library that was now upgraded, so the higher level package could use a relinking to benefit from the bug fixes from the new library; optional ability to install only the type of library currently needed - shared or static, etc. Much of it goes to blue-sky ideas though with minimal benefit for normal desktop/server systems and potentially high maintenance effort, so I haven't put much effort into putting it into writing. But maybe someone interested wants to chat on IRC on the topic. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
