Re: [gentoo-dev] redistribute intel rpms
On Fri, Nov 06, 2009 at 05:58:09PM -0800, Sébastien Fabbro wrote: > > Additionally, from the base license: > > ] Subject to all of the terms and conditions of this Agreement and > > any specific ] restrictions which may appear in the Redistributables > > text files, Intel grants ] to you a non-exclusive, non-assignable > > copyright license to distribute (except ] under an Evaluation License > > as specified below) the Redistributables, or any ] portions thereof, > > as part of the product or application you developed using the ] > > Materials. > > > > Thus, we need to review the "any specific restrictions which may > > appear in the Redistributables text files" for problems as well. > The "Redistributables" seem a bit different in Intel sense, see my > post in [1]. I also put the redist file in [2]. Can you make a list of files in the giant tarball aren't included in the credist.txt list? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Re: redistribute intel rpms
On Sat, 7 Nov 2009, Duncan wrote: > The big combo tarball could then be restrict=mirror or whatever, with > or without a specific user click-thru (and restrict=interactive or > whatever) as necessary and already used on some packages, following > existing policies. > > Of course, there's certainly the complexity of automating the tarball > unpack of only the specific needed components, but gentoo/kde has a > **LOT** of experience with that sort of thing by now, and I'm sure > they'd be happy to share hints and helpful tactical strategies with > you, if you ask, and there's no way I can conceive it being even half > as dependency convoluted as kde4 was to figure out, so it should be > FAR easier. To make myself clearer, the tar ball includes a few binary rpms and a installer blob. Both icc and ifc tar ball include the mkl, idb and some common library rpms. If we go for a kde-split with a mirror restrict approach, users would still have to download the big (~800Mb) tar balls. Only users with use of all (icc, idb, ifc, mkl, ipp, tbb) intel software would benefit of downloading them. It is also the fact Intel has a history of changing their packaging system. Not to mention that a rpm split seems to me lot simpler to maintain and quicker to package for me than the kde-split mirror-restricted approach, and the fact my interest for these packages is limited. -- Sébastien
[gentoo-dev] [maintainer-needed] app-emulation/kvm
KVM needs a maintainer. Plain and simple. If you're interested please step and and start wrangling some bugs. -- Doug Goldstein
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Torsten Veller wrote: > What's the status of the stats project? What's missing? What help is > needed? Hello Torsten, thanks for your interest. Let me quote myself from a recent reply on a similar question: for the quickest summary possible these steps are needed: - make me have and take time for it (soon again as planned) - fix server performance to not take 10 seconds per gentoo-submission (my alchemy code is partly stupid, now i know) - move batch processing upstream (depends on upstream co-op) - get more gentoo people join coding after (http://soc.gentooexperimental.org/projects/stats/issues) > I'd really like to see a system that can answer: > "How often is cpv x installed on arch y (testing/stable flavour)?" That's possible, yes. Please elaborate more on motivation and details. Sebastian
Re: [gentoo-dev] Re: QA: package.mask policies
On Wed, 11 Nov 2009 18:11:37 +0100 Torsten Veller wrote: > > Tomáš Chvátal wrote: > > > But if we look on tag of screen-4.0.3 or its release: > > > screen-4.0.3.tar.gz07-Aug-2008 06:30 821K > > > screen-4.0.3.tar.gz.sig07-Aug-2008 06:30 65 > > *screen-4.0.3 (25 Oct 2006) > > Part of the famous "Software from the future" series. > Proudly presented by your Gentoo time travel agency. Yes, corrected again. The original came out in 2006, whatever the timestamp on the site says. The _p* was a CVS snapshot that was added to the tree years later. I'll get me coat, jer
[gentoo-dev] Re: QA: package.mask policies
> Tomáš Chvátal wrote: > > But if we look on tag of screen-4.0.3 or its release: > > screen-4.0.3.tar.gz07-Aug-2008 06:30 821K > > screen-4.0.3.tar.gz.sig07-Aug-2008 06:30 65 *screen-4.0.3 (25 Oct 2006) Part of the famous "Software from the future" series. Proudly presented by your Gentoo time travel agency.
Re: [gentoo-dev] QA: package.mask policies
On Sun, 8 Nov 2009 18:20:00 +0100 Tomáš Chvátal wrote: > But if we look on tag of screen-4.0.3 or its release: > screen-4.0.2.tar.gz27-Jan-2004 05:46 821K > screen-4.0.2.tar.gz.sig27-Jan-2004 05:47 65 > screen-4.0.3.tar.gz07-Aug-2008 06:30 821K > screen-4.0.3.tar.gz.sig07-Aug-2008 06:30 65 > You see the pattern? It is 1 year newer than it. Correct. The snapshot should have been named _pre20070403. Regards, jer
Re: [gentoo-dev] =kde-base/kdelibs-3* removal, bug 292791
Nice, kde3 deprecation removal is in full effect. You rock Samuli! On Wed, 2009-11-11 at 17:32 +0200, Samuli Suominen wrote: > Goal is to have =kdelibs-3* out of tree by this year, and get > autoconf-2.64 keyworded for ~arch. See the bug in $summary, > and open bugs as you see needed. > > Thanks, Samuli > signature.asc Description: This is a digitally signed message part
[gentoo-dev] =kde-base/kdelibs-3* removal, bug 292791
Goal is to have =kdelibs-3* out of tree by this year, and get autoconf-2.64 keyworded for ~arch. See the bug in $summary, and open bugs as you see needed. Thanks, Samuli
Re: [gentoo-dev] Removing kde-base/arts from tree.
Samuli Suominen wrote: > Here's _somewhat_ complete list of ebuilds that have a depend on > kde-base/arts, excluding those that are masked for other reasons > or ones that I plan on handling myself. And the "unreasonable" goal is done. kde-base/arts is masked, remaining unmasked ebuilds fixed, and USE arts is temporarily masked in base/use.mask until kde-base/* is wiped out of KDE 3.5.10.
Re: [gentoo-dev] Removing kde-base/arts from tree.
On Wed, Nov 11, 2009 at 12:14:41AM +0200, Samuli Suominen wrote: > Here's _somewhat_ complete list of ebuilds that have a depend on > kde-base/arts, excluding those that are masked for other reasons > or ones that I plan on handling myself. > [..] > media-video/vlc-0.9.10:arts There is a bug with ffmpeg for ppc which is blocking vlc-1.0.2 stabilization. Please, consider just dropping arts support from 0.9.10 instead of removing the ebuild. The ffmpeg bug isn't simple enought to be fixed for the end of the week. Thanks. -- Mounir
