Re: [gentoo-dev] RFC: Gentoo News file about GNOME 3.2's unmasking

On Sun, Nov 27, 2011 at 1:36 AM, Zac Medico wrote: > GLEP 42 refers to GLEP 22, which says nothing of ~arch specifiers. The > current portage code literally compares the news item's keyword to the > current profile's ARCH variable, so ~arch specifiers will not match. The > code is in the DisplayKe

Re: [gentoo-dev] tkabber completely broken in stable

On 11/26/2011 04:15 PM, "Paweł Hajdan, Jr." wrote: > Please see , tkabber is > completely broken in stable since February. > > * ERROR: net-im/tkabber-0.9.9 failed: > * dev-tcltk/tclxml-3.2-r1 does not actually support the expat USE flag! > * >

[gentoo-dev] tkabber completely broken in stable

Please see , tkabber is completely broken in stable since February. * ERROR: net-im/tkabber-0.9.9 failed: * dev-tcltk/tclxml-3.2-r1 does not actually support the expat USE flag! * * Call stack: * ebuild.sh, line 56: Called pkg_se

Re: [gentoo-dev] RFC: Gentoo News file about GNOME 3.2's unmasking

On 11/26/2011 10:55 AM, Nirbheek Chauhan wrote: > On Sat, Nov 26, 2011 at 11:51 PM, Mart Raudsepp wrote: >> On L, 2011-11-26 at 12:43 +0530, Nirbheek Chauhan wrote: >>> A question: it currently restricts only on the basis of If-Installed, >>> but is there a workaround for the absence Display-If-Vi

Re: [gentoo-dev] RFC: Gentoo News file about GNOME 3.2's unmasking

On Sat, Nov 26, 2011 at 11:51 PM, Mart Raudsepp wrote: > On L, 2011-11-26 at 12:43 +0530, Nirbheek Chauhan wrote: >> A question: it currently restricts only on the basis of If-Installed, >> but is there a workaround for the absence Display-If-Visible filter? >> If there isn't, I'll commit it as-is

Re: [gentoo-dev] RFC: Gentoo News file about GNOME 3.2's unmasking

On L, 2011-11-26 at 12:43 +0530, Nirbheek Chauhan wrote: > Hello folks, > > Attached is a short news file announcing the unmasking of GNOME 3.2 > with a link to the upgrade guide. Since GNOME 3 is already in the > tree, and the news file content is straightforward, I'd like to commit > this in 24h

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, Nov 26, 2011 at 9:49 PM, Mike Frysinger wrote: > On Saturday 26 November 2011 07:50:27 Nirbheek Chauhan wrote: >> I'm not sure the two are really comparable. However, looking at a >> simple string sort on 30,000 strings, I don't see it taking a >> significant amount of time at all: > > sur

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, Nov 26, 2011 at 9:38 PM, Michał Górny wrote: > On Sat, 26 Nov 2011 21:28:51 +0530 > Nirbheek Chauhan wrote: >> There are still a few specific cases in which CoW would indeed be >> useful. IIRC, reflinking of files works across btrfs *subvolumes*, and >> such a copy would normally be detec

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Saturday 26 November 2011 07:50:27 Nirbheek Chauhan wrote: > On Sat, Nov 26, 2011 at 5:08 PM, Fabian Groffen wrote: > > On 26-11-2011 16:56:41 +0530, Nirbheek Chauhan wrote: > >> [...] Besides, sorting even 30,000 > >> entries (if you're merging every ebuild in portage) should not take > >> more

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, 26 Nov 2011 21:28:51 +0530 Nirbheek Chauhan wrote: > On Sat, Nov 26, 2011 at 8:39 PM, Michał Górny > wrote: > > But in this particular case, I don't think COW is particularly > > useful. If it works only on filesystem bounds, we could move the > > file directly anyway. > > > > There are

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, 26 Nov 2011 10:25:15 -0500 Rich Freeman wrote: > On Sat, Nov 26, 2011 at 10:09 AM, Michał Górny > wrote: > > But in this particular case, I don't think COW is particularly > > useful. If it works only on filesystem bounds, we could move the > > file directly anyway. > > Yup - I would on

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, Nov 26, 2011 at 8:39 PM, Michał Górny wrote: > But in this particular case, I don't think COW is particularly useful. > If it works only on filesystem bounds, we could move the file directly > anyway. > There are still a few specific cases in which CoW would indeed be useful. IIRC, reflin

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, Nov 26, 2011 at 7:14 PM, Rich Freeman wrote: > isn't supported.  It is available in stable coreutils.  Some speculate > that this option could increase fragmentation (both copies will share > extents from the original file, and have some extents of their own), > but btrfs doesn't overwrite

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, Nov 26, 2011 at 10:09 AM, Michał Górny wrote: > But in this particular case, I don't think COW is particularly useful. > If it works only on filesystem bounds, we could move the file directly > anyway. Yup - I would only use it if you really are doing a copy and not a move (neglecting the

[gentoo-dev] Re: RFC: Gentoo News file about GNOME 3.2's unmasking

On Sat, Nov 26, 2011 at 9:35 AM, Alexandre Rostovtsev wrote: > On my part, it was a failure of imagination. I had always seen large > changes dumped in ~arch with no warning or documentation (even the > png15 upgrade didn't get a news item until libpng-1.5.x went stable), Of course - just figured

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, 26 Nov 2011 08:44:28 -0500 Rich Freeman wrote: > Oh, on the topic of btrfs, if any emerge operations do file copies, > adding --reflink=auto to the cp command will GREATLY improve > performance. That does a copy-on-write copy - it behaves like a > hard-link as far as time to create goes,

[gentoo-dev] Re: RFC: Gentoo News file about GNOME 3.2's unmasking

On Sat, Nov 26, 2011 at 7:56 AM, Nirbheek Chauhan wrote: > On Sat, Nov 26, 2011 at 5:56 PM, Rich Freeman wrote: >> On Sat, Nov 26, 2011 at 2:13 AM, Nirbheek Chauhan >> wrote: >>> Since GNOME 3 is already in the >>> tree, and the news file content is straightforward, I'd like to commit >>> this

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, Nov 26, 2011 at 7:59 AM, Ciaran McCreesh wrote: > On Sat, 26 Nov 2011 18:20:27 +0530 > Nirbheek Chauhan wrote: >> Actually, reading the code it seems that it's about the file merge >> order of a single package. My participation in this entire discussion >> is m00t. Never mind. :p > > ...i

[gentoo-dev] Re: RFC: Gentoo News file about GNOME 3.2's unmasking

On Sat, Nov 26, 2011 at 7:56 AM, Nirbheek Chauhan wrote: > I think that the addition of a Display-If-Visible option would help, > along with the addition of news file procedures to the devmanual and > the quizzes. Even I didn't know where to commit the news file before > some creative googling tod

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, 26 Nov 2011 18:20:27 +0530 Nirbheek Chauhan wrote: > Actually, reading the code it seems that it's about the file merge > order of a single package. My participation in this entire discussion > is m00t. Never mind. :p ...in which case it's often an awful lot faster to sort by inode, not b

[gentoo-dev] Re: RFC: Gentoo News file about GNOME 3.2's unmasking

On Sat, Nov 26, 2011 at 5:56 PM, Rich Freeman wrote: > On Sat, Nov 26, 2011 at 2:13 AM, Nirbheek Chauhan wrote: >> Since GNOME 3 is already in the >> tree, and the news file content is straightforward, I'd like to commit >> this in 24hrs if there are no problems. > > If we're gong to go to all th

[gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, Nov 26, 2011 at 5:08 PM, Fabian Groffen wrote: > On 26-11-2011 16:56:41 +0530, Nirbheek Chauhan wrote: >> [...] Besides, sorting even 30,000 >> entries (if you're merging every ebuild in portage) should not take >> more than a few secs. > > A linux kernel has around that much of files, and

[gentoo-dev] Re: RFC: Gentoo News file about GNOME 3.2's unmasking

On Sat, Nov 26, 2011 at 2:13 AM, Nirbheek Chauhan wrote: > Since GNOME 3 is already in the > tree, and the news file content is straightforward, I'd like to commit > this in 24hrs if there are no problems. If we're gong to go to all the trouble to create upgrade guides and news/etc, wouldn't it m

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On 11/26/11 12:26 PM, Nirbheek Chauhan wrote: > If it should be sorted[1], it should really be sorted in the reverse > order of distfile-download size. That would be extremely useful on > systems with slow internet connections. [...] > > 1. I'm obviously assuming that dep nodes that do not depend

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On Sat, Nov 26, 2011 at 4:28 PM, Fabian Groffen wrote: > On 26-11-2011 01:54:35 +, Arfrever Frehtes Taifersar Arahesis wrote: >> commit:     1d4ac47c28706094230cb2c4e6ee1c1c71629aa0 >> T> Org> >> AuthorDate: Sat Nov 26 01:52:49 2011 + >> Commit:     Arfrever Frehtes Taifersar Arahesis gen

[gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

Attempt 2 from correct email address, sorry for any duplicate in advance. On 26-11-2011 01:54:35 +, Arfrever Frehtes Taifersar Arahesis wrote: > commit: 1d4ac47c28706094230cb2c4e6ee1c1c71629aa0 > T> Org> > AuthorDate: Sat Nov 26 01:52:49 2011 + > Commit: Arfrever Frehtes Taifersar

Re: [gentoo-dev] repoman not complaining when going straight to stable

On Sat, 26 Nov 2011 10:15:53 +0100 ""Paweł Hajdan, Jr."" wrote: > This shouldn't be allowed, should it? The package is keyworded only > ~x86, and I'm adding amd64 stable keyword, and repoman doesn't complain. It would need to fetch latest CVS file from server to check against previous state. I

[gentoo-dev] repoman not complaining when going straight to stable

This shouldn't be allowed, should it? The package is keyworded only ~x86, and I'm adding amd64 stable keyword, and repoman doesn't complain. $ ekeyword x86 netboot-0.10.2.ebuild netboot-0.10.2.ebuild --- netboot-0.10.2.ebuild 2011-11-23 02:41:03.0 +0100 +++ netboot-0.10.2.ebuild.new