Re: [gentoo-portage-dev] .53, .54 and beyond...

2005-12-06 Thread warnera6

Jason Stubbs wrote:

On Wednesday 07 December 2005 01:01, Marius Mauch wrote:

On Tue, 6 Dec 2005 23:19:38 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:

If there's no solid opposition, Saturday I will put current trunk into
~arch as 2.1_beta20051210.

Well, I've already stated several times that IMO using a 2.1 branch is
wrong (use 2.2 instead), but if I'm overvoted, so it shall be.

As Brian stated, 2.2 being a version higher than 2.1 will have all the same 
expectations placed on it. From what I can see, 1% of users know anything 
about 2.1 so 99% would be wondering why there was a jump from 2.0 to 2.2.
Do you have anything against 2.1 other than fearing that people will expect 
more from it than it will turn out to be?

As for stable users? If arch teams are willing to selectively choose
what fixes they want backported to stable (when they're not prepared
to move the ~arch version into stable) things will go much smoother.
Of course, it would still be our responsibility to get those things
backported and assert some confidence that it is working. However,
once the requested fixes are backported all that needs to be done is
put out the patched stable version with ~arch keywords and then leave
it up to the arch teams again. Except for the slight extra burden on
(which I believe many would actually find to be a blessing), it
should be a win-win situation.

Just in case you forgot and also for general reference, when I asked
the arch teams about the portage keywording policy a few months ago
(wether we should stable even without testing on all archs or to
delegate that to arch teams) everyone seemed to be happy with the old
policy, at least nobody voted for a change. As portage doesn't really
have any arch specific code and a rather short dep list IMO it also
doesn't yield any real benefit other than more people testing it (which
is of course always a good thing).

Really, the bottom line is that regardless of what the response was when you 
asked about portage keywording, if all the arch teams had confidence in what 
we thought 2.0.53 would have been stable a long time ago. On the surface the 
only benefit is extra testing (which has already payed off) but it also 
allows others to take an active hand in the quality of portage as well as 
strengthens the communication channels. It's these auxillary benefits as well 
as the benefit of being able to focus on trunk more (which will yield faster 
rollout of features) that make me think it is the best way to go.

On Wednesday 07 December 2005 01:21, Alec Warner wrote:

I spoke with Brian today ( no clue if he will be sending mail or not )
but he stressed that he would like the cache rewrite in ~arch.

Any reason why you're speaking on his behalf?

From what I understood he was busy/moving IRL and didn't have time to 
catch up on his mail, so I told him I would send something expressing 
what he said when we spoke on IRC; he didn't explicitly tell me to do 
so, but I told him I was going to.

I would prefer that it be in .54, the code itself is old, 6+ months.  It is 
a straight backport from the 2.1 branch (the dead one) and the interface 
code to make it fit with 2.0 is small compared to the patch size ( Brian

estimated 100-150 lines ).

These are all reasons that I myself have given already.

I don't have a problem with releasing 2 ebuilds, one with the patch and one 
without ( or a use flag ) although the question that raises is will the 
cache rewrite actually end up in .54 final, or will it be put off :)  

This, I do have a problem with. You're essentially suggesting that three lines 
be maintained rather than the current two.

I can't tell if you followed what I said in my last email so I'll reiterate.
Trunk will go into ~arch on Saturday. 2.0.54 will go out (also in ~arch) two 
weeks after that with the two fixes and include the cache rewrite based on 
the opinion of a broad range of users (rather than just the noise makers). 
SHA1 will of course also go in based on how it is voted.

Bah, for some reason I kept thinking that the rewrite wasn't in trunk, 
but as I look in svn now I see it there; my apologies :/

The detailed explanation looks good to me ;)

-Alec Warner (Antarus)
-- mailing list

Re: [gentoo-dev] Around 425 non-existent packages in p.mask?

2005-11-22 Thread warnera6

Luis F. Araujo wrote:

Hello everyone,

A few days ago i glanced over package.mask , and i was surprised
about how many non-existent ebuild/packages entries are there.

So, i wrote a script to try to get a list of those orphaned entries,
and it looks like there are more than 400 packages/ebuilds which are still
listed in p.m but that don't exist in the tree anymore.
(A bunch of them from the KDE herd btw)

*Please* take a look at ,
for the list of these non-existent ebuilds/packages, in case you have 
forgotten something
in there. I'd like if  every person takes care of their own entries if 
possible. If not, i *personally* could go slowly removing the entries, 
along with other

people willing to help, or any other _better_ suggestion to deal with this?

I *of course* haven't checked all of the entry generated by the script 
manually ,
so there might probably exist packages which are indeed correct, so 
please re-check

before doing something.

I also noticed (slight detail) that there are a couple of recent entries 
at the bottom
of this file, isn't the policy to have new entries added at the top? , 
is there any special

reason for this?

Ok, that's all for now!

Looks like something that could be added to the list of unstable 
ebuilds deal that also gets sent here, simple to script... ;)

-- mailing list

Re: [gentoo-dev] Commercial software in portage

2005-09-22 Thread warnera6

Chris Gianelloni wrote:

On Thu, 2005-09-22 at 15:29 -0500, Brian Harring wrote:

Alternatives/better approaches I'd be open to, although I'll admit up 
front I think what you're attempting needs to be pkg specific, which 
implies DESCRIPTION in the ebuild (to me at least).

Snipping pretty much everything since I *really* don't care.

I'm just dumping this idea.  I was proposing it because of a
conversation with a user where we thought it would be a good idea to
give the user some way of knowing that a package requires some
additional purchased (or otherwise obtained) portion that is not a
distfile/tarball.  Anyway, you seem to have done a good job of
convincing me of whatever it is you think you've convinced me of, but
the truth is I just didn't care enough to bother getting into some
pointless pissing match over something that I didn't feel very strongly
about in the first place.  Basically, you win by default of me just
not caring enough to argue anymore.
A.  The above is kind of sad in terms of the outcome, I'm sorry more 
people didn't jive with your idea, but there is no need to cry about it.
B.  Whats wrong with stuffing it into metadata.xml and modifying p.g.o 
to pull the extra data out?  It certainly isn't that complicated.  Or 
just modify the DESCRIPTION field.  Doom3 - DESCRIPTION =  A popular 
first person shooter.  This game requires a license key to play. Simple no?

-Alec Warner
-- mailing list

Re: Two-level USE-flag system VAR: [gentoo-dev] USE=minimal for kernel sources

2005-09-22 Thread warnera6

Tom Fredrik Blenning Klaussen wrote:

 The average gentoo users are not stupid.
Many people would not agree with that statement ;)

come so far as to adjust something beyond the most basic USE flags at
all, you're probably advanced enough to deciphre such a message. (It
would be nice to have some knowledge of who the average gentoo user is

Now as for the USE flag system. It has actually become so big that it's
difficult to use it effectively.

  There is a USE flag group GLEP that is being implemented...sometime ;)
  I don't think masking USE flags has come up...*pokes portage people*

Also might want to submit the ebuild to breakmygentoo or some other

I'll consider it, but as mentioned above it's really a change to an

You can put eclasses in the overlay as well IIRC.

-Alec Warner (antarus)
-- mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

2005-09-19 Thread warnera6

Mark Loeser wrote:

Paul de Vrieze wrote:

I think that dev-util is a very specific category containing 
development utilities of some sort. There might be some 
misclassifications in them, but from a user perspective I don't really 
care about the language anything is written in. As C++ is so 
widespread I don't think that anything but app-misc or the like should 
be moved into a dev-cpp category.

This isn't for what the package is written in, but more for what the 
package is for.  If the package is a utility for use when doing coding 
with C++, like the ones I listed, then I think it should be in dev-cpp. 
 That's what the metadata for the category describes it to be.


Once again I'd like to point out that organizing packages in the tree by 
category is a stupid idea for this very reason.

-- mailing list

Re: [gentoo-dev] [RFC] Portability eclass

2005-09-16 Thread warnera6

Diego 'Flameeyes' Pettenò wrote:

On Friday 16 September 2005 19:28, Mike Frysinger wrote:

current stable does yes, but ive started adding customizable compression to

Okay, then *that* is a problem :P Suggestion how to fix it?

You are going to have to ask portage what it used via a PortageAPI call, 
I'd gather.

-- mailing list

Re: [gentoo-dev] USE=minimal for kernel sources

2005-09-08 Thread warnera6

Greg KH wrote:

On Thu, Sep 08, 2005 at 10:49:04PM +0100, twofourtysix wrote:

On 05/09/05, Petteri R?ty [EMAIL PROTECTED] wrote:

I have a couple of old machines I maintain and emerging and unmerging
kernel sources take a while because there are so many files. Also one
set of gentoo sources takes about 230MB of disk space. By removing stuff
not belonging to x86 I was able to succesfully run make with 58MB/230MB
removed. The stuff I removed:
arch/* except i386 and x86_64
include/asm-* expect asm-generic, asm-i386 and asm-x86_64

Is this safe?

No it isn't.  Please don't try to do this, it's not worth it.  If disk
space is limited, just build on one box, and install the kernel to the
other one.
IMHO it is, but not as a USE flag (it will never be stable enough 
without upstream support) but I think many would find the functionality 
useful in a script.  I know I would.  If it works most of the time and 
saves space, there is no reason not trim things.  If it breaks, you 
immediately revert to a normal build.

Or, put the kernel source on a cd, and build off of it (putting the
objects on your local disk.)  This lets you only use the local disk for
your built objects.


greg k-h

-- mailing list

Re: [gentoo-dev] tentative x86 arch team glep

2005-09-06 Thread warnera6

Ciaran McCreesh wrote:

On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer [EMAIL PROTECTED]
| What about !arch or something (to connect with the one reply to the
| summary thread) to really indicate unstable on that arch?  Should
| cover those things that sorda work on the arch, but you rather want
| developers or experienced users that can patch bugs to look at it ...

Those go in per-profile package.masks. It's more flexible than a

Speaking of flexabilty, are there tools out there to perform look-ups 
into p.masks to figure out why things are masked?  There seems to be a 
standard format to the file although the part at the beginning kind of 
throws off a simpler regex.  Flexability is good sure, but I would think 
a developer needs to easily determine why something is pmasked ( broken, 
testing, security, removal, etc... ) and keywords do that a lot faster 
than searching through a pmask file.  If the searching is sped up via a 
better format and a searching tool then all the better, yes?

The other thing being a keyword is right in the ebuild where pmask 
status is in package.mask.  I am not for putting pmask status in the 
ebuild though, as that is not necessary, once again a tool problem :/

-- mailing list

Re: [gentoo-dev] tentative x86 arch team glep

2005-09-06 Thread warnera6

Ciaran McCreesh wrote:

On Tue, 06 Sep 2005 17:41:35 -0400 warnera6 [EMAIL PROTECTED]
| Speaking of flexabilty, are there tools out there to perform look-ups 
| into p.masks to figure out why things are masked?

emerge -pv

emerge -pv would be a cludge for what many are after.  If I want to say, 
figure out how many mediawiki versions are pmasked; emerge -pv is a 
crappy way to go about it.  I will look into taking that code and put it 
in another, more flexable script ;)

-Alec Warner
-- mailing list

Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`

2005-08-17 Thread warnera6

Jon Portnoy wrote:

On Wed, Aug 17, 2005 at 03:45:49PM +0200, Henrik Brix Andersen wrote:

not everyone uses echangelog


it does, but not everyone uses echangelog

Why not?

Because I don't want to. :)

badjokeYou are the weakest link, goodbye!/badjoke
-- mailing list