Re[2]: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Jakub Moc]

7.11.2005, 9:41:04, Grobian wrote:

> On Sun, Nov 06, 2005 at 09:56:35PM +, Ciaran McCreesh wrote:
>> | Then what is the point of this GLEP?  Instead, just warn people
>> | through existing intrastructure, which is cheap from an engineering
>> | perspective because everything is already there in place, and don't
>> | think of implementing all kinds of extras just to warn a user one
>> | extra time, since "trying to warn them any further becomes futile"
>> | anyway.
>> 
>> The current warning levels we have are insufficient. This GLEP proposes
>> a new system for warnings which will be far harder to accidentally
>> ignore. There are, however, limits to how far we can reasonably go
>> before we make the solution worse than the problem.

> Remember that there are packages in the tree that satisfy the preemptive
> requirement, since they simply die when trying to upgrade and a certain
> amount of prerequisites is not met.  This prevents the user from losing
> data files or making them inaccesible, while at the same pointing out
> what needs to be done and why, using a short message.

Uhm, breaking the emerge chain in *not* an alternative to this GLEP, in no
way... Leaving the rest of the upcoming rant/flame for ciaranm's pleasure. :=)


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpgVqKI75PvO.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Jakub Moc]

7.11.2005, 20:11:23, Grobian wrote:

> Ciaran McCreesh wrote:
>> On Mon, 07 Nov 2005 19:32:38 +0100 Grobian <[EMAIL PROTECTED]> wrote:
>> | So, what list should the user that wants to receive those
>> | **important** messages sign up to?
>> 
>> That's your first misconception right there. Most users don't sign up
>> for things.

> Doesn't matter.  If the important messages aren't posted or you have to 
> extract them yourself the effect is the same.

> Besides that, I see no arguments why users don't.  No proof either.

OK, I'd really suggest you join #gentoo-apache for a week, if you want some
proof. Browsing forums.g.o. rants wrt the Apache layout changes is also helpful 
in
this respect. ;p


--
Jakub

pgpZ3qNIGXwpw.pgp
Description: PGP signature

[gentoo-dev] use.defaults and pointless commits

[Jakub Moc]

Hello everyone,

would someone more competent explain to me, why

- this feature even exists
- why has a mass of things been commited in there recently

?

It's

- confusing users
- rendering /etc/portage/package.keywords useless (install a dep for one
particular ebuild and enjoy the USE flag enabled globally)
- causing unwanted results (I did not really install app-text/recode for the
purpose of enabling USE=recode globally and make it clash with half of php USE
flags e.g.)
- causing pointless breakage/bailing out in current ebuilds for users that have
not touched USE flags on their system at all

Related links:

http://viewcvstest.gentoo.org/viewcvs.py/gentoo-x86/profiles/base/use.defaults?r1=1.22&r2=1.23
http://bugs.gentoo.org/show_bug.cgi?id=112074
http://bugs.gentoo.org/show_bug.cgi?id=86687#c7

Suggested solution: remove use.defaults feature from portage; meanwhile, stop
adding stuff in there. It gains nothing, just confuses people and breaks
things.

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgphqmjgbN1UP.pgp
Description: PGP signature

[gentoo-dev] Re: use.defaults and pointless commits

[Jakub Moc]

18.11.2005, 16:33:08, Jakub Moc wrote:

> - rendering /etc/portage/package.keywords useless (install a dep for one
> particular ebuild and enjoy the USE flag enabled globally) - causing unwanted
> results (I did not really install app-text/recode for the purpose of enabling

Err, /etc/portage/package.use of course...


--
jakub

pgpq8cGF1iFA5.pgp
Description: PGP signature

Re[2]: [gentoo-dev] punting the use.defaults feature

[Jakub Moc]

18.11.2005, 16:43:12, Mike Frysinger wrote:

> i see no reason to keep use.defaults around anymore, i think the rest of our
> config/profile system covers for it adequately and in a manner that doesnt
> confused people

Also, IIRC, saner alternatives have been suggested, like IUSE="+bleh" to enable
a use flag by default on a per-ebuild basis; use.defaults is something well
hidden from users, and USE flags automagically appearing/disappering after
emerge sync/installing an ebuild cause a lot of confusion.

>> - why has a mass of things been commited in there recently

> because they belong there

and break things/confuse people? What exactly is the benefit from this? Sorry,
I've apparently missed something, since I can't see much sense in committing
something just because it "belongs there"... Did not notice any call for adding
all that stuff either; actually - it's been done after someone requested to
remove one particular thing from use.defaults.

>> - confusing users

> the file has always confused people, whether they be user or dev

One more reason to get rid of it... :)

>> - rendering /etc/portage/package.keywords useless (install a dep for one
>> particular ebuild and enjoy the USE flag enabled globally)

> unrelated

Well, I don't think so... If I want to enable a feature for one specific ebuild
and a USE flag in /etc/portage/package.use pulls in a dep, that in turn enables
that use flag globally, it's obviously not what I intended and forces me to add
yet another -flag into make.conf

>> - causing unwanted results (I did not really install app-text/recode for the
>> purpose of enabling USE=recode globally and make it clash with half of php 
>> USE
>> flags e.g.)
>> - causing pointless breakage/bailing out in current ebuilds for users that 
>> have
>> not touched USE flags on their system at all

> you're confusing "feature" with "bug" ;)

I actually consider this feature to be a bug... :=)


--
jakub


pgpQWIIF3naSh.pgp
Description: PGP signature

Re[2]: [gentoo-dev] punting the use.defaults feature

[Jakub Moc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


18.11.2005, 20:18:58, Drake Wyrm wrote:

> Jakub Moc <[EMAIL PROTECTED]> wrote:
>> Well, I don't think so... If I want to enable a feature for one
>> specific ebuild and a USE flag in /etc/portage/package.use pulls in a
>> dep, that in turn enables that use flag globally, it's obviously not
>> what I intended and forces me to add yet another -flag into make.conf

> If you don't want portage to employ dark magic in guessing which use
> flags you want enabled, don't let it. Specify your use flags explicitly.

> Put USE="-* oneuse twouse reduse blueuse" in make.conf to set the
> globals, and _then_ start tweaking in "package.use".


No. That just does not make any sense. We are enabling default flags in
profiles only to force users to do -* and reinvent the wheel?


- --
jakub
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDfjTXhxfV/c66PZ4RAoxCAJwMBc3jqUoelsFRiIe0ptbwe9NWqgCeMyLw
WSWg09q/ZdiRfqVqqjFQBlI=
=ZE+p
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 0:29:24, Kurt Lieber wrote:

> What purpose does this serve?  This would create all sorts of confusion.
> Right now, you can meet someone in IRC and make a reasonable assumption that
> their email address is @gentoo.org.  This would confuse things
> horribly imo.  What about people like me that span multiple roles?

> What happens when someone (again, like me) starts out in one area, moves to
> another, then still a third and finally a fourth?  We're going to be
> updating aliases all over the place and for what?

> How does any of this make Gentoo Linux a better distro?  Does it reduce
> bugs?  Improve QA?  Can I add -staff.gentoo.org to my CFLAGS and get a
> 0.1% speed increase?

> There is no technical reason why any of this is necessary and it doesn't
> provide any tangible benefits that I can see.  If a user really wants to
> know someone's role within the project, they can go look it up on the web
> site.

+1 on this, and please don't touch bugzie aliases, there's enough mess as it is
(postgresl herd - [EMAIL PROTECTED]; apache herd - [EMAIL PROTECTED] -
[EMAIL PROTECTED]) If you want to do something useful, then please check that
you have existing alias in metadata.xml for the ebuilds that you are
maintaining (to name a few: qt, secure-tunneling or comm-fax is NOT an existing
alias on bugzilla).


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpxJBU5c01Jv.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 0:58:29, Grant Goodyear wrote:

> My preference is that the subdomain chosen should succinctly reflect the role
> that arch testers serve.  My personal preference would be to choose something
> like "aide", "helper", "assistant", or something similar. (Indeed, I'd have
> preferred "volunteer" if it weren't for the niggling fact that we're all
> volunteers.)

> -g2boojum-

Once again - I don't know if it's not been clear enough so far, from the
replies on this topic: I don't have time nor desire to dig out somewhere on the
web what's the correct email I should use to contact someone... there are about
200 more or less active Gentoo devs around and the last thing I need is to
ponder upon what project/role that particular person is on. What's the benefit?
:/

Please, don't introduce such PITA.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpsnSiumXLQP.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 1:07:40, Homer Parker wrote:

> On Fri, 2005-11-18 at 23:29 +, Kurt Lieber wrote:
>> There is no technical reason why any of this is necessary and it
>> doesn't
>> provide any tangible benefits that I can see.  If a user really wants
>> to
>> know someone's role within the project, they can go look it up on the
>> web
>> site.

> I'm guessing you didn't read the logs from the council meeting where 
> it
> got stipulated that this be done. [1] I also apologize (again) for it
> hitting the list the day before it was to be voted on, and stated that
> it could wait if need be. Council seemed to be pleased with it enough to
> allow it to pass.

> [1] 

> /me wanders off in search of his flameproof suit


Sorry, but the above does not make the thing any better than an *officially
approved* PITA. Does not really answer klieber's question at all, nor does it
answer the objections of other people expressed in this thread.


--
jakub

pgp8uBACEGwUH.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 1:38:03, Grant Goodyear wrote:

> Incidentally, the benefit is to make users who are actively helping Gentoo
> feel like they're part of the family.  It was decided that a straight
> @gentoo.org address would be confusing, though, since most people associate
> those addresses with developers.  I'm fairly agnostic on the whole thing,
> myself, but since the Council voted to approve the GLEP, I was simply trying
> to do my best to put forth a proposal that fit within that framework.

> -g2boojum-

Uhm, no? Most people associate those addresses with people associated with
Gentoo, perhaps? And, most people are not interested in internal Gentoo
structure and workings, as well?

Before deciding on such proposals, it might be also wise to consult infra
people who'll have to implement and maintain such things, IMHO. And, how
exactly will be people having multiple roles handled here - still missing a
clear answer...

I'm *not* against the concept of arch testers at all, in fact I find this idea 
pretty
beneficial, but why do we need to complicate things and why do we need to
create third-level domain emails for that?

--
jakub

pgpMA7vL46NrY.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 3:07:41, Ciaran McCreesh wrote:

> Sure, recognise their contributions, by giving them credit in ChangeLogs.

How exactly does testing stuff fit into *changelogs*, have I missed something?


-- 

jakub

pgpd4At0gxKS4.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 3:49:46, Ciaran McCreesh wrote:

> On Sat, 19 Nov 2005 03:27:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | 19.11.2005, 3:07:41, Ciaran McCreesh wrote:
| >> Sure, recognise their contributions, by giving them credit in
| >> ChangeLogs.
> | 
> | How exactly does testing stuff fit into *changelogs*, have I missed
> | something?

> "Stable on $arch, thanks to $at1 and $at2 for testing and hunting down
> build issues."

Thanks, no... Reminds ne of the debates on forums.g.o, why emerge --changelog
feature is useless and why people file pointless bugs: too much irrelevant
stuff.

Testing ebuilds when keywording/marking stable is supposed to be
mandatory and such stuff does not belong into changelogs. (Submitting patches
is naturally completely different thing, but that's not what ATs do 99% of the
time they spend testing stuff).


-- 

jakub

pgpQVYcgsQSLw.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 5:30:35, Stephen P. Becker wrote:

>> Testing ebuilds when keywording/marking stable is supposed to be
>> mandatory and such stuff does not belong into changelogs.

> Sorry, but that's a big no.  People that add/remove keywords without 
> making note in the Changelog deserve a massive kick in the nuts.  I'm 
> not sure if you have been paying attention to Changelogs, but all of the 
> sane arches have and will continue to make such entries.

> -Steve

Grrrmhhh, was it so much unclear? I mean: "stable on x86" definitely belongs to
changelogs, while "stable on x86, thanks Jim for opening a keywording bug, Jack
and Jim for testing and Joe for reminding me five times to mark it finally
stable when I forgot about it" does NOT.

It's the responsibility of the developer who keyworded the thing anyway, ATs
are not allowed to keyword stuff and don't have RW CVS access, so what is the
purpose of tracking such stuff in changelogs and cluttering them? Use CVS
commit messages to track such things if you think you need it.

--
jakub

pgpjq8z3F08C9.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 10:31:23, Thierry Carrez wrote:

> Corey Shields wrote:

>>>Before deciding on such proposals, it might be also wise to consult infra
>>>people who'll have to implement and maintain such things, IMHO. And, how
>>>exactly will be people having multiple roles handled here - still missing a
>>>clear answer...
>> 
>> Jakub++  Nobody in infra is on board with this idea, so you will be hard 
>> pressed to find someone willing to implement it.

> What I find disturbing here is that nobody found the issue interesting
> enough to read the October Council decisions as to what was needed to be
> changed for the GLEP to be approved. But when, one month later, those
> requirements have been met and the GLEP approved, lots of people
> discover that the issue is interesting and complain about it (when it's
> a little too late to be changed).

Erm, what exactly could have been discussed, the revised GLEP being submitted
about a day before the council meeting? Are you expecting people to hang on
email 24/7?

> I'm losing faith in Gentoo. When the GLEP was first discussed, the
> general mood was that we shouldn't give ATs the same powers than we give
> to devs (in particular, no right to vote for the Council), and in
> consequence a need to tell them apart. The Council rejected the proposed
> GLEP in that sense. Now, the mood is like the Council want to yellowstar
> some part of our contributors... and the discussion happen on the same list.

> You can't just ignore the discussion and the iterim decisions and
> complain afterwards when the decision is taken.

I've already mentioned that I don't oppose to AT concept and making them
official Gentoo stuff (and a couple of people did that as well), but drawing
the distinction around an email address, resulting in troubles for
infrastructure and hassle for users/other devs has not been properly considered
apparently; still waiting for someone to show a single benefit of such an
arrangement.

Email address is a means of communication with people, not a *power*. If
anyone's interested in/does care for what's the exact role of that particular
person in Gentoo, that's what roll-call is for. AT or not, any person w/
@gentoo.org email address is representing Gentoo, users don't care what's the
difference between ATs, forums staff and full devs and I don't see why exactly
they should even care. Users also don't care if someone has CVS commit privs or
voting rights. These are internal Gentoo things, email address is not playing
any role in that.

Now, we might we perhaps move the focus to more important issues jstubbs
mentioned in his last email, expecting that any implementation of the now
approved GLEP wrt the email addresses won't be pushed in a similar way the
whole revised GLEP has been, until infra issues and usefulness of this are
sorted out/reconsidered at least.


-- 

jakub

pgpO0DycdKZ4m.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Email subdomain

[Jakub Moc]

19.11.2005, 23:19:41, Brian Harring wrote:

> On Sat, Nov 19, 2005 at 03:20:57PM -0600, Lance Albertson wrote:

>> I would have preferred that the people involved with this could
>> have directly asked infra if this would work for us. That's a simple
>> request that I did not see from these folks.

> It's a crazy notion, but y'all could've commented in the *TWO* months 
> that this glep has been percolating, "yo, what do you want from an 
> infra standpoint?".

> Or implemented anoncvs in the meantime, thus nuking the main request 
> that's being made of infra.

/ne notes there's been no such thing like subdomains in the *original*
(rejected) GLEP...


--
jakub

pgp6MXTC6V2qc.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Request for changes to GLEP 41

[Jakub Moc]

20.11.2005, 12:10:35, Mike Frysinger wrote:

> On Sat, Nov 19, 2005 at 04:26:20PM +, Kurt Lieber wrote:
>> * Drop the idea of giving the arch testers an email alias altogether

> works for me but i think makes the GLEP less meaningful

Unless we are able to move to some important things instead of flexing muscles
and ego in endless debates on importance of subdomains creating pointless
administrative overhead, someone *please* with sugar on top drop that idea from
the GLEP.

This debate starts to be pretty much ridiculous.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpWu0qWCJkCy.pgp
Description: PGP signature

Re[2]: [gentoo-dev] status of http://wwwredesign.gentoo.org

[Jakub Moc]

21.11.2005, 13:23:29, Herbert G. Fischer wrote:

> Good job!
 
>  - The bottom menus are very nice but I think they are in the wrong place.
> The natural human being will search for all the site menu items on the top or
> "first" page (without scrolling). The rule in this case is to put all menu
> items in one place, or, if this items need to be separated, so organize and
> group related items. "Docs" in the top then "documentation" right bellow and
> "Documentation" on the bottom again is a waist of space, don't you think?
 
Well, I would like to see them on the left (and really could live without those
illustrative pics accompanying them, but that's just me. ;)


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpmAujfzog05.pgp
Description: PGP signature

Re: [gentoo-dev] Frozen Bacula??

[Jakub Moc]

21.11.2005, 14:22:39, Herbert G. Fischer wrote:

> Hi,
 
>  I'm looking forward to use Bacula 1.38.1 that was released last week but
> not even 1.38.0 that was released 31 october 2005 has an ebuild yet. There is
> some problem with it? It's abandoned?
 
>  Please let me know if you need help on this ebuild. I don't know how to
> create an ebuild and include it on the Gentoo Portage but I'm interested in
> using Bacula 1.38.1 because of it's newest aditions.
 
http://bugs.gentoo.org/show_bug.cgi?id=111677


--
jakub

pgpYc8OswYHKK.pgp
Description: PGP signature

Re[2]: [gentoo-dev] status of http://wwwredesign.gentoo.org

[Jakub Moc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


21.11.2005, 20:16:47, Renat Golubchyk wrote:

> On Mon, 21 Nov 2005 01:37:00 -0600 Lance Albertson
> <[EMAIL PROTECTED]> wrote:

> Variable names and commands are bright blue in the old docs. The new
> color is darker and that does not improve readability since the
> contrast is not optimal. I think a brighter tint would make it easier
> to distinguish the text color from the (highlighted) parts.

> Cheers,
> Renat

Was like that originally, looked pretty bad and distracting.


- --
jakub
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDgjknhxfV/c66PZ4RAg/gAJ0c30PyYH49Hjt8XionDC+a3JAGZgCfUaE1
IKq3wzs1zG+UcgwNA7ypYQ4=
=Dxaf
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] Decision to remove stage1/2 from installation documentation

[Jakub Moc]

22.11.2005, 17:30:50, Chris Gianelloni wrote:

> On Tue, 2005-11-22 at 09:54 -0600, Lance Albertson wrote:


> Also, the problem is not so much needing manpower for testing as far as
> Release Engineering is concerned.  It is instead having some method in
> place where devs actually perform QA on their own packages.  A prime
> example of this is bug #110383.  I was always under the impression that
> if you were adding a flag to a package that affected "system" that it
> was your responsibility to ensure that "system" still works, rather than
> passing it off onto the Release Engineering team.  Now, I don't know
> what package it is that is pulling in hal for this user, so it most
> likely is not hal's fault, but it illustrates the point perfectly.

Blame vapier for that one ;p (Bug 99533 half-fixed for ~arch only);
alternatively, you can blame usata for adding emacs support to gpm in the first
place (Bug 80217).


-- 

jakub

pgprFm6K2qXMG.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation

[Jakub Moc]

22.11.2005, 18:51:12, Simon Stelling wrote:

> Harald van D?k wrote:
>> (Note that I'm not going to argue either way whether this is a good
>> thing; I'm merely pointing out that the docs do say we're about choice.)

> You still can choose between stage3 and stage3+GRP without having to do 
> anything
> but following the handbook :)

Ah, that's a nice choice... ;p

Seriously, I suppose noone plans to remove stage1 from the mirrors; then it
would be nice to have it properly documented (probably outside of handbook and
with warning that it's an unsupported install method if releng wish so). It's
still useful for people and I guess complete removal of docs will just lead to
some half-baked howtos published in forums.g.o. and people complaining on IRC
that it does not work.

-- 

jakub


pgpPPzyNO76WZ.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Decision to remove stage1/2 from installation documentation

[Jakub Moc]

22.11.2005, 19:03:49, Grant Goodyear wrote:

> I keep hearing this, isn't there a real difference between a stage 1 and a
> stage 3 install inasmuch as somebody who needs (or wants) to dramatically
> tailor what's in the system profile can choose to do so from a stage 1 or 2,
> but would have to remove packages after the fact if starting from a stage 3?
> I wouldn't have a problem with that, as long as we document it, but it just
> seems that the claim that the old and new methods produce _exactly_ the same
> results seems to be stretching things a bit.

> -g2boojum-

Uhm, which reliable tools do we have for removing no-longer needed packages?
emerge --depclean producing the huge red "I'm broken" warning? Or emerge
--prune with similar warning in man page?

Hmmm...

-- 

jakub

pgpiPdhkPJTAa.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation

[Jakub Moc]

22.11.2005, 19:13:36, Danny van Dyk wrote:

> Thomas Kirchner schrieb: | I'm against this change, personally.  Stage1 has
> *always* been for | advanced users.  If someone screws up their own system
> (which is possible | in any number of other ways, as well) then it's their
> fault.  Gentoo | isn't about babying users.  It is about choice.  And if
> changing that is | the only way to reduce your workload, well...

> In which way do we take away your ability to choose by moving
> documentation from one place to another one? It's just the aim to not
> include this documentation into the handbook (which ends up on the
> installcds) and to move it out of the scope of ricers.

If you look at http://www.gentoo.org/doc/en/faq.xml (How do I Install Gentoo
Using a Stage1 or Stage2 Tarball?) I'd not exactly say that the documentations
has been *moved*. Compare that with the original handbook.


-- 

jakub

pgpwo0tJZp6yl.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Decision to remove stage1/2 from installation documentation

[Jakub Moc]

22.11.2005, 20:57:15, Chris Gianelloni wrote:

> The idea was to move out the stage1/stage2 docs to somewhere else.  Then
> create some sort of "Advanced Installation Topics" guide or something, to
> list out the replacement procedures for customizing a system from a stage3
> tarball, then, eventually, drop the stage1 and stage2 tarballs.

Erm, did you read what solar wrote about hardened stages and why should stage1
still stay?

> I was working on the idea of doing it all in stages.  The "problem" occurred
> from people freaking out because they didn't bother reading the entire news
> blurb that tells exactly where the instructions moved to, plus links to the
> bug # and discussion.  There's also this nice section in the Handbook.

> "A stage3 tarball is an archive containing a minimal Gentoo environment,
> suitable to continue the Gentoo installation using the instructions in
> this manual. Previously, the Gentoo Handbook described the installation
> using one of three stage tarballs. While Gentoo still offers stage1 and
> stage2 tarballs, the official installation method uses the stage3
> tarball. If you are interested in performing a Gentoo installation using
> a stage1 or stage2 tarball, please read the Gentoo FAQ on How do I
> Install Gentoo Using a Stage1 or Stage2 Tarball?"

That FAQ section has nothing in common with the original stage1 docs. Sorry,
installing stage3 to remove all the use flags cruft subsequently, bootstrap and
re-emerge the system and then ponder which packages are not needed any more
(again, there's no reliable tool to remove unneeded stuff from system, I've
already mentioned this once) - hmmm... :/

And - once stages 1+2 are removed (as you are suggesting above), then I'll
install the system only to build my own stage1 w/ catalyst, then reformat and
start over with my own stage? Ah, that makes live sooo much easier ;p


> Really, everybody is just up in arms over a knee-jerk reaction to not
> reading carefully.  What it boils down to is either not knowing the
> facts, or trolling/flaming.

Why exactly is evaporating stage1 an ultimate goal here (as it seems to me?).
So don't support it, but why it should not exist?


-- 

jakub

pgp2A35Wx1G0J.pgp
Description: PGP signature

Re[4]: [gentoo-dev] Decision to remove stage1/2 from installation documentation

[Jakub Moc]

22.11.2005, 21:58:50, Chris Gianelloni wrote:

>> That FAQ section has nothing in common with the original stage1 docs. Sorry,
>> installing stage3 to remove all the use flags cruft subsequently, bootstrap
>> and re-emerge the system and then ponder which packages are not needed any
>> more (again, there's no reliable tool to remove unneeded stuff from system,
>> I've already mentioned this once) - hmmm... :/

> No.  That FAQ section is there to describe how to install from a stage1
> or stage2 tarball and has nothing to do with a stage3 tarball, nor did I
> ever say that it would.  I'm not sure I understand what you're getting
> at here.

Uhm, do I really need to quote it here?


"How do I Install Gentoo Using a Stage1 or Stage2 Tarball?

...

However, Gentoo still provides stage1 and stage2 tarballs. This is for
development purposes (the Release Engineering team starts from a stage1 tarball
to obtain a stage3) but shouldn't be used by users: a stage3 tarball can very
well be used to bootstrap the system."


Sorry, but that does not answer the original FAQ question at all...
The above does not describe a stage1 install, but a workaround procedure you've
invented because of your strong dislike of stage1 install. However much you
say the result is the same, it's not. E.g. - how exactly I get rid of those
unneeded packages once I've changed the use flags, bootstrapped and rebuilt the
system? Honestly, stage3 is something I don't find useful for a server install
because the default use flags are aimed at desktop systems.

Sure, I can use hardened stage3, compiled for i386 and enjoy the Debian
feeling. ;p

> The whole point here is in what we want to support.

So don't support it, but let it exist!

>> Why exactly is evaporating stage1 an ultimate goal here (as it seems to me?).

> It's usefulness is far outweighed by the problems it causes, and it is
> really no longer necessary, nor has it been for over a year now.

Uhm, I've seen quite a couple of examples in this debate why it is still
necessary and useful.

>> So don't support it, but why it should not exist?

> I'll explain this just once.  If we release it, we are expected to
> support it.  There are *tons* of examples of things we won't do because
> we don't want the headache of supporting it.  Why should this be any
> different?

sigh... You are not required to support it - exactly like you are not expected
or required to support gcc-4 and gcc-4.1 and you can mark any bugs about it as
INVALID (happens every day, quite frankly).


-- 

jakub


pgpJVJFKWnV1D.pgp
Description: PGP signature

Re[6]: [gentoo-dev] Decision to remove stage1/2 from installation documentation

[Jakub Moc]

23.11.2005, 0:26:03, Chris Gianelloni wrote:

>> However, Gentoo still provides stage1 and stage2 tarballs. This is for
>> development purposes (the Release Engineering team starts from a stage1
>> tarball to obtain a stage3) but shouldn't be used by users: a stage3 tarball
>> can very well be used to bootstrap the system." 
>> 
>> Sorry, but that does not answer the original FAQ question at all...

> Umm... yeah.  So you snip it RIGHT BEFORE THE INSTALL INSTRUCTIONS...
> Good show... *rolleyes*

I can summarize those "ommited" instructions for you, looks pretty much like
this: How do I make a cup of coffee? Uhm, you first make a cup of tea, then
pour it out into the kitchen sink, and then make your coffee.

> emerge -e world && emerge -e world && emerge depclean

You've missed revdep-rebuild to fix the borkage that emerge depclean produced. 
;)

>> Sure, I can use hardened stage3, compiled for i386 and enjoy the Debian
>> feeling. ;p

> You can do whatever you like.  Nobody is forcing you to do anything.

> That being said, you are not going to force *me* to do anything, either.

Hmm, have I missed an argument here? Actually, the above is incorrect. You
*are* forcing me to use stage3, but whatever... after all I still have the nice
choice to not use GRP, as already mentioned previously, so no need to complain.

> Look.  I don't care what you think I should do.  I really don't.  You can
> argue this point until you're blue in the face, but until I see you
> volunteering to do THE WORK you really have no say.  This really is something
> that is an internal decision to Release Engineering.  We have discussed it
> and we're in agreement here.  Now, the one thing that I've not seen *anyone*
> here do is step up to help with any of this.  Instead, all I see is flames,
> name calling, and other useless arguments.  We decided that we do not want to
> put out unsupported, known broken, crap.

> Do you really not understand the fact that we are making an attempt to
> improve the quality of our distribution.  We are trying to improve the end
> user experience.  We have already seen that users are not following the
> documentation, as it is.  The Handbook keeps growing in size and complexity,
> and there's no end in sight.  All the while, the quality is going to shit
> because we crossed the line where we can feasibly test what we're producing a
> long, LONG time ago.  You're more than welcome to argue this for as long as
> you want, but I am done.


   Yeah, as I see it, this will only reach the acceptable quality when it goes
GLI click click click way, of course also additionally hiding the dangerous use
flags from users so that they cannot possibly break anything when installing,
since they don't read the instruction properly. By that time, most of the
people who cared will have switched to LFS, and the rest won't mind really. And
additionally, this might attract a considerable Manra^^Wiva user base, so
everyone will benefit. ;p


*Now* I hope I've finally been sarcastic enough to justify the incredibly
pissed-off tone you've shown in your previous reply. I've not exactly seen any
flames or name calling here, and I'm not the one to blame for the fact
that you're feeling overloaded. Jump back in when you are in more constructive
mood. With this level of irritation caused by anyone who does not jump happily
on stage1 grave, the debate lacks any sense. Bleh...

-- 

jakub

pgp8NgfK6PDnA.pgp
Description: PGP signature

Re[8]: [gentoo-dev] Decision to remove stage1/2 from installation documentation

[Jakub Moc]

23.11.2005, 11:25:58, Paul de Vrieze wrote:

> On Wednesday 23 November 2005 01:55, Jakub Moc wrote:
>> > emerge -e world && emerge -e world && emerge depclean
>>
>> You've missed revdep-rebuild to fix the borkage that emerge depclean
>> produced. ;)

> After double rebuilding of the complete world I would seriously doubt it 
> that any stray dependencies were still around. If there were, it would be 
> because of broken ebuilds. That should be reported as bugs and fixed 
> instead of relying on revdep-rebuild.

You've probably missed the point. It's emerge depclean that's broken; again -
we are lacking any reliable way to punt unneded packages.

BTW, I'd still like to know how I'll get nptl(only) hardened install once
stage1 is gone. i386 does not have nptl, and I've done change CHOST && emerge
-e system && emerge -e world job a couple of times and it never went smoothly.


-- 

jakub

pgpqyAFKp9Nmd.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Re: Possible solution: email subdomain

[Jakub Moc]

23.11.2005, 20:07:15, Dan Meltzer wrote:


> Can we get all current developers renamed to nick.developer then? just
> to alleiviate any confusion someone may have...

> [snip a buttload or two]

NO (I sincerely hope at least), and please let's finally stop messing w/ email
addresses causing further confusion and administrative overhead for no good
reason. :=(

*sigh*


-- 

jakub


pgpVcDtneAbEB.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Re: enewuser/enewgroup getting their own eclass

[Jakub Moc]

23.11.2005, 22:14:31, Duncan wrote:

[irrelevant twaddle omitted]

> It may be possible to automate code creation, but it's not possible to
> automate a community, and humans in such a community /don't/ tend to stay
> strictly on topic. That's just the way humans are, and have been for far
> longer than either you or I have been around.

I can't speak for others, but personally I'm not interested in receiving such
crap in my mailbox. There's enough traffic here as it is. Please, keep on topic
or go chat elsewhere.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpPaxpB7jwvO.pgp
Description: PGP signature

Re[2]: [gentoo-dev] manpages that requires dependencies

[Jakub Moc]

25.11.2005, 0:58:28, Ciaran McCreesh wrote:

> On Fri, 25 Nov 2005 00:49:23 +0100 "Diego 'Flameeyes' Petteno"
> <[EMAIL PROTECTED]> wrote:
> | Hi everybody, a little question that I'd like to be answered (so that
> | we can make it a sort of rule).
> | How should manpages that are generated be managed?
> | 
> | The common sense and looking to other ebuilds would say to always
> | build man pages, but when it asks me to install something like
> | docbook-sgml-utils, I'm tempted not to do that ;)

> man pages can't be considered optional (despite what RMS says). They're
> not fancy extra HTML API documentation, they're core, so they don't get
> a USE flag.

> Of course, if FEATURES were in the USE expand list, you could use
> ! features_noman ? ( ) ...

That is all fine and dandy, but if you search bugzilla for USE=doc related
bugs, you might think twice before adding yet another inevitably broken thing
to portage. docbook-sgml-utils & co. is extremely fragile and buggy thing.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpZ9CTbskDFd.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Update of http://wwwredesign.gentoo.org

[Jakub Moc]

25.11.2005, 8:06:51, Flammie Pirinen wrote:

> 2005-11-25, Curtis Napier sanoi, jotta:

>> So on that note, I've gone over the design and gotten it closer to 
>> Aarons's reference. [...] Check out what I did change in the meantime.

> Uh-oh. The usability regression from what the site was yesterday is
> unbelievable. Almost all of the texts are too small to read again, and
> the color combinations are also unreadable again.  I hope that you and
> Aaron are still going to take into account at least all the usability
> related requests from the feedback you asked, because I'd be pretty
> annoyed to see yet another web site redesign that manages to make
> original website even more unusable than it was.

Ouch, what happened again?!... I can't agree more. I object to any redesign if
the whole thing was arranged so badly that all the accessibility flaws are to
be considered an unchangeable part of the "design". Better stick w/ the current
one in that case. :-(


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpd4hgTLeSpP.pgp
Description: PGP signature

Re[2]: [gentoo-dev] manpages that requires dependencies

[Jakub Moc]

27.11.2005, 15:39:48, Jason Stubbs wrote:

> On Sunday 27 November 2005 22:09, Ned Ludd wrote:
>> On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
>> > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
>> > > Except that no{man,info,doc} are on the to-die list anyway.
>> >
>> > They are very valuable features and quite easy to use without mucking
>> > with INSTALL_MASK. I'm against this change without some justification.
>>
>> further investigation shows that you can't simply get rid of these as
>> several core ebuilds use the feature to control the creation of
>> packages. A quick grep shows that several ebuilds do stuff like.
>> has noman FEATURES && do_stuff
>>
>> openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
>> no{man,info,doc} FEATURES= already.

> Core packages or not, they are all broken. When the requirement came up, the 
> respective maintainers should have spoken up so that a proper solution could 
> be found. When are the quick hacks going to stop? :|

I can't see why exactly do we need to get rid of useful features? :-(

-- 

jakub

pgpdTiupJuCiA.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86

[Jakub Moc]

30.11.2005, 22:19:27, Peter Ruskin wrote:

> On Wednesday 30 November 2005 20:12, Mark Loeser wrote:
>> gcc-3.4.* will not be selected as your system compiler after
>> merging it.  The old gcc profile is still valid, therefore it is
>> kept.  Users have to consciously go and change their profile to
>> change their gcc, so nothing is going to just magically break.

> But we should not yet be encouraged to switch to 3.4.  I upgraded to 
> i686-pc-linux-gnu-3.4.4 a long time ago but my gcc profile is still 
> firmly fixed at 3.3.5-20050130 because of bug #101471.  This bug 
> was opened 2005-08-05 and it's still not fixed.

> Whenever I try 3.4.4 I can't rebuild glibc because of this bug.

Sure. So remove USE=vanilla from your use flags and it will work. That bug
won't be fixed, because it's not a bug.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpkKIpnkGEFu.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86

[Jakub Moc]

1.12.2005, 0:29:48, Chris Gianelloni wrote:

> On Wed, 2005-11-30 at 17:34 -0500, Philip Webb wrote:

>> Ordinarily, I upgrade packages individually when it seems appropriate
>> & never do 'emerge world' with or without '-e' or other flags;
>> I do 'esync' every weekend & look at what is marked as having changed.

> Technically, you don't need to rebuild world.  You only need to rebuild
> stuff that uses C++ and links to libstdc++.

revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid
things like Bug 64615.


-- 

jakub


pgpgEl2aFDbjP.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86

[Jakub Moc]

1.12.2005, 1:30:41, Marien Zwart wrote:

> Not sure if everyone is aware of this, but most installed pythons link to
> libstdc++.so. This is not a problem if you run the above revdep-rebuild (it
> should catch it just fine). It is a problem if you get rid of gcc 3.3 before
> installing libstdc++-v3 or running the revdep-rebuild, as it will leave you
> with a broken python and therefore unable to emerge.

Which returns us to the question why don't we build python with nocxx so that
we could avoid this major PITA.


-- 

jakub


pgpQpg8uVxpUk.pgp
Description: PGP signature

Re: [gentoo-dev] New x86 developer: Joshua Jackson

[Jakub Moc]

10.12.2005, 11:09:50, Bryan �stergaard wrote:

> Added to the > menagerie are 3 fish, 2 bird and a hamster.

Hey, so that was you who stole jforman's hamsters during bugzie upgrade and
broke the thing? :P

Welcome... ;)


-- 

jakub

pgp3AC7XoWZMa.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Re: Changes to date format of current GLEPs

[Jakub Moc]

13.12.2005, 22:00:12, Ciaran McCreesh wrote:

> On Tue, 13 Dec 2005 21:54:48 +0100 Danny van Dyk <[EMAIL PROTECTED]>
> wrote:
> | Do you _really_ think this make a GLEP necessary?

> Yes. Otherwise, the next person who comes along and writes a GLEP that
> does something to do with dates will have to rationalise the whole date
> format decision all over again.

> You're assuming that "GLEP == lots of work". This is the case for some
> things, but it isn't true in all situations. Look at 43 for an example.

Pardon my ignorance, but how's a GLEP amending a GLEP (amending a GLEP ...)
less confusing than just changing the text of the original GLEP... Huh, goes
beyond me...


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp6OIKAOoK3K.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Jakub Moc]

14.12.2005, 0:05:03, Olivier Crete wrote:


> And why not just adding a changelog to the glep explaining the changes?
> I really don't like to idea of having to read 8 gleps to find out how to
> write a glep ... and calling it glep 1.a is a good idea.. or 1.1

+1

-- 

jakub

pgpLbeynqVjnu.pgp
Description: PGP signature

Re[2]: [gentoo-dev] UPGRADE ANNOUNCEMENT bugs.gentoo.org

[Jakub Moc]

14.12.2005, 18:12:05, Georgi Georgiev wrote:

> And for the network challenged, output in local time:

And for the bandwidth/time-challenged, who do not wish to waste their time
reading useless emails:

:0:
* ^From:[EMAIL PROTECTED]
/dev/null


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpV6fMOpMxt2.pgp
Description: PGP signature

Re: [gentoo-dev] baselayout-1.11.14 stabilization

[Jakub Moc]

20.12.2005, 15:36:02, Mike Frysinger wrote:

> since we have baselayout-1.12.x in ~arch, the new stable candidate
> (1.11.14) isnt getting much air time ... can people try upgrading to
> it and post any feedback they have with it ?  it should mostly be a
> bugfix release over 1.11.13 since we arent doing any more real features
> for the 1.11.x branch ...
> -mike

Using for over a week, fixed udev for me, did not break anything... Ship it!
:=)

-- 

jakub

pgprrgT5isbKE.pgp
Description: PGP signature

[gentoo-dev] Commiting of ~arch virtual/* ebuilds causes deptree issues

[Jakub Moc]

Hello here,

the virtual/ thingy broke the deptree again with virtual/libstdc++ (see Bug
116253), essentially the same issue like with virtual/x11. These virtuals
need to go straight stable if any of their RDEPEND atoms is stable for a
particular arch.

Betelgeuse is working on a repoman check for this issue, meanwhile, if there
are more virtuals planned, please bear this in mind. :)

Thanks.

-- 

jakub

pgpcdJ0bugkrI.pgp
Description: PGP signature

Re: [gentoo-dev] mac/xmms-mac licence issue

[Jakub Moc]

25.12.2005, 3:11:53, Bret Towe wrote:

> i can understand putting proper warning in the ebuild if the dev thinks
> that its worth the user really noting the issues surrounding it, not
> forcing their ideals onto the user if i wanted that i would run debian

Erm, we are not forcing our ideal on users, we simple refuse to commit an
ebuild for code which has no valid license.

For those unfamiliar with the whole thing (Bug 52882, Bug 94477 and tons of
dupes): Someone has forked a proprietary code with a sucky license,
relicensed it under fake LGPL for the sole purpose of being able to host the
project on SF, and even explicitely acknowledges that what he's doing is
illegal:

--- COPYING --
Due to the license , so I can't make it public,
Last November, I decided to register mac-port at SourceForge,
so I had to choose an open source license, so I chosen LGPL
for this mac-port. It is close to the original license,
but doesn't get the permission from the original author, Matt.

This license would be changed when the author asks in the
future.
--

What the heck kind of license and behaviour is the above? And why should
Gentoo ship such crap?

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpLILkpRpuBF.pgp
Description: PGP signature

Re[2]: [gentoo-dev] mac/xmms-mac licence issue

[Jakub Moc]

25.12.2005, 3:51:15, Brian Harring wrote:


> Jakub responded in this thread about shipping a crap license... imo, 
> that's not the issue.

> The issue is that we would be knowingly violating a license (however 
> horrid the license is).  

> Two routes out of this- clean room reimplementation of the codec, or
> someone manages to track down the original author and gets the code 
> converted to a different license.  Latter still is tricky, since any 
> contributions to the project, you would need all authors to sign off 
> on the new license- this is assuming the project doesn't do 
> centralized copyright, and assuming people have actually contributed 
> to it beyond original author.


Not exactly what I meant. There's actually no (clear) license, the original
one would apply to the original code, not to the patches submitted after
it's been "re-licensed" under LGPL. Since upstream is dead, we can't ship
the original code (leaving the question why we should do it at all aside),
also we can't exactly find all the people who contributed the patches under
LGPL, and there's no way to contribute the code back to upstream as the
original license requires. Such code is a real "bargain" to commit :P

Rewrite from scratch, that's what left here. So much you get if you start
with a bullshit license originally and then go MIA. :/

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp5tbo6BzPB3.pgp
Description: PGP signature

Re[2]: [gentoo-dev] mac/xmms-mac licence issue

[Jakub Moc]

25.12.2005, 4:17:05, Bret Towe wrote:

> On 12/24/05, Carsten Lohrke <[EMAIL PROTECTED]> wrote:
>> This isn't politics, but copyright infringement on top of a ridiculous 
>> license
>> (when you want to see it as one) we had a short discussion1 about several
>> months ago.

> im sorry i fail to see how copyright infringement or a ridiculous licence
> matters when commiting a ebuild to portage just pick a licence if thats the
> issue warn the user and leave it at that

Yuck. I'm sorry, but arguments like "copyright does not matter, just go ship
it" won't fare too well, leaving further debate pretty much pointless.
Copyright *does* matter, if you want to see an example how a ridiculous
license kills the job, go see qmail ebuilds.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpaNFE9KAryN.pgp
Description: PGP signature

Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Jakub Moc]

>> Currently there are quite a few ebuilds in the tree that execute dodoc or
>> dohtml for files that do not exist. I think it would be nice to have
>> ebuilds die if this is the case. To not break current ebuilds this would
>> only happen with FEATURES="stricter".

Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
checks implemented in recent portage versions. Some of these bugs are
completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
etc. What's the point of this breakage? Why are these QA checks fatal,
causing ebuilds to bail out? How can you disable such checks per-ebuild
(AFAIK - you can't) to not annoy users with QA notices and breakage one can
do nothing about anyway?

As Flameeyes pointed out, dodoc/dohtml is also used in eclasses. This can
break many ebuilds. Users will report duplicate bugs because they will not
realize that it's the eclass causing the failure, not the ebuild. Again,
what's the point? How will it work with FEATURES="nodoc"? Why should an
ebuild ever fail just because some doc file is missing or got renamed or
whatever?


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpPOJRY0EZSR.pgp
Description: PGP signature

Re[2]: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on

[Jakub Moc]

26.12.2005, 14:28:12, Jason Stubbs wrote:

> On Monday 26 December 2005 20:01, Jakub Moc wrote:
>> >> Currently there are quite a few ebuilds in the tree that execute dodoc
>> >> or dohtml for files that do not exist. I think it would be nice to have
>> >> ebuilds die if this is the case. To not break current ebuilds this would
>> >> only happen with FEATURES="stricter".
>>
>> Sigh... There are already bugs flowing in for TEXTRELs/executable stacks
>> checks implemented in recent portage versions. Some of these bugs are
>> completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc.
>> etc.

> Sigh... None of these issues have made there way to dev-portage.

> --
> Jason Stubbs

Well, then assign Bug 116499 or Bug 116602 to yourself (qemu), there're
textrels in openoffice-bin, mozilla-firefox-bin (upstream, don't hold your
breath to get this fixed), acroread (cantfix really), this for sure will be
an issue for many games binaries, etc. While it's often upstream/cantfix, I
don't see much sense in making these QA checks fatal really.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpmuHTx23Adq.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning

[Jakub Moc]

26.12.2005, 16:35:33, Ciaran McCreesh wrote:

> On Mon, 26 Dec 2005 00:09:57 -0500 Doug Goldstein <[EMAIL PROTECTED]>
> wrote:
> | the USE defaults are a bit INSANE... We need to get rid of some of
> | this crap...

> No, you just don't understand how they work. It's not an issue of
> "is foo important". It's an issue of "for packages with optional foo
> support, does it make most sense for foo to be enabled by default?".

OK, then:

alsa - this does not make most sense definitely, this horrible thing needs
to die.

emboss - "Adds support for the European Molecular Biology Open Software
Suite." WTF? Why are we abusing make.defaults for such stuff?

eds - please, fix the ebuilds properly instead of throwing the thing on
everyone. This has already caused numerous invalid bugs with people
wondering why the heck portage wants to emerge gnome with USE="-gtk -gnome"

motif - no need to repeat Cardoe's description...  and this has caused tons
of "cups depends on X" bugs.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp2215uzTW7p.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning

[Jakub Moc]

26.12.2005, 18:07:45, Ciaran McCreesh wrote:

> On Mon, 26 Dec 2005 17:57:17 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | alsa - this does not make most sense definitely, this horrible thing
> | needs to die.

> Why? On x86, alsa is the least broken sound system, and on x86, the
> target for the default profiles is desktops, and most desktops have
> soundcards.

Uh eh... I meant *arts*, no clue how I wrote alsa.


-- 

jakub

pgp54Gtoj1uG5.pgp
Description: PGP signature

Re[4]: [gentoo-dev] Stupid USE defaults that need cleaning

[Jakub Moc]

26.12.2005, 19:36:23, Joe McCann wrote:

> On Mon, 2005-12-26 at 17:57 +0100, Jakub Moc wrote:

>> eds - please, fix the ebuilds properly instead of throwing the thing on
>> everyone. This has already caused numerous invalid bugs with people
>> wondering why the heck portage wants to emerge gnome with USE="-gtk -gnome"
>> 

> For the record, the eds flag was added as a default flag because every 3rd
> gnome user would file bugs or complain via forums because they installed
> gnome, found no evolution-data-server integration, and then be bummed when
> they had to recompile packages again. This whole thread seems to have come
> from a misunderstanding of how use.defaults work and 20 min of boredom.

OK, so because every 3rd gnome user is not able to add the proper use flag
to make.conf, every non-gnome user is stuck with investigating and putting
-eds into make.conf to avoid pulling in gnome crap. Wonderful.

Yes, I am ranting, because this kind of use flags basically pulls in huge
number or unwanted dependencies; exactly the same thing with motif - would
someone explain why the heck do do we need this thing in make.defaults?

I don't think that this discussion will lead somewhere, so - anyone cares to
add a non-bloated x86 profile (basically, something like
profiles/hardened/x86/2.6 minus the hardened stuff) so that people who don't
want all this bloat can have a sane starting point?

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp7yuTYcnogo.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning

[Jakub Moc]

26.12.2005, 22:21:14, Diego 'Flameeyes' Petteno wrote:

> On Monday 26 December 2005 20:24, Jakub Moc wrote:
>> exactly the same thing with motif - would
>> someone explain why the heck do do we need this thing in make.defaults?
> Because people emerges xpdf waiting for xpdf binary and they won't find it 
> with -motif, as it requires motif integration

Eeek?! This is totally broken behaviour...

> , but I think more people would
> just have xpdf installed because of cups or older kpdf/gpdf versions.
> Now that poppler is there, the problem might be mitigated, in the future, tho,
> as cups still uses xpdf and not poppler yet.

That would be really nice...


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpXbJO9BVhi7.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Changing description for the xml global use flag

[Jakub Moc]

29.12.2005, 12:52:09, Mike Frysinger wrote:

[rant omitted]

Maybe you could rather have used those 5 minutes you had spent writing your
mail to fix horde ebuilds/eclass instead. They have been broken with
dev-lang/php ever since it came into portage. :P

Have a nice day...

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpcIGWOQtg0m.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Changing description for the xml global use flag

[Jakub Moc]

29.12.2005, 14:20:37, Mike Frysinger wrote:

> On Thursday 29 December 2005 08:06, Jakub Moc wrote:
>> Maybe you could rather have used those 5 minutes you had spent writing your
>> mail to fix horde ebuilds/eclass instead. They have been broken with
>> dev-lang/php ever since it came into portage. :P

> speaking of dicks, i knew i hadnt heard from you in a while

> i dont recall ever seeing a bug report about this issue ... oh, thats because
> no one said anything about it or filed one, funny how that works
> -mike

For your reference, I even cared to attach a patch for horde (among tens of
other bugs filed for dev-lang/php compitibility) - but that patch never made
it to portage, despite the bug has been marked as fixed.

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

Should I reopen the bug or will you do so yourself?

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpfAV8SbOqHB.pgp
Description: PGP signature

Re[2]: [gentoo-dev] ChangeLogs and rsync time

[Jakub Moc]

3.1.2006, 12:47:27, Chris Gianelloni wrote:


> So you have now taken what was described as an automatic solution to
> reduce size into a manual process, reducing usability of the ChangeLog
> and increasing workload for every ebuild developer.

> I'm sorry, but I still think the idea of simply RSYNC_EXCLUDEing the
> ChangeLog by default would be a much better solution.

+1; I frequently find even pretty old changelog entries useful (even the
'stable on foo' ones are useful, if you need to find out who keyworded the
thing stable despite the fact that it's severely broken).

As for RSYNC_EXCLUDE by default, that's not something that should be
considered until GLEP 42 or an equivalent solution gets implemented.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpv20IbxGk5B.pgp
Description: PGP signature

Re[2]: [gentoo-dev] What to do with GCC 4 related bugs?

[Jakub Moc]

3.1.2006, 17:34:46, Bjarke Istrup Pedersen wrote:

> Is there a metabug where we can keep track of all the GCC 4 bugs?
> If so, what bug # ?

Sure - http://bugs.gentoo.org/show_bug.cgi?id=117482


--
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpm3hXequP5c.pgp
Description: PGP signature

Re: [gentoo-dev] mysql commercial

[Jakub Moc]

3.1.2006, 18:54:07, Steve Rodgers wrote:

> Hi does anyone have any experience of deploying mysql commercial build into a 
> gentoo platform?

> Several mysql dependencies such as php will need to have the ebuild slot 
> there so I guess it's
> up to me to maintain an overlay equivalent that provides the same as the 
> portage ebuild?

> Does this exist and if not - would it be of use for me to contribute back to 
> portage?

> e.g. app-db/mysql-commercial

> Thanks

> Steve

Dunno what exactly "commercial" means here, it you mean official -bin,
there's some overlay and ebuilds in Bug 83424, there's also some weird
commerical/mysql/amd64 profile but I don't have any clue who commited that
and why...

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp3PiINPH7ZM.pgp
Description: PGP signature

[gentoo-dev] last rites - x11-misc/bbapm

[Jakub Moc]

Try #2, following the suggestion in 
http://bugs.gentoo.org/show_bug.cgi?id=20201#c11

x11-misc/bbapm: Bug 20201, segfaults, last release 6 years ago (a.k.a. dead
as a nail in the lamp-room door)

Unless someone steps up, it'll be package masked in two weeks and removed from 
portage.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)




pgpIjwuRDEgJE.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ca-certificates PDEPEND

[Jakub Moc]

9.1.2006, 17:12:31, Andrea Barisani wrote:

> On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:

>> 
>> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
>> If so should it be a 'no*certs' flag or a USE=cacerts ?

> USE=cacerts sounds the proper course of action to me.

NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
realplayer thing again.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpsEZgc6Hws7.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Re: ca-certificates PDEPEND

[Jakub Moc]

9.1.2006, 17:28:04, Andrea Barisani wrote:

> On Mon, Jan 09, 2006 at 05:21:42PM +0100, Jakub Moc wrote:
>> 
>> 9.1.2006, 17:12:31, Andrea Barisani wrote:
>> 
>> > On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:
>> 
>> >> 
>> >> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag?
>> >> If so should it be a 'no*certs' flag or a USE=cacerts ?
>> 
>> > USE=cacerts sounds the proper course of action to me.
>> 
>> NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned
>> realplayer thing again.

> It's the realplayer thing that should be fixed. Can't believe that
> ca-certificates got relatively quiet as a PDEPEND because of that ;).

No, it's not, it's FETCHCOMMAND/wget thing. Would like to hear about
alternatives besides those discussed ad nauseam in Bug 101457.

Realplayer does *not* depend on ca-certificates in ANY way, it's
FETCHCOMMAND that's broken w/ unknown CA and self-signed certificates. Since
not honoring self-signed certificates by default can be hardly considered as
a bug, hence the depenency on ca-certificates in wget.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpcX6wvYqpUZ.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Re: ca-certificates PDEPEND

[Jakub Moc]

9.1.2006, 17:56:30, Luca Barbato wrote:

> Jakub Moc wrote:
>> 9.1.2006, 17:12:31, Andrea Barisani wrote:
>> 
>> 
>>>On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote:

> Just add it as DEPEND and everybody would be fine, isn't it?

Not a realplayer issue (see the other mail).


-- 

jakub

pgpCrhzxTI4Gt.pgp
Description: PGP signature

Re[2]: [gentoo-dev] RFC: emerge snapshots

[Jakub Moc]

24.1.2006, 19:36:49, Wernfried Haas wrote:

> 2 (already implemented) things you may find useful (unless you know
> them already of course):
> - adding buildpkg to your FEATURES builds binary packages, which makes 
>   it faster to revert to older versions if the new one cause
>   problems.
> - dispatch-conf does a great job for the configuration files,
>   especially when up- and downgrading packages.

... and quickpkg makes a quick backup of a package incl. configuration files
and modifications you've made since it has been installed.



-- 

jakub



pgpoNuC59oxsz.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable

[Jakub Moc]

26.1.2006, 23:02:28, MIkey wrote:

> You can purge the old gcc immediately after it upgrades instead of after
> the entire system completes.

How the fsck does it matter? What's your obsession here??? So purge it and
stop this finally, you have a freedom to purge it and you have a freedom to
not use stage1 and you have a freedom to not use Gentoo at all, ktnxbye.

> Take your pick:
> http://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=revdep&field0-0-1=component&type0-0-1=substring&value0-0-1=revdep&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=revdep&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=revdep

Eh???


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpcj9z9V3tLh.pgp
Description: PGP signature

Re[2]: [gentoo-dev] IUSE and LINGUAS?

[Jakub Moc]

30.1.2006, 12:46:28, Jason Stubbs wrote:

> On Monday 30 January 2006 16:43, Ciaran McCreesh wrote:
>> On Mon, 30 Jan 2006 06:17:36 +0100 "Diego 'Flameeyes' Petteno"
>> <[EMAIL PROTECTED]> wrote:
>> | Also, as repoman complain about linguas_blabla not being a valid
>> | useflags, all the linguas_* useflags should be listed in use.desc
>> 
>> No, part of the point of USE_EXPAND is that they shouldn't. This is a
>> repoman bug.

Not only repoman - see Bug 70648

> I have yet to be enlightened on any merit of USE_EXPAND is so perhaps you 
> could explain as to why there should be user-configured-yet-undocumented 
> options for ebuilds? More precisely, how should they be documented if not
> via use.desc?

Pretty much exhaustively flam^W discussed in Bug 70648 as well. LINGUAS are
not use flags, otherwise they wouldn't have to exist. Sticking this stuff
into IUSE just bloats it like hell, and as ciaranm pointed in another mail,
maintaining lists of honored LINGUAS in each ebuild it just huge maintenance
overhead with no gain...


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp0nwD5keLq8.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] multislot mysql

[Jakub Moc]

Honestly, I don't see why is this needed. It works the same way like apache
slots or php slots or whatever other slots. If users emerge an ebuild
explicitely, they get the highest version available, if they want something
else, they can do

"echo >=dev-db/mysql-5*" >> /etc/portage/package.mask"

That's exactly the same amount of user intervention required as if they
should enable multislot use flag in package.keywords instead (considering
that users definitely don't want to enable such flag globally for things
like binutils or gcc). Also, the current behaviour doen not take away the
possibility for other ebuilds to depend on a specific slotted mysql version,
e.g. if something doesn't work with 5.x but works just fine with 4.1. That
won't be possible once multislot use flag is required for slotted install.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpfEOpvV3PGc.pgp
Description: PGP signature

[gentoo-dev] Last rites: net-nds/gq

[Jakub Moc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

GTK-based LDAP client. This thing has no maintainer, is broken and dead
upstream (unmaintained, last release 2+ ago).

If anyone still wants to keep it in portage, see
http://bugs.gentoo.org/show_bug.cgi?id=122336 for the outstanding issues.

Otherwise, I suggest to p.mask this in two weeks and then remove from
portage.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFD7F4FhxfV/c66PZ4RAgOCAJ0SILUpIjRt6P0CAdoFT+/XgvhgDgCeNrt2
KN52uieOUTtEjstTzTDlXHA=
=TEaS
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Last rites: dev-db/dybase

[Jakub Moc]

For those who wonder wth is that... Description: DyBASE is very simple
object oriented embedded database for languages with dynamic type checking.

The ebuild lacks a maintainer, is completely bogus and fubar, a.k.a. doesn't
work at all and needs complete rewrite to work with dev-lang/php. The same
is true for python and ruby APIs.

Will be package.masked today and removed from portage in two weeks unless
someone has a very good reason to keep it and want to rewrite it from
scratch. See Bug 60472.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)
 

pgprIqEZw2TTi.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Last rites: net-nds/gq

[Jakub Moc]

10.2.2006, 14:56:58, Olivier Crete wrote:

> On Fri, 2006-10-02 at 10:33 +0100, Jakub Moc wrote:
>> Otherwise, I suggest to p.mask this in two weeks and then remove from
>> portage.

> Is there any other useful gtk ldap browser in the tree ?

Not that I would know... Anyway, nls can be fixed by using sys-devel/gettext
instead of the crappy bundled implementation it seems, you can work around
the distcc issue using CC=$(tc-getCC) or something like that, the deps are a
trivial thing to fix. However, kerberos issues seem non-trivial, and there's
also a problem that this thing refuses to save preferences completely (Bug
76057), which is kinda annoying. :P

Honestly, not worth wasting time IMO, this stuff is really abandonware with
non-existent upstream.


-- 

jakub

pgpwlyjqp37TD.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Last rites: net-nds/gq

[Jakub Moc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


10.2.2006, 20:03:45, Donnie Berkholz wrote:

>> Olivier Crete wrote:

>> Is there any other useful gtk ldap browser in the tree ?

> There's a bug for LAT -- http://bugs.gentoo.org/show_bug.cgi?id=86854 --
> but the current assignee apparently doesn't want it.


Well, that looks like .Net - /me runs :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFD7OaKhxfV/c66PZ4RAs2IAJ4i5t4m1/J5AVC1aLvwionQgSw6XwCgq7kG
mKR+ztnqHiJxflj+0o9HaVk=
=jyFx
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] gtk2 use flag deprecation = bashing my head against the wall

[Jakub Moc]

Reading the last two comments (Bug 106560) from devs who removed them from
CC again makes my cry out loud in desperation.

People, *please* read the two attachments I've posted there, and think again
before stating something about "fixed months ago" etc. etc.

:-(

http://bugs.gentoo.org/show_bug.cgi?id=106560

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpnufdngyRGw.pgp
Description: PGP signature

[gentoo-dev] Last rites: app-editors/gnotepad+

[Jakub Moc]

app-editors/gnotepad+ is a simple HTML and text editor. It lacks a
maintainer, doesn't compile and last release upstream was 5+ years ago.
Unless someone picks this up, it should be package.masked and removed from
portage. There are tons of better and working alternatives.

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

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpCqeLfgkccp.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+

[Jakub Moc]

16.2.2006, 22:05:54, Ciaran McCreesh wrote:

> On Thu, 16 Feb 2006 21:51:40 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | Unless someone picks this up, it should be package.masked and
> | removed from portage. There are tons of better and working
> | alternatives.

> Uh, it's not a last rites unless someone actually does the masking
> pending removal.

Uh, was this reply really needed?

BTW, x11-misc/bbapm is about one month
overdue (http://bugs.gentoo.org/show_bug.cgi?id=20201)


-- 

jakub


pgpe3g3pwY5Bw.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+

[Jakub Moc]

16.2.2006, 22:47:49, Ciaran McCreesh wrote:

> On Thu, 16 Feb 2006 22:32:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | BTW, x11-misc/bbapm is about one month
> | overdue (http://bugs.gentoo.org/show_bug.cgi?id=20201)

> It's not overdue. It hasn't had a proper last rites email sent out yet
> and probably won't get one either, given the flamefest that occurred
> last time someone tried to tidy up commonbox...

Uhm... you need to refresh your memory, it seems:

From: Jakub Moc <[EMAIL PROTECTED]>
To: gentoo-dev@lists.gentoo.org
Subject: last rites - x11-misc/bbapm
Date: 6.1.2006, 15:13
=== Start of original message ==
Try #2, following the suggestion in 
http://bugs.gentoo.org/show_bug.cgi?id=20201#c11

x11-misc/bbapm: Bug 20201, segfaults, last release 6 years ago (a.k.a. dead
as a nail in the lamp-room door)

Unless someone steps up, it'll be package masked in two weeks and removed from 
portage.


-- 

jakub

pgp6Xsi3KUMsH.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+

[Jakub Moc]

16.2.2006, 23:08:51, Ciaran McCreesh wrote:

> On Thu, 16 Feb 2006 22:55:33 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | 16.2.2006, 22:47:49, Ciaran McCreesh wrote:
| >> On Thu, 16 Feb 2006 22:32:13 +0100 Jakub Moc <[EMAIL PROTECTED]>
| >> wrote:
| >> | BTW, x11-misc/bbapm is about one month
| >> | overdue (http://bugs.gentoo.org/show_bug.cgi?id=20201)
> | 
| >> It's not overdue. It hasn't had a proper last rites email sent out
| >> yet and probably won't get one either, given the flamefest that
| >> occurred last time someone tried to tidy up commonbox...
> | 
> | Uhm... you need to refresh your memory, it seems:

> It's not a proper last rites email unless it's sent by someone who's
> actually going to follow through with it.


OMG, stop this crap and don't waste our time. You specifically asked me to
do it - http://bugs.gentoo.org/show_bug.cgi?id=20201#c11

Also, there wasn't exactly any flamefest so I don't know what you are
referring to above. You sent out a mail and noone gave a damn about that
stuff, should have been removed from from the tree 1 1/2 year ago.

http://marc.theaimsgroup.com/?l=gentoo-dev&m=109233643723408&w=2


Punt the broken thing from portage.

--

jakub

pgpmc9Aqil4fP.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+

[Jakub Moc]

16.2.2006, 23:58:41, Ciaran McCreesh wrote:

> On Thu, 16 Feb 2006 23:45:45 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | OMG, stop this crap and don't waste our time. You specifically asked
> | me to do it - http://bugs.gentoo.org/show_bug.cgi?id=20201#c11

> No, I asked you to do it properly, not to send out one last rites email
> for something you're not going to remove.

What are you talking about? commonbox is listed as maintainer of that stuff,
it's been broken for years, you neither fixed it or bothered to remove it
from portage, nor did you at least re-assign that to maintainer-needed and
remove yourself from metadata.xml.

You asked me to send last rites, I did, noone cares about that stuff - so
will you finally punt the broken thing, instead of this pointless trolling??
Or should I CC QA on that bug, so that someone else will do it if you don't
want to?

> | Also, there wasn't exactly any flamefest so I don't know what you are
> | referring to above. You sent out a mail and noone gave a damn about
> | that stuff, should have been removed from from the tree 1 1/2 year
> | ago.

> Try looking harder next time.

That's exactly the link you provided in
http://bugs.gentoo.org/show_bug.cgi?id=20201#c7 so why on earth should I try
to look harder?


-- 

jakub

pgpYbmvKjrYEc.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+

[Jakub Moc]

17.2.2006, 0:23:49, Ciaran McCreesh wrote:

> On Fri, 17 Feb 2006 00:14:42 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | 16.2.2006, 23:58:41, Ciaran McCreesh wrote:

> | 
> | What are you talking about? commonbox is listed as maintainer of that
> | stuff, it's been broken for years, you neither fixed it or bothered
> | to remove it from portage, nor did you at least re-assign that to
> | maintainer-needed and remove yourself from metadata.xml.

> You should probably go and read herds.xml sometime.

Or maybe you should, rather...

$ herdstat commonbox
Herd:commonbox
Email:   [EMAIL PROTECTED]
Description: Blackbox and derivative works
Developers(5):   ciaranm gothgirl ka0ttic pyrania superlag

http://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap21

> | You asked me to send last rites, I did, noone cares about that stuff
> | - so will you finally punt the broken thing, instead of this
> | pointless trolling?? Or should I CC QA on that bug, so that someone
> | else will do it if you don't want to?

> bbapm is only a small part of the problem. If you're going to do
> something, do it properly. Stop wasting other people's time by doing it
> piecemeal and getting it wrong.

It's exactly your job, TBH. So far you've done nothing in this regard,
except for wasting other people's time and keeping broken POS in portage.

> | | That's exactly the link you provided in |
> http://bugs.gentoo.org/show_bug.cgi?id=20201#c7 so why on earth | should I
> try to look harder?

> Well, I *was* expecting you to use a bit of common sense when handling
> the issue.

Blah blah blah will you post the link referring to that "flamefest"
you've been mentioning over and over again? Apparently not. So - this has
nothing to do with common sense and everything to do with your trolling.


-- 

jakub

pgpEelg4Xtewv.pgp
Description: PGP signature

Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+

[Jakub Moc]

17.2.2006, 0:42:13, Ciaran McCreesh wrote:

> (ommited)

http://upload.wikimedia.org/wikipedia/commons/9/9e/DoNotFeedTroll.jpg

Everyone else, sorry that you had to read this debate... :/

-- 

jakub


pgpDXBRuHXpDD.pgp
Description: PGP signature

Re[2]: [gentoo-dev] bug #20201 and bbapm

[Jakub Moc]

27.2.2006, 18:23:09, Ciaran McCreesh wrote:

> On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner <[EMAIL PROTECTED]>
> wrote:
> | bbapm has been masked due to no one responding with anything useful to
> | last rites e-mail.  It will be punted in 30 days.

> No no no. Do this properly. Clean up *all* the broken blackbox applets,
> not just the one that has someone whining on a bug report. There are at
> least two in the tree that're more broken than this.

*Please*, be so kind and look at metadata.xml for those ebuild, then just
either do it *yourself* or ask someone from your fellow-devs in commonbox
herd to do it for the other ebuilds that you failed to mention above...
Don't move broken stuff on other people's shoulders, as you've already done
once.

I fail to see why are you claiming here that there's even more broken stuff
in the tree, yet as a member of maintainer herd haven't dealt with that
properly for quite an extensive period of time - and then you are asking
*other* people to do something "properly".

The fact that there are other ebuilds broken as well isn't any valid reason
for keeping this particular broken thing on portage. That way, nothing would
be punted from portage, ever.

TIA.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpJ6oWCjQowX.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

27.2.2006, 21:37:09, Ciaran McCreesh wrote:

> On Mon, 27 Feb 2006 20:26:10 + Stuart Herbert <[EMAIL PROTECTED]>
> wrote:
> | On Mon, 2006-02-27 at 17:08 +, Ciaran McCreesh wrote:
| >> Abuse from people like you whenever someone finally gets brave
| >> enough to document all the ways in which webapp-config is broken.
> | 
> | This isn't the first time we've heard this tune from you, and alas I
> | fear it won't be the last.
> | 
> | You know where bugzilla is.  You know how to contact any of the
> | webapp-config maintainers via email, or via IRC.  We're ready to
> | listen to your input, and to work with you (or anyone else) on fixing
> | any genuine problems that webapp-config has.  The more feedback we
> | get, the better we can make this package for everyone's enjoyment.

> Then please start with bug 120088. Once that one's fixed we'll go from
> there.


May I ask how is that related to webapp-config?


You can't escape this way... so don't even try. You've been talking about
broken webapp-config, then go ahead and show us the breakage. If there's
nothing you have to say in that respect, then just rather stick foot in your
mouth next time you are going to assault someone.

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpm1h2ln0Bno.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

27.2.2006, 22:18:05, Stephen P. Becker wrote:

> Grant Goodyear wrote:
>> Ciaran McCreesh wrote:
>>> My point is that that's a nasty QA bug that's relying upon input from
>>> Stuart to be fixed. Whilst that one's still alive, I'm not going to go
>>> around filing more similar "breaks non-interactively" bugs because the
>>> discussion will just get repeated over and over.
>> 
>> Huh?  I just read through the bug, and it actually appears to be
>> resolved pending Chris' testing w/ the needed USE flags added to the
>> various profiles.  I'll admit that the fix is inelegant, but I'm missing
>> where it's waiting upon Stuart for additional info.  Am I missing something?

> There are still USE combinations which would be otherwise perfectly valid,
> but which cause php to fail to emerge, thus reaking non-interactivity and
> forcing people to (ab)use /etc/portage/package.use to get things working
> properly.

Yeah, and there will be, since chosing between stuff like mysql or recode on
behalf of the user is plain stupid and produces unexpected outcome, since
portage can't handle build_with_use this way, since portage can't handle use
flags conflict at emerge --pretend/--ask time, and last but not least since
there's no such policy that would mandate such changes.

However, I'm still one ear wrt the original topic, which was "all the ways
in which webapp-config is broken".


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpSRt1UKZEbw.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

27.2.2006, 22:33:21, Ciaran McCreesh wrote:

> On Mon, 27 Feb 2006 21:49:23 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | 
> | May I ask how is that related to webapp-config?
> | 

> It is related to Stuart, and hence utterly relevant to the conversation.

Ah, sure - so the topic is that you have personal issues with Stuart and are
washing your dirty laundry in a public ML?

You still haven't posted posted a *single example* of webapp-config
brokeness. You, I'd say you should either back up claims about "all the ways
in which webapp-config is broken" or apologize to the concerned developers
for false claims.

Still waiting.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp56jdp76Pag.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

27.2.2006, 22:32:39, Ciaran McCreesh wrote:

> I quote the official policy:

> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
>> Occasionally, ebuilds will have conflicting USE flags for
>> functionality. Checking for them and returning an error is not a
>> viable solution. Instead, you must pick one of the USE flags in
>> conflict to favour. One example comes from the msmtp ebuilds. The
>> package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL
>> at all. Because GnuTLS is more featureful than OpenSSL, it is
>> favoured:

> It's a QA violation, and not a feature as you claim.

> I find it particularly worrying that you try to pass of blatant policy
> violations as a feature. The first step in QA is detecting that there
> is a problem.

No, that's not a policy document, ebuild policy is documented here:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1

Moreover, the cited howto is wrong, since it will break built_with_use
checks, as explained on the relevant bug and as explained here on mailing
list before. The howto also doesn't apply to cases like recode vs. mysql,
because that's a completely different functionality, you can't exactly
choose which one is better on behalf of the user.

So, to sum it up - you can't make up for portage's lack of features by
inventing a policy that doesn't work. Once again - until portage can handle
USE-based dependencies and until portage can handle conflicting use flags,
there's nothing that could be done here.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgprwDQAkXsrs.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

27.2.2006, 22:32:39, Ciaran McCreesh wrote:

> I quote the official policy:

> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
>> Occasionally, ebuilds will have conflicting USE flags for
>> functionality. Checking for them and returning an error is not a
>> viable solution. Instead, you must pick one of the USE flags in
>> conflict to favour. One example comes from the msmtp ebuilds. The
>> package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL
>> at all. Because GnuTLS is more featureful than OpenSSL, it is
>> favoured:

And - one more note - when and where has been the following change discussed
and who approved that?!

http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpAWJJBeYTVG.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 13:54:36, Stephen P. Becker wrote:

>> You still haven't posted posted a *single example* of webapp-config
>> brokeness. You, I'd say you should either back up claims about "all the ways
>> in which webapp-config is broken" or apologize to the concerned developers
>> for false claims.
>> 
>> Still waiting.
>> 

> OK, here is one.  It seems that webapp-config silently assumes your 
> webserver is apache by default.  If a user uses lighttpd for example, 
> this is totally incorrect.

Why don't you voice your solutions on Bug 11007? The whole underlying stuff
is hell broader than what webapp-config assumes or doesn't assume.

> Now, this doesn't cause webapp-config to fail to emerge, but the first 
> time you emerge any webapp, you get a big nasty error about no Apache 
> group available, which further requires the end user to dig around the 
> webapp-config manpage to figure out the correct file to edit *just* to 
> get a silly php script to install in the correct location.

The above is a direct result of purging all kind of useful predefined
users/groups from /etc/{passwd,group} without considering any wider
consequences. It has already caused circular deps and broke a couple of
things, included but non-limited to installing Gentoo itself (search
bugzilla for related bugs). Where is the whole benefit from this, I still
have to see.

webapp-config should be updated to handle such situation more gracefully, so
why don't you file a bug about this? Is that all you have wrt "all the ways
in which webapp-config is broken"? If so, that's not really much of a
justification of the broad claim ciaranm has made as a QA project member.

> And please, don't tell me this is a feature.  It breaks noninteractivity 
> for every "webapp" in the entire tree.

What kind of non-interactivity? What's this universal non-interactivity
blurb of yours and ciaranm's about? There's no such thing when it comes to
configuration. If you want automated "configuration", then please use
Windows and stop moaning. If you don't want to read manpages or at least
--help, then please use Windows as well. If you want to use non-default
setup, then you need to change default values, that's what common sense
dictates at least. And don't use the (non)-interactivity magical formular in
a context where it has zero sense.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpFxviIqcbv0.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 15:00:49, Stephen P. Becker wrote:

>> What kind of non-interactivity? What's this universal non-interactivity
>> blurb of yours and ciaranm's about? There's no such thing when it comes to
>> configuration. If you want automated "configuration", then please use
>> Windows and stop moaning. If you don't want to read manpages or at least
>> --help, then please use Windows as well. If you want to use non-default
>> setup, then you need to change default values, that's what common sense
>> dictates at least. And don't use the (non)-interactivity magical formular in
>> a context where it has zero sense.

> No! You are completely missing the point.  The non-interactivity of 
> which we speak is the idea that when you emerge some package, it is 
> perfectly reasonable (and in fact should be required) to expect that 
> package to install to your userland with no further prodding.  There 
> should be no USE collisions which cause the emerge to die.  There should 
> be no default configuration which will break other packages in the tree 
> by default.

> Note that in no way am I talking about auto-configuration, as that would 
> be silly.  The example problem with webapp-config which I have described 
> here forces a user to intervene to get packages to install to the proper 
> location.  This is not desirable.

Selecting a webserver to use with a webapp package is a part of
configuration. So again, the whole non-interactive idea is irrelevant wrt
webapp-config and non-default setups. No defaults in default config won't
work/won't improve anything either, since some webapps need to have their
config files server-owned. Running a server and webapps is not a no-brainer
which should just automagically work; to the contrary - users should think
about what they are doing or they just should run a server app.

> Basically, I really don't see why webapp-config can't have some logic 
> built in which makes it smart enough to figure out which webserver 
> somebody is using.

Sure, you can make webapp-config depend on virtual/magic where

RDEPEND="|| ( app-admin/artificial-intelligence app-admin/mind-reader )

and then

emerge lighttpd apache  

I think it's pretty much obvious that this just won't work since such
virtual doesn't and won't exist.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpZk7zF5dP7K.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 15:39:40, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | No, that's not a policy document, ebuild policy is documented here:
> |
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1

> No, the whole thing is policy.

No, it isn't. And silently sticking parts of unofficial gentoo devmanual
into official Gentoo docs, and then silently turning them into a "policy"
enforced under QA disguise is a bad very practice, and pretending that this
has been in the mentioned _howto_ (not policy) for a long time as just plain
silly. Since you haven't answered the question in one of my previous emails
at all, let me ask again:

When and where has been the following change discussed and who approved
that?

http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo


> | Moreover, the cited howto is wrong, since it will break built_with_use
> | checks

> No, that's a separate issue.

No, it isn't. If you want something to have as a policy, it needs to be
error-free, reasonably applicable and not doing more harm than if it isn't
applied at all. And implementing such stuff requires a proper discussion,
considering the consequences and some sort of consent among affected
developers. (Also, that howto example is less than fortunate/clear,
like some user noted in Bug 124401).

> | The howto also doesn't apply to cases like
> | recode vs. mysql, because that's a completely different
> | functionality, you can't exactly choose which one is better on behalf
> | of the user.

> No, it does apply.

No, it doesn't, you can't reasonably favour one of two completely different
functionalities based on some automagic assumption/developer discretion.
That doesn't benefit users in any way and just produces unexpected results
(hey, I explicitely enabled "recode" use flag and php compiled without, the
ebuild is broken, fix0r it!)

> | So, to sum it up - you can't make up for portage's lack of features by
> | inventing a policy that doesn't work. Once again - until portage can
> | handle USE-based dependencies and until portage can handle
> | conflicting use flags, there's nothing that could be done here.

> Until Portage can handle conflicting USE flags, one should take the
> policy-mandated solution that has been sufficient for everyone else for
> four years or more. Sure, it's not perfect, but it's a hell of a lot
> better than repeatedly exploding in the user's face midway through an
> install.

No, noone should enforce a policy that

- doesn't exist (see above)
- hasn't been discussed properly and approved (see above)
- it's consequences haven't been considered wrt whether its benefits
overweight the negatives and whether is useful at all.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpj5iahK5mPv.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 16:12:32, Patrick Lauer wrote:

>> This is a whitespace / coding style breakage. The correct format should
>> be:
>> 
>> webapp_read_config() {
>> 
>> Yes, it's an utterly trivial problem, but it is a QA violation. Getting
>> a complete list is something that takes a heck of a lot longer, and I
>> have yet to be convinced that my time would not be better spent
>> elsewhere.
> Wow. That is ... impressive. After about two days of asking for any real
> bugs you are able to show a trivial syntax issue?

> Please stop yelling "it si teh b0rk!" if you can't even list any serious
> issues, and stop being rude to other people.

Patrick++

If you can't do any better, then please apologize for your conduct and false
claims and shut up... TIA.


-- 

jakub

pgpdwtplthOTQ.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 16:29:07, Stephen Bennett wrote:

> On Tue, 28 Feb 2006 16:08:05 +0100
> Jakub Moc <[EMAIL PROTECTED]> wrote:

>> When and where has been the following change discussed and who
>> approved that?
>> 
>> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo

> According to my recollection, it was discussed between members of QA
> and devrel. According to the CVS logs, it was committed by a member of
> devrel, at QA's request. You can't pass it off as a QA project
> conspiracy, since they didn't make the change.

I'm sorry, but discussing such stuff affecting pretty much everyone who
writes ebuilds among a couple of people simply isn't enough to make this a
policy. And then silently applying this and starting to scream "QA
violation, look, what a nasty QA violation!!!" is plain ridiculous.

Punting every single piece of broken sh*t from the tree requires notifying
everyone on -dev ml and allowing a period of time before it's actually done,
so silently changing/stating policies is a very broken practice.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpOpdcyaXkH8.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 16:42:46, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | If you can't do any better, then please apologize for your conduct
> | and false claims and shut up... TIA.

> Sure I can do better. But you didn't originally ask for better, you
> asked for anything. If better's what you're after:

> SLOT="${PVR}"

Eh? Seen kernel2.eclass? Going to file a bug about that as well? Seen
gst/gstreamer eclasses? Going to file QA bugs about them as well? And -
what's exactly the QA violation there, if you could enlighten us?

Maybe I could point you to
http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/slotting/ ?

> Now, please apologise for insinuating that I don't have any real claims
> to make. I find it extremely offensive that you're questioning my
> technical ability.

No, I won't apologize, I don't see any reason to do it after all the baloney
you've shown here. I have to agree w/ rl03 that your benefits for this whole
project are net negative.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpEIQRV01qb0.pgp
Description: PGP signature

Re: [gentoo-dev] Policies (was: [RFC] QA Team's role)

[Jakub Moc]

28.2.2006, 17:24:21, Danny van Dyk wrote:

> Hi Jakub,

> If you don't agree with the contents, why didn't you raise your
> opposition earlier?

I don't feel any need to raise opposition against some unofficial manual,
what would be the point in that? I'm raising my hand against silently
incorporating parts of it (that affect a lot of stuff in the tree) into
official docs without a proper discussion, even more so that they are being
claimed as an official QA policy now. Documents located in private devspace
of some devs are non-official and noone checks their contents for
correctness, they are private activity of those devs.

> If you agree with the contents, please ask yourself if the current
> discussion is necessary.

See above.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)


pgpCnRIPUEj5F.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 17:35:32, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer <[EMAIL PROTECTED]>
> wrote:
> | Ok, sorry for being dumb :-)
> | What exactly is the issue there? I don't see the issue in setting SLOT
> | depending on ... uhm ... some variable. Looks kinda logical at first
> | glance, but I'm not aware of the issues it causes.

> PVR includes the revision of an ebuild. This means that if a revbump is
> made on a webapp package to fix a critical flaw, users will still have
> the old broken package installed too. This is especially relevant for
> security issues, but also applies to other kinds of fix.

Not including the revision into the SLOT can break the apps by removing the
needed files from a live site... I still can't see any *QA* violation there.

> Ebuilds can't override this either. Read on in the eclass and you'll
> notice that it checks that SLOT hasn't been changed to something sane.

Yeah, it checks for that since that's the way the eclass is designed. You
can't declare a slot in a kernel ebuild either.

Well, starts to be boring - so, either come with something valid from QA
standpoint or stop now.

-- 

jakub

pgpdnAxBRtsYS.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 18:09:54, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 18:00:03 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
| >> PVR includes the revision of an ebuild. This means that if a
| >> revbump is made on a webapp package to fix a critical flaw, users
| >> will still have the old broken package installed too. This is
| >> especially relevant for security issues, but also applies to other
| >> kinds of fix.
> | 
> | Not including the revision into the SLOT can break the apps by
> | removing the needed files from a live site... I still can't see any
> | *QA* violation there.

> Again, that's a design flaw. It's an eclass that's abusing SLOT, thus
> it's a QA issue.

OK, so kernel-2.eclass is abusing the slot as well, go scream on kernel
devs.

> | Yeah, it checks for that since that's the way the eclass is designed.
> | You can't declare a slot in a kernel ebuild either.

> One is a design flaw. The other is not.

Ah, tell me about the dual standards :P

> | Well, starts to be boring - so, either come with something valid from
> | QA standpoint or stop now.

> This is a valid issue from a QA standpoint. This is also why I'm not
> going to waste my time doing a proper list -- rather than addressing
> issues, they are being passed off as irrelevant or even features.

Next time, rather think a couple of times up before claiming something very
broken on a public mailing list where you have no proof for such claims.
Will be immensely helpful for everyone involved.

Thanks.


-- 

jakub

pgpxuk46qcDZF.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 18:11:57, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 17:02:11 + Renat Lumpau <[EMAIL PROTECTED]> wrote:
> | On Tue, Feb 28, 2006 at 04:35:32PM +, Ciaran McCreesh wrote:
| >> Ebuilds can't override this either. Read on in the eclass and you'll
| >> notice that it checks that SLOT hasn't been changed to something
| >> sane.
> | 
> | Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to
> | whatever the hell you want. But don't let my facts get in the way of
> | your nonsense.

> And it sticks out a nasty ewarn and says that the ebuild is probably
> broken.

> Again, you're dismissing QA issues as nonsense, and you wonder why I
> don't waste my time doing a full audit.

Ah, so this is the horrible and nasty ewarn?


ewarn "This ebuild overrides the default SLOT behaviour for webapps"
ewarn "If this package installs files into the htdocs dir, this is"
ewarn "probably a bug in the ebuild."


Sigh... what kind of QA issue is that? Go file bugs about those nasty QA
notices portage spits out every now and then as well, if you are so
concerned about warnings. Indeed, please don't waste your time and first of
all don't waste ours. Go audit whatever you want, but please keep this
off-list. Or maybe don't stare on the screen if ewarns scare you that much.
;)


-- 

jakub

pgp9R7YoX0YoI.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 18:38:10, Ciaran McCreesh wrote:


> Sheesh, you'll probably claim that this isn't broken next too:

> if [ "${IS_UPGRADE}" = "1" ] ; then
> einfo "Removing old version ${REMOVE_PKG}"

> emerge -C "${REMOVE_PKG}"
> fi

No, I won't claim that... I'd rather love to know why didn't you point out
to an obvious eclass flaw about 30 emails and many hours ago, saving us from
all the eclass formating, slotting and ewarn blurb. The above needs to be
fixed, period.

To return to the original topic - focus your QA efforts on real issues. Same
goes for that non-interactivity stuff. QA that serves no other purpose than
inventing problems to enforce an inevitably hackish solution (there's no
good one because the needed tools are not available) is not useful at all.
There's nothing useful in inventing policies that create more problems than
they solve and that are forcing shitty bash code into the tree to work
around missing features.

Portage is a tool to install and manage packages, and serves no good purpose
on its own. Crippling installed packages and their available features for
the sole purpose of having nice ebuild tree with clean bash code is not what
QA is for. Improving the whole process is fine and welcome, as long as it
doesn't unnecessarily interfere with the desired outcome. Users need to
install some software they want to use and need its features, portage and
ebuids are only the means to do that, not a holy cow.


-- 

jakub

pgpbyDVjG5w40.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 19:39:15, Mike Frysinger wrote:

>>  ewarn "This ebuild overrides the default SLOT behaviour for
>> webapps" ewarn "If this package installs files into the htdocs dir, this
>> is" ewarn "probably a bug in the ebuild." 
>>
>> Sigh... what kind of QA issue is that?

> which part dont you understand ?  the user sets a variable and then is told 
> that the package probably contains a bug ... seems pretty confusing to me
> -mike

rl03 already replied to that. I don't see any QA issues there, and if
someone from QA team does, then he probably has too much time to ponder over
the tree and invent issues where they don't exist. I don't see any point
"fixing" this, at least until FEATURES="mindreader" is implemented. Portage
QA notices may be equally confusing to the users, with this kind of logic,
yet they stay there - and number of people complaining about USE_EXPAND
notices is much higher than the number of people who complained about
confusing ewarn from webapps slot (exactly zero is far as I could find).

Once again, don't invent problems, please.

--

jakub

pgpdQ4EP3Mcai.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 20:59:42, Mike Frysinger wrote:

> On Tuesday 28 February 2006 12:51, Renat Lumpau wrote:
>> On Tue, Feb 28, 2006 at 05:11:57PM +, Ciaran McCreesh wrote:
>> > And it sticks out a nasty ewarn and says that the ebuild is probably
>> > broken.
>>
>> Which it _probably_ is. See, this is a numbers game. In most cases, if you
>> use the webapp eclass, setting SLOT="0" is incorrect. There are some cases
>> in which it's just fine. Until FEATURES="mindreader" is implemented, how is
>> the eclass to know what you're trying to do? So it prints a warning and
>> doesn't die. Number of angry users storming bugs.g.o - 0.

> why do you need to be a mindreader ?  the user requested they control the 
> package, thus it isnt a bug, so dont issue a warning
> -mike

Sure, and when *ebuild* requested it instead, then portage will be
automagically informed. So yeah, we can implement yet another variable into
the eclass, and we can do tons of other magic voodoo about three lines of
eclass that noone has ever noticed until today, and the whole thing can be a
lot more complex for sure. Sorry, I call this a complete waste of time.

-- 

jakub

pgpzxcCYEJMz9.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 21:39:43, Mike Frysinger wrote:

> whats your point ?  if an ebuild author wants to control the SLOT, then
> they should be able to without having an invalid warning issued on the
> subject

> considering the nature of the warning, it should be trivial to make it into a
> proper QA check by having the class see where files were installed and then 
> warn/abort if certain conditions are met

> there's no reason for the user to see this crap
> -mike

Yeah, and there's no reason for user to see USE_EXPAND QA notice crap,
eclass inherited illegally crap and a couple of others - this isn't going
anywhere.

You are trying to solve something that noone ever complained about. Why not
rather solve stuff like ebuilds that depend unconditionally on arts, but
because they inherit kde eclass they get bogus arts use flag from the
eclass. This is an issue that's truly confusing and that people are filing
bugs about. There's the difference between doing something useful and
wasting time on an artificially invented issue.

--

jakub

pgpE24KYMB5NY.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

1.3.2006, 1:40:53, Mike Frysinger wrote:

> On Tuesday 28 February 2006 19:28, Ciaran McCreesh wrote:
>> On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson
>>
>> <[EMAIL PROTECTED]> wrote:
>> | I should note that if are a Gentoo Developer and have
>> | problems/concerns/issues with Ciaran's attitude/actions, please
>> | comment on bug #114944. (this bug is only open to Gentoo developers).
>> | Its better if you say it yourself in this bug rather than letting
>> | other people quoting what you say.
>>
>> I should note that if you are a Gentoo developer who has found my
>> advice helpful, you should comment on bug #114944 since certain people
>> are trying to turn Gentoo development into a popularity contest.

> there's a lot more to the issue, but it's sad if that's all you see in the bug
> -mike

Indeed. Ciaran, that bug is not about technical competence; it's about your
civil communication skills, that are as lacking as penguins on the Sahara
desert in your case. Technical skills themselves are not useful for a
project the requires you to communicate w/ other people in a civilized
manner.

As someone else noted, certains "skills" might be fit for a car salesmen but
not for developers of a Linux distro. If a company hires a technically
brilliant QA guy only to find out later on that this brilliant guy has
killed the whole team while communicating his finding to others in such
style you have shown on this thread and on many other occasions before,
it'll be the QA guy who gets booted out, not the whole team. If that doesn't
happen soon enough, the rest of the team can leave meanwhile and the whole
business is doomed.

-- 

jakub

pgp4mO9BF1jel.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 16:31:26, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> wrote:
> | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:
| >> Yes, it's an utterly trivial problem, but it is a QA violation.
| >> Getting a complete list is something that takes a heck of a lot
| >> longer, and I have yet to be convinced that my time would not be
| >> better spent elsewhere.
> | 
> | Where is a coding style problem related to quality of code in general
> | and assurance in particular?

> It's more relevant than you might think. Screwing up layout like that
> breaks various QA checking tools that assume that things are in the
> standard format.

A tool that chokes on coding style (like tabs and whitespaces) should be
ifself fixed.


-- 

jakub

pgpwjkHXYNH9r.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

28.2.2006, 16:29:10, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | 28.2.2006, 15:39:40, Ciaran McCreesh wrote:
| >> On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <[EMAIL PROTECTED]>
| >> wrote:
| >> | No, that's not a policy document, ebuild policy is documented
| >> | here:
| >> |
| >> 
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1
> | 
| >> No, the whole thing is policy.
> | 
> | No, it isn't.

> 'Fraid it is. Everything in the devrel handbook that isn't explicitly
> marked as a guideline is policy.

Sorry, such procedure is not acceptable until you change the whole
metastructure of the project so that a bunch of people is allowed to dictate
to others whatever they think is fit. (Another question is how many people
will want to work on such project.) Until that's done, things should be
discussed and some form of consent reached.

> | When and where has been the following change discussed and who |
> approved that? |  |
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo

> Wouldn't know. That was nothing to do with me. I just wrote the
> original text (or actually, that might not even have been me). It
> finding its way into the policy docs was devrel's doing.

Again, see above.

| >> | Moreover, the cited howto is wrong, since it will break
| >> | built_with_use checks
> | 
| >> No, that's a separate issue.
> | 
> | No, it isn't. If you want something to have as a policy, it needs to
> | be error-free, reasonably applicable and not doing more harm than if
> | it isn't applied at all. And implementing such stuff requires a
> | proper discussion, considering the consequences and some sort of
> | consent among affected developers. (Also, that howto example is less
> | than fortunate/clear, like some user noted in Bug 124401).

> built_with_use isn't a question of conflicting USE flags. It's a
> separate question of dependency resolution, and in this situation it
> *can't* be solved using the method that's been standard for four years
> or more.

Sure it is. You can't silently enable/disable some feature if other ebuilds
are checking for that feature using those very use flags that you have
ignored/overriden/bypassed. Such checks are useless then and more stuff gets
broken than gets fixed.

> | No, it doesn't, you can't reasonably favour one of two completely |
> different functionalities based on some automagic | assumption/developer
> discretion. That doesn't benefit users in any | way and just produces
> unexpected results (hey, I explicitely enabled | "recode" use flag and php
> compiled without, the ebuild is broken, | fix0r it!)

> By all means warn the user. There's nothing in policy disallowing that.

That doesn't work, it breaks other things as explained above. Please, don't
use a hammer where watchmaker's screwdriver is a proper tool, otherwise
you'll severely damage the whole thing. One minute spent on tweaking use
flags is much less important than a bunch of useful features missing just
because you've hammered the whole stuff together.

> | No, noone should enforce a policy that
> | 
> | - doesn't exist (see above)

> The whole devrel handbook is policy, except where otherwise noted. See
> Mike's reply.

Then any significant change there requires a sane procedure.


-- 

jakub

pgp3XISjAzxvT.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

1.3.2006, 11:29:47, Danny van Dyk wrote:

>> > | Where is a coding style problem related to quality of code in general
>> > | and assurance in particular? > > It's more relevant than you might
>> think. Screwing up layout like that > breaks various QA checking tools
>> that assume that things are in the > standard format.
>>
>> A tool that chokes on coding style (like tabs and whitespaces) should be
>> ifself fixed.
> Hmm, you never used repoman, right? repoman checks for whitespace and tab 
> oddities and warns you, if you want to commit them.


Sure I did... that's not the breakage of a QA tool ciaranm has been talking
about, though. If some tool stops to work b/c of spacing/indenting issues,
then it's broken. Meanwhile, if you can't bear formating/whitespace issues,
then either fix it yourself or file a bug and wait until someone gets to it
or fixes it when next revbump/another bunch of more important fixes is due.

Expecting that someone will fix a cosmetic issue within five minutes from
the time when a bug is filed and ranting about it on #gentoo-qa and mailing
lists isn't useful but rather plain annoying.

-- 

jakub

pgpR49V6Zhcqz.pgp
Description: PGP signature

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

1.3.2006, 13:09:55, Paul de Vrieze wrote:

> On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote:

>> | > if [ "${IS_UPGRADE}" = "1" ] ; then
>> | > einfo "Removing old version ${REMOVE_PKG}"
>> | >
>> | > emerge -C "${REMOVE_PKG}"
>> | > fi

> This code (or an equivalent kludge/hack) does however allow features that are
> of great value to our users. While I agree that such hacks should be avoided
> if possible, I think in this case it is not. As such the appropriate response
> is to isolate the hack in a central place, where it is clear to be seen and 
> can easilly be fixed. This allows the quality of the hack to be ensured, 
> relieving many webapps from doing hacks themselves.

> While this hack is being used, some effort should be put into
> constructively creating a proper solution for the problems that were
> hacked around. Saying  "this is not allowed because of X policy" is not
> helpful as the costs of  disallowing it greatly outweigh the costs of
> overlooking it in a controlled  manner.

Well yeah, but the problem here is that portage doesn't allow such stuff to
be used safely (locking issues, race conditions). And yeah, it's kinda
lacking sort of feature that would have its use in a couple of places.

--

jakub

pgpaEP0jPlTm4.pgp
Description: PGP signature