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
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.
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
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
On Sun, 8 Nov 2009 18:20:00 +0100 Tomáš Chvátal scarab...@gentoo.org 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
Tomáš Chvátal scarab...@gentoo.org 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.
On Wed, 11 Nov 2009 18:11:37 +0100 Torsten Veller ml...@veller.net wrote: Tomáš Chvátal scarab...@gentoo.org 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
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
KVM needs a maintainer. Plain and simple. If you're interested please step and and start wrangling some bugs. -- Doug Goldstein
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
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 . I also put the redist file in . 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