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

[alex . alexander]

Hello :)

I've created some KVM images to aid Gentoo Developers and
the KDE herd in ebuild development and maintainance.

Two images are currently available: [1]
an X-less ~x86 with various tools preinstalled [like layman]
and
a copy of the first ~x86 with kdebase-meta[kdeprefix] and a
few other packages installed on top of it

The portage tree is in a separate image, along with binary
packages of most stuff installed in the two images.
(a bz2 of the tree is in /usr just in case)

The images are available at dev.gentooexperimental.org [1].
Please read the README [2] for instructions and more information :)

An image with -kdeprefix kde is also en route.

I would really appreciate feedback on the images:
* things you liked
* things missing
* things you'd do differently
either through these mailing lists or in freenode/#gentoo-kde
so I can make future revisions better and more useful!

Regards,
Alex Alexander (wired)
Gentoo KDE Team Herd Tester

[1] http://dev.gentooexperimental.org/~wired/kvm/
[2] http://dev.gentooexperimental.org/~wired/kvm/README.txt

signature.asc
Description: OpenPGP digital signature

[gentoo-dev] blocking mixed versions of split QT libraries

[Alex Alexander]

QT doesn't work well when mixed versions of its core libraries are
installed. Usually an emerge -avDu world solves the problem, but some
users tend to avoid this.

For example, lets say you have parts of QT 4.4.2 on your system. QT
4.5.1 is available and a user decides to manually update qt-core, or
to install KDE which has a QT dependency on a QT library not
installed. In these cases, portage will update only a part of the
installed QT libraries, leaving the system in a mixed state.

QT based apps don't like that. Others will refuse to build, others
will fail to run.

We've managed to experimentally block partial QT upgrades by adding an
RDEPEND to all QT libraries [1] in qting-edge overlay. Portage
understands this and throws out B blocks if you try to change versions
only in parts of QT, but upgrades/downgrades fine if you do them all
at once (or use -Du world).

This "fix" also catches stale QT libraries that nothing depends on
anymore because the user has removed whatever required them (and never
ran --depclean).

Unfortunately we've got reports from paludis users stating that they
can't update QT from qting-edge anymore.

What I'd like to discuss is the following:

1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
2) Is our implementation considered correct and acceptable by the PMS guys?
3) Whats the general Gentoo Policy on mixed versions? Do we care, or
is our policy "please -Du world"?

We've also managed to achieve the same thing by adding PDEPENDs to
each QT library for any other QT libraries that depend on it:

i.e. if qt-xmlpatterns depends on qt-gui, we add the following to qt-gui:
PDEPEND="
|| ( !x11-libs/qt-xmlpatterns ~x11-libs/qt-xmlpatterns-${PV} )
"

the above (expanded for all libraries) has the same effect as the [1]
RDEPEND but looks a bit more hackish.

thanks

[1] lines 30-59
http://github.com/gentoo-qt/qting-edge/blob/master/eclass/qt4-build-edge.eclass

--
Alex Alexander || wired
Gentoo QT && KDE Herd Tester
http://www.linuxized.com

Re: [gentoo-dev] blocking mixed versions of split QT libraries

[Alex Alexander]

> From what I understand you are utilizing portages ability to
> automagically resolve blockers when all blockers will be resolved within
> the current command.  Agree?? or is it the fact that you are doing
> !>x11-libs/qt-assistant-${PV}-r that is causing the paludis problem?

Yes, portage's auto-resolving ability thats exactly what we're using
to make this happen.

> I would suggest that you just tell paludis users to use --dl-blocks
> discard when updating qt.  After looking at the eclass im not sure
> whether it will work or not.  im assuming that discarding blocks will
> just ignore everything, but I haven't tested it so can't be sure.

Well since there's no other obvious way to achieve the whole thing,
this seems like the only option for paludis users for now. If it
works.

>> 1) Is there a saner way to achieve our goal of doing whatever is
>> possible to avoid mixed QT versions?
>
> I don't believe so, not within current ways of declaring dependencies.

maybe the PMS guys could implement something... :D

>> 2) Is our implementation considered correct and acceptable by the PMS guys?
>> 3) Whats the general Gentoo Policy on mixed versions? Do we care, or
>> is our policy "please -Du world"?
>
> I say we should be stopping them from happening.
>
> Good work btw.

Thank you for your thoughts

--
Alex Alexander || wired
Gentoo QT && KDE Herd Tester
http://www.linuxized.com

Re: [gentoo-dev] blocking mixed versions of split QT libraries

[Alex Alexander]

On Mon, May 18, 2009 at 17:21, Ciaran McCreesh
 wrote:
> Not really. There's no particularly good mechanism for ensuring equal
> versions of things where not everything has to be installed. The best
> option I can think of is to have a meta package called, say, split-qt,
> and to do all your external (not inter-qt-library) dependencies as:
>
>    x11-libs/split-qt[gui][xmlpatterns]
>
> and then have x11-libs/split-qt's deps be like:
>
>    gui? ( ~x11-libs/qt-gui-${PV} )

how would that solve a user's "emerge -av1 qt-core" when a new Qt
version becomes available?

--
Alex Alexander || wired
Gentoo QT && KDE Herd Tester
http://www.linuxized.com

Re: [gentoo-dev] blocking mixed versions of split QT libraries

[Alex Alexander]

On Mon, May 18, 2009 at 19:51, Ciaran McCreesh
 wrote:
> It wouldn't, although it would be fixed as soon as someone tried to
> install a package with a Qt dep.
>
> Dependencies the way they are now aren't really expressive enough to
> handle what you're after -- split packages are considered unrelated.

so the RDEPEND in qting-edge seems to be the only working solution for now...

is paludis expected to behave like portage in the near future
regarding these blocks?

are there any plans to add support for these kinds of cases in the
PMS? other sets of packages could probably benefit from such a feature
as well.

thanks

--
Alex Alexander || wired
Gentoo QT && KDE Herd Tester
http://www.linuxized.com

Re: [gentoo-dev] github <> g.o.g.o

[Alex Alexander]

On Sat, Feb 25, 2012 at 01:55:37PM +0100, Justin wrote:
> Hi all,
> 
> is there a way to do a way or two way sync between a repo on github and
> on g.o.g.o?
> 
> I have the felling that I heard of an official overlay which is operated
> like this. Could someone please point me to this overlay and the technique?

For every secondary repo you want to keep synced, add a pushurl entry

pushurl = 

below your main "url =" line in the repo's .git/config file.
Git will automatically push to all pushurl entries automatically when
you "git push".

We do this in the Qt overlay (with gitorious atm):

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://git.overlays.gentoo.org/proj/qt.git
pushurl = g...@gitorious.org:gentoo-qt/qt.git

Regards,
-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs due www-server herd removal

[Alex Alexander]

On Wed, Mar 21, 2012 at 12:26:12PM +0100, Pacho Ramos wrote:
> As discussed in "[gentoo-dev] www-servers herd is empty" thread,
> we agreed with dropping this herd and let people get what they want
> to maintain. This is the list of orphan packages:
...
> www-servers/lighttpd

This is not an orphan :)

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

Re: [gentoo-dev] rfc: location of portage tree

[Alex Alexander]

On Tue, Mar 27, 2012 at 02:05:54PM -0500, William Hubbs wrote:
> All,
> 
> I know this has come up before, but I don't really recall what the
> specific objections were.
> 
> IMO the portage directory doesn't belong under /usr at all.
> I was chatting with another developer who uses
> /var/cache/portage/{tree,distfiles}, and I'm thinking about switching my
> default setup to do this.
> 
> I realize that historically the portage tree has been installed under
> /usr, but Can we consider changing this default for new installations
> and providing instructions for users for how to get the portage tree out
> of /usr?
> William

If/when this happens, we should also consider improving the internal
structure of the portage folder. At the moment we just throw everything
in it, which is not very user friendly. I recommend creating a subfolder
for the actual tree, keeping distfiles and packages out.

For example, my /usr/portage/ on this system looks like this:

portage/
tree/
profiles/ -> tree/profiles/
distfiles/
packages/
layman/

it is a big improvement over the current
distfiles-and-packages-mixed-with-tree-while-layman-wanders state :)
-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com


signature.asc
Description: Digital signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Alex Alexander]

On Mar 31, 2012 11:00 AM, "Ciaran McCreesh" 
wrote:
>
> On Fri, 30 Mar 2012 17:55:27 -0400
> Richard Yao  wrote:
> > I think we should wait for Portage 2.2 to be stabilized before we
> > declare Gentoo 2.0. @preserved-libs is enough of an advance that I
> > think claiming 2.0 would be merited, if only for the attention it
> > would draw at Phoronix.
>
> Do you really want to be advertising an awful hack that doesn't really
> work, is conceptually unsound and that breaks all kinds of things in
> subtle ways?
>
> --
> Ciaran McCreesh

@preserved-libs works very well and is awesome. hack or not. IMO it should
be in stable already. I've been using it on stable production boxes for
years without any issues :)

Alex | wired

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Alex Alexander]

On Mar 31, 2012 12:57 PM, "Ciaran McCreesh" 
wrote:
>
> On Sat, 31 Mar 2012 12:44:03 +0300
> Alex Alexander  wrote:
> > @preserved-libs works very well and is awesome. hack or not. IMO it
> > should be in stable already. I've been using it on stable production
> > boxes for years without any issues :)
>
> ...and here we see the problem. You think that "I haven't noticed it
> break" means "it works".
>
> The problem with preserved-libs (and emerge --jobs, for that matter) is
> that the design is "I can think of a few ways where it might break, so
> I'll hard-code in special cases to handle those, but in general I
> can't think of what other problems there are so it's fine". That's a
> bad way of doing things.
>
> --
> Ciaran McCreesh

No. I didn't say I think it works, I said I have proof it works.

You can argue about the implementation details all you want and it'll still
work.

If you can make it better then, by all means, send a patch. Otherwise stop
spreading false FUD, please.

Thanks :)

Alex | wired

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Alex Alexander]

On Mar 31, 2012 5:57 PM, "Ciaran McCreesh" 
wrote:
>
> On Sat, 31 Mar 2012 15:08:29 +0300
> Alex Alexander  wrote:
> > No. I didn't say I think it works, I said I have proof it works.
>
> Well that's interesting, because there are plenty of examples where it
> doesn't work, and all that it takes to disprove a theory is a single
> counterexample. So I think you're misunderstanding what constitutes
> proof here -- "some evidence" certainly isn't it.
>
> --
> Ciaran McCreesh

Boring. You conveniently ignored the other part of my message.

I'll repeat it: no matter how much you argue, it'll still work fine for me.

That said, I think we can end this conversation now :)

Gentoo \o/

Alex | wired

Re: [gentoo-dev] RFC: PROPERTIES=funky-slots

[Alex Alexander]

On Sat, Jun 23, 2012 at 9:22 PM, Ciaran McCreesh
 wrote:
> On Sat, 23 Jun 2012 20:23:13 +0200
> Michał Górny  wrote:
>> On Sat, 23 Jun 2012 19:06:38 +0100
>> Ciaran McCreesh  wrote:
>> > On Sat, 23 Jun 2012 20:09:03 +0200
>> > Michał Górny  wrote:
>> > > > That's just it, though -- this no longer holds. -r300 is now
>> > > > being used for something that is exactly the same version as
>> > > > -r200.
>> > >
>> > > Did you look at SONAME?
>> >
>> > Look at SONAME before deciding what package to install? Kindly
>> > explain how that works.
>>
>> I'm just saying that these are two different versions of the package.
>> If you want GTK+3, you take the newer one. If you want GTK+2 compat,
>> you take the older slot. What's wrong with that?
>
> The package mangler does not know that 1.1-r300 is not a "better"
> version than 1.1-r200, or that 1.2-r200 is not a "better" version than
> 1.1-r300. Indicating packages where this kind of strangeness happens
> allows manglers to know that things that are usually true about the
> relationship between slots and versions no longer hold, and that in
> these specific cases it should consider slots to be heavily independent.

You already have this info, it's called a "slot dependency".

-- 
Alex

Re: [gentoo-dev] RFC: PROPERTIES=funky-slots

[Alex Alexander]

On Sat, Jun 23, 2012 at 9:37 PM, Ciaran McCreesh
 wrote:
> On Sat, 23 Jun 2012 21:35:47 +0300
> Alex Alexander  wrote:
>> > The package mangler does not know that 1.1-r300 is not a "better"
>> > version than 1.1-r200, or that 1.2-r200 is not a "better" version
>> > than 1.1-r300. Indicating packages where this kind of strangeness
>> > happens allows manglers to know that things that are usually true
>> > about the relationship between slots and versions no longer hold,
>> > and that in these specific cases it should consider slots to be
>> > heavily independent.
>>
>> You already have this info, it's called a "slot dependency".
>
> It's not a property of individual packages that happen to depend upon
> the problematic package. The property holds or not for a package
> regardless of whether anything depends upon it.

They are part of the deal.

If your package has reverse deps, you don't want to update it before
figuring out it's reverse dependencies anyway, you never know what
slot/version restrictions you're going to get.

If it is a package without reverse dependencies, updating to the most
recent slot and/or version should be expected unless the user has the
slot defined in the world file.

-- 
Alex

Re: [gentoo-dev] RFC: PROPERTIES=funky-slots

[Alex Alexander]

On Sat, Jun 23, 2012 at 10:16 PM, Ciaran McCreesh
 wrote:
> On Sat, 23 Jun 2012 22:14:32 +0300
> Alex Alexander  wrote:
>> If it is a package without reverse dependencies, updating to the most
>> recent slot and/or version should be expected unless the user has the
>> slot defined in the world file.
>
> That's the part that no longer holds. The package mangler now needs a
> way of knowing that for a certain few packages, bringing in new slots
> when not explicitly required is undesirable.

Or the PM can notify the user that a new slot has come up and instruct
them to specify their desired slot in their world file.

-- 
Alex

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Alex Alexander]

On Sep 16, 2012 4:55 PM, "Brian Harring"  wrote:
>
> Folks-
>
> Keeping it short and quick, a basic glep has been written for what I'm
> proposing for DEPENDENCIES enhancement.
>
> The live version of the doc is available at
>
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html

Am I the only one who thinks that this dep:{build,...} thing looks really
ugly and is hard to read?

IMO simply removing the "dep" part would greatly improve things:

DEPENDENCIES="
:build,run? ( ... )
:run? ( ... )
"

s/:/@/ would also be interesting

DEPENDENCIES="
@build,run? ( ... )
@run? ( ... )
"

Alex | wired

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Alex Alexander]

On Sep 17, 2012 6:13 AM, "Brian Harring"  wrote:
>
> On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
> >On Sep 16, 2012 4:55 PM, "Brian Harring" <[1]ferri...@gmail.com>
wrote:
> >>
> >> Folks-
> >>
> >> Keeping it short and quick, a basic glep has been written for what
> >I'm
> >> proposing for DEPENDENCIES enhancement.
> >>
> >> The live version of the doc is available at
> >>
> >[2]
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
> >ndencies.html
> >
> >Am I the only one who thinks that this dep:{build,...} thing looks
> >really ugly and is hard to read?
> >
> >IMO simply removing the "dep" part would greatly improve things:
>
> That 'dep' part isn't great, but it's added for a reason; to unify
> with USE_EXPAND/use group intended syntax.  There's a reference in
> there to
> http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which
> I'll formalize soon enough.
>
>
> >DEPENDENCIES="
> >:build,run? ( ... )
> >:run? ( ... )
> >"
>
> For your suggestion, consider it if we *do* fxi USE expand- via using
> the same : form.
>
> Using app-admin/mcollective ad an example, it's deps are thus:
>
> DEPEND="ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
> ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
> RDEPEND="dev-ruby/stomp
> ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
> ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
>
> Which, if USE_EXPAND targets were groupped, would go from this
>   ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>   ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
>   dep:run? ( dev-ruby/stomp )"
>
> to this:
>   ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
>   ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
>   :run? ( dev-ruby/stomp )

Ok, now I get it. I've read the other threads as well, but failed to put it
all together. Happens when you barely sleep every night :-)

I don't like this mix of dependency types and use flag deps. It smells
trouble. Dependency types should be easy to separate and read, but the
above example is a mess, "dep:" or no "dep:".

Why? Because you have to scan the whole thing to sort out which lines are
dependency types and which lines are use deps and even then it would be
easy to misread something.

If we want to stay away from labels (which aren't that bad IMO), I'd
recommend the following instead:

Force explicit setting of the dependency type and disallow the mix of
dependency types and use flag deps at the same level / block.

DEPENDENCIES="
  :build,run? ( lib/foo )
  :run? (
lib/bar
someuseflag? ( random/app )
  )
  :*? (
thing? (
  :build? ( lib/thing )
  :run? ( lib/thingrunner )
)
"

Or, using your example:

:build,run? (
  ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
  ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
)
:run? ( dev-ruby/stomp )

Alex | wired

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Alex Alexander]

On Sep 22, 2012 10:58 AM, "Michał Górny"  wrote:
>
> Hello,
>
> The current dependency syntax:
>
>   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:

The syntax you are describing is used all over portage, not just
dependencies. Some examples are the /etc/portage/package.* files,
has_version or exact version matching when emerging.

Changing it just for dependencies would most certainly confuse people and
tbh I like the current syntax :-)

Alex | wired

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Alex Alexander]

On Sep 22, 2012 7:38 PM, "Michał Górny"  wrote:
>
> emerge 'foo >= 1.1' 'bar < 1.0'?
> emerge foo '>=' 1.1 bar '<' 1.0?

How is the above easier to read than

emerge >=foo-1.1 

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Alex Alexander]

On Sep 22, 2012 8:25 PM, "Michał Górny"  wrote:
>
> On Sat, 22 Sep 2012 20:11:48 +0300
> Alex Alexander  wrote:
>
> > On Sep 22, 2012 7:38 PM, "Michał Górny"  wrote:
> > >
> > > emerge 'foo >= 1.1' 'bar < 1.0'?
> > > emerge foo '>=' 1.1 bar '<' 1.0?
> >
> > How is the above easier to read than
> >
> > emerge >=foo-1.1 
> Did you even test it? That would create '=foo-1.1' and then fail trying
> to read 'bar-1.0'. It's rather:
>
>   emerge '>=foo-1.1' ' > I think your example is working against you*.*
> >
> > The current syntax is much easier to read than the
> > quote-and-whitespace-tracking horror of your example :-P
>
> It's no less quoting than in the current case. And it could be simply
> extended to supporting quoting-less syntax, e.g.:
>
>   emerge foo -gt 1.1 bar -lt 1.0

I still find whitespace inappropriate for this kind of things. You are
trying to replace a single atom that instantly gives you all required
information with a format that does not clearly separate atoms, IMHO anyway
:-)

Alex | wired

[gentoo-dev] [warning] the bug queue has 85 bugs

[Alex Alexander]

Our bug queue has 85 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 97 bugs

[Alex Alexander]

Our bug queue has 97 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 89 bugs

[Alex Alexander]

Our bug queue has 89 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 83 bugs

[Alex Alexander]

Our bug queue has 83 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 81 bugs

[Alex Alexander]

Our bug queue has 81 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 82 bugs

[Alex Alexander]

Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 93 bugs

[Alex Alexander]

Our bug queue has 93 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 83 bugs

[Alex Alexander]

Our bug queue has 83 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 96 bugs

[Alex Alexander]

Our bug queue has 96 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 88 bugs

[Alex Alexander]

Our bug queue has 88 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 85 bugs

[Alex Alexander]

Our bug queue has 85 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 82 bugs

[Alex Alexander]

Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 82 bugs

[Alex Alexander]

Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 89 bugs

[Alex Alexander]

Our bug queue has 89 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 94 bugs

[Alex Alexander]

Our bug queue has 94 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 82 bugs

[Alex Alexander]

Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 97 bugs

[Alex Alexander]

Our bug queue has 97 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 95 bugs

[Alex Alexander]

Our bug queue has 95 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 84 bugs

[Alex Alexander]

Our bug queue has 84 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 82 bugs

[Alex Alexander]

Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 88 bugs

[Alex Alexander]

Our bug queue has 88 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 90 bugs

[Alex Alexander]

Our bug queue has 90 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 84 bugs

[Alex Alexander]

Our bug queue has 84 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 92 bugs

[Alex Alexander]

Our bug queue has 92 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 99 bugs

[Alex Alexander]

Our bug queue has 99 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 95 bugs

[Alex Alexander]

Our bug queue has 95 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 88 bugs

[Alex Alexander]

Our bug queue has 88 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 82 bugs

[Alex Alexander]

Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 84 bugs

[Alex Alexander]

Our bug queue has 84 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 85 bugs

[Alex Alexander]

Our bug queue has 85 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 86 bugs

[Alex Alexander]

Our bug queue has 86 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 98 bugs

[Alex Alexander]

Our bug queue has 98 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 94 bugs

[Alex Alexander]

Our bug queue has 94 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 85 bugs

[Alex Alexander]

Our bug queue has 85 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 86 bugs

[Alex Alexander]

Our bug queue has 86 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 87 bugs

[Alex Alexander]

Our bug queue has 87 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

[gentoo-dev] [warning] the bug queue has 89 bugs

[Alex Alexander]

Our bug queue has 89 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

Re: [gentoo-dev] Packages up for grabs

[Alex Alexander]

On Thu, Jan 3, 2013 at 12:57 AM, Panagiotis Christopoulos <
pchr...@gentoo.org> wrote:

> On 22:52 Thu 20 Dec , Pacho Ramos wrote:
> > Due araujo no longer taking care of them:
> > dev-lang/gnu-smalltalk
> > ...
>
> I'm taking this one.
>
> --
> Panagiotis Christopoulos ( pchrist )
> ( Gentoo Lisp Project )
>

o_O

xD
-- 
Alex 

Re: [gentoo-dev] GCC 4.7 unmasking

[Alex Alexander]

On 25 Feb 2013 06:53, "Ryan Hill"  wrote:
>
> I'm going to be unmasking 4.7.2 later this week.  There are still 47 open
bugs
> blocking the 4.7 tracker, so if any are yours now would be a good time
> to take a look at them.
>
> https://bugs.gentoo.org/390247

Can't you just smell all those Gentoo systems gearing up for long emerge -e
sessions? xD

Thanks for working on this.

Alex | wired

Re: [gentoo-dev] Draft news item: preserve-libs default for portage-2.1.12

[Alex Alexander]

On Sun, Jun 02, 2013 at 05:41:21PM -0700, Zac Medico wrote:
> Please review the attached news item which announces the preserve-libs 
> default for portage-2.1.12. Note that our council has discussed this 
> change in their 2013-05-14 meeting [1], and they were in favor of 
> allowing it.
> 
> [1] http://thread.gmane.org/gmane.linux.gentoo.project/2448/focus=2452
> -- 
> Thanks,
> Zac

> Title: Portage preserve-libs default
> Author: Zac Medico 
> Content-Type: text/plain
> Posted: 2012-06-07
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-apps/portage-2.1.12
> 
> Beginning with sys-apps/portage-2.1.12, FEATURES=preserve-libs is enabled by
> default. This feature will preserve libraries when the sonames change during
> upgrade or downgrade. Libraries are preserved only if consumers of those
> libraries are detected. Preserved libraries are automatically removed when
> there are no remaining consumers. Run `emerge @preserved-rebuild` in order to
> rebuild all consumers of preserved libraries.
> 
> If you would like to disable this behavior by default, then set
> FEATURES="-preserve-libs" in make.conf. See the make.conf(5) man page for more
> information about this feature.

Looks good. Perhaps you'd like to add that this replaces revdep-rebuild
in case it's not obvious to some users.

By the way: Wh h xD
I almost believed this would never happen.

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com


signature.asc
Description: Digital signature

[gentoo-dev] revbumping ebuilds after USE dependency changes

[Alex Alexander]

Hello,

Please revbump an ebuild after changing its USE dependencies.

Using net-p2p/transmission as an example, it used to depend on 
dev-qt/qtgui:4=[dbus]
however, qtgui lost the dbus useflag, so the dependency was changed to
dev-qt/qtgui:4=[dbus(+)]
without revbumping the transmission ebuild. [0]

Portage fails to notice this when resolving dependencies if the package was
installed prior to the change, resulting in errors like the following:
  (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts
with dev-qt/qtgui:4/4=[dbus] required by
(net-p2p/transmission-2.80::gentoo, installed)

which, I imagine, could be very frustrating for a user who doesn't mess
with the internals of Gentoo often.

You might think that such a revbump is overkill, but in reality the user will
have to re-emerge the package anyway in order to get rid of the error, so there
is no point in avoiding it, unless portage changes the way it handles these
changes.

[0] 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2

Thanks,
-- 
Alex Alexander | wired@gentoo
+ www.linuxized.com
++ www.leetworks.com


signature.asc
Description: Digital signature

Re: [gentoo-dev] revbumping ebuilds after USE dependency changes

[Alex Alexander]

On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote:
> On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander  wrote:
> > Hello,
> >
> > Please revbump an ebuild after changing its USE dependencies.
> >
> > Using net-p2p/transmission as an example, it used to depend on
> > dev-qt/qtgui:4=[dbus]
> > however, qtgui lost the dbus useflag, so the dependency was changed to
> > dev-qt/qtgui:4=[dbus(+)]
> > without revbumping the transmission ebuild. [0]
> >
> > Portage fails to notice this when resolving dependencies if the package was
> > installed prior to the change, resulting in errors like the following:
> >   (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts
> > with dev-qt/qtgui:4/4=[dbus] required by
> > (net-p2p/transmission-2.80::gentoo, installed)
> >
> > which, I imagine, could be very frustrating for a user who doesn't mess
> > with the internals of Gentoo often.
> >
> > You might think that such a revbump is overkill, but in reality the user 
> > will
> > have to re-emerge the package anyway in order to get rid of the error, so 
> > there
> > is no point in avoiding it, unless portage changes the way it handles these
> > changes.
> >
> > [0] 
> > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2
> >
> 
> Actually, Portage normally handles this situation gracefully by using
> the dependencies from the portage tree instead of vdb. However, in the
> case of a slot-operator dep, it always uses vdb.
> 
> See bug 477544.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=477544

Aha, thanks for the bug, missed it. Well, my recommendation is still
valid until portage gets fixed. Glad to know someone's looking into
it though.

-- 
Alex Alexander | wired@gentoo
+ www.linuxized.com
++ www.leetworks.com


signature.asc
Description: Digital signature

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alex Alexander]

On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer  wrote:

> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote:
> > On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote:
> >> Greetings,
> >>
> >> Gnome Herd decided to target stablilization of 3.8 [1] which requires
> >> systemd.
> >>
> >> What are the reasons to stable 3.8 and not 3.6, a version w/o this
> >> restriction, enabling all non systemd users to profit from this
> >> eye-candy as well.
> >>
> >> I raise the freedom of choice card here. And deliberately choosing an
> >> uncooperative version doesn't shine a good light.
> >>
> >> Facts, pls!
> >>
> >>Michael
> >>
> >> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252
> >
> > To stabilize gnome-3.6, we would need
> > 1. one or (preferably) two *active* gentoo developers;
> > 2. who are familiar with gnome's internals and are able to backport
> > bugfixes from 3.8/3.10 without support from upstream developers; and
> > 3. who volunteer to run openrc+gnome-3.6 for a long time on their main
> > machines so that they can give a stable 3.6 the support that the word
> > 'stable' implies.
> >
> > We do not have such people on the gnome team.
> >
>
> Seeing the noise in #gentoo from people getting whacked in the kidney by
> the systemd sidegrade ... that's a very optimistic decision.
>
> It'll cause lots of pain for users that suddenly can't start lvm
> properly and other nasty landmines hidden in the "upgrade path". By
> stabilizing this early you're causing lots of extra work for others.
>
> I hope you understand that some of us will be very rude and just suggest
> to unmerge gnome on all support requests as it now moves outside our
> support range ...
>
> Have a nice day,
>
> Patrick
>

Although I understand your frustration, I don't see any other options for
the Gentoo gnome team. People who don't like this should take their
complaints upstream.

-- 
Alex Alexander
+ wired
+ www.linuxized.com
+ www.leetworks.com

[gentoo-dev] [warning] the bug queue has 89 bugs

[Alex Alexander]

Our bug queue has 89 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

Re: [gentoo-dev] [warning] the bug queue has 89 bugs

[Alex Alexander]

On Wed, Nov 6, 2013 at 6:08 PM, Tom Wijsman  wrote:

> On Wed,  6 Nov 2013 14:00:02 +0200 (EET)
> Alex Alexander  wrote:
>
> > Our bug queue has 89 bugs!
> >
> > If you have some spare time, please help assign/sort a few bugs.
> >
> > To view the bug queue, click here: http://bit.ly/m8PQS5
>
> Is this notice automated? Feel free to ping us (b-w) as well or instead.
>
> Thank you to everyone whom helped along here and there.
>
> Spent a full two hours on helping to empty the queue; there are some
> bugs with pending information left, and one I don't know how to assign.


It's automated, check runs once a day.

Good work everyone, queue is down to 9 bugs at the moment :)

Cheers,
-- 
Alex Alexander
+ wired
+ www.linuxized.com
+ www.leetworks.com

Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed

[Alex Alexander]

On 9 Nov 2013 12:16, "Lars Wendler"  wrote:
>
> Am Fri, 08 Nov 2013 20:17:27 -0500
> schrieb Chris Reffett :
>
> > On 11/8/2013 7:14 PM, Markos Chandras wrote:
> > > Hi,
> > >
> > > I see nobody seems to take care of nagios packages anymore.
> > > There are numerous bugs (and many of them are pending version
> > > bumps).
> > >
> > > Is the sysadmin@ herd still interested in this package? If not,
> > > could you please consider moving it to maintainer-needed@? Maybe
> > > users are interested in working with proxy-maintainers to bring
> > > this package up to date.
> > >
> > > https://bugs.gentoo.org/buglist.cgi?quicksearch=net-analyzer%2Fnagios
> > >
> > If sysadmin@ doesn't want it, I know a user/potential dev who would be
> > interested in maintaining it with me as a proxy. Just let me know.
> >
> > Chris reffett
> >
>
> Oh dear...
>
> I already have too many packages to take care of but my company is using
> nagion on Gentoo so I take care of it. Although I wouldn't mind if
> somebody else helps with the packages as well.

I would like to help as well.

Nagios herd + git overlay for easier nondev contributions? :)

Alex | wired

Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed

[Alex Alexander]

On Sat, Nov 9, 2013 at 5:20 PM, Diego Elio Pettenò
wrote:

> I don't understand people's insistence with a single product herd given we
> don't have enough manpower yet and I don't want to have an explosion of
> aliases I need to subscribe to, the spam is enough as it is.


Herds are definitely not the solution for everything, but they make sense
when you have multiple people interested in maintaining large sets of
ebuilds. If nothing else, they make life easier for bug wranglers,
especially when you have >2 maintainers.

-- 
Alex Alexander
+ wired
+ www.linuxized.com
+ www.leetworks.com

Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed

[Alex Alexander]

On Sat, Nov 9, 2013 at 5:43 PM, Diego Elio Pettenò
wrote:

>
> On Sat, Nov 9, 2013 at 3:30 PM, Alex Alexander  wrote:
>
>>
>> On Sat, Nov 9, 2013 at 5:20 PM, Diego Elio Pettenò <
>> flamee...@flameeyes.eu> wrote:
>>
>>> I don't understand people's insistence with a single product herd given
>>> we don't have enough manpower yet and I don't want to have an explosion of
>>> aliases I need to subscribe to, the spam is enough as it is.
>>
>>
>> Herds are definitely not the solution for everything, but they make sense
>> when you have multiple people interested in maintaining large sets of
>> ebuilds. If nothing else, they make life easier for bug wranglers,
>> especially when you have >2 maintainers.
>>
>
> You read my comment the wrong way (or I wrote it too hastily to be
> understood). I mean I don't see the need to split sysadmin herd in three or
> more. Sure there is stuff in sysadmin that I don't care about because I
> don't use, but nothing forces me to maintain all of it. And if nobody cares
> about I'm perfectly fine to mark it as m-n.
>
> But I don't see the point in saying "well, nobody cares about nagios but
> two people, so we're moving it to a nagios herd". Might as well just use
> the two maintainers there, then.
>
> Yes I know I haven't been active at all. My time management is terrible
> and even after meeting Tom Limoncelli in person I doubt I'll magically
> start getting better at it, but I'll try to work on it.
>

I misunderstood you, I thought you were comparing having herds to not
having herds at all, my bad. I replied hastily and didn't consider that
nagios and friends are part of a herd already.

I agree that splitting herds is not necessary in a case like this.

-- 
Alex Alexander
+ wired
+ www.linuxized.com
+ www.leetworks.com

Re: [gentoo-dev] Doing and then undoing slotmoves

[Alex Alexander]

On Wed, Dec 18, 2013 at 11:11 AM, Fabio Erculiani  wrote:

> Hi,
> 6 days ago gienah committed a bunch of slotmoves for the haskell
> glib/gtk stuff [1], basically moving the pkgs to slot 0 (from slot 2).
> This was done in file 4Q-2013.
> It turns out that the same gienah moved those pkgs to slot 2 (from
> slot 0) in 2Q-2013 [2].
>
> I have never seen something like that and this generated an
> interesting bug in entropy (well, I fixed it...). What I am asking is
> quite simple though.
> Is this allowed? Should the previous slotmove be removed?
>

Did a few quick tests, seems to me that the old slotmove should be removed.

Alex

[gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

[Alex Alexander]

Hello fellow developers,

In the first meeting of the new QA team, we discussed the state of the
gtk{,2,3} USE flags in the main tree. [0]

In its current state, USE="gtk" means gtk2. The Gnome team is trying to change
this into "the most recent gtk version" (it is a work in progress).

Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages that
may support either or both the toolkits. To handle this, a few developers have
introduced the "gtk3" useflag, that prefers gtk3 over gtk2 when both toolkit
versions are supported. At this point, the Gnome team highly recommends
prefering gtk3 if possible, skipping the useflag altogether. [1]

Some developers choose to follow the Gnome team's highlights, while others
choose to go their own way. The QA team would like to establish a guideline
that solves this problem in the best way possible.

During our discussion, it was pointed out that keeping a generic USE="gtk" is
sub-optimal. The non-straightforward nature of new toolkit versions makes
transitioning from one to the other a slow, tedius process and we think that a
non-versioned USE flag makes things even worse.

A few of our members recommended a move away from the unversioned USE="gtk" to
versioned-only USE flags. Qt managed to do this quite successfully when they
transitioned from the unversioned USE="qt" (that actually meant qt3) to
USE="qt4". The benefits can be seen now that qt5 is around the corner.
USE="qt5" is straightforward, does not mess with qt4 packages and was
introduced to the tree without messing with current packages too much - other
than adding a new use flag where appropriate. There is also no need for
USE="qt" anymore.

To achieve this, version 3 of gtk should always be enabled by USE="gtk3". At
some point in the future, when gtk2 consumers reach zero, we will retire "gtk"
for good. Then, if some day gtk4 comes around, we will be able to introduce
support for it in the tree by simply adding USE="gtk4", without having to
re-structure half the tree.

We are reaching out to the developer community to hear your thoughts and ideas
on the matter. We would like to reach a decision that could possibly affect and
direct the state of whole tree. This decision could then be turned into a
policy, improving Gentoo's consistency across the tree.

Cheers

[0] 
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
-- 
Alex Alexander | wired@gentoo


signature.asc
Description: Digital signature

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Alex Alexander]

On 20 Feb 2014 10:12, "Michał Górny"  wrote:
>
> Dnia 2014-02-20, o godz. 01:44:17
> Steev Klimaszewski  napisał(a):
>
> > On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
> > > On 20/02/14 00:23, Ulrich Mueller wrote:
> > > > Following up to today's QA meeting: The gtk3 USE flag is used by
> > > > 27 packages, so I suggest making it a global flag:
> > > >
> > > > gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> > > >
> > > > Ulrich
> > >
> > > that would suggest it's fine to use, and is anything but temporary
> > >
> > > -1 from here
> > >
> > MATE desktop (which I hope to bring in to Portage soon) can be built
> > against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from
> > me.
>
> Except that now users have to use USE='gtk gtk3' to get GUIs in random
> applications that support only one toolkit. And then handle
> REQUIRED_USE mess for packages that support choosing one of the two.
>
> > Just because gtk+ 3 is the latest, does not mean it's the greatest,
> > and I really wish people would realize that newest != bestest.
>
> Yet it's supported, unlike GTK+2. I really wish people would actually
> step up to fix bugs when the time comes rather than shouting about their
> right to choose.

The main idea here is to create a system that is consistent.

Yes, gtk2 is still used and IMO we need to provide support for it as long
as there are apps linked to it with no real alternatives.

But we also need to think about the future. The situation today is a total
mess.

In an ideal world, gtk3 would replace gtk2 everywhere in an instant, making
this discussion pointless. Unfortunately, this is not the case.

Versioned USE flags solve most of the problems with minimum fuss, while
paving the road for a much cleaner gtk3 -> gtk4 transition.

We don't really need generic use flags anyway. Adding gtk3 to your USE is
really easy and I expect our user base to be able to handle these things
with ease.

Alex

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Alex Alexander]

On 20 Feb 2014 12:30, "Samuli Suominen"  wrote:
>
>
> On 20/02/14 12:07, Duncan wrote:
> > Samuli Suominen posted on Thu, 20 Feb 2014 07:55:44 +0200 as excerpted:
> >
> >> On 20/02/14 00:23, Ulrich Mueller wrote:
> >>> Following up to today's QA meeting: The gtk3 USE flag is used by 27
> >>> packages, so I suggest making it a global flag:
> >>>
> >>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3
> >>>
> >>> Ulrich
> >> that would suggest it's fine to use, and is anything but temporary
> >>
> >> -1 from here
> > You must have missed the news implied by that "following up" wording,
> > then.  See the announcement/thread "February 2014 QA policy updates",
> > posted by creffett, just a few minutes before this thread started.
>
> I find it sad the QA team has been taken over by some of the new and
> semi-new
> developers who don't completely understand the implications of this
> decision yet
> since they haven't lived through the older transitions.

Well, I find it sad that Gentoo is trying really hard to resist change -
although things have been improving lately.

Honestly, I really like the new QA team, we actually push things forward!
Sure, not everyone will always agree with us, but that is natural.

By the way, we did not take over. We were entrusted with this role, we
discuss everything with the community and try to take decisions that are
good for Gentoo. We don't have some secret ulterior motive to take over the
world through Gentoo.

For what it's worth, as a QA member I always vote with what I believe is
best for Gentoo in mind.

Cheers,
Alex

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Alex Alexander]

On Sun, Feb 23, 2014 at 6:59 PM, Peter Stuge  wrote:

> Tom Wijsman wrote:
> > I'd say that if around 7 people vote on the matter that that is
> > based on a necessary amount of understanding.
>
> That is just incredibly naïve.
>
> [...]
>
> In history lessons you may have learned about majorities of populations
> supporting something the same individuals consider a pretty darn bad
> idea in hindsight, but which they were unable to decide on correctly
> at the time.
>
> You need to learn to respect what you don't know that you don't know.
>

You assume too much. Which is ironic, considering that you're calling us
naive.

We are not playing guessing games here.

Making a decision means that we have the proper knowledge on the matter at
hand. We can't guarantee that our decision will be correct, but we can
sleep at night knowing we did our best, with the best of intentions.

Cheers,
-- 
Alex Alexander
+ wired
+ www.linuxized.com
+ www.leetworks.com

[gentoo-dev] Packages looking for new maintainers.

[Alex Alexander]

I've dropped myself from the maintainer list in the following packages.
Feel free to pick them up if you use them, they deserve better :)

app-misc/vifm
x11-misc/okindd (also in Qt herd, dead?)
x11-misc/whaw
x11-misc/qsynergy (also in Qt herd)

www-client/luakit
this one hasn't had a release for a while, but it has an active github
network.

www-client/uzbl
no recent releases for this either, but it has an active branch on github.

The last two need work if you plan to make your own releases
or backports, a lot of things have changed.

Thanks,
-- 
Alex Alexander
+ wired
+ www.linuxized.com
+ www.leetworks.com

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

[Alex Alexander]

On Thu, Aug 6, 2009 at 22:17, Zac Medico wrote:
> It would be pretty trivial to use a PORTAGE_PROFILES variable in
> make.conf, to replace /etc/make.profile. You could do something like
> this:
>
> PORTAGE_PROFILES="/usr/portage/profiles/desktop
> /usr/portage/profiles/gnome"
>
> You could use this approach to pull in profiles from overlays too if
> desired.

This looks pretty neat. Many (new) users who ignore or are ignorant of
profiles could benefit by it, since they'll (have to) look at it when
they first open the default /etc/make.conf

> --
> Thanks,
> Zac
>
>

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

Re: [gentoo-dev] Re: Devaway for me, for a whole year period(military service)

[Alex Alexander]

On Tue, Aug 11, 2009 at 20:32, Markos Chandras wrote:
> Now, it is my time to say goodbye ( but not forever ) . I am *forced* to join
> the greek army from 16/8/2009 until May 2010. So I wont be active during this
> period. When I come back, I expect a more shiny Gentoo which will provide
> great experiences to our users.
>
> So long people. It was a pleasure to work with you so far. See you in May :)
> --
> Markos Chandras (hwoarang)
> Gentoo Linux Developer [KDE/Qt/Sound/Sunrise]
> Web: http://hwoarang.silverarrow.org
>
>
>

9+ months of pure slacking eh :p

Try to hang in there and come back in one piece!

Καλό κουράγιο μεγάλε ;)

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

Re: [gentoo-dev] 2009.0 profiles

[Alex Alexander]

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.
> -mike

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

I think 10.0 is cool :)

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

Re: [gentoo-dev] Stabilization of Python 3.1

[Alex Alexander]

*On Sat, Sep 19, 2009 at 23:21, Robert Bridge  wrote:
> So the question isn't SHOULD python-3 be stabilised, it's what will break if
> it is surely?

There seems to be a misunderstanding on what will happen if/when
python 3 gets stabilized.

The short answer is... *drum roll*... nothing :)

I'm guessing that the idea of getting python 3 stable is to allow
people interested in using it to do so easily. We're talking about the
stabilization of python 3, NOT switching portage or your system to it.

Python 2.6 will continue to be the user's default python even after he
installs version 3. In fact, if you're using ~testing you should have
it already and your system is probably still working OK :)

Now.. if a user decides to switch his system *manually* to python 3
without thinking... he's asking for it :)

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

[gentoo-dev] rfc: Qt version 4.5.2 news item

[Alex Alexander]

We're planning on stablereq'ing Qt 4.5.2 (really) soon, so I've
written this news item to cover default USE flag changes that could
confuse users :)

Please review, thanks:

Title: Qt 4.5.2 default USE flag changes
Author: Alex Alexander 
Content-Type: text/plain
Posted: 2009-09-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: http://www.linuxized.com/p192

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

Re: [gentoo-dev] rfc: Qt version 4.5.2 news item

[Alex Alexander]

On Wed, Sep 23, 2009 at 10:16, Ulrich Mueller  wrote:
> GLEP 42 says that you should wrap lines at 72 columns.
>
> Ulrich

Correct, I was sure I'd miss something.
Thanks :)

Title: Qt 4.5.2 default USE flag changes
Author: Alex Alexander 
Content-Type: text/plain
Posted: 2009-09-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: http://www.linuxized.com/p192

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

[gentoo-dev] 2nd KDE (mini) Meeting - September 2009

[Alex Alexander]

Hey,

The KDE Team will have a supplemental September meeting tomorrow to
discuss the state of KDE 4.3.1 and Qt 4.5 / gcc 4.4, as agreed in the
previous meeting.

Date: Thursday,  2009/09/24
Time: 1900 UTC
Channel: #gentoo-meetings

Topics:
- KDE 4.3.1 state: bugs, stabilization
- Qt 4.5.x and gcc 4.4

see ya there :)

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

Re: [gentoo-dev] rfc: Qt version 4.5.2 news item

[Alex Alexander]

On Wed, Sep 23, 2009 at 10:35, Alex Alexander  wrote:
> Title: Qt 4.5.2 default USE flag changes
> Author: Alex Alexander 

committed, thanks :)

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

Re: [gentoo-dev] Anyone intrested in maintaining Midnight Commander?

[Alex Alexander]

On Fri, Oct 2, 2009 at 21:57, Samuli Suominen  wrote:
> The latest version is now patch free, 4.7.0_pre3, and there's only 1 bug
> open. So I'm basically done with it.
>
> If any of you actually use it, feel free to substitute me from the
> metadata.xml, I just picked it up because nobody else did.
>
> Thanks, Samuli

/me uses it

I'll take it off your hands, thanks for taking care of it for so long.

-- 
Alex || wired

Re: [gentoo-dev] Updated handbooks for autobuilds

[Alex Alexander]

On Sun, Oct 4, 2009 at 21:42, Joshua Saddler  wrote:
> There. I did the x86 and amd64 handbooks (networked, anyway; who cares about 
> networkless). They're now ready for the 10th anniversary. I'm pretty sure.
>
> I also did the x86 quickinstall handbooks.

Thanks Joshua!

-- 
Alex || wired

Re: [gentoo-dev] gentoo-news repository

[Alex Alexander]

On Thu, Oct 8, 2009 at 12:08, Ulrich Mueller  wrote:
> Opinions?

Sounds good, although it could get a bit crowded if we remove /,
unless we remove really old items (like >= 2 years old).

-- 
Alex || wired

Re: [gentoo-dev] gentoo-news repository

[Alex Alexander]

On Thu, Oct 8, 2009 at 14:07, Markos Chandras  wrote:
> Crowded? I don't think so :)
> The number of news items is quite small, so I think we can afford having them
> all in the same folder

I'm assuming devs will eventually pick this feature up and use it more often :)

But yeah, as long as someone cleans up *really* old items, it
shouldn't be a problem.

-- 
Alex || wired

[gentoo-dev] KDE Team Meeting - October 2009

[Alex Alexander]

Greetings,

The KDE Team will have its usual monthly meeting this Thursday.

Date: Thursday,  2009/10/22
Time: 1900 UTC
Channel: #gentoo-meetings

Late announcement, I know, but I guess better late than never :)

Reply to this email with anything you'd like to have discussed at the meeting.

Everyone should be there so we can celebrate having KDE 4 stable!

Thanks,
-- 
Alex || wired
Gentoo Dev
www.linuxized.com

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

[Alex Alexander]

On Mon, Oct 26, 2009 at 21:42, Zeerak Waseem  wrote:
> having to choose a profile, gives less time for the wavering user

Why all the fuss? No-one said we're removing the plain "desktop"
profile, we're simply adding *more* options.

If you want generic DE options pre-enabled, choose the desktop profile.
If you *know* you only need KDE as your DE, choose KDE,
If you *know* you only need GNOME as your DE, choose GNOME,
If you need both or can't decide, either choose Desktop and add the
USE flags yourself or use both profiles together.

Beats enabling default USE flags without asking you :)

-- 
Alex || wired
Gentoo Dev
www.linuxized.com

[gentoo-dev] Re: KDE Team meeting November 2009

[Alex Alexander]

On Sun, Nov 15, 2009 at 03:26:24PM +0100, Tomáš Chvátal wrote:
> Hi,
> This months meeting will be held as usual so i am anouncing it in advance so 
> we discuss and prepare on the topics. As a sidenote: since Qt team is leaving 
> us kde to their own project space this meetings from now on will be focused 
> only on kde relevant matters.

Just wanted to add that although Qt has its own project now, we don't
want to break up the fine meetings we've been having so far.
So we'd like to continue having common meetings for the time being :)

Things we have on Qt agenda for now:

* Proposition to return to monolithic Qt ebuilds

In last meeting we decided to continue this discussion in ML. 
We should revisit the subject in this meeting, especially now
that one of the major issues is gone with the removal of old Qt versions.

* Status of new qt-tng.eclass

* #gentoo-qt - its there, do we want to use it?

Thanks,
-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpIsxqWkw99o.pgp
Description: PGP signature

Re: [gentoo-dev] metdata.dtd should require

[Alex Alexander]

On Tue, Dec 15, 2009 at 06:19:00PM +0300, Peter Volkov wrote:
> So what we will do with this? It'll be great to fix dtd to follow our
> requirements, but there is a problem:
> 
> if we change dtd like this:
> 
> 
> 
> we will force all metadata.xml files have strict order of tags: first
>  then other tags. Currently there are about 200 ebuilds with
> different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 .

Forced ordering looks fine to me... we could announce the change, let
devs fix their metadata during a short period of time (say, 2 weeks),
then force-fix the ones left (200 is a small number) and apply the dtd fix.

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpa6qfA2bTVF.pgp
Description: PGP signature

Re: [gentoo-dev] Election for the Gentoo Council empty seat

[Alex Alexander]

On Wed, Dec 30, 2009 at 09:27:12PM +0200, Markos Chandras wrote:
> > On Tue, Dec 15, 2009 at 11:57:41PM -0100, Jorge Manuel B. S. Vicetto wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > Hello.
> > >
> > > As announced by Denis (Calchan)[1], we need to have an election for the
> > > Gentoo Council's empty seat.
> > > We'll be putting up a page with all the information for the Council
> > > election, including the election officials, asap. I'll send another
> > > email later with the link and the missing information, but for now, let
> > > me just share the dates for nomination and voting:
> > >
> > > nomination: December 17th to 30th
> > > voting: January 1st to 14th
> > >
> > > To nominate anyone for the empty seat, please send an email to the
> > > gentoo-dev ml. Anyone can nominate for the Council, but only current
> > > Gentoo Developers can stand for and vote in the election.
> > >
> > > If you have any doubts, please contact me in IRC, you can use the
> > > elections project channel[2], or email the Elections team[3].
> > 
>  
> I nominate Alex Alexander ( wired )

I accept the nomination.

Thanks Markos :)

> Cheers
> 
> -- 
> Markos Chandras (hwoarang)
> Gentoo Linux Developer [KDE/Qt/Sound/Sunrise/Kernel/AMD64/Bug-wrangler]
> Web: http://hwoarang.silverarrow.org

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpl8S2IoF270.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Alex Alexander]

On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
> I sometimes think the main problem is the tree itself. Portage really
> should had a directory of its own, but maybe with anoher structure,
> like /var/portage, /var/portage/tree (the current
> PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
> itself), /var/portage/overlays/layman or /var/portage/layman.
> I of course realize that change the structure of the whole portdir would
> had inresting complications, so take this comment just as serious as you
> like.
> 
> But overlays really was an afterthought?

I like this suggestion, it certainly makes the whole folder structure
cleaner. If we're going to fix stuff, lets do it properly once and for
all.

Some compatibility code that checks and uses the old default locations
while printing out warnings would help existing users with the
transition without breaking current systems. Users with custom PORTDIR
and friends could be notified through a news item.

/var/portage/
/var/portage/tree
/var/portage/layman
/var/portage/overlays (non-layman managed, layman could also be in here)
/var/portage/distfiles
/var/portage/packages

or %s/var/usr/

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpC37DfrQPPw.pgp
Description: PGP signature

[gentoo-dev] an update script for the gentoo developer

[Alex Alexander]

Hello fellow devs,

I've created a script to help me keep my tree/overlays up-to-date,
automatically regenerate metadata, update eix, etc.

It's not anything too sophisticated, but it works for me, so I thought
I'd share it with you guys.

An updated version of the script is available at my gentoo devspace:
http://dev.gentoo.org/~wired/scripts/update

./update -h gives you all available options
edit the script to set the defaults to your liking.

the script expects the following directory structure:

${DATA_DIR}/
  main/
  gentoo-x86/
  gentoo/ (optional)
  gentoo-news/ (optional)
  overlays/
  {various overlays}
  overlays_disabled/
  {overlays not used}
  make.conf
  autogenerated, holds active overlay list
  imported in /etc/make.conf
  ${SCRIPT_OUTPUT}
  if called with -c, all output goes here

the make.conf is sourced in /etc/make.conf and is generated each time
the overlays/ folder gets updated.

the script is constantly improved and I keep the online version
up-to-date. there are some options that diff/fetch the latest version
for you automatically.

I'll probably add a --sync option soon to make it useful on
systems without a CVS checkout.

hopefully some of you will find it useful.

patches and feedback always welcome :)
-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgp4UPO4oVOmv.pgp
Description: PGP signature

Re: [gentoo-dev] New category for version control

[Alex Alexander]

On Thu, Mar 04, 2010 at 10:32:47AM +0100, Ulrich Mueller wrote:
> >>>>> On Thu, 4 Mar 2010, Christian Faulhammer wrote:
> 
> > My proposal would be to call it dev-scm and put all version
> > controls, direct frontends, plugins and the like into that.
> 
> Better call it dev-vcs to avoid confusion with both the Scheme
> language and with software configuration management.

Nice idea, +1.

I too prefer dev-vcs as the category name.

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgphqAM5dBleT.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events

[Alex Alexander]

On Wed, Mar 10, 2010 at 07:45:21AM -0500, Mike Frysinger wrote:
> the front page of http://gentoo.org/ now links to a Google Calendar (see side 
> bar).  this has been around for a while, but it seems it's been more of an 
> "underground" thing, so it's time to raise its awareness.
> 
> like other aspects of Gentoo, all Gentoo developers have access to it to add 
> their own events.  anything Gentoo related may be added of course !  
> meetings, 
> events, scheduled package events, etc...
> 
> the access step requires a bit of help though -- simply e-mail me off list 
> your gmail account and we can get you set up.  once you have access, you may 
> easily pass it on to other Gentoo peeps.
> -mike

excellent idea! thanks for taking the time to do this :)

i've added my gentoo email to my personal google account so you should be
able to add me using that, could you try?

thanks,
-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgp0zEFpLLvJM.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo calendar for tracking Gentoo events

[Alex Alexander]

On Wed, Mar 10, 2010 at 08:18:11AM -0500, Mike Frysinger wrote:
> On Wednesday 10 March 2010 07:56:42 Alex Alexander wrote:
> > On Wed, Mar 10, 2010 at 07:45:21AM -0500, Mike Frysinger wrote:
> > > the front page of http://gentoo.org/ now links to a Google Calendar (see
> > > side bar).  this has been around for a while, but it seems it's been
> > > more of an "underground" thing, so it's time to raise its awareness.
> > > 
> > > like other aspects of Gentoo, all Gentoo developers have access to it to
> > > add their own events.  anything Gentoo related may be added of course ! 
> > > meetings, events, scheduled package events, etc...
> > > 
> > > the access step requires a bit of help though -- simply e-mail me off
> > > list your gmail account and we can get you set up.  once you have
> > > access, you may easily pass it on to other Gentoo peeps.
> > 
> > excellent idea! thanks for taking the time to do this :)
> 
> sorry, i didnt mean to make it sound like this was my idea ... Diego put it 
> together originally and it's slowly grown since
>
> > i've added my gentoo email to my personal google account so you should be
> > able to add me using that, could you try?
> 
> google didnt warn when i added, so presumably it worked
> -mike

it did, thanks
-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpXOawPoPzEV.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC]: Proxy-maintainer project

[Alex Alexander]

On Thu, Mar 18, 2010 at 06:29:56PM +0200, Markos Chandras wrote:
> Dear fellow developers,
> 
> A new project is about to start so I am requesting your feedback
> 
> The primary goal of the Proxy Maintainers[1] project is to create and 
> maintain 
> relationships between developers and users in order to ensure packages in the 
> Gentoo tree stay up to date. This involves a few main tasks: 
>
> 
> [...]
>
> 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in 
> Gentoo bugzilla?I think the latter is the best

IMO, the best route would be to start with-in Gentoo Bugs, then slowly
move each contributor to a proxy-maintainer overlay.

This overlay would not have a review process for ebuilds, meaning that every
contributor that has passed the first stage (by submitting a few ebuilds in
bugzilla) will be granted access.

that way users will:

* get experience on actually committing stuff to a tree
* learn how to use tools like repoman and git (think of the future ;))

it will also be better for us. moving packages from the overlay to tree
will be simpler, also tracking versions and package status will be
easier.

> 2) I think an email alias is not needed We can "monitor" maintainer-wanted/-
> needed alias if needed. What do you think?

If we go with the new overlay, I think we'll need an alias where the
users can ask for help and talk about their packages.

> 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that 
> the specific bug is already taking by another developer and that somebody is 
> working on it. So marking a bug with a keyword e.g. "PROXY" might be useful.

Thats not a bad idea.
Another solution would be to assign the bugs to proxy-maintain...@g.o.

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpSloZtxpV78.pgp
Description: PGP signature

Re: [gentoo-dev] Empty herd: sgml

[Alex Alexander]

On Mon, Mar 22, 2010 at 02:25:43AM -0100, Jorge Manuel B. S. Vicetto wrote:
> Here is a list of the packages that would be moved to maintainer-wanted:
> 
> app-doc/halibut
> app-office/passepartout
> app-text/asciidoc
> app-text/build-docbook-catalog
> app-text/docbook2X
> app-text/docbook-dsssl-stylesheets
> app-text/docbook-sgml-dtd
> app-text/docbook-sgml
> app-text/docbook-sgml-utils
> app-text/docbook-xml-dtd
> app-text/docbook-xml-simple-dtd
> app-text/docbook-xsl-stylesheets
> app-text/gentoo-guide-xml-dtd
> app-text/grutatxt
> app-text/html2text
> app-text/html401
> app-text/htmlrecode
> app-text/htmltidy
> app-text/html-xml-utils
> app-text/linuxdoc-tools
> app-text/openjade
> app-text/opensp
> app-text/robodoc
> app-text/sablotron
> app-text/sgml-common
> app-text/sgmltools-lite
> app-text/sgrep
> app-text/txt2tags
> app-text/xhtml1
> app-text/xml2doc
> app-text/xml2
> app-text/xmlformat
> app-text/xmlstarlet
> app-text/xmlto
> www-client/htmlview
> 
> 
> The following packages would be dropped to the remaining maintainers:
> 
> app-emacs/nxml-mode (emacs)
> app-emacs/psgml (emacs)
> app-text/gnome-doc-utils (gnome)
> app-text/highlight (tex)
> app-text/scrollkeeper-dtd (gnome)
> app-text/scrollkeeper (gnome)
> app-text/webgen (ruby)
> dev-ruby/xml-simple (ruby)

A lot of useful stuff here.

I've added myself and tampakrap to the sgml herd,
we'll try to keep it in good shape :)

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpug5W71Iomd.pgp
Description: PGP signature

Re: [gentoo-dev] Handling of keywording bugs with only one arch

[Alex Alexander]

On Sat, Mar 27, 2010 at 04:26:46PM +0200, Petteri Räty wrote:
> On 03/12/2010 09:18 PM, Petteri Räty wrote:
> > There seems to be two different schools on who to assign a keywording
> > bug with only a single arch. I have myself assigned it to the arch in
> > question but there's a difference of opinion here:
> > http://bugs.gentoo.org/show_bug.cgi?id=272160#c5
> > Let's get agreed on a single approach and I will add a note here:
> > http://devmanual.gentoo.org/keywording/index.html
> > I naturally support the approach I have been doing as I think the arch
> > team is the one in charge.
> > 
> > Regards,
> > Petteri
> > 
> 
> So let's summarize for assigning to the single arch:
> 
> Against (and my comments on why they don't apply):
>  - Comments would only go to arch team after resolving:
>   * maintainer is still in Cc or Reporter
>  - Arch teams not in charge of fixing problems
>   * If problems come up they deserve a new bug as a dependency
>   * one bug per issue and a stabilization bug is about stabilization
>  - Maintainer being able to decide when to go stable
>   * Bug wranglers should still assign to maintainers for their ack
>   * The maintainer assigns it to the arch team
> 
> In support (and my comments in support):
>  - Can be used as a gentle reminder for slacker arches
>  - The arch teams are actually ones doing the work to resolve the bug
>   * As they are the ones to mark it as resolved it makes sense for them
> to be the assignees
> 
> So based on this I propose that I will write this down in appropriate
> places in to our documentation and commit a week from now. Please object
> if you don't agree and we can discuss some more.
> 
> Regards,
> Petteri

The only reason I don't really like this is because it breaks
consistency. We have a ground rule, assign to maintainer, CC arch(es).
Why make it more complicated? I have a feeling people will continue
CCing arches out of habit.

Ofcourse, individual cases (such as slacking arches) can be handled
independently.

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpupeyfobUFd.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative

[Alex Alexander]

On Wed, Mar 31, 2010 at 02:20:35AM -0700, Brian Harring wrote:
> Hola all-
> 
> For those who aren't familiar, pkg_pretend is in EAPI4- the main usage 
> of it is will be use dep checking- this email is specifically 
> regarding an alternative to it that *should* be superior for that use 
> case, but I'm looking for feedback.
> 
> Basically, we use the original VALID_USE proposal from way back in 
> '05- if you're familiar w/ MYOPTIONS, they're reasonably similar.
> 
> Roughly, VALID_USE is a list of constraints stating what the allowed 
> use flag combinations are for this pkg.  If you think of normal 
> depdencies (I must have openssl and python merged prior), it's the 
> same machinery.
> 
> [snip]
> 
> Comments desired; assuming no significant blowback, I'll be pushing 
> this to the council level since eapi4 is annoying feature locked right 
> now.

I like the whole concept, it is clean and straightforward.

Also, notifying the user of any possible issues and breaking so he can
make the actual decision sounds far better than making the choice for him.

VALID_USE does look a bit strange.

how about
IUSE_RULES
or
IUSE_RESTRICTIOMS
or
RUSE
?

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpYxpiVZQG04.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- humpback, genstef, wrobel

[Alex Alexander]

On Tue, May 25, 2010 at 11:39:10AM +0200, Torsten Veller wrote:
> Here's a bunch of packages up for grabs, due to maintainers retiring..
> 
> maintainer-needed
> -
> sys-apps/ivman

grabbed this one ;)

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


pgpwhTJeyfRfC.pgp
Description: PGP signature