Re: [gentoo-dev] Farewell, Gentoo.
On Sat, Jan 02, 2010 at 05:44:31AM -0800, David Shakaryan wrote: > Once again, thank you for everything, but my time has come. Adieu! Looks like one of the last of "our generation" of Gentoo kids is going to leave. Thanks for everything omp, hopefully you'll say hello every once in a while in some of our shared IRC channels. It was a pleasure working with you. -- Alexander Færøy pgpMuQ7GTo2b4.pgp Description: PGP signature
[gentoo-dev] Virtuals don't have a license
Virtual packages don't install any files, so there's nothing where a license could apply to. Therefore LICENSE should be the empty string for them. (This must not be confused with the license for the ebuild itself, which is GPL-2 and is in the ebuild's header.) The issue becomes more important together with ACCEPT_LICENSE, since the user shouldn't be required to accept anything for installation of a virtual. If there are no objections, I'll remove all licenses from the virtual category (or rather ask fauli to do it with his keywording script). Similar for HOMEPAGE which should be the empty string too. Ulrich
[gentoo-dev] net-fs/netatalk is facing removal
since noone seems to care about this package, and it's blocking glibc stabilization it will be removed from tree wrt bug 300218 last chance thanks, Samuli
[gentoo-dev] Lastrite: dev-libs/dbus-qt3-old and x11-themes/licq-themes
# Samuli Suominen (08 Jan 2010) # Uncompatible package with >= licq 1.3.8 and USE qt4 # Will need some work in bug 220637 # Needs a maintainer # Masked for removal in 30 days x11-themes/licq-themes # Samuli Suominen (08 Jan 2010) # Obsolete Qt3 bindings for DBUS, not used by anything. # Masked for removal in 30 days. dev-libs/dbus-qt3-old
Re: [gentoo-dev] Non-free software in Gentoo
On 01/08/2010 12:26 AM, Greg KH wrote: If the kernel loads a firmware file that is not free, or if the device itself has a firmware in it that you can not change so easily, has _nothing_ to do with the license of the kernel, I don't think anybody is concerned about the license of "the kernel", but rather the license of sys-kernel/gentoo-sources. Gentoo-sources contains "the kernel" as well as a bunch of other stuff (documentation, firmware, etc). It can only have a single license if EVERYTHING installed by the package is usable under that single license. The LICENSE in an ebuild pertains to the package - not just to the largest component or majority of the package. Very few people install gentoo-sources mainly to read the docs or get a firmware blob, but they are still there, and the license should reflect this.
Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
On Saturday 26 December 2009 08:15:22 Thomas Sachau wrote:
> On 12/26/2009 11:25 AM, Fabian Groffen wrote:
> > This is about what I understood. Now here I have some questions that
> > may or may not be relevant.
> >
> > What triggers a multilib build? Is it unconditional, or can it be
> > turned on/off per package? How does Portage resolve/verify that a
> > library is built for the right ABI in that case?
>
> Currently multilib-portage does add a USE flag called "lib32". If you
> enable it, you will get the cross-compile, else just the normal install.
> In addition this flag is internally used like an EAPI-2 usedep, so it will
> require the dependencies to be built for all ABIs too.
this is something that needs to be fixed per the earlier discussion
> > Unpacking sources many times feels like a terrible waste to me,
> > especially for things like GCC. If we would just start building outside
> > of the workdir (sources) into a separate builddir, wouldn't that just
> > be much cleaner and a nice EAPI feature?
>
> That might be an extra step, once the basic implementation works, but you
> will have to adjust some things, since e.g. cmake-utils eclass does
> already something like that, maybe others do it too, so you would have to
> change those ebuilds/eclasses or add exceptions or extra rules to portage
> for those. Some packages like gcc or glibc already do this multilib-stuff
> internally with the multilib USE flag, so you currently wont get any
> better experience for them.
indeed ... it'd be nice if we only ran src_unpack() once, but there are
packages in EAPI0 that modify the source based on ABI/build flags. the only
safe way is to always run the src_unpack() multiple times.
once this implementation settles on top of EAPI{0..3}, we can look at EAPI4+
to optimize the flow.
> > Since you make each compilation multiple times, you also obtain a fully
> > identical installation of the same package. How do you deal with that?
> > Do you have /usr/bin{64,32} directories for example too? If you only
> > keep libs (found by a scanelf scan or something), how do you know what's
> > relevant. Alternatively, if you build the full application anyway,
> > isn't it a waste to throw away the result? You could see multilib also
> > as two (unrelated) trees, such as e.g. a Gentoo Prefix installation.
> > A nasty one: how to deal with libs that actually contain hardcoded paths
> > to configuration from e.g. /etc or /var in your implementation?
>
> Currently i only work and test with amd64-ARCH, so with x86 and amd86 ABI.
> For those, the lib-part is easy since the crosscompile does install the
> libs into /usr/lib32 while the 64bit ones go into /usr/lib64. The headers
> for both ABIs are diffed and different ones are preserved, the rest is
> isntalled as usual. For binaries, normally only the one for the
> DEFAULT_ABI, so in this case the 64bit one, will be preserved. But you can
> tell multilib-portage to preserve the 32bit binaries. In that case, the
> binaries will be called $binary-$ABI and a symlink $binary to a wrapper
> created, which calls the real binary depending on the current ABI.
can you guys think of a package where the bindirs differ and/or we care ?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Saturday 02 January 2010 13:21:05 Pacho Ramos wrote: > El vie, 01-01-2010 a las 13:31 +, Mike Frysinger escribió: > > This is your monthly friendly reminder ! Same bat time (typically > > the 3rd Thursday at 1800 UTC / 2000 CET / 1400 EST), same bat channel > > (#gentoo-council @ irc.freenode.net) ! > > > > If you have something you'd wish for us to chat about, maybe even > > vote on, let us know ! Simply reply to this e-mail for the whole > > Gentoo dev list to see. > > > > Keep in mind that every GLEP *re*submission to the council for review > > must first be sent to the gentoo-dev mailing list 7 days (minimum) > > before being submitted as an agenda item which itself occurs 7 days > > before the meeting. Simply put, the gentoo-dev mailing list must be > > notified at least 14 days before the meeting itself. > > > > For more info on the Gentoo Council, feel free to browse our homepage: > > http://www.gentoo.org/proj/en/council/ > > I would like to know what was finally decided about "Adding real > multilib features from current multilib-portage to currently hardmasked > and testing portage-2.2*", as I failed to see if, finally, an approval > from the council is needed for merging it to portage-2.2 or not and, if > needed, if it will be discussed finally on this meeting. the multilib discussion hasnt moved past the development stages yet, so there's nothing to be discussed by the council or merged by the portage team. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
On Friday 25 December 2009 09:00:36 Thomas Sachau wrote: > On 12/25/2009 06:10 AM, Denis Dupeyron wrote: > > On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau wrote: > >> I will make it short, since i already requested it 3 times, did create a > >> thread at gentoo-dev ML: > >> > >> agenda topic: Discussion and approval for following item: > >> > >> Adding real multilib features from current multilib-portage to currently > >> hardmasked and testing portage-2.2* for wider testing, more eyes looking > >> at it and hopefully more people helping improving it, so we can get a > >> version, which most can accept for PMS and maybe next EAPI. > > > > Sorry, I forgot to send an email explaining what happened on the > > council alias as promised. The consensus was that the project wasn't > > mature enough to go ahead. Also more generally the council's job isn't > > discussing but deciding, approving, etc... Discussing is what should > > happen on mailing lists. > > Since i see noone arguing against adding the multilib features to current > testing branch of portage, the discussion part already seems to be done. > so a simple approval is ok, drop the discussion request. that's incorrect. you still havent addressed my outstanding issues. until you do, i dont see how you can push for this being added to portage. or i missed some update along the way, but the last e-mail i see is from me dated 26.10.2009 ... -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] bash-4.1 going into unstable
i havent noticed any problems on my systems, so unless someone notices (and files a bug about) some problems, i'll be moving it into ~arch in the next ~week or so. -mike signature.asc Description: This is a digitally signed message part.
