Re: [gentoo-dev] Assigning bugs back to bug-wranglers@

[Jeremy Olexa]

On Mon, Jun 30, 2008 at 12:27 PM, Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> To anyone (else) out there who thinks that bug wranglers should be
> punished when they make mistakes in the heap of unthankful work they
> perform on a more than daily basis, I would like you to know that if
> you reassign bugs (back) to bug-wranglers@ without properly
> communicating the reason you are doing so, I have no option but to
> close the bug as CANTFIX. The reasoning is that bug-wranglers is a
> waystation (or perhaps a reception desk) between users and developers -
> we cannot begin to fix your bugs for you.

Sounds reasonable to me. Can't be too hard to do "Assigning back to
b-w's because I don't maintain this package" or similar.

On a side note: How is the "b-w SOP doc" coming? It is obvious to me
the b-w is tedious a time consuming so I would like to help every now
and then but I really am not sure about the rules wrt assignment just
by looking at metadata.xml. IMO, b-w'ing is something that anyone can
do.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] new eclass and portage category: octave-forge.eclass and dev-octave

[Jeremy Olexa]

> [3] 
> http://overlays.gentoo.org/proj/science/browser/overlay/eclass/octave-forge.eclass

You may want to look into making it eclass-manpages ready.

-Jeremy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] IBM article of interest ?

[Jeremy Olexa]

Philip Webb wrote:

080717 Jan Kundr�t wrote:

"01 Dec 2000 Updated 03 Jul 2008" [2]
[2] http://www.ibm.com/developerworks/linux/library/l-awk1.html


The '03 Jul 2008' has been added since I sent my comment to them yesterday !
However, the incorrect URL for Gentoo Technologies -- www.gentoo.org --
is still there, probably because I didn't mention it in my comment,
so I'll try sending them another.


I don't know all the details or the 'proper' way to handle what you are 
doing. But I wanted to say thanks for spending time on this.


-Jeremy

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Proposal: Make developer profiles more difficult to select

[Jeremy Olexa]

Nikos Chantziaras wrote:
Some kind of warning or other mechanism that does selecting this profile 
without knowing what you're doing would be a good idea.


This isn't enough?

%% grep KNOW *
make.defaults:I_KNOW_WHAT_I_AM_DOING="yes"

;)

Re: [gentoo-dev] Re: [RFC] New policy: LDFLAGS should be respected

[Jeremy Olexa]

Arfrever Frehtes Taifersar Arahesis wrote:

It will at least allow QA team to fix such bugs where patches are already
available.


So, if bugs are being fixed why is there a need to fix something that 
isn't broken with regards to a policy _needed_ to enforce this action? 
Are bugs being ignored or RESOLVED, WONTFIX?


Hypothetically, if there was such a policy and there was 100's of bugs 
filed with patches (maintainers should handle the patches anyway) this 
isn't any different than the present lack of policy. Let us also pretend 
that there were 100's of bugs filed that had no such patches 
available..would the QA team have the manpower to generate patches to 
fix this and apply them or would the bugs just rot in bugzilla and not 
achieve anything?


-Jeremy

Re: [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?

[Jeremy Olexa]

Please consider a new PROPERTIES=interactive setting that allows an
ebuild to indicate that it uses stdin and stdout for user


I don't think anyone will disagree with this one. The one problem that I 
see is that if the ebuild still doesn't have this value in it, portage 
will *look* like it has hung itself out to dry. I have no idea if this 
is easy to fix or not. If it is easy, then I still would like to propose 
that it gets sent to the foreground when in background mode. What will 
portage's behavior be when the user asks to be in background mode and 
there is an ebuild in the depgraph that has PROPERTIES=interactive? If 
it bails out, then the problem described above is moot (only if 
maintainers are diligent).


-Jeremy

Re: [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?

[Jeremy Olexa]

Zac Medico wrote:


Like Alec said, I don't think this is a difficult thing to get right
and even if the maintainer doesn't get it right initially then it's
not something that's very difficult to spot and fix. More elusive
bugs certainly do exist. That said, I still would like to make use
of the standard job control functions to detect and handle cases
like that. However, that does not entirely preclude the usefulness
of the knowledge that PROPERTIES=interactive is intended to provide.



I agree with all the points presented. Sounds like you have a pretty 
good plan here.


Thanks,
-Jeremy

Re: [gentoo-dev] The Plethora of Patches

[Jeremy Olexa]

Andrew D Kirch wrote:


Good points, I take it that you have found a mentor and are becoming a 
dev to drive this project then?


-Jeremy

Re: [gentoo-dev] The Plethora of Patches

[Jeremy Olexa]

On Thu, Aug 14, 2008 at 12:00 AM, Andrew D Kirch <[EMAIL PROTECTED]> wrote:
> Jeremy Olexa wrote:
>>
>> Andrew D Kirch wrote:
>> 
>>
>> Good points, I take it that you have found a mentor and are becoming a dev
>> to drive this project then?
>>
>> -Jeremy
>
> I've spoken in the past with both Elfyn McBratney, and Homer Parker. I have
> also submitted quite a few ebuilds via the bugs.gentoo.org system.  I have
> decided that I'm pretty much not willing to fight the uphill battle with the
> red tape that presently exists at Gentoo.  I found a problem, and wrote up a
> pretty sensible, and not difficult to implement solution for a problem that
> is both negatively affecting the code base Gentoo maintains, the quality of
> all FOSS code, and that has the potential to embarrass the Gentoo
> development community.
>
> Andrew

Ok, well.. If you have extra time available to write up a solution for
IMO, a non-issue, then you have time to devote to "dev stuff" - but,
if you don't want to become a dev then I would rather you didn't
anyway. Put it this way, maybe some of us have decided that our time
could be better used fixing Gentoo than fighting the uphill battle
with the red tape that presently exists at $UPSTREAM. It is a two-way
street for everyone in the FOSS world. Like I said, I like your
points. Personally, I try to submit everything upstream but I only
maintain very few ebuilds. I think this is common practice amongst
Gentoo devs.

List replies preferred. Have a good day,

-Jeremy

Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.

[Jeremy Olexa]

On Mon, Aug 18, 2008 at 5:12 PM, Tobias Scherbaum <[EMAIL PROTECTED]> wrote:
> John Brooks wrote:
>> Random idea: How about a different bug assignee for maintainer-needed
>> packages with provided ebuilds/patches? Either something generic, or
>> try to go for something more category/package specific (herds, etc).
>> Lots of work for bugwranglers, though. There is a huge difference to
>> developers between an unmaintained package with no progress and just
>> looking over an ebuild that has been used successfully by several
>> people.
>
> No need for an additional mail/bugzie alias here, we could simply use a
> KEYWORD like the existing 'Inclusion' (which isn't used that much for
> now, 63 open bugs have that keyword) or a new 'HasPatch' as a
> counterpart for 'NeedPatch'.

(This email isn't targeted towards Tobias - just replying)

What is wrong with the KEYWORD called 'EBUILD' defined as: "Marks an
issue to be a user submitted ebuild." ? You can easily make a search
that is assigned to maintainer-needed and has the EBUILD keyword (or
any keyword).[1]

I feel like you guys are trying to solve issues related to an
underlying problem but not actually targeting the problem itself. The
main issue is a lack of man-power. Also, devs willing to maintain
packages but then later retiring and leaving the packages in limbo.
Maybe there should be some policy such as, when devs retire if no one
else steps up to maintain the package, then it automatically gets
moved to sunrise overlay and only maintained packages stay in the
portage tree. This would cut down on our current 247 maintainer-needed
bugs[2] or our 35 bugs assigned to maintainer-needed with 'bump' in
the summary[3]. However, keep in mind that we do have 497 bugs
assigned to anyone with 'bump' in the summary[4].

Just some thoughts to ponder,
Jeremy

[1]: http://tinyurl.com/6y653y
[2]: http://tinyurl.com/6olohq
[3]: http://tinyurl.com/5d3tfl
[4]: http://tinyurl.com/689y5p

Re: [gentoo-dev] LICENSE and revbumps

[Jeremy Olexa]

Ryan Hill wrote:

On the other hand, it also seems completely ridiculous from a practical
POV to have to wait 30 days (and waste arch team resources) to fix an
incorrect licence on a stable package.


And have everyone recompile the package, thus wasting cpu cycles and 
users' time.


I would have to imagine that if upstream changed the license that the 
old installation would be covered by the old license. What do binary 
distributions do if an upstream changes the license? ;) Or are we 
talking about dev error here?


-Jeremy

[gentoo-dev] RFC: addition of virtual/fonts package

[Jeremy Olexa]

I'm thinking that a virtual/fonts package would be a good addition to 
the tree. We have hit this issue in Gentoo Prefix where any font package 
would satisfy a dependency. I also have an open bug where a package 
depends on corefonts but the reporter has stated that another fonts 
package will work. Frankly, I would rather *not* depend on the 
proprietary M$ fonts, myself. So my proposal would be to make every 
fonts package satisfy some virtual and then other packages can depend on 
that virtual to satisfy the need for *some* fonts. I just don't have a 
game plan for the best way to do it.


Do you people agree that this could be useful?
Does anyone have a suggestion for the best way to get it done?

Thanks for reading!
-Jeremy

[gentoo-dev] Re: Last rites: x11-terms/root-tail

[Jeremy Olexa]

Jeremy Olexa wrote:

# Jeremy Olexa <[EMAIL PROTECTED]> (12 Sep 2008)
# Masked for removal in 60 days. dead upstream, missed modular X 
transition.

# See bug #127193
x11-terms/root-tail



I have lifted this mask. Multiple users have said that it works and they 
want it in the tree. I also got it to work with additional research. See 
the latest comments on bug #127193 if interested.

Re: [gentoo-dev] Re: RFC: addition of virtual/fonts package

[Jeremy Olexa]

Ryan Hill wrote:

On Mon, 22 Sep 2008 22:03:53 -0500
Jeremy Olexa <[EMAIL PROTECTED]> wrote:

I'm thinking that a virtual/fonts package would be a good addition to 
the tree. We have hit this issue in Gentoo Prefix where any font

package would satisfy a dependency. I also have an open bug where a
package depends on corefonts but the reporter has stated that another
fonts package will work. Frankly, I would rather *not* depend on the 
proprietary M$ fonts, myself. So my proposal would be to make every 
fonts package satisfy some virtual and then other packages can depend

on that virtual to satisfy the need for *some* fonts. I just don't
have a game plan for the best way to do it.

Do you people agree that this could be useful?
Does anyone have a suggestion for the best way to get it done?


Is it something like currently deps on corefonts but liberation-fonts
works?  I think there was a bug open somewhere for that at some point.
I could see a virtual on a some agreed upon choice of core fonts, but
to have every font package in it...


Yes, that is my open bug that I have at the moment. bug #215661. But it 
is not the first time I have come across this. Maybe every font package 
satisfying a virtual is silly, I don't know. Maybe there are only a 
couple of package which can be interchanged, is it known which ones? If 
that was the case, then it is trivial to do || ( corefonts 
liberation-fonts ) and the case is closed here.




There are also lot of packages that depend on ttf-bitstream-vera that
might work just as easily with dejavu.



I have heard this as well.

Re: [gentoo-dev] Usage of econf with an additional || die

[Jeremy Olexa]

Ben de Groot wrote:


So, can we have a nice little table of which functions die by themselves
and which ones need || die added in ebuilds? Please?

Thanks,



A quick grep of /usr/lib/portage/bin clues you in that every function 
that is an external file does *not* die by itself. So, emake, do*, etc..


%% grep -c die * |grep -v ":0"
ebuild.sh:61
etc-update:14
isolated-functions.sh:18
misc-functions.sh:26
repoman:2

I believe this is because you can have those functions in a subshell and 
then die won't behave predictably. I'm sure some PM people will correct 
me if I am wrong. ;)


-Jeremy

Re: [gentoo-dev] Testing is not a valid reason to package.mask

[Jeremy Olexa]

On Thu, Oct 2, 2008 at 3:30 PM, Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> On Thu, 2 Oct 2008 22:24:35 +0200
> Jeroen Roovers <[EMAIL PROTECTED]> wrote:
>
>> # Gen 2 Developer <[EMAIL PROTECTED]> (`date`)
>> # Masked for testing.
>> >=rofl-cat/omgpkg-ver
>>
>>
>> Please people,
>>
>>
>>if you want to get something tested, then don't mask it. If you
>> find that you cannot commit an ebuild because of badly keyworded
>> dependencies, then drop the relevant keywords and file a bug report
>> with a KEYWORDREQ.
>
> Lest I forget, the exception being that a particular version should
> never ever go stable, in which case the masking reason should still be
> different. In that case you would still not mark it as "masked for
> testing" - what I wanted to clarify is that the mask reason isn't valid
> if you want stuff to get tested, as it prevents exactly that from
> happening.

I would argue that overlays are a bigger barrier to testing than being
"masked for testing"

At least they are exposed to the entire Gentoo population if they are
p.masked in the tree. Additionally, there are use cases for p.masking
for testing in the tree, especially if you have users testing it for
you. There shouldn't be a limit to the amount of self-QA that we
provide to "protect" the users, if so deemed necessary.

Just saying...
-Jeremy

Re: [gentoo-dev] "Slacking" arches - which are stable, which aren't?

[Jeremy Olexa]

Friedrich Oslage wrote:

Am Sonntag, den 05.10.2008, 16:26 -0500 schrieb Steev Klimaszewski:

Thoughts? Helps?



Afaik we have 3 types of arches:

- experimental
They are not CCed on stablization bugs and don't do stablizations at
all.

~mips, ~sparc-fbsd and ~x86-fbsd

- unsupported
They are CCed on stablizations bugs, but they are not supported by the
Gentoo Linux Security Project. It may take quite long until they
actually do the stablization. But I'm also wondering why some of their
profiles are marked as "dev".

arm, ia64, m68k, sh, s390

- supported
Most popular arches, supported by the Gentoo Linux Security Project,
they usually do your stablizations in time unless it requires some
exotic hardware(the devs/ats don't have) to test.

alpha, amd64, hppa, sparc, ppc, ppc64, x86

Sources:
- commits logs
- http://www.gentoo.org/security/en/vulnerability-policy.xml


I would suggest moving all the "slacking" arches to "experimental" until 
there is desire from the dev community (read: manpower) to support a 
stable tree again. Until then, it seems pretty pointless to keep 
assigning bugs to these arches and they just keep rotting there because 
no one gets around to them.


2 cents,
-Jeremy

Re: [gentoo-dev] Re: "Slacking" arches - which are stable, which aren't?

[Jeremy Olexa]

Steev Klimaszewski wrote:

On Sun, Oct 5, 2008 at 9:07 PM, Ryan Hill <[EMAIL PROTECTED]> wrote:

On Sun, 05 Oct 2008 20:44:51 -0500
Jeremy Olexa <[EMAIL PROTECTED]> wrote:


I would suggest moving all the "slacking" arches to "experimental"
until there is desire from the dev community (read: manpower) to
support a stable tree again. Until then, it seems pretty pointless to
keep assigning bugs to these arches and they just keep rotting there
because no one gets around to them.

2 cents,
-Jeremy

++ $473.57




My aim with the email wasn't to start up this discussion so much as to
figure out which arches are supported by stable keywords, and which
ones are okay to not request stable keywords so that bugs don't sit
around for months without action on them.  I know that vapier is
pretty much the only dev with an sh or s390 box, but I know there are
a couple of people with ARM, I was just hoping we had some sort of
official list somewhere.



I wasn't trying to go down that road either but you should know that 
this discussion will be forced there if there is to be any conclusion to 
this topic. AFAIK, it is incorrect right now to exclude s390, arm, sh, 
etc on stablereqs right now..But, I ask this question to the dev 
community: "Why?" There are ~190 open bugs with s390 as assignee or on 
the CC list. Does it *really* matter if these under-staffed "odd" arches 
have a stable tree or not? If there is a problem with a stable package 
right now, will there be a new version marked stable in a reasonable 
amount of time? I think we can conclude that having a stable tree for 
understaffed arches might cause more harm than good.


To conclude my input on the topic:
It is my opinion that filing stablereqs against these arches is silly. 
However, I will continue to do so until requested otherwise. I respect 
that people may not have enough resources or time to keep up to x86 or 
amd64, so maybe there needs to be a policy change somehow..? (or maybe 
it just needs to be clarified better)


-Jeremy

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

[Jeremy Olexa]

Fabian Groffen wrote:


Most notably, in Prefix all keywords are full GLEP53 style, which
results in e.g. amd64-linux.  We did this on purpose, because in Prefix
we don't necessarily are on Gentoo Linux.  We also chose to expand fbsd,
nbsd and obsd to their long variants, mainly because the short variants
might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD,
polyBSD or DragonflyBSD, DesktopBSD.  (At some point we were a bit
over-enthausiastic.)

I would like to hear some opinions on the keywords in general, as well
as the particular problem of having Gentoo Linux, and a Linux supported
by Gentoo Prefix.  Right now there is just the difference of "-linux"
appended, however this is not the clearest distinction between the two.
Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
and should we use something like PREFIX_KEYWORDS?



Ignoring the bit about how to name the keywords.. ;)

I am undecided about Prefix keywords in the normal KEYWORDS variable. In 
particular, we are overloading the -linux keyword to mean that it will 
run on any linux that Gentoo Prefix supports. This includes, Gentoo, 
RHEL, SLES, FreeMint, $OTHER.


Is there any problem with "overloading" the keywords like that? If not, 
then it shouldn't be a problem to keep prefix keywords in the KEYWORDS 
field. OTOH, I don't think we should add another variable to ebuilds.


Thoughts?

-Jeremy

Re: [gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI

[Jeremy Olexa]

On Thu, Oct 9, 2008 at 1:15 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Thu, 9 Oct 2008 19:46:55 +0200

> What's the scope of the changes? I think it'd be easiest to discuss
> this if you posted an informal summary describing the differences in
> terms of which bits of PMS are affected.

Ciaran, others:

In a way I feel like we (the Prefix project) are mis-using the EAPI
value. If we have something that is designed to work with *any* EAPI,
is it really a special EAPI? haubi said something on the gentoo-alt
list that made me think about this more:
"When an usecase of something is orthogonal to what that thing is
designed for, one should consider using a different thing for this
usecase." -source unknown

Is this PROPERTIES-like information? Is that easily supportable in the PM?

Re: [gentoo-dev] System packages in (R)DEPEND?

[Jeremy Olexa]

On Sun, Oct 12, 2008 at 12:04 PM, Thomas Sachau <[EMAIL PROTECTED]> wrote:
> I see packages like bison, flex, perl or sed in the system set. And i also 
> see ebuilds depending on
> them. I also heard from Peter Volkov (pva) that there where discussions about 
> removing different
> packages from the system set. So now my question is:
>
> Should we depend on all system packages? Should we depend on some packages, 
> because they could be
> removed? If yes, which ones? Or should we leave the system packages out 
> completly?

In my quick 30 seconds of searching I found at least one bug on this
very issue. You may find more if you look for them. ;)

https://bugs.gentoo.org/show_bug.cgi?id=221311

Please provide reasons/justifications for the proposal of removing
packages from the system set or from the ebuilds instead of just
raising random questions (which end up with no results and hence just
"noise").

-Jeremy

Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs

[Jeremy Olexa]

Robin H. Johnson wrote:

Notes:
--
1. For handling no-herd, we should add an entry into herds.xml to
   catch it (maintainer-needed  g.o). Every herd listed in an ebuild MUST 
be in
   herds.xml.


As rbu pointed out, this is slightly incorrect. Most of my ebuilds 
contain no-herd. ;) As do others.



2. Herds that do not wish to be contacted for specific bugs should add an
   maintainer element stating that (and use 'ignoreauto' on the element).
   This case however should be very rare, as the package probably doesn't
   belong in the herd if the herd doesn't care about it.
3. If you want the default assignment to go to a maintainer, and NOT the herd, 
   move the  element further down in the metadata.xml!


AFAIK, "default" now it is assign to maintainer and cc herd and nearly 
always herd is higher up in the file. So, [nearly] all ebuilds will have 
to change metadata.xml


OT, Do the changes to the bugzie interface block bugzilla 3 migration?

Re: [gentoo-dev] kerberos USE flag

[Jeremy Olexa]

On Fri, Oct 31, 2008 at 1:09 PM, Marius Mauch <[EMAIL PROTECTED]> wrote:
> On Fri, 31 Oct 2008 10:52:59 -0400
> Doug Goldstein <[EMAIL PROTECTED]> wrote:
>
>> Someone remind me again why we have the kerberos USE flag enabled by
>> default?
>
> AFAIK it was added so that the default profile provides support for
> joining a Windows domain (same for the ldap flag).

Sounds like a candidate for USE defaults, EAPI-1. Seems like a silly
design choice to add it globally, IMHO.

Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Jeremy Olexa]

Mark Loeser wrote:


I really don't understand why it is better to break the stable trees of 
$ARCH instead of just making them all ~ARCH. (ie. ~mips, ~x86-fbsd, 
etc). If the $ARCH doesn't have the manpower to do stable reqs then they 
don't have the manpower to fix broken stable trees either or do security 
bugs. So, IMHO, this proposal doesn't solve anything. With the key 
problem being that the 'slacker' arches can't keep up with the stable 
reqs and hence a large number of stale ebuilds and stale bugs being kept 
around.


-Jeremy

Re: [gentoo-dev] An official Gentoo wiki

[Jeremy Olexa]

Mark Loeser wrote:

So, gentoo-wiki.com went down for a awhile and took something away from
our users something that is useful.  Its back now, but I think we should
consider having our own official wiki that our users can contribute to.
We already have something very similar to this on the forums, and this
would just give the correct tool to put their documentation on.

I already know some people are going to hate this idea and say that the
documentation could be wrong, etc, so lets look at how others have
handled this situation.  It seems that Ubuntu has their own official
documentation section and a community section where users can contribute
to.  We can put a nice big warning saying that the user documentation
may have some errors, and that any such errors should not be directed at
the maintainers of the package or the GDP.

What are others feelings on this?  What issues do you see with having a
wiki?  Do you see anyway to resolve the issue you see with us having a
wiki?



I have been following gentoo-wiki's new procedures and rebuild process 
and I think they are on a good track right now.


I am throwing this out there, can we ask Mike Valstar for a dump of all 
his stuff, slap it on gentoo hardware under a wiki.gentoo.org link? It 
could be a "community building" experience and offering the stability of 
gentoo hardware to a service like gentoo-wiki. Maybe also invite Mike to 
be the admin of said hardware, etc. Thoughts?


(I don't know what a community wiki would require for infra hardware, 
maybe someone will chime in)


2 cents,
Jeremy

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/netbeans: ChangeLog netbeans-6.5-r1.ebuild netbeans-6.5.ebuild

[Jeremy Olexa]

Peter Volkov wrote:

В Сбт, 22/11/2008 в 18:11 +, Miroslav Sulc (fordfrog) пишет:

fordfrog08/11/22 18:11:25
  Added:netbeans-6.5-r1.ebuild
  Log: netbeans compiles fine even with JDK 1.6 so I dropped the restriction on 
JDK, also commons-fileupload linking fixed



Index: netbeans-6.5-r1.ebuild
===
pkg_setup() {
if use netbeans_modules_apisupport && ! ( use netbeans_modules_harness && use 
netbeans_modules_ide && use netbeans_modules_java ) ; then
eerror "'apisupport' USE flag requires 'harness', 'ide' and 'java' 
USE flags"


Additionally, 'apisupport', 'harness', 'ide' and 'java' are not USE 
flags. You have to set NETBEANS_MODULES, not USE. You can easily test 
this by trying "NETBEANS_MODULES="apisupport" USE="java" emerge -pv 
netbeans" and see that netbeans_modules_java does not get set.

-Jeremy


exit 1
fi


Why do you use exit 1 instead of die?


local tmpfileplatform="${T}/platform.txt"
cat ${tmpfile} | grep -v "libs.jna/external/jna-3.0.2.jar" > 
${tmpfileplatform}
mv ${tmpfileplatform} ${tmpfile}


grep can read files on it's own so no need for cat file | grep... Also possibly

sed -e "/libs\.jna\/external\/jna-3\.0\.2\.jar/d" -i ${tmpfile}

will work better here and in some other places...

Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins

[Jeremy Olexa]

On Wed, Aug 6, 2008 at 3:18 PM, Robin H. Johnson <[EMAIL PROTECTED]> wrote:

> Getting the bot out there
> -
> If you would like to have the new bot in your #gentoo-* channel, would
> each channel founder/leader please respond to this thread, stating the
> channel name, and that they are the contact for any problems/troubles.

Hi,
#gentoo-prefix please. I am the channel founder and am available on
irc for 'issues'
Thanks,
Jeremy

[gentoo-dev] Proposal for flag-o-matic.eclass (append-ldflags)

[Jeremy Olexa]

Hello,
I am seeking a positive code review on the following change to
flag-o-matic.eclass, diff is below (reasons are below that):

%% cvs diff
Index: flag-o-matic.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v
retrieving revision 1.126
diff -u -r1.126 flag-o-matic.eclass
--- flag-o-matic.eclass 3 Nov 2008 05:52:39 -   1.126
+++ flag-o-matic.eclass 25 Nov 2008 18:36:04 -
@@ -417,7 +417,8 @@

   x=""
   for x in "$@" ; do
-   test-flag-${comp} "${x}" && flags="${flags}${flags:+ }${x}"
+   test-flag-${comp} "${x}" && flags="${flags}${flags:+ }${x}" || \
+   ewarn "removing ${x} because ${comp} rejected it"
   done

   echo "${flags}"
@@ -656,7 +657,7 @@
   ewarn "Appending a library link instruction
(${flag}); libraries to link to should not be passed through LDFLAGS"
   done

-   export LDFLAGS="${LDFLAGS} $*"
+   export LDFLAGS="${LDFLAGS} $(test-flags "$@")"
   return 0
 }

Reason:
We hit this little gem in Gentoo Prefix when some ebuilds started
using flags that non-GNU linkers didn't accept and actually aborted
on. For example, the darwin ld does not accept --no-as-needed. So, the
initial work-around was to check to see if we had a GNU ld, and only
apply if so. (aside, further investigation revealed that GNU and
darwin ld are actually pretty non-clever in this regard. For example,
the hp-ux linker will just ignore non-valid flags) But this is not
very friendly to the lack of Gentoo Prefix developer availability. ;)

A convienient side effect of the above patch is that it protects
Gentoo users from typos in ebuilds. For example, "append-ldflags
--foo" will cause compilation to abort, but with the above patch, a
ewarn will be issued instead and compilation will continue. Besides
typos, if the GNU ld ever changes in some non-compatible way, there
will be less breakage.

There will be claims that additional checking to the flags should not
be added to Gentoo Linux because it is redundant (Gentoo only uses GNU
ld). However, time test-flags "$@" only takes 0m0.017s on my host. I
guess this number could be larger on less modern hosts..I don't know.

Comments? Good, bad, or otherwise? The Gentoo Prefix team always aims
to have as minimal diffs as possible from the gentoo-x86 tree, hence
the motivation for this request to review and inclusion into the
gentoo-x86 tree.

Thanks,
Jeremy

[gentoo-dev] Re: Proposal for flag-o-matic.eclass (append-ldflags)

[Jeremy Olexa]

On Mon, Dec 8, 2008 at 10:33 AM, Jeremy Olexa  wrote:
> Hello,
> I am seeking a positive code review on the following change to
> flag-o-matic.eclass, diff is below (reasons are below that):

Er, cancel that. The proposed patch isn't robust enough to catch
something like "append-ldflags -Wl,--bad-flag" As such, we will leave
it local to Gentoo Prefix until we can come up with a better idea.

Thanks,
Jeremy

[gentoo-dev] bash version in ebuilds/eclasses...non-compliance and what to do?

[Jeremy Olexa]

Exhibit A:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/python.eclass?r1=1.48&r2=1.49

This causes me pain on my hosts that don't have >=bash-3.1[0] for
/bin/bash. Because I can't install portage with an old bash until I
get a new python installed which uses python.eclass which isn't
supported with my /bin/bash (quite circular indeed)

Technically there are workarounds for me...but it is still annoying.
So...what do we do? A) Specifically allow >=bash-3.1 features in
ebuilds/eclasses. or B) revert the commit because the PMS says[1] that
we comply with >bash-3.0

Please discuss, thanks.
-Jeremy

[0]: See bash CHANGES file. "+=" is new to bash-3.1
[1]: "The ebuild file format is in its basic form a subset of the
format of a bash script. The interpreter is assumed to be GNU bash,
version 3.0 or later." -Chapter 6 "Ebuild File Format" [2]
[2]: http://dev.gentoo.org/~ferdy/pms/pms-eapi-2-approved-2008-09-25.pdf

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Jeremy Olexa]

Andrey Grozin wrote:

On Wed, 24 Dec 2008, Petteri R?ty wrote:

Who has been removing die statements? Is this a suggested way of action
somewhere by someone?
As recently discussed on the list, econf dies by itself, and || die 
should better be removed after econf. The same is true for, e.g., 
eqmake4. It was discussed (don't have a reference to the thread at hand) 
that it would be useful to have a table which shows which functions die 
by themselves, and which not.


Andrey



I see this asked every X months and never quite figured out why, (this 
isn't personal against you, Andrey)


%% pwd
/usr/lib/portage/bin
%% grep -l die *
ebuild.sh
etc-update
isolated-functions.sh
misc-functions.sh
repoman

So, that means that none of these die:
%% ls do*
dobin*dodoc*   dohard*  doinitd*  dolib.a*   domo*  dosed*
doconfd*  doenvd*  dohtml*  doins*dolib.so*  donewins@  dosym*
dodir*doexe*   doinfo*  dolib*doman* dosbin*

or

%% ls new*
newbin*newdoc*   newexe*newins*newlib.so*  newsbin*
newconfd*  newenvd*  newinitd*  newlib.a*  newman*

etc.

Take a look for yourself and you will see why there has never been a 
"table" or anything created. (it is trivial - and you have the source on 
your computer already)


Maybe this should be a question asked on the new dev quizies.."How do I 
tell if something dies on its own or not?"


HTH,
Jeremy

Re: [gentoo-dev] glep-42-news: sparc multilib profile

[Jeremy Olexa]

On Tue, Dec 30, 2008 at 8:04 AM, Friedrich Oslage  wrote:

> [1] http://dev.gentoo.org/~bluebird/sparc-multilib/

I would put it in the gentoo.org/doc/en/ domain and link to it in the
gentoo-sparc index
(http://www.gentoo.org/proj/en/base/sparc/index.xml)

2 cents,
Jeremy

Re: [gentoo-dev] Re: reorganization of /var/lib gentoo-related files

[Jeremy Olexa]

Fabio Rossi wrote:

On Wednesday 31 December 2008, Duncan wrote:


Except that... in theory, some or all of those apps could technically be
used on/for other distributions and platforms as well.


Yes, this is the theory but I think they'll be never ported to other 
distributions.


sabayon doesn't use these apps? How about gentoo based livecds, etc. ?

-Jeremy

Re: [gentoo-dev] [RFC] bugs.g.o supported overlays should register

[Jeremy Olexa]

Jeroen Roovers wrote:

 Hi folks,


in light of some recent discussions where overlay maintainers found
that bug reports had been assigned "incorrectly" and thought it was apt
to inform the miscellaneous bug wranglers of the correct assignees, I
thought it would be a good idea to introduce a new list, akin to
metadata.xml and herds.xml, to resolve this issue once and for all. As
with herds and metadata, this overlays.xml should list a repository's
name, HOMEPAGE and the e-mail address(es) of its maintainers.

In the absence of such information, a bug wrangler may assign the bug
report to someone who has contributed to the overlay in question, or to
anyone who might reasonably know whom to properly assign the bug report
to.

In case assignment goes awry, and when the assignee is part of the team
of proper assignees, then the team or assignee should make sure
overlays.xml is updated to reflect the current maintainance status and
should add the remainder of the assignees themselves. Nothing else
needs to be done in this case - the next time a different bug wrangler
might be handling a bug report about that overlay, so CC'ing or pinging
(on IRC) doesn't make sense - updating overlays.xml would. If the
assignee is not part of the maintainer team of the overlay in question,
then the bug may be bounced back to bug-wrangl...@g.o.

Please discuss.


Kind regards,
 jer



So you are asking for the layman file to be updated properly or what?

layman -i 

IMO, what would really benefit us is to have a site akin to 
http://gpo.zugaina.org/ on a Gentoo host to *find* packages that are in 
'official' overlays.


-Jeremy

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Jeremy Olexa]

On Tue, Jan 20, 2009 at 5:40 PM, Ferris McCormick  wrote:
> On Tue, 20 Jan 2009 23:50:47 +0100
> Jan Kundrát  wrote:
>
>> Ferris McCormick wrote:
>> > 'cp -i' will at least ask a question, and I find that marginally better
>> > --- it's confusing, but at least it says something.  But it seems to me
>> > that if we hit this case, no one (including the package owner) knows
>> > which .xml file to use, so stopping the build makes sense, but do it
>> > with some message that explains exactly what is going on.
>>
>> The problem is that the whole build won't *abort*, but rather become
>> interactive.
>>
>> I for one think that having it die (in the unlikely case that s
>> developer made a mistake) is better than letting it hang indefinitely
>> (in the unlikely case that a developer made a mistake) :).
>
> That's what I meant by "stopping the build".  My concern is that when
> we do stop the build, we do it with some useful error message and make
> it clear that the user did not screw up and so should do something to
> fix it.  ("die file exists" looks to me like an attempt to ask the user
> to fix something, not an ebuild problem.)

Sure. Makes sense.

>
> As I think about it, I am not sure how this could happen.  It would
> either be an ebuild that the package owner never tried or a change in
> the source file.  And why wouldn't a change in the source file cause an
> immediate termination because the length would suddenly be wrong?  And

Regardless of *how* it happens, my only point is to not put any
interactiveness in ebuilds for *whatever* reason. If it does prompt
for a response (again, for whatever reason) then all of portage's
background features are "broke" (waiting for input). So, as I
suggested in irc, the two solutions are to use the suggested method in
the OP or to set PROPERTIES=interactive in the ebuild..either way will
work. I would personally avoid the properties route on ebuilds that I
write though because it doesn't *need* to be interactive.

-Jeremy

> if the now-upstream-supplied build.xml file is different from the one
> the developer put together, wouldn't you probably want a revision bump
> at that point?
>>  Think about
>> insane users setting up cronjobs and what not...
>>
>> Cheers,
>> -jkt
>>
>> --
>> cd /local/pub && more beer > /dev/mouth
>>
> Clearly, I misspoke when I said I'd not respond further. :)
>
> Regards,
> Ferris
> --
> Ferris McCormick (P44646, MI) 
> Developer, Gentoo Linux (Sparc, Userrel, Trustees)
>

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Jeremy Olexa]

Donnie Berkholz wrote:

This is your one-day friendly reminder !  The monthly Gentoo Council
meeting is tomorrow in #gentoo-council on irc.freenode.net.  See the
channel topic for the exact time (but it's probably 2000 UTC).

If you're supposed to show up, please show up.  If you're not supposed
to show up, then show up anyways and watch your Council monkeys dance
for you.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/



Sorry for the late request.

Can we get a consensus on bash version in the tree? this thread[1] is 
unresolved. I understand that the PMS draft is not set in stone (or 
something), but please...let's progress and update the spec[2]. I feel 
that this makes it hard for other projects relying on Gentoo to do some 
things without being able to *know* what version of bash is allowed.


Currently, our /draft/ says bash-3.0 but our tree says otherwise.

[1]: http://thread.gmane.org/gmane.linux.gentoo.devel/59154
[2]: Or make the tree comply, I don't really care tbh.

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

[Jeremy Olexa]

Donnie Berkholz wrote:

On 21:28 Wed 21 Jan , Jeremy Olexa wrote:
Can we get a consensus on bash version in the tree? this thread[1] is  
unresolved. I understand that the PMS draft is not set in stone (or  
something), but please...let's progress and update the spec[2]. I feel  
that this makes it hard for other projects relying on Gentoo to do some  
things without being able to *know* what version of bash is allowed.


Which projects relying on Gentoo are having a hard time? It's helpful to 
know the impact of a problem when deciding what to do about it.




Well.. pet projects, nothing major really.

However,
In Gentoo Prefix, I found the issue in the original post on the other 
thread because my host system had bash-3.0 on it so I wanted to save a 
lengthy compile on an obscure platform. If Gentoo specs say "bash-3.X is 
guarenteed to work" then it is simple to say that we require that the 
user compiles this version while bootstrapping a new Prefix. Otherwise, 
its a mystery what works. Some platforms that I bootstrap on have 
bash-2.05 and it would be nice to *know* what I should upgrade to.


I think the spec should just be upgraded because it isn't exactly 
obvious to the casual dev what is a 3.0 feature vs 3.1, etc. We already 
have 3.1 features in the tree, I'm not sure where the red tape is here.

Re: [gentoo-dev] slot deps in package.mask and profiles

[Jeremy Olexa]

Jorge Manuel B. S. Vicetto wrote:

Hi.

I talked to Zac  earlier in #gentoo-portage about adding an
entry to package.mask for KDE-4.2.0 using slot deps. Thomas 
and Patrick  raised the concern we might need profile
eapis and that PMS nailed p.mask to EAPI-0.
Zac confirmed that the first stable version to support slot deps in p.
mask was 2.1.3.16, that it was stabled in bug 197165 - 14 months ago
- - and that the first stages to include it were the 2008.0 stages.
Thus, can we finally give the ok to use slot deps in package.mask? Can
we also give the ok to use it everywhere in all 2008.0 and later profiles/ ?


What happens on a 2007.0 base install if slot deps are used in p.mask? 
You only need to upgrade portage before anything else?


-Jeremy

Re: [gentoo-dev] slot deps in package.mask and profiles

[Jeremy Olexa]

Jorge Manuel B. S. Vicetto wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:

On 21:04 Sun 25 Jan , Ciaran McCreesh wrote:

On Sat, 24 Jan 2009 20:25:44 -0100
"Jorge Manuel B. S. Vicetto"  wrote:

I talked to Zac  earlier in #gentoo-portage about adding an
entry to package.mask for KDE-4.2.0 using slot deps. Thomas
 and Patrick  raised the concern we might
need profile eapis and that PMS nailed p.mask to EAPI-0.
Zac confirmed that the first stable version to support slot deps in p.
mask was 2.1.3.16, that it was stabled in bug 197165 - 14 months ago
- - and that the first stages to include it were the 2008.0 stages.
Thus, can we finally give the ok to use slot deps in package.mask? Can
we also give the ok to use it everywhere in all 2008.0 and later
profiles/ ?

The Council approved profile eapi files for use a while ago (can't
remember when -- http://council.gentoo.org/ isn't being updated), and

Last month's meeting


they discussed timeframes for using newer EAPIs then too. Did you see
that discussion?
"An EAPI=0 profile always needs to exist so that users with old portage 
can upgrade. Otherwise they will sync and have no valid profile 
available so cannot emerge a new version of portage.


"Decision: Approved. Existing stable profiles must use EAPI=0. New or dev 
 ^

profiles can use higher EAPIs.


Acoording to this we will never be able to use slot deps in package.mask
as it's a global file. Given my first mail, can we agree to make EAPI-1
the minimum EAPI for files under profiles/ ? Can we also create a rule
on how / when to update the minimum EAPI in profiles/ ?


So, portage that is unaware of EAPI-1 will just happily ignore the atom 
and move on..? In that case:


Please no! It is hard enough for a base 2007.0 install to be upgraded 
due to the "portage & bash blocker" (and other issues) - We need to wait 
much longer for an EAPI bump in a non-new profile (if ever, as Brian 
Harring suggests - I agree).


I know this might seem as a hassle to you but there *are* other entities 
that provide a base 2007.0 install. Who knows how every 
group/entity/company/etc use Gentoo.. While I agree that it isn't 
necessarily our problem, however, we shouldn't make it harder for them 
or anyone that has a 2007 base install. (We still mirror the 2007.0 
stages[1], 2007.0 cds are available[2] for purchase, etc[3] etc[4]).


IMO, it would be a dis-service to bump EAPI in a non-new profile for our 
user-base. I don't see any Pro's besides "easier to type" =/ So, I think 
the Council decision is appropriate.


-Jeremy

[1]: http://distfiles.gentoo.org/releases/x86/2007.0/
[2]: http://www.linuxcd.org/view_distro.php?lst=&id_cate=20&id_distro=12
[3]: http://lylix.net/linux-vps-plans
[4]: http://www.linode.com/faq.cfm




"Ref: 
http://archives.gentoo.org/gentoo-dev/msg_930f58fcebcbbcbe523c001f2c825179.xml";


I haven't finished & posted last month's summary 
 yet because of a 
long holiday vacation and lots of work deadlines after returning. I'll 
get all that stuff updated this week.

Re: [gentoo-dev] slot deps in package.mask and profiles

[Jeremy Olexa]

Alec Warner wrote:

On Mon, Jan 26, 2009 at 8:01 PM, Jeremy Olexa  wrote:

Jorge Manuel B. S. Vicetto wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:

On 21:04 Sun 25 Jan , Ciaran McCreesh wrote:

On Sat, 24 Jan 2009 20:25:44 -0100
"Jorge Manuel B. S. Vicetto"  wrote:

I talked to Zac  earlier in #gentoo-portage about adding an
entry to package.mask for KDE-4.2.0 using slot deps. Thomas
 and Patrick  raised the concern we might
need profile eapis and that PMS nailed p.mask to EAPI-0.
Zac confirmed that the first stable version to support slot deps in p.
mask was 2.1.3.16, that it was stabled in bug 197165 - 14 months ago
- - and that the first stages to include it were the 2008.0 stages.
Thus, can we finally give the ok to use slot deps in package.mask? Can
we also give the ok to use it everywhere in all 2008.0 and later
profiles/ ?

The Council approved profile eapi files for use a while ago (can't
remember when -- http://council.gentoo.org/ isn't being updated), and

Last month's meeting


they discussed timeframes for using newer EAPIs then too. Did you see
that discussion?

"An EAPI=0 profile always needs to exist so that users with old portage
can upgrade. Otherwise they will sync and have no valid profile available so
cannot emerge a new version of portage.

"Decision: Approved. Existing stable profiles must use EAPI=0. New or dev
^
profiles can use higher EAPIs.

Acoording to this we will never be able to use slot deps in package.mask
as it's a global file. Given my first mail, can we agree to make EAPI-1
the minimum EAPI for files under profiles/ ? Can we also create a rule
on how / when to update the minimum EAPI in profiles/ ?

So, portage that is unaware of EAPI-1 will just happily ignore the atom and
move on..? In that case:

Please no! It is hard enough for a base 2007.0 install to be upgraded due to
the "portage & bash blocker" (and other issues) - We need to wait much
longer for an EAPI bump in a non-new profile (if ever, as Brian Harring
suggests - I agree).

I know this might seem as a hassle to you but there *are* other entities
that provide a base 2007.0 install. Who knows how every
group/entity/company/etc use Gentoo.. While I agree that it isn't
necessarily our problem, however, we shouldn't make it harder for them or
anyone that has a 2007 base install. (We still mirror the 2007.0 stages[1],
2007.0 cds are available[2] for purchase, etc[3] etc[4]).


Dude, even people like Ubuntu/Canonical don't support stuff that old
(current LTS is April 2008).

The tree is now; see the date?  It's 2009, not 2007.

One of the biggest problems Gentoo has is backwards compatibility and
legacy stuff; it is the nightmare of every project and there has to be
a point where you say 'tough.'  So make a decision, announce it widely
that on X date the tree will just break for users; write up a FAQ on
how to upgrade past it, and then make the changes.


2008.0 was released on Jul 6 2008[1]. So, you think that after 6 months, 
it is time to say "tough"? Sorry, I don't agree.


[1]: http://www.gentoo.org/proj/en/releng/release/2008.0/index.xml#doc_chap2



Realize once again that the tree was not designed very well and it has
issues on a number of levels and it can't all be engineered around;
and for progress to be made you will *have to break existing stuff*.


IMO, it would be a dis-service to bump EAPI in a non-new profile for our
user-base. I don't see any Pro's besides "easier to type" =/ So, I think the
Council decision is appropriate.


You seriously see no benefits to EAPI 1 or 2 in profiles?  What about
slot deps? use deps? these things have been core feature requests
since 2003; surely you don't think they are useless to our users?


No, I didn't say that at all, *sigh*




-Jeremy

[1]: http://distfiles.gentoo.org/releases/x86/2007.0/
[2]: http://www.linuxcd.org/view_distro.php?lst=&id_cate=20&id_distro=12
[3]: http://lylix.net/linux-vps-plans
[4]: http://www.linode.com/faq.cfm

Re: [gentoo-dev] Packages up for grabs

[Jeremy Olexa]

Donnie Berkholz wrote:


app-misc/colordiff
sys-process/iotop


I picked up these two. metadata changed. I'll get to the bugs next week 
sometime.


-Jeremy

Re: [gentoo-dev] GCC 4.3 patches will be applied nowish

[Jeremy Olexa]

On Sun, Feb 8, 2009 at 1:54 AM, Ryan Hill  wrote:
> All bugs blocking #198121 having obviously correct (eg. missing header)
> patches will be applied by me in the coming week.  If you have concerns
> about me touching your package (i swear i'll wash my hands first),
> please let me know.
>
> As always, applying these patches yourself makes me a happy monkey.
>
> I'll try to have this done by the end of the week.  I will also handle
> filing of stabilization bugs for these packages at the end of
> February.
>
> https://bugs.gentoo.org/showdependencytree.cgi?id=198121&max
> depth=1&hide_resolved=1

Ryan,
Surely, at this point we aren't going to let all those bugs hold up
gcc-4.3 stabilization? Most of which were only found via Diego's
tinderboxing which implies that no user cares enough about the package
to report a bug (or no one uses the package). I've been working on the
gcc-4.3 stabilzation tracker and all the bugs now have arches CC'd on
the bugs so, once the glibc-2.8 stab tracker is resolved (which Fauli
has been working on) I think we should be good to mark gcc-4.3 stable.

-Jeremy

Re: [gentoo-dev] Packages up for grabs

[Jeremy Olexa]

On Wed, Feb 11, 2009 at 12:02 PM, Santiago M. Mola  wrote:
> Hello,
>
> All my packages are up for grabs. Feel free to add yourself to
> metadata.xml and don't hesitate to ask me any doubts about them.

I hope this doesn't mean you are retiring.. =/

> app-shells/bash-completion

I already have a snapshot script for this and have been meaning to
bump our version. I'll just add myself to metadata now.

Thanks,
Jeremy

[gentoo-dev] Time to remove app-shells/bash-completion-config

[Jeremy Olexa]

Hello,
I would like to request that bash-completion-20081218 to be marked
stable by the arches soon here.

In doing so, I'm going to make the following change to bash-completion.eclass:

-RDEPEND="bash-completion?
-   ( || (
-   app-admin/eselect
-   app-shells/bash-completion-config
-   )
-   )"
+RDEPEND="bash-completion? ( app-admin/eselect )"

We should only be using eselect now to enable bash-completion. I think
bash-completion-config is broken now anyway
(https://bugs.gentoo.org/show_bug.cgi?id=253878). So, after this
change, I will p.mask b-c-c for removal.

Any concerns? The upgrade path in the future is going to be wierd as
upstream is releasing v1.0 soon, but that is not concern for now.
Thanks,
Jeremy

Re: [gentoo-dev] Time to remove app-shells/bash-completion-config

[Jeremy Olexa]

On Tue, Feb 17, 2009 at 1:49 PM, Donnie Berkholz  wrote:
> On 11:55 Tue 17 Feb , Jeremy Olexa wrote:
>> We should only be using eselect now to enable bash-completion. I think
>> bash-completion-config is broken now anyway
>> (https://bugs.gentoo.org/show_bug.cgi?id=253878). So, after this
>> change, I will p.mask b-c-c for removal.
>>
>> Any concerns? The upgrade path in the future is going to be wierd as
>> upstream is releasing v1.0 soon, but that is not concern for now.
>
> http://bugs.gentoo.org/show_bug.cgi?id=218557
>
> [Comment #0] mescali...@gentoo.org : 2008-04-20 12:26:38 
> ---
> if I type:
>
>  eselect bashcomp enable [TAB]
>
> I get a 'Killed' string printed to terminal:
>
>  eselect bashcomp enable Killed
>
> and it messes up the bash shell (i.e. history doesn't work anymore)
>
> [Comment #3] w.schwie...@web.de : 2008-07-31 00:41:39 
> ---
> Created an attachment (id=161784)
> Replacement for the current eselect completion script

This is not a fault of bash-completion but rather the eselect
bash-completion module itself. Since our eselect team is defunct, I
will mask the bash-completion USE flag for app-admin/eselect unless
someone steps up to take care of it (working patches exist, anyone?).
Analogy: If subversion's bash-completion module was broken, it
wouldn't block anything to do with app-shells/bash-completion. Instead
you would work it out with upstream.

Also: *enabling* bash-completion modules via eselect works just fine.
So, I don't get why this reply was needed on this thread.

-Jeremy

[gentoo-dev] Re: Time to remove app-shells/bash-completion-config

[Jeremy Olexa]

On Tue, Feb 17, 2009 at 11:55 AM, Jeremy Olexa  wrote:
> Hello,
> I would like to request that bash-completion-20081218 to be marked
> stable by the arches soon here.
>
> In doing so, I'm going to make the following change to bash-completion.eclass:
>
> -RDEPEND="bash-completion?
> -   ( || (
> -   app-admin/eselect
> -   app-shells/bash-completion-config
> -   )
> -   )"
> +RDEPEND="bash-completion? ( app-admin/eselect )"

Done. Use app-admin/eselect to enable bash completion modules.

-Jeremy

[gentoo-dev] treecleaner policy change wrt removal date

[Jeremy Olexa]

Small change:

Effective immediately "30 days notice" is becoming 30-59 days and "60 
days notice" is becoming 60-89 days.


Basically, all removal dates are going to be the last day of the month 
in whichever month is appropriate. This allows us to process many bugs 
at once. You won't see an exact count of days in the package.mask file, 
though. Meaning: we will still say "removed in 30 days" but the bugs 
will say "Removal date: "


Thanks,
Jeremy

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Jeremy Olexa]

Petteri Räty wrote:

Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post a single reply to this thread in order to make it
easy to read through. The existing thread should be used for actual
discussion about the GLEP and the alternatives. This should be a useful
experiment to see if we can control ourselves :)

My notes so far:

1) Status quo
  - does not allow changing inherit
  - bash version in global scope
  - global scope in general is quite locked down

2) EAPI in file extension
  - Allows changing global scope and the internal format of the ebuild
  a) .ebuild-
- ignored by current Portage
  b) ..ebuild
- current Portage does not work with this
  c) ..
- ignored by current Portage

3) EAPI in locked down place in the ebuild
  - Allows changing global scope
  - EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache
  - Does not allow changing versioning rules unless version becomes a
normal metadata variable
* Needs more accesses to cache as now you don't have to load older
  versions if the latest is not masked
  a) 
  b) new subdirectory like ebuilds/
  - we could drop extension all together so don't have to argue about
it any more
  - more directory reads to get the list of ebuilds in a repository
  c) .ebuild in current directory
  - needs one year wait

Regards,
Petteri



Thanks for gathering input from the dev community. I do not wish to 
respond to the monster thread (and won't).


Personally, I don't need the flexibility that glep55 provides for *my* 
ebuilds. The current scheme doesn't bother me. And actually, after doing 
some testing, I found that at least one of that packages/projects that I 
am involved in will need updating every time the extension changes (or 
some more broad change - I don't have time to investigate too much tbh). 
So, I would prefer that the file extension did not change [much/every 
eapi]. However, I can roll with the punches if it truely is needed. I 
also understand that some change is good in the long run even if it has 
some upfront cost to it.


However, in case that this discussion gets deferred until later, I would 
like to express that the Council should "request" (not demand) that 
portage adds support for the leading 2 ideas that result from the 
current discussion. This will allow us to not wait even longer when we 
are having this discussion in 2010 (hypothetically).


Thanks for listening, Petteri.
-Jeremy

Re: [gentoo-dev] Should that file be a License ?

[Jeremy Olexa]

Mounir Lamouri wrote:

On Mon, Feb 23, 2009 at 10:44 AM, Marijn Schouten (hkBst)
 wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mounir Lamouri wrote:

Hi,

I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
#258518) but upstream added a file named p2pnat_license.txt (see
http://dpaste.com/123376/) This file looks to authorize gnugk project
(and users) to use p2pnat technology. gnugk is already licensed under
GPL-2 and I was wondering if this new file should be considered as
another license and if it has to be in the LICENSE line ? In this case,
should the file be added like he is in the gnugk tarball or should it be
"templatized" like most licenses ?

Thanks,
Mounir


That paste is gone/expired.


I attached it to this email.


Mounir



bump. Can anyone help out here? Is it a license or a doc?

http://dev.gentoo.org/~darkside/tmp/p2pnat_license.txt

thx.

Re: [gentoo-dev] Developer Retirements

[Jeremy Olexa]

On Mon, Mar 9, 2009 at 1:44 PM, Doug Goldstein  wrote:
> I'm wondering what exactly is the harm in letting developers idle for a
> while? While they might not be actively committing they are still
> knowledgeable people that are just as capable as everyone else to push in a
> fix for small packages. There's lots of bugs in bugzilla with items that
> just need someone active to commit them. There's even a lot of these items
> are filed by retired Gentoo developers who could have easily pushed this fix
> for all users. The fact that someone only does one commit a year does not
> marginalize their contribution. While it may be small it is improving the
> overall quality of the distro. I'm constantly seeing developers getting
> upset over getting pushed out.

The problem comes when $idle_dev has XX bugs assigned to them and they
don't get resolved and no one else knows that there are issues. Then
users get the attitude that they shouldn't even file bugs because no
one fixes them and they just sit there.

So, I agree with you as long as $idle_dev doesn't pretend to maintain
packages and the team that they belong to doesn't consist of people of
the same activity level. (rendering the team useless too).

2 cents,
-Jeremy

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Jeremy Olexa]

Tiziano � wrote:

Hi everyone

With eapis 1 and 2 we introduced nice features but also a couple of new
problems. One of them are the use dependencies when the package you
depend on doesn't have the use flag anymore (see [1] for an example).

So I think it's time for a short eapi bump with some distinct
improvements:


I'm replying to the top level because I don't think any of the ideas are 
particularly bad. However, I wanted to raise this point:


Should the next EAPI (as proposed) be a major "release" in terms of 
naming? And should it really be adding features? It is my opinion that 
EAPI bumps should move slower, one every year or so, in order to 
preserve upgradeable options for people that don't update often. 
However, I'm not going to let my opinion here block progress if it is 
needed.


I would propose that EAPI="2.1" be an extension of EAPI="2" and be 
limited to only bug fixes as presented instead of smashing the bug fixes 
in EAPI="3" along with new features.


With that said, can't bug fixes be implemented without an EAPI bump? I 
suppose that is not exactly safe in all cases.. =/ But, we should do a 
better job fixing "bugs" while the EAPI is in ~arch still. No, I don't 
have any ideas on how to accomplish that.. =P


(Don't let this post turn into bikeshedding wrt naming options, just 
throwing it out there without wanting to defend it too much)


-Jeremy

Re: [gentoo-dev] Developer Retirements

[Jeremy Olexa]

Marijn Schouten (hkBst) wrote:


As opposed to those same bugs being assigned to maintainer-needed and getting
lots of attention?



The inactive dev can just as easily resolve a m-needed bug as one that 
is assigned to himself. The added benefit that some people actually look 
at the m-needed queue on rainy days. (me, patrick, loki_val, etc).


-Jeremy

Re: [gentoo-dev] gentoo KVM images now available :)

[Jeremy Olexa]

On Fri, Mar 13, 2009 at 6:53 AM,   wrote:


Hi,
I already posted some initial images on tinderbox.

http://tinderbox.dev.gentoo.org/virtualization/amd64/

Some weeks old by now. But I am fairly confident that image building
can be made automatic via scripting. Granted, I did not make an
announcement of my latest images just the old ones[1], it is just a
pet project for me in its current state. It is extremely easy to make
a new image for others with the weekly automated builds now.

-Jeremy

[1]: http://blog.jolexa.net/2008/11/14/on-virtualization/

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Jeremy Olexa]

Alexey Shvetsov wrote:

Alec Warner wrote:

I am interested in the number of ebuilds at specific APIs in the tree,
do you have those numbers?
Basically, how much work is this (raw ebuild count)?


Total ebuilds   26209
EAPI0 ebuilds   22880
EAPI1 ebuilds   1855
EAPI2 ebuilds   1474

this numbers based on regexps =)



With these numbers, I don't exactly see the point of deprecating EAPI0. 
Too much work that we could be spending elsewhere.. Although, I suppose 
someone will propose to make the "default EAPI" be 1 instead of 0. I 
don't see a point for that either.


-Jeremy

Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

[Jeremy Olexa]

Alin Năstac wrote:


Fine, then remove $PV from patch name and use it in any ebuild version
you want. Or just decouple the patch version from the ebuild version
(foo-bar-r1.patch sounds OK to me).



What exactly is your problem that you are trying to solve here? Posting 
to the community to stop doing something without providing reasons to 
stop is not going to go anywhere. I like having the PV in the patch 
name..so, you haven't convinced me.


-Jeremy

Re: [gentoo-dev] Re: Please review: prefix.eclass

[Jeremy Olexa]

On Wed, Apr 1, 2009 at 4:13 AM, Christian Faulhammer  wrote:
> Hi,
>
> Donnie Berkholz :
>
>> On 12:59 Fri 27 Mar     , Fabian Groffen wrote:
>> > This eclass facilitates in some of the needs of the Gentoo Prefix
>> > project.  For now it provides the 'eprefixify' function, which is
>> > often used in Gentoo Prefix ebuilds to incorporate the used offset
>> > prefix into files.
>>
>> It's great to see you moving toward folding this back into the main
>> tree! My only comment is that eprefixify could really use a better
>> name because that one sounds really awkward. How about doprefix, or
>> something else?
>
>  To install a prefix file?  Like doman, dobin. :)

Not that I want to start an argument over a function name but it helps
if you understand what eprefixify() does.

eprefixify simply does a 's/@GENTOO_PORTAGE_EPREFIX@/$EPREFIX/' where
EPREFIX is expanded to its abs value. The common use case for
eprefixify is on installed scripts where you should be able to run the
program in a prefix shell or not. (ie. you should be able to run it
without EPREFIX being set in your env - this is true of all prefix
executables)

So, no, we do not exactly feel like a do* name is appropriate because
this function is not installing anything. In a sense, we made
'eprefix' a verb and that really seems to make sense to new devs and
new users.

-Jeremy

[gentoo-dev] RFC: best way to introduce USE=prefix

[Jeremy Olexa]

Hello all,
In the Gentoo Prefix project we have a special USE flag: 'prefix',
kind of like $ARCH USE flags. I am writing here to ask of the best way
to introduce a global implicit USE flag to gentoo-x86. There has been
some interest from other devs to kill diffs in ebuilds between
gentoo-x86 and prefix overlay. The addition of this USE flag will
allow this to happen in a more staged approach.

We utilize the prefix USE flag for various things, such as (but not limited to):
-Exclude dependencies that the host OS provides (glibc, xorg-server, etc)
-No-op a particular action not appropriate for prefix
-Ensure a particular action that is only needed for prefix

ie.
# unavoidable conditional patch, can't submit upstream either, rare case
use prefix && epatch prefix-search-path.patch
# glibc is provided from the host OS, at least can't install in prefix
!prefix? ( elibc_glibc? ( >=sys-libs/glibc-2.36 ) )
# rarely seen in real life, but something like this is possible.
$(use_enable !prefix some-host-os-feature)

So, my recommendation is to:
1) mask the prefix USE flag in base/use.mask because no one except the
prefix profiles should use this flag.
2) unmask and force the USE flag in prefix profile.
3) add entry to use.desc.
addendum) use.{mask,force} imply that the USE flag is explicit so
there will be no QA warnings.

However, we have toyed with other ideas. One of which is to introduce
IUSE=prefix in prefix.eclass similar to the USE=multilib approach. I
don't really like this idea because it exposes the use flag and we
don't want it exposed to the users.

BTW, the prefix profiles are not in gentoo-x86 yet, discussion will
follow the USE flag introduction.

Thanks,
-Jeremy

Re: [gentoo-dev] RFC: best way to introduce USE=prefix

[Jeremy Olexa]

On Sat, Apr 4, 2009 at 2:47 PM, Fabian Groffen  wrote:
> On 04-04-2009 20:41:34 +0100, Ciaran McCreesh wrote:
>> The two aren't mutually contradictory. Quite the contrary.
>>
>> For EAPI 3, we're aiming to make it illegal to do anything with a flag
>> unless it's either explicitly listed in IUSE or handled via a number of
>> special magic profile variables, so you'd either have to list it
>> everywhere or use one of the profile variables. Once you do that, how
>> you mask / force it is up to you, unless you need some kind of special
>> package manager handling for that flag.
>
> Sounds to me it would be ok then to add it now in use.mask, and then
> EAPI 3 is done, define it in whatever special variable it needs to be
> added to according to the specs then.  IUSE_IMPLICIT -- assuming it can
> be defined in the profiles -- seems like a good way to prepare for that,
> since it makes explicit it is implicit, IMO.

Alright, I have talked to a few people in IRC. This solution seems to work:

* IUSE_IMPLICIT="prefix" in base/make.defaults (for EAPI-3 and greater)
* prefix in base/use.mask (so no profiles will be able to use it
unless specifically unmasked)
* unmask USE=prefix and force it in prefix profiles - not in gentoo-x86 yet

Patch located here if anyone cares to look:
http://dev.gentoo.org/~darkside/tmp/USE-prefix.patch

This is the combined logic of this thread, anything I overlooked?

Thanks,
Jeremy

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

[Jeremy Olexa]

Mart Raudsepp wrote:

Hello,

I have had this project in my mind for a while, so it's about time to
get it out there, as to see if feedback finds it a good one - and if
that is so, if there are people who want to make it happen.



Hmm, I wonder what the point is when there is 400 maintainer-needed bugs 
open..


I think a maintainer-wanted team won't accomplish much because it just 
uses more developer time from a pool of "not enough time" that exists 
already. If people are a) too lazy to contribute to sunrise, b) don't 
know about sunrise, or c) don't know enough about ebuilds to contribute 
to sunrise, then we need to fix[1] that.


I don't see any reason to create a team that duplicates the sunrise 
work. Keep in mind, I am against pretty much any overlay, I think work 
should be kept in the main tree. But, for ebuild maintenance with 
limited developer time, sunrise just makes sense(tm).


Some other possible directions include:
1) maintainer-needed team - Where a group maintains the set of 761 
m-needed packages.
2) proxy maint project[2] - Where a group helps users commit to the main 
tree, very similar to the sunrise project. Very similar to this proposal 
but better conserves our developer time.


-Jeremy

[1]: http://dev.gentoo.org/~darkside/sunrise_proposal.txt
http://dev.gentoo.org/~darkside/sunrise_status.txt
[2]: http://dev.gentoo.org/~antarus/projects/proxy-maint/

Re: [gentoo-dev] The fallacies of GLEP55

[Jeremy Olexa]

On Thu, May 14, 2009 at 2:06 PM, David Leverton
 wrote:
> yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid shell (at
> least if we decide to allow bash 3.1 features), and has the same effect

To stir things up:
Who decides this? There are more and more bash-3.1 features in the
tree and I brought it up to the Council months ago becase the PMS says
that only bash-3.0 is allowed but no one cares.

-Jeremy

Re: [gentoo-dev] RFC: Gentoo Support Everywhere

[Jeremy Olexa]

Comments welcome, and thanks for reading.


(replying to random)

Look, there has been a whopping 6 developer comments on this thread - 
none of them opposed. This means to me that you should continue on with 
your plan. You are already a moderator of our forums, so get someone 
with cvs access (probably whomever committed 
http://www.gentoo.org/proj/en/gse/ ) to add more content to that page 
and make it official.


Like you said, you are already doing this anyway, so it isn't going to 
be "more work" for anyone.


Oh, and I would make this a subproject of the forums project too. It 
wouldn't be anymore work for the forums people and you can be the lead 
of GSE without involving the higher level project. It just makes sense, 
IMO, because forums and GSE are so closely related.


Long story short, "just do it"

-Jeremy

Re: [gentoo-dev] RfC: News item for Baselayout 2 stabilisation

[Jeremy Olexa]

On Wed, May 20, 2009 at 10:39 AM, Christian Faulhammer  wrote:
> Hi,
>
> there is no set date, but I want to post a GLEP 42 news item before the
> actual stabilisation.  Maybe other channels like the web page can carry
> that news then, too.  Please comment the attached news item.
>  Vapier wanted to know, if it is possible that the news item is
> displayed user has (a) Baselayout 1 installed while (b) Baselayout is
> stable.  From what I know there is no such conditional for a news item,
> but I may be wrong.
>
> V-Li

I hope it goes without saying that bug 213988
(http://bugs.gentoo.org/213988) should be resolved before either
stabilization or news posting. The doc is somewhat out of date now.

-Jeremy

Re: [gentoo-dev] RfC: News item for Baselayout 2 stabilisation

[Jeremy Olexa]

On Wed, May 20, 2009 at 2:13 PM, Josh Saddler  wrote:
> Jeremy Olexa wrote:
>> I hope it goes without saying that bug 213988
>> (http://bugs.gentoo.org/213988) should be resolved before either
>> stabilization or news posting. The doc is somewhat out of date now.
>
> I assume you mean the baselayout-2/openrc migration guide?
>
> Not as far as we know. And what we, the GDP, *know* is entirely
> dependent on the bug reports and *guide updates* that you, the rest of
> the community, submit. :)
>
> (Yes, we know that our other documents do not have anything about
> baselayout-2/openrc in them. That's why we have the tracker bug. If
> you've got something to report, send it in!)
>
>

Uhh, I submitted one bug but it was promptly ignored because "the GDP
doesn't work on docs for unstable ebuilds" - which is why I raised
this point ;) After that one bug, I lost motivation to file bugs
because it landed on /dev/null.

-Jeremy

Re: [gentoo-dev] RfC: News item for Baselayout 2 stabilisation

[Jeremy Olexa]

On Wed, May 20, 2009 at 2:36 PM, Jeremy Olexa  wrote:
> On Wed, May 20, 2009 at 2:13 PM, Josh Saddler  wrote:
>> Jeremy Olexa wrote:
>>> I hope it goes without saying that bug 213988
>>> (http://bugs.gentoo.org/213988) should be resolved before either
>>> stabilization or news posting. The doc is somewhat out of date now.
>>
>> I assume you mean the baselayout-2/openrc migration guide?
>>
>> Not as far as we know. And what we, the GDP, *know* is entirely
>> dependent on the bug reports and *guide updates* that you, the rest of
>> the community, submit. :)
>>
>> (Yes, we know that our other documents do not have anything about
>> baselayout-2/openrc in them. That's why we have the tracker bug. If
>> you've got something to report, send it in!)
>>
>>
>
> Uhh, I submitted one bug but it was promptly ignored because "the GDP
> doesn't work on docs for unstable ebuilds" - which is why I raised
> this point ;) After that one bug, I lost motivation to file bugs
> because it landed on /dev/null.

Sorry, ignore me here. Josh updated the guide for my bug but it just
wasn't resolved yet.

Re: [gentoo-dev] RFC: Gentoo Support Everywhere

[Jeremy Olexa]

On Wed, May 20, 2009 at 3:08 PM, Dale  wrote:
> Alistair Bush wrote:
>> Dale wrote:
>>
>>
 The Gentoo subforum on LQ would help to collect the posts in one place.


>>> That would be the point.  Gentoo has its own forum so why have two
>>> forums?  What would be the point in having two places to go look for
>>> answers?  Better yet, why would Gentoo support both forums?
>>>
>>> I'm a member at LQ tho I haven't been there in a long while.  I just
>>> don't see why there has to be two forums when the one forum we have is
>>> more than enough.  If someone can't find the Gentoo forums, I'm not sure
>>> they can find the chair and keyboard either.  lol
>>>
>>>
>>
>> How about we ask for a subforum to be created with a BIG STICKY telling
>> it is better to ask support questions at forums.gentoo.org
>>
>> Could it be possible that users don't know about f.g.o?  ( find it
>> highly unlikely actually)
>>
>> Alistair
>>
>>
>>
>
> I'm not 100% against this.  I do like your idea a lot tho.  I have two
> things that concern me but may not make sense to anyone else.
>
> 1:  Anyone remember the GUI installer?  I didn't think there was enough
> people back then to support that "monster" either.  I liked the idea but
> thought Gentoo would be better served by letting the devs concentrate on
> better things and most likely more important things.  I feel about the
> same way about this.  In the past week or so, I have seen discussions
> about packages not having maintainers and other things that needs
> attention but lack time or man power.  While Gentoo has come a VERY long
> way in even the past few months, I would hate to see it get bogged down
> with another project.  If it gets more projects than it can handle, the
> "death of Gentoo" talk will start again.  I been here long enough to see
> that a few times.

The point that you are missing is that Jesús is already doing the same
stuff now as he will in the future. He just needs a project page to
make his "job" even easier and 'official' for LQ management.

>
> 2:  I sort of like having basically one place to go for help.  The place
> I go is Gentoo.  That includes the Gentoo mailing list and the Gentoo
> forums.  If LQ has a forum, who is next, justlinux, then someone else
> etc etc etc?  Am I and a lot of other people going to have to search
> half a dozen websites to find a fix?  What if the answer to my question
> is on a website I am not familiar with or know about?  There would be a
> lot of duplication of threads across several sites and fixes would be
> harder to find.   I am a member at justlinux, LQ and several other sites
> and I on occasion help people on other sites but I don't go looking for
> Gentoo fixes there.

Agreed, but people will do it anyway. We can't "shut down"
http://www.gentoo-quebec.org/forum/ for example.

>
> I'm not a dev by any means and what I say may not count for anything and
> could be ignored if needed.  I have been using Gentoo since the old 1.4
> days, even that was old when I got the CD, so I would hate to see Gentoo
> stall or stagnate again.  Number two really concerns me a lot.  The devs
> can decide if they should support the idea as far as man power.  I don't
> see a way around having to search different sites to find fixes tho.

I highly, highly doubt that the GSE project will cause any stagnation
of Gentoo Linux. Jesús is not an ebuild developer, so if anything his
efforts here will *help* Gentoo and could bring in more community
members. The more community members we have, the more ebuild
developers we might get, etc etc.

>
> That said, I know Jeremy at LQ from talks in the past.  I know the site
> and it is a great site.  I am not questioning that at all.
>
> As for people knowing about Gentoo and the forums, go to google and type
> in Gentoo.  First hit, Gentoo home page.  Even includes links to the
> docs and other pages that are handy.
>
> Thoughts?

I really don't understand your negativity showing in this thread. I'm
not trying to attack you or anything, so don't get the wrong
impression.

>
> Dale
>
> :-)  :-)
>
>

Re: [gentoo-dev] New metadata fields

[Jeremy Olexa]

On Wed, Jun 3, 2009 at 9:38 AM, Steve Dibb  wrote:
> I had an idea for some new fields to go in metadata.xml.  Not sure if we
> would need a GLEP for this or not?  Anyway, what do you guys think:
>
> Two things I can think of adding that would be useful:
>
> - ChangeLog URL
> - Bug Tracker
>
> I know I hate hunting down the two of them, and both of them could be useful
> references for developers and users.
>
> Plus, not every upstream has them, so they can of course be optional fields.
>
> Steve
>
>

mraudsepp pointed this out in irc (I didn't know about it either):
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4

You are allowed to use  and 

So...have fun ;)

-Jeremy

Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild

[Jeremy Olexa]

Maciej Mrozowski wrote:

While it usually doesn't do any particular harm (but I guess security and 
prefix/alt team won't agree on this) - insanely enabling everything by default 


The Prefix team does not care either way.


is not the best idea in my opinion.
Of course we need an example. Let's have a look at latest stable media-
video/mplayer-1.0_rc2_p20090322 ebuild:

IUSE="3dnow 3dnowext +a52 +aac aalib +alsa altivec +amrnb +amrwb arts +ass
bidi bindist bl +cddb +cdio cdparanoia -cpudetection -custom-cflags
-custom-cpuopts debug dga +dirac directfb doc +dts +dv dvb +dvd +dvdnav dxr3
+enca +encode esd +faac +faad fbcon ftp gif ggi -gtk +iconv ipv6 jack
joystick jpeg kernel_linux ladspa libcaca lirc +live lzo mad md5sum +mmx
mmxext mng +mp2 +mp3 musepack nas +nemesi +network openal +opengl oss png pnm
pulseaudio pvr +quicktime radio +rar +real +rtc -samba
+schroedinger sdl +speex sse sse2 ssse3 svga teletext tga +theora +tremor
+truetype +unicode v4l v4l2 vdpau vidix +vorbis -win32codecs +X +x264 xanim
xinerama +xscreensaver +xv +xvid xvmc zoran"

Personally I'd really like to hear some explanation from maintainers about the 
reasons mplayer needs all those dependencies or why they are *really* 
recommended for every user of *any* profile (let me remind this).


But thats's not the point - the point is, Gentoo probably needs some policy to 
advise, when some newly added USE flags are appropriate to be enabled by 
default.


I suggest as follows:
- When newly added USE flag makes already provided feature optional - needs to 
be enabled by default (this is required to make package feature set somewhat 
invariant after update)
- When newly added USE flag adds new feature that is considered very common 
(that's tricky part and decision should be always made by herd, not individual 
developer) *but* *does* *not* *pull* *any* *dependencies* - enable by default
- in any other case *do* *not* *enable* by default - (why? because "I use it 
so I'll enable it by default" is not enough of an explanation)


What's the opinion on that? I guess we need some policy or at least some 
suggestion mentioned in devmanual - really..


IUSE defaults or USE defaults in profiles..Either way...someone will 
complain. This is why you can disable flags in package.use, *or* select 
a non-desktop profile. meh..


-Jeremy

Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

[Jeremy Olexa]

On Sun, May 31, 2009 at 11:25 PM, Jorge Manuel B. S.
Vicetto wrote:


Thanks to those that have nominated me, I would not have expected it
to be honest. I am going to decline for the Council election. I have
lots of other items going on in my life and can't quite add this to my
plate.

Thanks,
Jeremy

[gentoo-dev] app-portage/deltup needs help

[Jeremy Olexa]

Hello devs,
It has been brought to my attention that deltup is in need of some 
lovin' via a treecleaner bug (bug 246916). Both deltup and 
app-portage/getdelta are used in combination to provide smaller tarballs.


If anyone is interested in helping out the Gentoo dial-up users, please 
consider picking these up. These will eventually have to leave the tree 
soonish for security reasons (bundling vulnerable bzip versions).


I'm not interested in these packages, just spreading the word. They use 
to be maintained by genstef.


%% bugz search deltup
218901 genstefapp-portage/deltup need support of lzma compression
234990 genstefdeltup deletes patches for sys-libs/db-4.6.21_p3-r1:
240121 genstefapp-portage/deltup: CFLAGS are ignored
246189 genstefapp-portage/deltup-0.4.4 does not respect LDFLAGS
246916 genstefapp-portage/deltup: fails with forced --as-needed

%% bugz search getdelta
212012 tools-portageGetdelta.sh compares wrong files before delta fetch
239439 genstef[PATCH] app-portage/getdelta-0.7.8 breaks with EAPI=

-Jeremy

Re: [gentoo-dev] Re: New eselect news item for X11 on alphas

[Jeremy Olexa]

Tobias Klausmann wrote:
Hi! 


On Tue, 30 Jun 2009, Christian Faulhammer wrote:

Tobias Klausmann :


Revision: 2

 This is only needed for an in-repo revision...so please leave it at 1.


but but no fixes are available yet, please see

 But but


Imagine a trembling lower lip with that :)

Fixed both, new version below. Thanks again.

Title: xorg-x11-7.4 and xorg-server-1.5 kernel support
Author: Tobias Klausmann 
Content-Type: text/plain
Posted:
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: x11-base/xorg-server
Display-If-Profile: default-linux/alpha
Display-If-Profile: default/linux/alpha


The Display-If-Profile field didn't work because I am seeing this news 
item on my amd64 host..


-Jeremy

Re: [gentoo-dev] Keeping profiles/ tidy

[Jeremy Olexa]

Samuli Suominen wrote:

I've just closed http://bugs.gentoo.org/show_bug.cgi?id=105016. But bugs
like these shouldn't be around in the first place. When you remove a
package from tree, please grep the profiles/ directory for matching
entries and remove them too.

Anyhow, package.mask's and package.use.mask's should all be cleaned now,
unless I missed something ofc. Thanks to idl0r for this scripts!

Main package.mask has still some ancient cruft left that aren't so
obvious why they are masked to everyone, except the person who masked
them in the first place and unfortunately not all of them are around
anymore.. :-/

If you have some.. please audit it.

Thanks, Samuli



Thank you for doing that. What.. 1000 lines removed from profiles/ ?? :)

-Jeremy

Re: [gentoo-dev] New 10.0 profiles are in repository

[Jeremy Olexa]

Samuli Suominen wrote:

As subject says,

default/linux/*/10.0
default/hardened/linux/*/10.0

Profiles are up, the 10.0 releng / 10th anniversary ones.

All new development is to be done with these.

For users of 2008.0 this doesn't mean much as they are cloned ones.

New LiveCD's will be based on 10.0.

For arch's & hardened: You should deprecated 2008.0 in, let's say, when
year changes and point users to switching to 10.0 ones (feel free to do
this sooner). Handbooks needs to be also updated.

Thanks, Samuli



Hi Samuli,
Given the multi-inheritance nature of profiles, it is not obvious what 
changed to me. So, what is new with 10.0 profiles or are they a 
"cosmetic" naming change?


Thanks,
Jeremy

Re: [gentoo-dev] Multimedia overlay

[Jeremy Olexa]

Josh Saddler wrote:


Why isn't this on git.overlays.gentoo.org?

If it's not on Gentoo infrastructure, it's not "official."





Q: Are All Official Overlays Hosted On overlays.gentoo.org?

A: No. Gentoo developers are free to put their overlay wherever suits 
them best; they don't have to use overlays.gentoo.org if they don't want to.


http://www.gentoo.org/proj/en/overlays/userguide.xml

[gentoo-dev] RFC: Make 10.0 profiles EAPI-2 'compliant'

[Jeremy Olexa]

I am suggesting that the new 10.0 profiles be marked as EAPI-2
compliant. This involves setting the content of the 'eapi' file to "2"
and bumping up the required portage version.

This seems like progress to me. Often, developers are complaining that
they can't use SLOT syntax in profiles (I know that is EAPI-1). Since,
the only time we can bump EAPI syntax in profiles is upon a new
directory creation, this seems like a good time to me. The new
profiles are still in flux until the official stages/cd's are
produced.

Also, another good reason is: "why not?" I don't think any Gentoo user
can avoid EAPI-2 up til now anyway.

Any comments? No comments means it will be decided off-list.
Timeframe: 1 week from now.
-Jeremy

Re: [gentoo-dev] Unmasking of libxcb 1.4 and related libs in !2008.0 profiles

[Jeremy Olexa]

On Tue, Aug 18, 2009 at 9:52 AM, Rémi Cardona wrote:
> Hi all,
>
> Just a quick heads up that I have just unmasked x11-libs/libxcb-1.4 and its
> companion libraries in all profiles _except_ 2008.0.

Hey Rémi,
Next time, mind running echangelog in the appropriate directory? It
help us look at a glance for what files are changed and rsync users
can't see commit messages.

Thanks,
Jeremy

Re: [gentoo-dev] Unmasking of libxcb 1.4 and related libs in !2008.0 profiles

[Jeremy Olexa]

On Tue, Aug 18, 2009 at 10:37 AM, Jeremy Olexa wrote:
> On Tue, Aug 18, 2009 at 9:52 AM, Rémi Cardona wrote:
>> Hi all,
>>
>> Just a quick heads up that I have just unmasked x11-libs/libxcb-1.4 and its
>> companion libraries in all profiles _except_ 2008.0.
>
> Hey Rémi,
> Next time, mind running echangelog in the appropriate directory? It
> help us look at a glance for what files are changed and rsync users
> can't see commit messages.
>
> Thanks,
> Jeremy
>

Oops, I need to recall this message. Sorry folks! =/
-Jeremy

Re: [gentoo-dev] Test request: Bugzilla load balancer

[Jeremy Olexa]

On Wed, Jul 29, 2009 at 1:29 PM, Robin H. Johnson wrote:
> Hi folks,
>
> I've been doing some more mucking with the Bugzilla code and setup, and
> I think I've got most of the issues worked out that previously prevented
> it from being fully load balanced.
>
> So, please test at:
> http://bugs-web-lb.gentoo.org/
> HTTP and HTTPS available.

Robin,
Thanks for your work. I see that it has been made the default now.
Seems more responsive in general, with the added redundancy bonus!

-Jeremy

[gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22

[Jeremy Olexa]

Sebastian Pipping wrote:

Hello!


Arrivals

The third peport table on installed packages "most-unmasked" has just
arrived:

http://smolt.hartwork.org:45678/static/stats/gentoo.html#installed_packages_most_unmasked


Questions
=
Before adding the forth "least-installed" table, I'd like to take the
chance to ask for input from the treecleaner team, as it may be of most
 interest to you in the future.


No need to add treecleaner to CC. I think we are all on this list anyway. ;)



 - Do you need anything that a dumb linear-with-counter approach
   cannot offer?


Right now, I can't think of anything else actually.



 - Would zero-install packages be more interesting than
   almost-zero ones or the other way around?


I don't really understand this question. Does "zero-install" mean that 
they are not installed at all? This isn't really useful, because the 
ommition of a package from the page can mean that no one has it 
installed. ;)





What's next
===
Besides before-mentioned table the task

  Collect FEATURES variables in three sets (conf, defaults, globals),
  not merged
  http://soc.gentooexperimental.org/issues/show/58

is next on my list.



Sebastian

Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay

[Jeremy Olexa]

Nikos Chantziaras wrote:

On 08/22/2009 05:59 AM, Nikos Chantziaras wrote:

On 08/22/2009 05:39 AM, Sebastian Pipping wrote:

Sebastian Pipping wrote:

Commits are done automatically, triggering and pushing is
manual at the moment.


By now a cron-based setup is running syncing the pure-funtoo overlay
(and therefore also its atom and rss feeds) every 24 hours.


There seems to be a bit of (minimal) duplication between pure-funtoo and
sunrise.


Uhm, I just discovered that there are conflicts with portage too.  That 
is not good.  After I added pure-funtoo, it messed up my emerge -u world 
(stuff like wanting to upgrade to sys-apps/baselayout-2.1.5).


pure-funtoo should not offer packages available in portage (sunrise is 
the lesser evil).


Huh? This is true of all overlays. If my overlay had baselayout-5.0 in 
it, you would be upgrading to that version if you had my overlay... By 
nature of overlays themselves, you should know what you are doing and 
how to handle it (ie. mask >=sys-apps/baselayout-2.0.1)


-Jeremy

Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay

[Jeremy Olexa]

Nikos Chantziaras wrote:

Of course that's my personal opinion.  I don't use 
"developer/experimental" overlays, I only use those who provide some 
extra packages I want.  And I was under the impression that pure-funtoo 
falls under this category: providing packages that don't exist in portage.


By the nature of Funtoo being a entirely different distribution, that is 
a wrong assumption. It is unreasonable to expect the pure-funtoo overlay 
owner to mask everything that is an upgrade but not in portage yet. I 
would recommend that you remove the pure-funtoo overlay, because your 
expectations don't match reality.


-Jeremy

Re: [gentoo-dev] New 10.0 LiveDVD release enhancements

[Jeremy Olexa]

Samuli Suominen wrote:

Fernando V Orocu (likewhoa) has been working on getting the 10.0 LiveDVD
images in shape for the Gentoo 10th year anniversary release. We need
some assistance in terms of LiveDVD testers, user suggestions for new
packages & software testers since there will be over 100+ new packages
on this release dvd.

We are looking for constructive feedback and ideas from both the
developer community and user community. We want this 10th year
anniversary release DVD to reflect our accomplishments over the year and
your feedback is highly appreciated.

Below are a few of the goals for the the LiveDVD release.

1. Supply both 32/64bit stable kernels
2. Enable HybridISO for the images
3. KDE/GNOME Desktop Environment
4. Speak-Up Functionality
5. 


Recently, Gentoo LiveCDs/DVDs moved to XFCE. I don't have a strong 
opinion on if XFCE is included or not, but I will assist if anything is 
needed on that front.


-Jeremy

Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay

[Jeremy Olexa]

Sebastian Pipping wrote:

Nikos Chantziaras wrote:

Uhm, I just discovered that there are conflicts with portage too.  That
is not good.  After I added pure-funtoo, it messed up my emerge -u world
(stuff like wanting to upgrade to sys-apps/baselayout-2.1.5).


Hopefully fixed
http://git.goodpoint.de/?p=pure-funtoo.git;a=commitdiff;h=341663321f0cf876390fff5967105e403ed3fcbc


See, the problem with this is when Gentoo itself gets a 
baselayout-2.1.x, then it is masked for them if they have the 
pure-funtoo overlay. IOW, people will complain one way, and then they 
will complain the other way. IMO, it is "busy work" for the overlay 
owner and should be left to the user to "know what they are doing" 
because all overlays are experimental.


2 cents,
-Jeremy

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Jeremy Olexa]

On Sun, Aug 30, 2009 at 10:45 AM, William Hubbs wrote:
> On Sun, Aug 30, 2009 at 08:16:47PM +0530, Nirbheek Chauhan wrote:
>> On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzott wrote:
>> > Hi there!
>> >
>> > The new udev-145 and newer have some new kernel requirements. How should 
>> > the
>> > ebuild verify they are met?
>> > Some possible ways:
>> > 1. Check config under /usr/src/linux
>> > 2. Check /proc/config.gz
>> > 3. Print message for user in pkg_postinst
>> >
>>
>> ebuilds usually use linux-info.eclass for this, but that only checks
>> /usr/src/linux -- although checking /proc/config.gz *as well* would be
>> better. That change should be made in the eclass.
>
>  I agree here.  The eclass should check /proc/config.gz.
>  Also, another reason to use the eclass is it respects KBUILD_OUTPUT if
>  it is set.
>
> If /proc/config.gz is the first thing we check, I don't think we need to
> bother at all with checking .config since we know the setup of the
> running kernel.  What does everyone think?

William, not picking on you, just replying in general.

People that suggest to only check /proc/config.gz only are pretty
crazy considering that file is a tunable option. What if the user has
CONFIG_IKCONFIG_PROC=n?? The ebuild fails?! Of course, I haven't seen
any code yet, so maybe people are just suggesting to check config.gz
if is exists, then proceed via other means? ;-)

-Jeremy

[gentoo-dev] About XFCE, renames, eclass, etc

[Jeremy Olexa]

Hello all,
You /may/ have noticed some fuzz going on with XFCE lately. Here is a 
quick outline of what Samuli and myself (mainly him though with my 
'consulting' =P ) have been doing.


- pkg renames: We want to match what upstream calls the packages. This 
includes renaming plugins to $foo-plugin instead of just $foo. But not 
ALL plugins, again we are only matching what upstream calls them 
(inclusive of inconsistency by upstream)


- xfce4.eclass vs xfconf.eclass: xfce4.eclass was basically useless due 
to upstream changes and it was confusing to users and devs alike. Since 
this eclass went from useful to people that knew it (before me) to a 
monster that didn't help anyone (now) it was deprecated. No ebuilds use 
it now and none should in the future. Use xfconf.eclass now, it was 
re-written from scratch and went through a few iterations to become the 
main xfce-related eclass. It is very useful for us, now.


- xfce-extras meta package: The meta package has left the tree in favor 
of the renames and ability to allow the user to choose what to install. 
A meta package /might/ come back in the form of a @set, but not soon. 
This decision was heavily based on community feedback: 
http://blog.jolexa.net/2009/08/01/gentoo-how-to-handle-xfce-extras/


- xfce-config.xml: http://www.gentoo.org/doc/en/xfce-config.xml Josh 
(nightmorph) updated this, basically an after thought by us so thanks Josh!


- xfce4-meta : former name xfce-base/xfce4. Renamed to reflect reality. 
This meta package is the *core* of XFCE, it *only* has in it what is 
required to run. Thus, returning XFCE to a minimalistic status in Gentoo 
Linux. This is desired because most XFCE users are looking for a 
lightweight WM, not a heavy DE. So, users will have to add a terminal, 
orage, thunar, etc to the world file instead of relying on a meta package.


- xfce-4.4 was removed. Sorry mips, Samuli gave you time to add your 
approval to 4.6, but it never happened.


- Stabilization requests, just bringing the stable tree more up2date and 
preparing for inclusion into the LiveDVD if desired by the LiveDVD builders.


Hope that helps anyone that was wondering wtf was going on lately =D
-Jeremy

Re: [gentoo-dev] Re: Multimedia overlay

[Jeremy Olexa]

On Thu, Sep 3, 2009 at 1:42 PM, Nikos Chantziaras wrote:

> Is this dead before it even began?  I'm getting no replies from
> yng...@gentoo.org.

He is away: 
http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml?select=yngwin#yngwin

Re: [gentoo-dev] About XFCE, renames, eclass, etc

[Jeremy Olexa]

Eray Aslan wrote:

On 03.09.2009 05:38, Jeremy Olexa wrote:

- xfce4-meta : former name xfce-base/xfce4. Renamed to reflect reality.
This meta package is the *core* of XFCE, it *only* has in it what is
required to run. Thus, returning XFCE to a minimalistic status in Gentoo
Linux. This is desired because most XFCE users are looking for a
lightweight WM, not a heavy DE. So, users will have to add a terminal,
orage, thunar, etc to the world file instead of relying on a meta package.


Thanks a lot for the update and for the awesome work.  One note for the
future:

An ewarn would have been nice for the above point.  emerge --depclean
output was a surprise (wanted to unmerge terminal etc) and surprise is
bad.  We don't want any surprises.

Thanks again.


I just added this:

 * xfce4-meta will just provide a minimal set of packages. You may also
 * want to emerge x11-terms/terminal, app-editors/mousepad,
 * app-office/orage, etc or similar packages.
 * More info can be found at:
 * http://www.gentoo.org/doc/en/xfce-config.xml

Hope that helps.
-Jeremy

Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)

[Jeremy Olexa]

On Mon, Aug 31, 2009 at 5:12 PM, Mounir Lamouri wrote:

> It's even worst when we try to use ACCEPT_LICENSE to have a free
> operating system.

FWIW: Given the state of ebuilds, I think this should never be
attempted unless the user knows it may not be accurate[1]. We should
not attempt to guarantee such statement, IMO.

> LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most
> LGPL-2 licensed packages in the tree are LGPL-2+ actually.

How are we, the non-lawyer types, suppose to know that? TBH, I don't
care and am not going to put much effort beyond reading the header of
COPYING or glancing at the HOMEPAGE to see what license they are
using. I think you are attempting to add much complexity to ebuilds
that will ultimately fail. Of course, you can volunteer to audit every
license and every ebuild. Thanks in advance for that =P

Thanks for putting work into making Gentoo better, I just am not
convinced on this subject.

-Jeremy

[1]: Look at how long bug 268796 took to get resolved. 4 months,
rather quickly too. Ebuilds stated GPL-2, when they were in fact BSD,
GPL-3, LGPL-2.

Re: [gentoo-dev] Re: 2009.0 profiles

[Jeremy Olexa]

Mike Frysinger wrote:

On Saturday 29 August 2009 05:42:45 Duncan wrote:

Mike Frysinger posted on Sat, 29 Aug 2009 02:56:33 -0400 as excerpted:

On Friday 28 August 2009 20:05:12 Alex Alexander wrote:

On Sat, Aug 29, 2009 at 00:23, Mike Frysinger wrote:

On Friday 28 August 2009 16:27:18 Sebastian Pipping wrote:

Mike Frysinger wrote:

10.0 is retarded

How would you like the problem to be addressed?

we already have a simple logical version system.  2009.0 is the next
step.

Years do not make a good versioning scheme, if one release gets out
late you're automatically considered outdated by users.

then help the release team to get more tested releases, otherwise
reality is we are releasing out of date install media

But as we all know, releases != profiles.  If there's no reason to update
the profiles besides the fact that the name incorporates a year, and they
look out of date, why do so?

For that reason, getting away from year for the profiles is a reasonable
idea, now that Gentoo seems to be mature enough that we don't need a new
profile multiple times a year.

OTOH, having the year in there, as long as people don't get fixated on
it, can be useful as an indication of when the profile was born, just not
necessarily that it's outdated.  If it weren't for the outdated
appearance, therefore, year would be fine.


except that profiles and releases have always been tied (for good reason).  
profile default changes are made as part of the release process.  if we want 
to change a USE flag default, we dont (shouldnt) be doing it to live profiles.  
it is part of the natural version bumping.  releng has always been managing 
new profiles since we started the process years ago and there's no reason to 
change now.


Well, besides the fact that releng is not interested in making new 
profiles...





Whatever, bikeshedding from my perspective, and this one I don't /care/
what the color/name is.  But since we already have 10.0 profiles in-tree,
just run with them, as it's more work to worry about changing them now,
than it's worth.  (And, I might add, I'm glad they're in, as the /last/
thing we need is to be stalemated debating it for a year or two, as it
/is/ bikeshedding.)


date based profiles isnt bikeshedding, it's logical.  and if your only 
complaint is that it doesnt matter, then there is absolutely no reason to go 
changing from what we've been doing for years with no complaints.  picking 
random numbers out of your ass (like 10.0) is confusing.


10 year anniversary of Gentoo. It's not random, nor is it confusing. IMO.


-mike

Re: [gentoo-dev] Re: perl-module.class review

[Jeremy Olexa]

On Mon, Sep 21, 2009 at 11:55 AM, Torsten Veller  wrote:

> if s/EXPF/TEST_EXPF/ in test.eclass, it does:
>
>  * another_test_src_configure
>  * another_test_src_compile
>  * test_pkg_postinst

Although I don't anticipate xfconf and cmake being used together, we
changed xfconf.eclass. ;) Thanks for your time to test there.

sed -i -e 's/EXPF/XFCONF_EXPF/g' xfconf.eclass

-Jeremy

Re: [gentoo-dev] Last rites: opengl-manpages, xorg-docs, xorg-sgml-doctools

[Jeremy Olexa]

On Tue, Sep 22, 2009 at 1:25 PM, Philip Webb  wrote:
> 090922 Rémi Cardona wrote:
>> # Rémi Cardona  (19 Sep 2009)
>> # Outdated and useless X doc packages
>> # Masked for removal in 30 days
>> app-doc/opengl-manpages
>> app-doc/xorg-sgml-doctools
>> app-doc/xorg-docs
>> Before anyone asks, opengl-manpages is a snapshot for Dec '00.
>> The online documentation at opengl.org is much much more up-to-date.
>
> On my generally upto-date system :

Older than 2 days? =P

Re-sync, 
http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-base/xorg-x11/xorg-x11-7.2.ebuild?r1=1.16&r2=1.17

>
>  root:503 ~> equery d xorg-docs
>  [ Searching for packages depending on xorg-docs... ]
>  x11-base/xorg-x11-7.2 (>=app-doc/xorg-docs-1.3)
>
> Is it safe for users simply to remove this pkg ?
>
> --
> ,,
> SUPPORT     ___//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT    `-O--O---'   purslowatchassdotutorontodotca
>
>
>

Re: [gentoo-dev] On shebangs of scripts

[Jeremy Olexa]

On Wed, Sep 23, 2009 at 2:53 AM, Fabian Groffen  wrote:
> Hi all,
>
> Recently, we added a new QA check in Gentoo Prefix' Portage to check
> shebangs (the #! things) of scripts before they are installed.  We
> basically did this simply because we don't want to use say
> /usr/bin/perl and because this executable might not exist (e.g. on
> vanilla FreeBSD).  Even if it does exist, we still don't want to use it,
> since we installed a newer/better version, that also can find the
> installed packages.  This basically does not affect Gentoo Linux,
> however, we do run into several other cases right now that do affect
> Gentoo Linux:
>
> - shebangs like #!python, these are invalid and used by some python
>  packages
> - shebangs like #!/usr/local/bin/python, this is not a good idea, used
>  IIRC by python itself
> - shebangs like #!/bin/csh or #!/bin/tcsh that are correct in itself,
>  but basically need tcsh to be installed to run, e.g. vim does this
>
> The problem with these is that they are executable scripts, e.g. a user
> could expect them to be able to run, IMO.  Solving this can be done by
> fixing the shebang (as for the first two cases), adding a runtime
> dependency (for the last case), or by removing the executable bit of the
> scripts so they no longer can be run, and they merely become
> examples/documentation.

Should there ever be executable scripts in /usr/share? If the
consensus is 'no', could portage remove the +x bit automatically?

Other distros debate about +x in /usr/share/doc too:
https://bugzilla.redhat.com/show_bug.cgi?id=487527#c3 - From what I
gather, other distros decided that they can be +x if they work
properly (meaning, proper dependencies)

>
> Should we start filing bugs on these issues?  In the end, they are
> broken scripts on the system.  Is there interest for porting the Prefix
> shebang QA check to normal Portage?
>
>
> --
> Fabian Groffen
> Gentoo on a different level
>
>

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in xfce-base/xfconf: ChangeLog xfconf-4.6.1.ebuild

[Jeremy Olexa]

2009/10/5 Tomáš Chvátal :
> Dne pondělí 05 Říjen 2009 23:31:03 Samuli Suominen napsal(a):
>> Jeremy Olexa (darkside) wrote:
>> > darkside    09/10/05 21:22:30
>> >
>> >   Modified:             ChangeLog xfconf-4.6.1.ebuild
>> >   Log:
>> >   Port Gentoo Prefix ebuild to gentoo-x86
>> >   (Portage version: 2.1.6.13/cvs/Linux x86_64)
>> > +           # Prefix compat. In Gentoo Linux, defaults to ${D}
>> > +           [[ -z ${ED} ]] && local ED=${D}
>>
>> Shouldn't this be moved into main Portage code instead of duplicating it
>> in ebuilds?

Hi, yes it should. It was brought up during the EAPI=3 planning cycle
and presented to the council for inclusion. It wasn't accepted in that
EAPI even though it is only a 3 line portage change (approx). So, it
will be duplicated in ebuilds and eclasses. Now, with this email I
fully expect a reply from /someone/ saying that "the Gentoo Prefix
implementation is just plain wrong" to which, I am going to silently
ignore.
-Jeremy

>>
>> > +           find "${ED}" -type f -name perllocal.pod -delete
>> > +           find "${ED}" -depth -mindepth 1 -type d -empty -delete
>>
> I put this stuff to eclass, but probably this SHOULD be handled by portage:
> this is the code i do (partial example :]):
>
> ...
> # Prefix compat:
> : ${EROOT:=${ROOT}}
> # Append missing trailing slash character
> [[ ${EROOT} = */ ]] || EROOT+="/"

Good idea, and public thanks for supporting Gentoo Prefix, Tomáš

-Jeremy

Re: [gentoo-dev] Unused ebuild built_with_use cleanup

[Jeremy Olexa]

On Thu, Oct 8, 2009 at 4:34 PM, Petteri Räty  wrote:
> Stelian Ionescu wrote:
>> On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote:
>>> I wrote a script to check which ebuilds use built_with_use and have
>>> keywords in never versions making the ebuild unused. This means that
>>> neither arch or ~arch users are likely to install the ebuild. The script
>>> and the list of ebuilds is attached. I plan on removing all these
>>> ebuilds two weeks from now unless a reason is given why not to. If you
>>> see an ebuild on the list that should be kept, please migrate it to EAPI
>>> 2. If you need assistance in migrating, I can help. With these gone
>>> built_with_use usage will be down to about 600:
>>
>> built_with_use shouldn't be removed until EAPI=3 gets approved because
>> currently there's no good way to emulate "--missing true|false|die"
>> yes, I can use something like this in sbcl:
>> || ( =sys-libs/glibc-2.6 )
>> but not all its use cases may be this simple
>>
>
> Even this is wrong because:
>
> betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE
> nls
>
> For most packages old versions are not kept around so just doing
>>=cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come
> across a case that couldn't be done with EAPI 2 yet. Granted the atoms
> can be a bit cleaner with EAPI 3 but considering how much zmedico slacks
> in implementing it, it's best to do migrating now with EAPI 2 than EAPI

Comments like these are not acceptable. Zac works his tail off on
portage. Please refrain from such comments in the future.
-Jeremy

> 3 in the far future.
>
> Regards,
> Petteri
>
>

Re: [gentoo-dev] openrc-0.5.1 arrived in the tree

[Jeremy Olexa]

On Tue, 13 Oct 2009 22:55:45 +0200, Branko Badrljica
 wrote:

> Main question is NOT whether it works for you, but whether it will break

> stuff on significant percent of other users.
> It broke on my machine, for example, and it was quite disconcerting, 
> since it was at quite inconvenient moment and I had note get to any 
> shred of documentation about ANY kind of substantial behaviour change of

> new openrc...

This is an unreasonable expectation for ~arch. Matthias tested it himself,
had another person test it and then had a number of people say that there
were no problems for them on this thread alone. There was no behavior
change according to upstream, which suggested the method that Matthias took
with USE=oldnet (MKOLDNET?). I respect that every system might be
different, did you file a bug with relevant info so that the docs can get
updated for the people in your situation? We can't document information if
people don't help.

I guess what I am trying to say, is give Matthias a break here. He did
more testing than most of us can do before we bump packages in ~arch.
Progress will not be made if packages live in p.mask, this is proven with
libtool-2, gcc, etc.

-Jeremy

Re: [gentoo-dev] Re: gentoo-x86 commit in net-mail/getmail: ChangeLog getmail-4.9.2.ebuild

[Jeremy Olexa]

Gilles Dartiguelongue wrote:

Le mardi 13 octobre 2009 à 23:48 +0200, Jeroen Roovers a écrit :

On Tue, 13 Oct 2009 21:22:13 +0200
Fabian Groffen  wrote:


We are working on a proper explanation targetted to devs of this.  I'm
sorry for the inconvenience caused.

How large of a change to the tree will this involve? Is it a small
number of packages that need to be fixed through the ebuilds right now?
will that number grow? Will you notify package maintainers of these
changes?


Apparently not, it's not that the change is complicated but I (and the
rest of the gnome herd) would rather have an upfront information about
any kind of changes to our ebuilds than discovering these through
gentoo-commits...


Jeroen / Gilles : Coming soon. The internal draft was just prepared but 
Fabian will be sending it.





For the moment you can find our own documentation here:
http://www.gentoo.org/proj/en/gentoo-alt/prefix/techdocs.xml

Where did you document D -> ED? Can you briefly describe what it does?


See the section "The variables ED and EROOT" on that link. I don't want 
to open it up for discussion on this thread though.




I'd also like to know why this cannot be handled by the usual D with
package manager support, this would save a lot of changes to ebuilds
(like the python abi stuff that still has no documentation afaik).

I sincerely want to see progress in the way we handle prefix, python
abis and all the cool stuff that is still in preparation, but let's do
it in a way to makes every dev aware of it (sending a mail to
gentoo-dev-announce for example), thanks.


Thanks for your support on behalf of the Prefix team,
-Jeremy

Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?

[Jeremy Olexa]

Daniel Bradshaw wrote:

Hi all,

It occurs to me that my work flow when doing updates follows a fairly
predictable (and probably common) pattern.
The obvious next step is to wonder why no one though of automating it...

When doing updates I tend to look through the package list and classify
things based on how likely they are to break.
Some packages, like findutils, are pretty robust and generally just get on
with working.
Other packages, like apache and ssh, need are more fragile and need plenty
of configuration.

Packages from the second group want emerging on their own, or in small
groups, the better to keep an eye out for notices about things that might
break, to update configs, and to check that they're running happily.

Once the update list is reduced to packages from the first group it's
fairly safe to run emerge -u world and not worry about things exploding
too badly.


So as I say, it occurs to me that most people probably follow some
variation of this selective upgrade method.
It might be handy to have some kind of metadata in the ebuilds that can be
used to indicate a package that is "demanding".
Then that flag could be used to highlight the package on a dep tree, or
optionally to block the emerge unless the package is specified explicitly.

`emerge -vaut @safe` would be kinda useful.

Just a thought.

Regards,
Daniel



I am seeing a trend here because this email aligns with the thoughts on 
the openrc email thread a few days ago. That being said, no clue how to 
implement it. Actually I think that marking a package as "demanding" 
would be the more useful than "safe" because probably 95+% of packages 
are "safe"


But, as with a request for an indicator for compile times[1], I think 
this proposal would be a failure in general because of subjective 
opinions between people. I would consider apache/lighttpd as being 
"safe" after initial configuration as long as you don't automatically 
etc-update. But you or someone else would not think it was safe. 
Therefore, nice in theory but probably wouldn't work in practice.


Nice idea, keep them rolling and I'm not trying to kill the thread. :)

-Jeremy
[1]: http://bugs.gentoo.org/288193

[gentoo-dev] Status of 10.0 profiles??

[Jeremy Olexa]

Hello,
Since the "10.0 release" there has not been an outward facing announcement
for users to switch profiles.

* Are we deprecating the 2008.0 profiles?
* Are 10.0 profiles "feature complete" ?
* Will there be an announcement?
* Why are only the 2008.0 hardened profiles deprecated? ( %% find
/usr/portage/profiles -name deprecated )

If users are suppose to switch to 10.0, then is anyone from the
t...@gentoo.org team planning on making the announcements? I would expect an
email to gentoo-user, gentoo-announce, gentoo-dev-announce, #gentoo topic,
and finally forums but that is just off the top of my head.

About 10.0: I know it happened, I know there is an irc channel. But, that
is about it. I think it would be nice if someone from the ten team could do
a postmortem of what worked and what didn't.

-Jeremy

Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME

[Jeremy Olexa]

Maciej Mrozowski wrote:

Hi there!

Resulting from discussion during last Gentoo KDE team meeting taking place 22 
Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo 
GNOME team representative, it's been decided to go ahead with splitting 
desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop 
specific separation which should result in desktop subprofiles being actually 
practical.

It's been proposed to:

- keep 'desktop' profile but strip it from any desktop specific features and 
settings, making it default recommended choice for anyone using non-KDE and 
non-GNOME desktop environment, yet avoiding USE flags bloat. Any other DE is 
free to join and create own DE-specific subprofile if needed.


Hi,
Just so it is clear and there aren't any questions in the future. The 
XFCE team maintains a set of recommended global use flags in our docs[1] 
(maintained by Josh (nightmorph)). So, whatever direction this ends up, 
xfce will not be going down that same road.


Additionally, One cool thing about Gentoo is that you *can* have more 
than one DE installed. We don't have things like KGentoo =P I hope this 
profile thing doesn't make it harder for end users to use GNOME and KDE 
at the same time.


-Jeremy

[1]: http://www.gentoo.org/doc/en/xfce-config.xml




- create 'KDE' (or 'kde') and 'GNOME' (or 'gnome') subprofiles within 
'desktop' profile and move any desktop specific things there. This should in 
theory allow us to not add 'recommended' IUSE defaults to desktop specific 
packages, but keep those settings in profile - making profile effectively 'out 
of the box' solution for those who need it.


If you have any comments, suggestions, important notices regarding this 
change, please keep discussion in gentoo-desktop mailing list.


Thanks

Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds

[Jeremy Olexa]

Some questions answered. snipped the rest.

Denis Dupeyron wrote:

2009/10/18 Tomáš Chvátal :

Why on earth portage simply does not detect the prefix enviroment is being run
and then INTERNALY switch D->ED and other variables.


If that means we can get away without touching ebuilds, apart from
changing their EAPI variable, then that's absolutely what we have to
do. I'd like things to be done the right way though (see below).


When you change econf to do --prefix=${EPREFIX}/usr then you cannot 
simply s/D/ED/ for everything. I hope this makes sense when you think 
about it. ;)


  src_install() {
emake DESTDIR="${D}" install || die
mv "${ED}"/usr/bin/{,exuberant-}ctags || die
  }

But then again, some ebuilds need no changing once you fix econf to do 
the work, which is nice.




On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller  wrote:

However, there is need for additional discussion. From the council
meeting log I could extract the following open questions:


It would be preferable for the discussion to happen on this list
before the meeting or we'll end up postponing again due to having more
questions coming up at that time.


We are willing to talk, but it always seems like the Council is "not 
prepared" no matter what we do. Hope everyone involved can change that.





 2. Should the Prefix team be allowed to do the necessary changes to
ebuilds themselves, or should it be done by the respective
maintainers?


I think here it's obvious that anybody who is an ebuild dev and sees
anything to fix (prefix or else) is encouraged to go ahead and do it,
as we've always done. The recommendation is and will always be to talk
to the current maintainers out of politeness and to be extra careful
(i.e. usually letting the maintainers do it) in case of
system/tricky/exotic package. We don't give full cvs access to the
whole tree to all ebuild devs for nothing.


It is quite obvious that we are not trying to make trouble. Talk is 
cheap, so we prefer that. But, we see no need to ask permission to add 
~prefix keywords, same as other arch teams.


Currently, 'repoman -d full' will fail in some packages. We are fixing this.


Also I think it would be nice if somebody took care of a portage
patch, since I hear it is rather simple. Fabian again? Or Zac? Any
other volunteers?

I would prefer to have all the pieces in places before the next
meeting so that we can vote on the real thing and have prefix
implemented the right way before the end of the year.


portage devs and prefix devs have agreed that it is rather 'easy' to 
merge the prefix-portage branch. Just waiting.. ;) We have access to 
check into the portage repo, so this should not hold anything up 
regarding any decisions.





 6. (Any question that I've missed?)



How are scripts using #!shebangs going to work?
You write an ebuild, and you DEPEND upon >=foo-3, because the build
process includes some foo code. The foo code is executed via
scripts using #!/usr/bin/foo. Normally, this is fine.
But on prefix, /usr/bin/foo might be a crappy, OS X mangled foo-2
that's no good. So even though you've got the foo-3 dep met, it'll be
met in /opt/Gentoo/blah, so your package will fail.


The prefix-portage branch has a nice feature that fixes shebangs 
automatically to be ${EPREFIX}/foo instead of /foo. It has even caught 
some Gentoo Linux bugs.





How are ebuilds to be marked as supporting prefix or not?

(Here I'm guessing that changing the EAPI variable will do)


Gentoo Prefix has keywords. So if EAPI 3 has ED/EROOT support but the 
ebuild doesn't use them then the ebuild does not need an EAPI bump. In 
this case, please rephrase your question to be "How are ebuilds to be 
marked as working on a prefix arch or not?" and then it is clear that it 
is the same as Gentoo Linux.





Why is there only a single permitted installation path?

(I'm under the impression this is a limitation of the windows
installer but not of prefix itself. So patching the installer would
fix that)


My installation path on my 6-8 prefix arches is in my NFS home. If you 
are referring to the Windows special installation package, well..that is 
just a "stage4" installer with binary packages. The windows installer is 
no where near the heart of Gentoo Prefix, instead it is a product of 
Gentoo Prefix and a convenience factor offered by another Prefix dev. It 
showcases the possibilities quite well, IMO.


You can set EPREFIX to anything. One of our users even set it to "/" - 
which we don't endorse but it is possible. :)





What exactly is expected from a prefix-compliant package manager to
support full prefix installs, as opposed to just supporting installs
to / with prefix-aware ebuilds?

(The PMS patch should answer that)

Denis.

Re: [gentoo-dev] Bugzilla testers wanted - "Email send to: no one" issue

[Jeremy Olexa]

On Sun, 15 Nov 2009 22:09:23 -0500, Mike Frysinger 
wrote:
> On Tuesday 03 November 2009 13:33:55 Christian Ruppert wrote:
>> Dear gentoo-dev subscriber,
>> 
>> as some of you might have been noticed, we're having some trouble with
>> Bugzilla's mail notification.
>> In some cases you might see something like "Email sent to: no one" [1]
>> where it was not supposed to happen.
>> 
>> We're not able to reproduce this issue so we would be glad if you guys
>> could help us with that.
>> Go and file some bugs with Product=Bugzilla and Component=Bugstest.
>> Also try on different nodes [2], [3] or [4].
>> 
>> So we need steps to reproduce it.
>> If you got something email[5] us or contact us via IRC (Nicks: robbat2
>> or idl0r).
> 
> funny enough, this seems to have gotten a lot worse since you posted
this 
> heads up.  i'm noticing plenty of missed initial notifications now.
> -mike

I too was seeing this at a frequency that was noticeable. In the past week
(or more), there has not been any missed emails that I have seen. Did
something get changed to fix this issue? Or are we still guessing?

-Jeremy