Re: [gentoo-dev] Re: Split desktop profile patches & news item for review
On Friday 12 March 2010 19:39:48 Ben de Groot wrote: > On 12 March 2010 10:48, Theo Chatzimichos 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
On 03/13/2010 01:07 AM, Ryan Hill wrote: > On Fri, 12 Mar 2010 18:33:12 +0100 > Ben de Groot wrote: > >> On 12 March 2010 16:59, Alexis Ballier 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
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
On Sat, 13 Mar 2010 11:34:22 +0100 Matti Bickel 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
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 > > > > 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
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.
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Friday 12 March 2010 15:18:21 Robert Bradbury wrote: > It would appear that the pending (0321) mask of Qt3 will break > sci-misc/qcad, sci-chemistry/xdrawchem and x11-misc/glunarclock. > [..] > > Thank you, > Robert Bradbury The decision about removing Qt3 has been made 9 months ago, the decision about the upcoming mask has been made 4 months ago. So you had all the time to move to Qt4. We aint gonna maintain a package ( or library if you prefer ) that has been abandoned from upstream a long time ago. So if you still want to use it, please add kde-sunset overlay. We dont have neither the manpower nor the time to patch/fix/maintainer/etc/etc/ Qt3 anymore. However, we DO offer you like 6 different versions of Qt4 *4.5.3 *4.6.1 *4.6.2 *4.6. *4.7. *4.7-prerelease ( soon ) *4. Which we actively maintain. We decided to move forward and we are aware that few of our users might not like it. If you still want a working Qt3, please take care of it on kde-sunset Thanks -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org
[gentoo-dev] Last rites: sys-fs/btrfs
# Joe Peterson (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
On 03/12/2010 10:11 PM, Jeremy Olexa wrote: > > On Fri, 12 Mar 2010 21:18:03 +0200, Petteri Räty > wrote: >> There seems to be two different schools on who to assign a keywording >> bug with only a single arch. I have myself assigned it to the arch in >> question but there's a difference of opinion here: >> http://bugs.gentoo.org/show_bug.cgi?id=272160#c5 >> Let's get agreed on a single approach and I will add a note here: >> http://devmanual.gentoo.org/keywording/index.html >> I naturally support the approach I have been doing as I think the arch >> team is the one in charge. > > 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
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
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
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
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)
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
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
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
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)
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
> "BdG" == Ben de Groot 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 OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review)
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
On Sunday 14 of March 2010 06:09:44 James Cloos wrote: > > "BdG" == Ben de Groot 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
