[gentoo-dev] Packages up for grabs
Hi, Since the rtl8192se driver was merged into kernel 3.0, I am no longer interested in maintaining the out-of-tree driver and its firmware package. net-wireless/rtl8192se net-wireless/rtl8192se-firmware I will reassign them to maintainer-needed in about a week, unless someone picks them up first, and removes me from metadata.xml. If you plan to maintain the driver, you may also want to look at the out-of-tree rtlwifi driver in bug 379953. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] gcc: dropping cld workaround
we added the cld workaround to gcc-4.3.0+ in early 2008 until packages sorted themselves out. i think they have at this point. in terms of kernels, we're talking about ones around 2.6.25 and earlier. i'll be dropping it from our gcc builds, so now is the time to make noise if this affects you. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gcc: dropping cld workaround
so... is this something where I should suddenly in a moment of clarity shout ah, that cld workaround ?! On Samstag 20 August 2011 20:03:04 Mike Frysinger wrote: we added the cld workaround to gcc-4.3.0+ in early 2008 until packages sorted themselves out. i think they have at this point. in terms of kernels, we're talking about ones around 2.6.25 and earlier. i'll be dropping it from our gcc builds, so now is the time to make noise if this affects you. -mike -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] gcc: dropping cld workaround
On Sat, Aug 20, 2011 at 2:08 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: so... is this something where I should suddenly in a moment of clarity shout ah, that cld workaround ?! On Samstag 20 August 2011 20:03:04 Mike Frysinger wrote: we added the cld workaround to gcc-4.3.0+ in early 2008 until packages sorted themselves out. i think they have at this point. in terms of kernels, we're talking about ones around 2.6.25 and earlier. i'll be dropping it from our gcc builds, so now is the time to make noise if this affects you. -mike https://bugs.gentoo.org/show_bug.cgi?id=379367 ... and, don't top post. Matt
Re: [gentoo-dev] gcc: dropping cld workaround
On Saturday, August 20, 2011 14:08:00 Andreas K. Huettel wrote: so... is this something where I should suddenly in a moment of clarity shout ah, that cld workaround ?! if you dont know immediately what i was referring to, then chances are you dont care :) otherwise, Matt provided good info -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds
On Fri, Aug 19, 2011 at 12:52 PM, Roy Bamford neddyseag...@gentoo.org wrote: As far as I am aware, under the current organisation there is no legal connection between the Gentoo Foundation Inc., and the Gentoo distribution. True, but that doesn't mean that the Foundation might not be found liable for things done using Foundation property, like servers, domain names, and trademarks - especially if the Foundation has prior knowledge of these actions. I'm not sure the car example was accurate, since in this case the distribution is being facilitated using Foundation property and clearly at this point the Foundation has knowledge that it is occurring. Regardless of who can get sued, we should comply with the GPL regardless. To that end I agree that we should refrain from shipping historical binaries unless we also tarball portage and the distfiles from the same period of time. I definitely agree with his suggestion that we should always make both available online simultaneously to avoid the 3-year rule. I'm sure that if the FSF were concerned they'd ask us nicely before suing anybody - especially since we are an FOSS effort ourselves that tries to comply with the GPL/etc. So, the risk is low, but that isn't a reason not to comply. Does anybody have a strong objection to removing historical binary distributions of Gentoo on any Gentoo-controlled/linked servers, or general disagreement with Duncan's proposal? I don't really want to get sidetracked into a debate about the boundaries between Council/Trustees/Foundation/Distro unless there is an actual disagreement on the matter at hand. Rich
Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds
On 2011.08.20 23:20, Rich Freeman wrote: On Fri, Aug 19, 2011 at 12:52 PM, Roy Bamford neddyseag...@gentoo.org wrote: As far as I am aware, under the current organisation there is no legal connection between the Gentoo Foundation Inc., and the Gentoo distribution. [snip] Regardless of who can get sued, we should comply with the GPL regardless. To that end I agree that we should refrain from shipping historical binaries unless we also tarball portage and the distfiles from the same period of time. I definitely agree with his suggestion that we should always make both available online simultaneously to avoid the 3-year rule. [snip] Rich Rich, There are two separate issue here and they have separate timescales for being addressed. We need to comply with the GPL now and always, so we should do as Duncan suggests. Take down old binaries now and post sources with new binaries. e.g. the liveDVDs. Sorting out our internal structure is a separate issue to address in slower time but it needs to be done before something goes wrong because there just won't be time then. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgppwoI3mHlpS.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds
On 17:41 Thu 18 Aug , Roy Bamford wrote: Just as long as we can provide the patch sets for a period of at least three years, in case someone asks. Thats a GPL requirement. Just to be clear, it's only a requirement if you're going with the written offer to provide source clause rather than the providing source at the same time as binary clause (i.e., 3b rather than 3a in GPL-2). -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpKNPzYQVAdA.pgp Description: PGP signature
Re: [gentoo-portage-dev] official way for setting per package CFLAGS and FEATURES?
On 07/19/2009 01:20 PM, Zac Medico wrote:
Pacho Ramos wrote:
Hello, I would want to always merge xorg-server, libdrm, and intel
driver (that likes to crash a lot) to be always compiled with debugging
symbols and FEATURES=${FEATURES} splitdebug
Searching in google seems that there are some available hacks done by
some forums users, but they seem to be a bit old and, before trying
them, I would want to know if there is an official way of doing it.
Thanks a lot :-)
I use pre_pkg_setup hooks defined in /etc/portage/env. For example:
cat /etc/portage/env/sys-libs/glibc
pre_pkg_setup() {
local x
for x in installsources splitdebug ; do
if ! has $x $FEATURES ; then
elog bashrc is adding $x to FEATURES for $PN
FEATURES=$FEATURES $x
fi
done
if ! hasq -ggdb $CFLAGS ; then
elog bashrc is adding \-ggdb\ to CFLAGS for $PN
CFLAGS=$CFLAGS -ggdb
fi
}
Please note that the above approach has been deprecated since
portage-2.1.9.24, due to inclusion of package.env support:
http://bugs.gentoo.org/show_bug.cgi?id=44796
In order to accomplish the same thing with package.env, you'd put
something like sys-libs/glibc debug.conf in /etc/portage/package.env,
and then you put your FEATURES and CFLAGS variable settings in
/etc/portage/env/debug.conf (same format as make.conf). This is
documented in the portage man page.
--
Thanks,
Zac
Re: [gentoo-portage-dev] Dependency calculation turning on USE flags?
On 21 August 2011 08:10, Matt Turner matts...@gentoo.org wrote: See https://bugs.gentoo.org/372513 ^ tldr version for everyone else. This is due to the || condition in virtual/fortran || ( sys-devel/gcc[fortran,openmp?] sys-devel/gcc-apple[fortran,openmp?] dev-lang/ifc dev-lang/ekopath-bin ) Where gcc[fortran] takes precedence over ifc. I wonder if there's some way we can manage this kind of situation? Perhaps portage could print alternative dependencies for virtuals, similar to the very helpful recent The following keyword changes are necessary to proceed: addition. This usecases specifics aside, I'd welcome some sort of way to show that an or condition is occurring somewhere in the tree, but it'd have to be opt-in, instead of opt-out, as the potential for being very noisy is great ( you'll get a lot of noise if you hit virtual/perl-* for instance ). And likewise, I'd love to have some way to produce some sort of graph for alternative merge trees that may work if you toggle some variable, but the amount of complexity to do this I'd imagine is quite large, and could easily be computationally expensive. It would very likely need some limiting factor for how deep it did permutations at. [ebuild N ] sys-libs/libstdc++-v3-3.3.6 USE=(multilib) nls 23,459 kB [ebuild N ] app-shells/tcsh-6.16 USE=perl -catalogs 869 kB # app-shells/tcsh-6.16 = #perl? ( # dev-lang/perl #) [ebuild N ] app-emulation/emul-linux-x86- compat-20100611 USE=(multilib) 930 kB [ebuild N ] virtual/libstdc++-3.3 0 kB # virtual/libstdc++-3.3 = #|| ( # =sys-libs/libstdc++-v3-bin-3.3* # =sys-libs/libstdc++-v3-3.3* #) [ebuild N ] dev-lang/ifc-10.0.026-r1 40,378 kB # virtual/fortran-0 -openmp = #|| ( # sys-devel/gcc +fortran # sys-devel/gcc-apple +fortran # dev-lang/ifc # dev-lang/ekopath-bin #) # virtual/fortran-0 +openmp = #|| ( # sys-devel/gcc +fortran # sys-devel/gcc-apple +fortran # dev-lang/ifc # dev-lang/ekopath-bin #) # || ( # sys-devel/gcc +fortran +openmp # sys-devel/gcc-apple +fortran +openmp # dev-lang/ifc # dev-lang/ekopath-bin #) [ebuild N ] virtual/fortran-0 USE=openmp 0 kB [ebuild N F ] sci-chemistry/cns-1.2.1 USE=openmp 31,981 kB Would be a sample output for depthlimit = 1 Note that in this example I have made a few omissions, some because I couldn't be bothered working out all the other ACCEPT_KEYWORDS stuff to mentally compute which of the above targets were actually possible to install and what ACCEPT_KEYWORDS permuations could be done, and others because they are for whatever reason fixed dependencies, thus, showing only dependencies that user choices can impact. ie: app-emulation/emul-linux-x86-compat-20100611 has different dependencies depending on the multilib USE flag, but that useflag is profile mandated so its pointless to show to a user. Alternatively, you could let the user dictate what type of permutations to display/compute, ie: use-flag based permutations, keyword based permutations, mask-based permutations, ||() conditional OR based permutations, package-version/slot permutations etc. For package version/slot permutations, it would display every variation on package/slot ( ie: slots/versions that are not the current version ) that were installable, or installable with some permutation ( if the depth of permutation is large enough ), so that a user could see a path of installation they wanted and twist user masks to make it happen. Of course, this is all looking like harder and harder stuff to do ( programming is the gateway-drug for feature creep ) , but it would still be something nice to have on a theoretical magic computer that can do all computations in zero time. ¢¢ -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-portage-dev] Dependency calculation turning on USE flags?
On Sun, 2011-08-21 at 10:22 +1200, Kent Fredric wrote: On 21 August 2011 08:10, Matt Turner matts...@gentoo.org wrote: See https://bugs.gentoo.org/372513 ^ tldr version for everyone else. This is due to the || condition in virtual/fortran || ( sys-devel/gcc[fortran,openmp?] sys-devel/gcc-apple[fortran,openmp?] dev-lang/ifc dev-lang/ekopath-bin ) Where gcc[fortran] takes precedence over ifc. I wonder if there's some way we can manage this kind of situation? Perhaps portage could print alternative dependencies for virtuals, similar to the very helpful recent The following keyword changes are necessary to proceed: addition. This usecases specifics aside, I'd welcome some sort of way to show that an or condition is occurring somewhere in the tree, but it'd have to be opt-in, instead of opt-out, as the potential for being very noisy is great ( you'll get a lot of noise if you hit virtual/perl-* for instance ). And likewise, I'd love to have some way to produce some sort of graph for alternative merge trees that may work if you toggle some variable, but the amount of complexity to do this I'd imagine is quite large, and could easily be computationally expensive. ... Alternatively, you could let the user dictate what type of permutations to display/compute, ie: use-flag based permutations, keyword based permutations, mask-based permutations, ||() conditional OR based permutations, package-version/slot permutations etc. For package version/slot permutations, it would display every variation on package/slot ( ie: slots/versions that are not the current version ) that were installable, or installable with some permutation ( if the depth of permutation is large enough ), so that a user could see a path of installation they wanted and twist user masks to make it happen. Of course, this is all looking like harder and harder stuff to do ( programming is the gateway-drug for feature creep ) , but it would still be something nice to have on a theoretical magic computer that can do all computations in zero time. ¢¢ -- Kent Well, for something now, you can emerge porthole and look at the Dependency view. It will display all options and show the recommended versions of the dep package (still needs some small tweaks to handle slots correctly). It is expandable (depth wise) until all deps are satisfied. The deps are also dbl-click able to pop up the dep in another window so you can view/change it's settings, merge, unmerge, etc.. And no it would not be suitable for portage, it is a guis based treeview and for human use only ;) But it can show you the alternatives for such cases. From there you can decide how you want to set things for the merges. -- Brian Dolbec brian.dol...@gmail.com signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] Dependency calculation turning on USE flags?
On 08/20/2011 03:22 PM, Kent Fredric wrote: On 21 August 2011 08:10, Matt Turner matts...@gentoo.org wrote: See https://bugs.gentoo.org/372513 ^ tldr version for everyone else. This is due to the || condition in virtual/fortran || ( sys-devel/gcc[fortran,openmp?] sys-devel/gcc-apple[fortran,openmp?] dev-lang/ifc dev-lang/ekopath-bin ) Where gcc[fortran] takes precedence over ifc. The reason that portage chooses ifc when USE=fortran is disabled is that this kind of behavior is sometimes desirable. It's discussed in bug 278729: http://bugs.gentoo.org/show_bug.cgi?id=278729 -- Thanks, Zac
