Re: [gentoo-dev] Re: Split desktop profile patches news item for review

2010-03-13 Thread Theo Chatzimichos
On Friday 12 March 2010 19:39:48 Ben de Groot wrote:
 On 12 March 2010 10:48, Theo Chatzimichos tampak...@gentoo.org wrote:
  First of all, I'll delay the commit since I need to write documentation
  patches, and I won't be able, as I'll leave soon for a conference and
  will be back on Monday.
 
 What exactly needs to be done for documentation? Maybe I can help there.
 
 Cheers,

KDE guide needs update (I'll do that) and also GNOME and xorg guides, and 
maybe the handbook (i'm still waiting for a confirmation by the docs team for 
that). Thanks for the offer

-- 
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt Teams
blog.tampakrap.gr


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: Qt3 mask breaks significant science packages

2010-03-13 Thread Samuli Suominen
On 03/13/2010 01:07 AM, Ryan Hill wrote:
 On Fri, 12 Mar 2010 18:33:12 +0100
 Ben de Groot yng...@gentoo.org wrote:
 
 On 12 March 2010 16:59, Alexis Ballier aball...@gentoo.org wrote:
 Or like the old gtk-1: completely abandon the package and let the
 consumers upgrade slowly. IMHO this is the less annoying approach for
 everyone.

 Abandoned packages do not belong in the portage tree. That's
 why we have a treecleaners project.
 
 The treecleaners project is tasked with keeping these packages working, and
 removing them only if there is no other alternative.
 
 

That's the ideal situation, unfortunately treecleaners is currently so
understaffed it's not necessarily always true

if a package is broken, and been in treecleaners queue for too long, and
it would be a semi-trivial fix, it simply doesn't get done without manpower

So devs: Please join treecleaners project :)



Re: [gentoo-dev] Re: Qt3 mask breaks significant science packages

2010-03-13 Thread Matti Bickel
Samuli Suominen wrote:
 if a package is broken, and been in treecleaners queue for too long, and
 it would be a semi-trivial fix, it simply doesn't get done without manpower

Because i can't find this info on the treecleaner project page: is there
a bugzilla query for the treecleaners queue, so others can take a
look/help out?

I have found 4 bugs assigned to treeclea...@gentoo.org, but i'm sure i
missed something.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Qt3 mask breaks significant science packages

2010-03-13 Thread Doktor Notor
On Sat, 13 Mar 2010 11:34:22 +0100
Matti Bickel m...@gentoo.org wrote:

 I have found 4 bugs assigned to treeclea...@gentoo.org, but i'm sure i
 missed something.
 

If you have time to spare, bugs assigned to maintainer-needed@ and
often rotting in bugzilla for ages despite having patches included will
give you lots of stuff to play with for starters:)

Perhaps the treecleaners alias should watch the m-needed@ bugs,
dunno. :)


signature.asc
Description: PGP signature


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

2010-03-13 Thread Markos Chandras
On Friday 12 March 2010 23:47:05 William Hubbs wrote:
 On Fri, Mar 12, 2010 at 08:11:50PM +, Jeremy Olexa wrote:
  On Fri, 12 Mar 2010 21:18:03 +0200, Petteri R??ty betelge...@gentoo.org
  
  wrote:
   There seems to be two different schools on who to assign a keywording
   bug with only a single arch. I have myself assigned it to the arch in
   question but there's a difference of opinion here:
   http://bugs.gentoo.org/show_bug.cgi?id=272160#c5
   Let's get agreed on a single approach and I will add a note here:
   http://devmanual.gentoo.org/keywording/index.html
   I naturally support the approach I have been doing as I think the arch
   team is the one in charge.
  
  The problem with assigning bugs to arch teams is when the user comments
  on the bug after it is resolved. If the arch team is CC'd, they remove
  themselves when done and any comments after the bug is closed goes to
  someone that is interested. If the arch team is assigned, then the
  comment basically goes to /dev/null. So, if we are to improve the user
  experience, assign to maintainer and CC arch team.
 
 This is a good enough reason for me to vote for assigning bugs to
 maintainers and cc'ing arch teams.  This is the way  I was taught that
 this should be handled, and this comment explains why.
 
 Since all the arch team does is stabilize or keyword, the maintainer
 needs to know if other issues come up with the bug after it is closed.
 
 William
I like that idea as well 
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org



Re: [gentoo-dev] Re: Qt3 mask breaks significant science packages

2010-03-13 Thread Samuli Suominen
On 03/13/2010 12:34 PM, Matti Bickel wrote:
 Samuli Suominen wrote:
 if a package is broken, and been in treecleaners queue for too long, and
 it would be a semi-trivial fix, it simply doesn't get done without manpower
 
 Because i can't find this info on the treecleaner project page: is there
 a bugzilla query for the treecleaners queue, so others can take a
 look/help out?
 
 I have found 4 bugs assigned to treeclea...@gentoo.org, but i'm sure i
 missed something.
 
 

Look also for bugs where treecleaner@ is in CC list.

19 bugs currently, so not that bad at the moment but even some of these
could be saved.



[gentoo-dev] Last rites: sys-fs/btrfs

2010-03-13 Thread Joe Peterson
# Joe Peterson lava...@gentoo.org (13 Mar 2010)
# Old, unmainted standalone kernel modules for older kernels.
# Kernels 2.6.29-rc1 and newer include integrated btrfs.
# Bug #285357 reports version 0.17 (newest standalone) does not build.
# Last rited: to be removed in 30 days.
sys-fs/btrfs


-Joe



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

2010-03-13 Thread Petteri Räty
On 03/12/2010 10:11 PM, Jeremy Olexa wrote:
 
 On Fri, 12 Mar 2010 21:18:03 +0200, Petteri Räty betelge...@gentoo.org
 wrote:
 There seems to be two different schools on who to assign a keywording
 bug with only a single arch. I have myself assigned it to the arch in
 question but there's a difference of opinion here:
 http://bugs.gentoo.org/show_bug.cgi?id=272160#c5
 Let's get agreed on a single approach and I will add a note here:
 http://devmanual.gentoo.org/keywording/index.html
 I naturally support the approach I have been doing as I think the arch
 team is the one in charge.
 
 The problem with assigning bugs to arch teams is when the user comments
 on the bug after it is resolved. If the arch team is CC'd, they remove
 themselves when done and any comments after the bug is closed goes to
 someone that is interested. If the arch team is assigned, then the comment
 basically goes to /dev/null. So, if we are to improve the user experience,
 assign to maintainer and CC arch team.
 
 -Jeremy
 

When a bug is marked as fixed it doesn't show up in searches developers
use so it's a matter of who reads the email and acts upon it. I don't
see why maintainers would be any more likely to act than an arch team
comprised of multiple people in the case of bigger arches. Let's not
forget that users are really supposed to open new bugs instead of
commenting on the resolved ones although I know there are users out
there who rather comment on a two year old only distantly related bug
than open a new one.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


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

2010-03-13 Thread Petteri Räty
On 03/12/2010 11:47 PM, William Hubbs wrote:

 
 Since all the arch team does is stabilize or keyword, the maintainer
 needs to know if other issues come up with the bug after it is closed.
 

The maintainer is the reporter or in Cc.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


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

2010-03-13 Thread Samuli Suominen
On 03/13/2010 07:07 PM, Petteri Räty wrote:
 When a bug is marked as fixed it doesn't show up in searches developers
 use so it's a matter of who reads the email and acts upon it. I don't
 see why maintainers would be any more likely to act than an arch team
 comprised of multiple people in the case of bigger arches. Let's not
 forget that users are really supposed to open new bugs instead of
 commenting on the resolved ones although I know there are users out
 there who rather comment on a two year old only distantly related bug
 than open a new one.

I would love to see a bugzilla feature that would entirely disable
commenting on closed bugs like on archlinux's bugtracking system[1]

[1] http://www.mail-archive.com/arch-gene...@archlinux.org/msg11996.html

That might possibly need Request reopen button of somesort, or we
could just always require people to open new bugs

Often people just wish to argue about the closing status, after the bug
has been resolved...



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

2010-03-13 Thread Petteri Räty
On 03/13/2010 07:21 PM, Samuli Suominen wrote:
 On 03/13/2010 07:07 PM, Petteri Räty wrote:
 When a bug is marked as fixed it doesn't show up in searches developers
 use so it's a matter of who reads the email and acts upon it. I don't
 see why maintainers would be any more likely to act than an arch team
 comprised of multiple people in the case of bigger arches. Let's not
 forget that users are really supposed to open new bugs instead of
 commenting on the resolved ones although I know there are users out
 there who rather comment on a two year old only distantly related bug
 than open a new one.
 
 I would love to see a bugzilla feature that would entirely disable
 commenting on closed bugs like on archlinux's bugtracking system[1]
 
 [1] http://www.mail-archive.com/arch-gene...@archlinux.org/msg11996.html
 
 That might possibly need Request reopen button of somesort, or we
 could just always require people to open new bugs
 

Maybe just modify Bugzilla so that there's a text besides the comment
box or submit button saying that unless the fix is broken open a new bug.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] eqawarn for main tree

2010-03-13 Thread Petteri Räty
On 03/12/2010 11:27 PM, Zac Medico wrote:
 On 03/12/2010 11:39 AM, Petteri Räty wrote:
 In eclasses there's often use for outputting QA warnings for ebuild
 authors (at least in java and python could immediately make use of
 this). Currently Portage has eqawarn available but it's considered
 internal. Hopefully eqawarn finds it's way to the next EAPI but in the
 mean while do we want:

 1) Do a wrapper like attached to eutils.eclass
 2) Use whatever e* function that seems most appropriate (for example
 einfo when it's common so user LOGging setups don't get too much noise)
 3) Have a speedy next EAPI if we can find more stuff like this to bundle
 
 Here's another option:
 
 4) Retroactively add eqawarn to all EAPIs and use introspection to
 call eqawarn only if available (and drop the introspection after
 about 1 year):
 
declare -F eqawarn /dev/null  \
eqawarn this is ignored by older package managers
 

I would rather focus on fixing the problem of new EAPI implementations
taking so long rather than retroactive hacks.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)

2010-03-13 Thread Brian Harring
On Mon, Mar 08, 2010 at 11:40:00PM +0100, Peter Hjalmarsson wrote:
 mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:
 
  Instead I think we should be improving eselect profile to support
  multiple inheriting /etc/make.profile files in a user friendly fashion,
  and in the end removing 249 subprofiles, instead of adding 28+.
  
 
 
 I vote for this one. A profile being a only contains what is interesting
 for that profile, and you can stash together some profiles into your
 own cocktail.
 Yeah, I know it sounds horrible, but it would still be better then to
 only be able to focus on one small set.
 
 For example if I am using the GNOME DE, and have someone other also
 using my computer, but who really wants to use KDE. Should I have to
 find out what from the KDE profile to enable in my env to make my
 GNOME-profile also tingle for KDE?
 
 I think having a set of base profiles for toolchains and alike (i.e.
 default, hardened) would be good. Then be able to add for example
 desktop/gnome or server and/or selinux profiles on top would be
 interesting. This also for maintainers, as for example PeBenito can
 focus on the selinux part of the profiles, and do not have to keep up to
 date with which hardened-compilers are currently masked/unmasked.

While I agree in principle within mixins, no one here is discussing 
the QA affect of it- right now we can do visibility scans of 
combinations of gnome + amd64 + 2010 because they're defined.

If there is a shift to having users do the combinations themselves 
(rather then combining w/in tree), there won't be visibility scans for 
it- end result, more broken deps should be able to slide by, more 
horked cycles, etc.

A solution there would be useful- one that preferably doesn't involve 
scanning every possible permutation of mixable profiles (you would 
*not* like the speed affect that would have on repoman).
~harring


pgp96WQbGx4Qb.pgp
Description: PGP signature


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

2010-03-13 Thread Duncan
Samuli Suominen posted on Sat, 13 Mar 2010 19:21:52 +0200 as excerpted:

 On 03/13/2010 07:07 PM, Petteri Räty wrote:
 When a bug is marked as fixed it doesn't show up in searches developers
 use so it's a matter of who reads the email and acts upon it. I don't
 see why maintainers would be any more likely to act than an arch team
 comprised of multiple people in the case of bigger arches. Let's not
 forget that users are really supposed to open new bugs instead of
 commenting on the resolved ones although I know there are users out
 there who rather comment on a two year old only distantly related bug
 than open a new one.
 
 I would love to see a bugzilla feature that would entirely disable
 commenting on closed bugs like on archlinux's bugtracking system[1]
 
 [1] http://www.mail-archive.com/arch-gene...@archlinux.org/msg11996.html
 
 That might possibly need Request reopen button of somesort, or we
 could just always require people to open new bugs
 
 Often people just wish to argue about the closing status, after the bug
 has been resolved...

Keep in mind that disabling further comments would disable genuine 
followups as well.

There have been a few times where a bug I've filed was closed before I 
found the ultimate cause of the bug (my config or fat-fingering), where I 
leave a comment when I do find the trigger, to hopefully help out others 
who might have the issue later.

There's also the issue of thanks, especially when it was a bug of my own 
causing and the dev took the time to explain what I was doing or had 
failed to do.  Awhile back I asked here if thanks was appropriate in such 
cases, or simply the bother of an extra mail on an already closed bug and 
thus better to skip, and was told go for it, thanks is unfortunately quite 
rare, and thus appreciated because bug squashing can sometimes feel pretty 
thankless, so I've tried to do so tho I can't say I always do.  I'd feel 
quite strange (and expect it would NOT be appreciated, so would simply 
skip it) if I had to open a new bug just to say thanks for fixing the old 
one!

But a note about opening a new bug if it's still an issue and you're not 
the author and therefore can't reopen this one, possibly suggesting bug 
clone, would probably be useful, I agree with petteri/betelgeuse there.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




Re: [gentoo-dev] Re: Split desktop profile patches news item for review

2010-03-13 Thread Mart Raudsepp
On Fri, 2010-03-12 at 16:47 +0100, Ben de Groot wrote:
 
 Even so, if we choose not to implement the split now, there are
 problems that need addressing in the current situation. The Qt team
 finds the mysql dependency that was added to the desktop profile
 three months ago (see bug #291996) unacceptable. How would you
 propose to solve this without splitting the desktop profile?

Probably by solving the issue there. Either not requiring a mysql USE
flag in the relevant places, or USE defaulting it on there for now for
just that package; or package.use enabled in desktop profile, instead of
globally.



-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: Split desktop profile patches news item for review

2010-03-13 Thread Mart Raudsepp
On Fri, 2010-03-12 at 11:48 +0200, Theo Chatzimichos wrote:
 I found your proposal about mixing profiles awesome, and I am willing to work 
 on this. In fact, I'm going to raise the issue on KDE's meeting this Thursday 
 at 20:00 UTC. Any freedesktop team members will be welcome there. But I'm not 
 going to step up from the current workaround I worked on, as things are not 
 that tragic. I will document and announce everything, and I will be watching 
 forums and IRC for some days to provide support. The only real problem in my 
 opinion would be this, people get confused about useflags and unexpected --
 newuse results. (btw I already announced it once in my blog, I will do it 
 again, and we'll also provide a news item, so I doubt this is even a real 
 problem as well).

I guess it's a question of how long the other proposal takes
implementing. If just a month or two, two migration within that time
period doesn't make so much sense. If we really estimate slow progress
there, then I guess we can have users deal with the multiple migrations
and some months of small benefits from the better profiles.
Just this situation with desktop profiles has existed for as long as
desktop profile have existed, so waiting a couple months more for the
perfect solution (while avoiding multiple migrations) doesn't sound like
a bad idea to me.

I appreciate you intending to take a lead on pushing the other proposal
too.

I guess I should review the gnome subprofile soon, I assume some of our
other guys already did though.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)

2010-03-13 Thread Mart Raudsepp
On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote:
 On Mon, Mar 08, 2010 at 11:40:00PM +0100, Peter Hjalmarsson wrote:
  mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:
  
   Instead I think we should be improving eselect profile to support
   multiple inheriting /etc/make.profile files in a user friendly fashion,
   and in the end removing 249 subprofiles, instead of adding 28+.
   
  
  
  I vote for this one. A profile being a only contains what is interesting
  for that profile, and you can stash together some profiles into your
  own cocktail.
  Yeah, I know it sounds horrible, but it would still be better then to
  only be able to focus on one small set.
  
  For example if I am using the GNOME DE, and have someone other also
  using my computer, but who really wants to use KDE. Should I have to
  find out what from the KDE profile to enable in my env to make my
  GNOME-profile also tingle for KDE?
  
  I think having a set of base profiles for toolchains and alike (i.e.
  default, hardened) would be good. Then be able to add for example
  desktop/gnome or server and/or selinux profiles on top would be
  interesting. This also for maintainers, as for example PeBenito can
  focus on the selinux part of the profiles, and do not have to keep up to
  date with which hardened-compilers are currently masked/unmasked.
 
 While I agree in principle within mixins, no one here is discussing 
 the QA affect of it- right now we can do visibility scans of 
 combinations of gnome + amd64 + 2010 because they're defined.

What sort of QA affects do you imagine it having?
Though I'm talking in the context of what I proposed - using it for just
the target profiles that only tweak USE flags and other such defaults,
nothing else. I considered QA affects for that case, at least in my own
thoughts. I think QA would be checked anyhow there, as part of all USE
flags enabled assumpting testing or static testing of various USE flag
combinations of a package (e.g, for statically finding circular
dependencies or the like).

If you put selinux and toolchains in the mix, that indeed could be
problematic to QA. Though one could probably define some profiles
somewhere that would get used for QA testing, but not exposed to users.

Do you foresee bad QA affects for the for the
desktop/developer/gnome/kde/server profiles case too, or just when
mixing in selinux/toolchains/etc?

 If there is a shift to having users do the combinations themselves 
 (rather then combining w/in tree), there won't be visibility scans for 
 it- end result, more broken deps should be able to slide by, more 
 horked cycles, etc.
 
 A solution there would be useful- one that preferably doesn't involve 
 scanning every possible permutation of mixable profiles (you would 
 *not* like the speed affect that would have on repoman).
 ~harring

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Qt3 mask breaks significant science packages

2010-03-13 Thread James Cloos
 BdG == Ben de Groot yng...@gentoo.org writes:

BdG Abandoned packages do not belong in the portage tree.

Nonsense.  That attitude only servers to harm the user base.

Leaving them in does not.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6



Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)

2010-03-13 Thread Brian Harring
On Sun, Mar 14, 2010 at 02:02:46AM +0200, Mart Raudsepp wrote:
 On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote:
  While I agree in principle within mixins, no one here is discussing 
  the QA affect of it- right now we can do visibility scans of 
  combinations of gnome + amd64 + 2010 because they're defined.
 
 What sort of QA affects do you imagine it having?

Simple enough.  Right now, you change a profile, or want to stable a 
pkg, you can do a scan and identify all new visibility issues from 
profiles- you can validate up front that for the list of 
supported/stable profiles, these changes occur.

If things are shifted over to prefering users mixing/matching profiles 
on their own (meaning we no longer have a gnome amd64 2010 for 
example), devs no longer get QA warnings when they break stuff for it.

Users see it however.

 Though I'm talking in the context of what I proposed - using it for just
 the target profiles that only tweak USE flags and other such defaults,
 nothing else.

Current QA (repoman/pcheck), if a use flag is defaulted on, it's deps 
in a pkg must be visible.  Via repoman/pcheck, they ensure that the 
default use configuration for a profile, all visible pkgs dependencies 
are visible (making the pkg fully usable).

Consider mixing/matching gnome/kde with a profile that has quite a few 
packages masked- say mips.  To be clear, this is a hypothetical case- 
I know it exists, I'm just choosing two likely targets.  Say gnome 
requires some codecs use flag flipped on triggering a dep on a pkg 
masked for mips.

I'm not saying these situations can't be worked around- we already fix 
them now as they come up.  The thing is, whenever you change something 
now, those profile combinations are validated- with mix/match 
approach, that validation won't be occuring, the users will be the 
ones seeing the breakage rather than the dev.

 I considered QA affects for that case, at least in my own
 thoughts. I think QA would be checked anyhow there, as part of all USE
 flags enabled assumpting testing or static testing of various USE flag
 combinations of a package (e.g, for statically finding circular
 dependencies or the like).

Either you're suggesting that repoman/pcheck would have to scan all 
arbitrary combinations of gnome/kde/desktop w/ misc arches, or you 
need to be a fair bit more precise about how QA tools would identify 
what profile combinations to check.

If you're proposing that the QA tool arbitrarily combines arches w/ 
various desktop/server mixins, I'll again note that the run time of 
visibility scans is directly related to # of profiles to check- for 
example, removal of mips profiles from profiles.desc is if memory 
serves me a ~33% reduction in visibility runtime for pcheck.

For repoman (which all devs have to use for commiting), # of profiles 
is even more of a critical value performance wise.


 Do you foresee bad QA affects for the for the
 desktop/developer/gnome/kde/server profiles case too, or just when
 mixing in selinux/toolchains/etc?

Issues will exist regardless of what the combination is.  The point 
I'm making is that with the current model, we catch those issues prior 
to commit- having users mix/match on their own means users will see 
those issues rather than devs.  Literally, they'll see the breakage.

~harring


pgpMhGs1sARlW.pgp
Description: PGP signature


Re: [gentoo-dev] Qt3 mask breaks significant science packages

2010-03-13 Thread Maciej Mrozowski
On Sunday 14 of March 2010 06:09:44 James Cloos wrote:
  BdG == Ben de Groot yng...@gentoo.org writes:
 BdG Abandoned packages do not belong in the portage tree.
 
 Nonsense.  That attitude only servers to harm the user base.
 
 Leaving them in does not.

But leaving them broken and unmaintained in main repository harms Gentoo 
quality and image.
User base is welcome to step up and help with maintenance and that's what 
guys in kde-sunsite overlay actually do.

So... patches welcome! Thanks!

-- 
regards
MM