Re: [gentoo-dev] Re: Qt3 mask breaks significant science packages
On 13 March 2010 00:07, Ryan Hill wrote: > On Fri, 12 Mar 2010 18:33:12 +0100 > Ben de Groot wrote: >> 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. No, treecleaners is tasked with either finding a maintainer for those packages, or removing them from the tree. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: Handling of keywording bugs with only one arch
Ryan Hill wrote: > I can't find it any more, but that's probably where this idea came > from. It never really made sense to me but I've done it on several occasions. me too. I guess it's been handed down for ages. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Qt3 mask breaks significant science packages
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. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Handling of keywording bugs with only one arch
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. I swear there used to be a piece of documentation that said that the final arch on a stabilization bug should be assigned and the maintainer moved to CC. I can't find it any more, but that's probably where this idea came from. It never really made sense to me but I've done it on several occasions. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Handling of keywording bugs with only one arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-03-2010 20:47, 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 agree with the above reasoning, but Petteri raised a good point about "old bugs". I suggest that for old bugs we swap the maintainer and the arch team so that the maintainer is added to CC and the arch team is assigned the bug. If and or when the bug is resolved, the maintainer can reassign the bug again. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLmsb4AAoJEC8ZTXQF1qEPqFAQALJvPNGfW1XGUvNptAIxyWl4 5XNRWH4cCgZMgOlESI5DeYRbBySw2ad36CPgm1SLe9AbXtpiDwzNlU4CSZuVZSRZ TsQ82/JjWBgYIkRUu81UmzwqGCC8sFwJfKjOGCwrq+bcC0M30GwtGgtRUW9+B8mO SdJ56QZdAUiUmHKG9zEW/xiE1U3VThp2Y/PwZP/BsRZqNQK/UpN+m2kPw4lYepGN uz9OryVCRXIkIaiPvcX5f94yLCcCtUDQ7JuLuc0tZYQbEKhTPcDtyf0aCfMUIfgr dtSulB6N0L4c03aHqpTCc5BeZwKlbh1VSTEBs7izHQ//Cdj3xJPbnmXWPxa5//vW p9KLdMl5pYIj/h+ENq7l08nmIsZ0ub7gJZPn2XOF6ywyzKJcX5Pg1oU8jQWdUh3L MDUbsZewUz/uubJDG+cawop9hUK0YCazV5DQ8B7niQlR8YNvDBItlsr6yicq4Tkx 9OFPLXZKC/qG0JTGoOyEYcSdFIHN+4R9SFow8twLnUH5BnMHRS0Qc4Pv1TkaW29Y y5Sosf/zt8NWMzBicyXZXnOBSeIhWEobJev2wOgFyFxlp9+HKwzMW4s4iB7ZfKjX MAVRGwMjwwqCKUa2usj3BANuIYj8Lb5TKkt1r+2eWysromOIi8J6Z+BTiI/NKdYu QB9KakEPzPaiL+/uSrVC =OgTi -END PGP SIGNATURE-
Re: [gentoo-dev] Handling of keywording bugs with only one arch
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 pgpCyvqzMRE65.pgp Description: PGP signature
Re: [gentoo-dev] eqawarn for main tree
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" -- Thanks, Zac
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On 03/10/10 11:36, Arfrever Frehtes Taifersar Arahesis wrote: 2010-03-08 22:28:16 William Hubbs napisał(a): On Fri, Mar 05, 2010 at 04:19:36PM -0800, Zac Medico wrote: No, it won't. To prove it, I've just tested with a stable stage3 containing portage-2.1.7.x. Here are the steps: 1) extract stable stage3 and chroot into it 2) mkdir /etc/portage&& echo "dev-lang/python ~*">> /etc/portage/package.keywords 3) Run `emerge -pu --deep=1 portage`: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-apps/sandbox-1.6-r2 [2.2] [ebuild UD] app-shells/bash-4.0_p35 [4.0_p37] [ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4] If you try `emerge -puD world` then you will see dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python atoms in the cracklib and libxml2 dependencies. However, in portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency like According to this, we can fix all of the dependencies in the tree then stabilize python3 without having any issues, so I would vote for this route, because it still oinsures that the stable tree will work together. Almost everybody has at least 1 package installed which supports both Python 2 and Python 3 and depends on dev-lang/python without version specification, so Python 3 would be pulled into dependency graph, so fixing of dependencies doesn't need to block stabilization of Python 3. What about introducing a python3 USE flag? Seems like that would keep everybody happy. --Ravi
Re: [gentoo-dev] Handling of keywording bugs with only one arch
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
Re: [gentoo-dev] Handling of keywording bugs with only one arch
On 03/12/2010 09:39 PM, "Paweł Hajdan, Jr." wrote: > On 3/12/10 8:18 PM, Petteri Räty wrote: >> There seems to be two different schools on who to assign a keywording >> bug with only a single arch. > > Why a special case for that? The general rule seems to be that the owner > is the maintaining herd (if any), otherwise the maintainer. Then all > arch teams and possible co-maintaining herds are CC-ed. > Perhaps a bad habit but I have been using my way as a gentle reminder on really old bugs to minor arches that you should do something already by switching them from Cc to assignee. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Handling of keywording bugs with only one arch
On 03/12/2010 09:18 PM, Petteri Räty wrote: > There seems to be two different schools on who to assign a keywording > bug with only a single arch. I have myself assigned it to the arch in > question but there's a difference of opinion here: > http://bugs.gentoo.org/show_bug.cgi?id=272160#c5 > Let's get agreed on a single approach and I will add a note here: > http://devmanual.gentoo.org/keywording/index.html > I naturally support the approach I have been doing as I think the arch > team is the one in charge. > > Regards, > Petteri > said archteam maintains the _keyword_, not the ebuild maintainers, so goes to the arch
[gentoo-dev] eqawarn for main tree
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
Regards,
Petteri
Index: eutils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.340
diff -u -r1.340 eutils.eclass
--- eutils.eclass 7 Mar 2010 03:00:08 - 1.340
+++ eutils.eclass 12 Mar 2010 19:36:28 -
@@ -63,6 +63,17 @@
fi
+# @FUNCTION: eqawarn
+# @USAGE: [message]
+# @DESCRIPTION:
+# Proxy to einfo for package managers that don't provide eqawarn and use the PM
+# implementation if available.
+if ! declare -F eqawarn >/dev/null ; then
+ eqawarn() {
+ einfo "$@"
+ }
+fi
+
# @FUNCTION: ecvs_clean
# @USAGE: [list of dirs]
# @DESCRIPTION:
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Handling of keywording bugs with only one arch
On 3/12/10 8:18 PM, Petteri Räty wrote: > There seems to be two different schools on who to assign a keywording > bug with only a single arch. Why a special case for that? The general rule seems to be that the owner is the maintaining herd (if any), otherwise the maintainer. Then all arch teams and possible co-maintaining herds are CC-ed. Anyway, I don't have a strong opinion about any of these, just prefer a simplicity of the rules. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
[gentoo-dev] Handling of keywording bugs with only one arch
There seems to be two different schools on who to assign a keywording bug with only a single arch. I have myself assigned it to the arch in question but there's a difference of opinion here: http://bugs.gentoo.org/show_bug.cgi?id=272160#c5 Let's get agreed on a single approach and I will add a note here: http://devmanual.gentoo.org/keywording/index.html I naturally support the approach I have been doing as I think the arch team is the one in charge. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
On Sex, 2010-03-12 at 17:59 +0100, Matti Bickel wrote: > Angelo Arrifano wrote: > > What do you people think on a new pkg_changelog function that would > > instruct the ebuild how to retrieve this kind of information from the > > package? > > No, please don't. I'm okay with it if your mean "at the end of > emerge -u ", but wouldn't it be pointless to see what changed > *after* you just installed the thing? Not pointless. If people don't read package changelogs/releasenotes, then it is highly probable they miss new features in the packages. > > The reason i'm against it is the complexity involved. You need to pull > down the source (up to hunderts of megabytes for openoffice), run > src_unpack and eventually src_configure phases. Then you need to know > where to look and what to show. A ChangeLog in the root of the source dir. is almost mandatory in autotools distributions. Despite the existence of a somewhat standard format for ChangeLogs, it is not enforced leaving the need to parse all the crap they through at us. > > But i agree it's cool to know what i will gain from my daily emerge run. > > As an alternative, let the ebuild provide a variable that points to > upstreams online Changelog or something, so you as a human can go parse > it yourself. But then you could also just take the HOMEPAGE variable > that's already there. > As Jeremy pointed out: "There is an optional tag in metadata.xml." That really looks like a better solution and it is something I might start putting on the packages I maintain. -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Re: Split desktop profile patches & news item for review
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, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
[gentoo-dev] Re: Split desktop profile patches & news item for review
Ben de Groot posted on Fri, 12 Mar 2010 16:47:13 +0100 as excerpted: > * Making it harder to get both GNOME and KDE things out of a profile >> (though the common things in desktop profile right now is quite >> suboptimal for GNOME) > > Either solution is suboptimal, so it is very much about weighing pros > and cons. In my opinion the split desktop profiles are an improvement > over the current situation. And it will be even better when your plan > for eselect profile improvements gets implemented. IOW, let's not let the (closer-to-)perfect be the enemy of the good. That has unfortunately stalled progress before. Let's not let it happen this time. It's going to take some time to get the new eselect profile features coded, tested, and thru the system (including deprecating the old version and profiles). We might as well have the benefit of the spit desktop profiles while the ultimate solution's being worked on, especially since this one's pretty much ready to go now (days to weeks, including the mentioned documentation delay, not months or years). -- 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] Qt3 mask breaks significant science packages
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. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On 12 March 2010 14:18, 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. The mask has already been in place since March 1st. > a) Has research been done to determine whether there are replacements for > these packages and why aren't they suggested in the mask comments? See the discussion in the relevant bugs and on the forums. For qcad see bug #284896 and for xdrawchem bug #299588. Glunarclock is unrelated. > b) If one is forced to run Qt3 in order to support these older packages, is > there *good* documentation on how to do this (and why isn't this > suggested in the mask comments)? Because package.mask is not the right place for documentation. It does refer to bug #283429, the tracker bug for the Qt3 mask and removal. This in turn refers to our announcement [1] which mentions that Qt3 and packages depending on it will remain available in the community-maintained kde-sunset overlay. > So before there is a rush to remove ebuilds it should be asked > whether it is possible to produce a static build and/or whether there is a > clear path provided for the retention of "legacy" packages? There is no rush. We first announced this in July 2009 [2] and then again in December [1]. We have given every opportunity to find appropriate upgrade paths. As mentioned, users who for some reason need or want to keep using legacy packages can use the kde-sunset overlay. 1: http://archives.gentoo.org/gentoo-dev-announce/msg_f295c1c2d9d70238d289de3a7ed5bf5c.xml 2: http://archives.gentoo.org/gentoo-dev-announce/msg_d851e05567d538b662f34de8dfdb7316.xml Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
Jeremy Olexa wrote: > There is an optional tag in metadata.xml. Good. Seems i'm not the first who thought about that ;) Yeah, maybe we can get the package managers to display the URLs corresponding to the atoms to be installed/updated when given a flag. But maybe that already exists, i haven't had a look in a while. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Friday 12 of March 2010 17:17:01 Fabian Groffen wrote: > On 12-03-2010 08:46:34 -0700, Denis Dupeyron wrote: > > That said they were perfectly entitled to make the decision of not > > wanting to maintain qt3 any longer. The only advice I can give is that > > all disgruntled users and developers create a qt3 project and > > adopt/unmask/re-commit the qt3 libraries for maintainers of packages > > who need it. I doubt this will happen as this could have been done a > > long time ago, but it's never too late. > > Didn't we have a graveyard thing/overlay somewhere some day? Some users > might happily prefer to use stuff that's treecleaned, or removed due > security issues. If removal of stuff would mean it's dumped in there it > can be easily used by users and more easily readded later afterwards, if > need arises. Yes, it's called kde-sunset and it contains KDE3 and should contain Qt3 applications (maybe it does, may not all of them though) removed from tree recently. It's not graveyard really as some users actively maintain this overlay. http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git (layman -a kde-sunset) -- regards MM
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
On Fri, 12 Mar 2010 17:59:58 +0100, Matti Bickel wrote: > As an alternative, let the ebuild provide a variable that points to > upstreams online Changelog or something, so you as a human can go parse > it yourself. But then you could also just take the HOMEPAGE variable > that's already there. There is an optional tag in metadata.xml. "Should contain a URL where the location of the upstream changelog can be found. The URL must be version independent and must point to a changelog which is only updated on new releases of the corresponding package. (This also implies that one can link to an automatically updated changelog in case of vcs snapshots only.) " http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4#doc_chap2 -Jeremy
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
Angelo Arrifano wrote: > What do you people think on a new pkg_changelog function that would > instruct the ebuild how to retrieve this kind of information from the > package? No, please don't. I'm okay with it if your mean "at the end of emerge -u ", but wouldn't it be pointless to see what changed *after* you just installed the thing? The reason i'm against it is the complexity involved. You need to pull down the source (up to hunderts of megabytes for openoffice), run src_unpack and eventually src_configure phases. Then you need to know where to look and what to show. But i agree it's cool to know what i will gain from my daily emerge run. As an alternative, let the ebuild provide a variable that points to upstreams online Changelog or something, so you as a human can go parse it yourself. But then you could also just take the HOMEPAGE variable that's already there. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On 12/03/10 17:17, Fabian Groffen wrote: > On 12-03-2010 08:46:34 -0700, Denis Dupeyron wrote: >> That said they were perfectly entitled to make the decision of not >> wanting to maintain qt3 any longer. The only advice I can give is that >> all disgruntled users and developers create a qt3 project and >> adopt/unmask/re-commit the qt3 libraries for maintainers of packages >> who need it. I doubt this will happen as this could have been done a >> long time ago, but it's never too late. > > Didn't we have a graveyard thing/overlay somewhere some day? Some users > might happily prefer to use stuff that's treecleaned, or removed due > security issues. If removal of stuff would mean it's dumped in there it > can be easily used by users and more easily readded later afterwards, if > need arises. > > As we have the "overlay depend on overlay" support now, we could easily put those packages into the sci overlay, if there would be a qt3 support/lib overlay. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Qt3 mask breaks significant science packages
Le vendredi 12 mars 2010 à 16:59 +0100, Alexis Ballier a écrit : > On Fri, 12 Mar 2010 08:46:34 -0700 > Denis Dupeyron wrote: > > [...] > > That said they were perfectly entitled to make the decision of not > > wanting to maintain qt3 any longer. The only advice I can give is that > > all disgruntled users and developers create a qt3 project and > > adopt/unmask/re-commit the qt3 libraries for maintainers of packages > > who need it. I doubt this will happen as this could have been done a > > long time ago, but it's never too late. > > 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. Well the discussion about dropping glib-1 and gtk-1 pops up once in a while in the herd. The removal hasn't been done yet because we focus more on packages that pops most on bugzilla for example. -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On 12-03-2010 08:46:34 -0700, Denis Dupeyron wrote: > That said they were perfectly entitled to make the decision of not > wanting to maintain qt3 any longer. The only advice I can give is that > all disgruntled users and developers create a qt3 project and > adopt/unmask/re-commit the qt3 libraries for maintainers of packages > who need it. I doubt this will happen as this could have been done a > long time ago, but it's never too late. Didn't we have a graveyard thing/overlay somewhere some day? Some users might happily prefer to use stuff that's treecleaned, or removed due security issues. If removal of stuff would mean it's dumped in there it can be easily used by users and more easily readded later afterwards, if need arises. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
On Fri, Mar 12, 2010 at 04:51:02PM +0100, Angelo Arrifano wrote: > On Sex, 2010-03-12 at 09:33 -0600, William Hubbs wrote: > > On Fri, Mar 12, 2010 at 04:16:05PM +0100, Angelo Arrifano wrote: > > > Hello all, > > > > > > [Speaking as user] I find myself many times stumbling through package > > > ChangeLogs to see what is new/changed after a emerge -u world. As some > > > of you might agree, this is time consuming. > > > > > > What do you people think on a new pkg_changelog function that would > > > instruct the ebuild how to retrieve this kind of information from the > > > package? Most of packages have a somewhat standard place for it in the > > > source tree, so I guess a default pkg_changelog function could, in > > > theory, be implemented. > > > > > > This function could be then called at user request by means of e.g. > > > emerge --showchangelog or at the end of emerge update (controlled > > > through a FEATURES="show-changelog" or something). > > > > Actually there is already an option for emerge to show the changelogs > > of packages that will be upgraded. Take a look at the --changelog > > option for emerge. It can be used along with --pretend to show you the > > changelogs of packages that will be upgraded. > > For a moment, you really tricked me into believing I've been missing > this feature. Specially by reading man emerge: > "This will show the ChangeLog entries for all the packages" > btw: shouldn't it read "ebuilds" here? /\ To me, if you change that wording to "ebuilds", you mean there will be a separate changelog for each *.ebuild file, so I would disagree with this change. > What I meant originally was to show the ChangeLog of the package > (ChangeLog inside source tree), not the ebuild ChangeLog. Not all upstreams provide changelogs (take a look at openrc as an example), so I'm not sure we could do this. Also, if we did, which file should we show (ChangeLog, NEWS, README ?) and how much of the file should we show? I'm not sure that there is an easy way to implement something like this. William pgpfBo8lY6KdC.pgp Description: PGP signature
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Fri, 12 Mar 2010 08:46:34 -0700 Denis Dupeyron wrote: [...] > That said they were perfectly entitled to make the decision of not > wanting to maintain qt3 any longer. The only advice I can give is that > all disgruntled users and developers create a qt3 project and > adopt/unmask/re-commit the qt3 libraries for maintainers of packages > who need it. I doubt this will happen as this could have been done a > long time ago, but it's never too late. 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. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Split desktop profile patches & news item for review
On 12 March 2010 09:36, Mart Raudsepp wrote: > * The split desktop profile plan retroactively modifies 2008.0 and 10.0 > profiles. Not a good thing for obvious reasons. While I agree with you in principle, this has not been Gentoo practice. The profiles have already been modified, multiple times, since the release. So either we need to revert those changes and start a new profile set (for an upcoming release or whatever), or we need to solve problems in the current profiles. I would support a new policy of not changing the release profiles once they have been officially released, and start working on a new "current" set of profiles immediately after release (or as soon as the need for change comes up). So we would in effect have stable and testing profiles, mirroring our ebuild policy. > * Adding yet more subprofiles, increasing repoman and pcheck time, > possibly confusing users (migration things; changing USE flags in a > perceived stable release profile leading to unexpected --newuse > triggering, etc) There are good reasons for these new subprofiles, and I'm sure our tools can handle them. Documentation and a news item about the changes should help prevent confusion among users. > * Making it harder to get both GNOME and KDE things out of a profile > (though the common things in desktop profile right now is quite > suboptimal for GNOME) Either solution is suboptimal, so it is very much about weighing pros and cons. In my opinion the split desktop profiles are an improvement over the current situation. And it will be even better when your plan for eselect profile improvements gets implemented. > * Putting the problem of suboptimal subprofiles handling under the > carpet again, greatly reducing the motivation for people to work on the > alternative better proposal I think it's rather the other way around: having split gnome and kde subprofiles makes it all the more apparent that the current handling of profiles is suboptimal. It will be a bigger motivation for change. I'm afraid that sweeping the problem of a suboptimal unified desktop profile under the carpet again by not implementing the split now will reduce motivation again for people to work on your proposal. 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? Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
On Sex, 2010-03-12 at 09:33 -0600, William Hubbs wrote: > On Fri, Mar 12, 2010 at 04:16:05PM +0100, Angelo Arrifano wrote: > > Hello all, > > > > [Speaking as user] I find myself many times stumbling through package > > ChangeLogs to see what is new/changed after a emerge -u world. As some > > of you might agree, this is time consuming. > > > > What do you people think on a new pkg_changelog function that would > > instruct the ebuild how to retrieve this kind of information from the > > package? Most of packages have a somewhat standard place for it in the > > source tree, so I guess a default pkg_changelog function could, in > > theory, be implemented. > > > > This function could be then called at user request by means of e.g. > > emerge --showchangelog or at the end of emerge update (controlled > > through a FEATURES="show-changelog" or something). > > Actually there is already an option for emerge to show the changelogs > of packages that will be upgraded. Take a look at the --changelog > option for emerge. It can be used along with --pretend to show you the > changelogs of packages that will be upgraded. For a moment, you really tricked me into believing I've been missing this feature. Specially by reading man emerge: "This will show the ChangeLog entries for all the packages" btw: shouldn't it read "ebuilds" here? /\ What I meant originally was to show the ChangeLog of the package (ChangeLog inside source tree), not the ebuild ChangeLog. > > Thanks, > > William > Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Fri, Mar 12, 2010 at 6:18 AM, 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. I'm not concerned but I feel sympathy for those who use these packages and many others. The decision from the qt project to remove qt3 and all its dependencies from the tree is suboptimal to say the least. A library project should be at the service of those using the library, not dictating to those using it. That said they were perfectly entitled to make the decision of not wanting to maintain qt3 any longer. The only advice I can give is that all disgruntled users and developers create a qt3 project and adopt/unmask/re-commit the qt3 libraries for maintainers of packages who need it. I doubt this will happen as this could have been done a long time ago, but it's never too late. Denis.
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
On Fri, Mar 12, 2010 at 04:16:05PM +0100, Angelo Arrifano wrote: > Hello all, > > [Speaking as user] I find myself many times stumbling through package > ChangeLogs to see what is new/changed after a emerge -u world. As some > of you might agree, this is time consuming. > > What do you people think on a new pkg_changelog function that would > instruct the ebuild how to retrieve this kind of information from the > package? Most of packages have a somewhat standard place for it in the > source tree, so I guess a default pkg_changelog function could, in > theory, be implemented. > > This function could be then called at user request by means of e.g. > emerge --showchangelog or at the end of emerge update (controlled > through a FEATURES="show-changelog" or something). Actually there is already an option for emerge to show the changelogs of packages that will be upgraded. Take a look at the --changelog option for emerge. It can be used along with --pretend to show you the changelogs of packages that will be upgraded. Thanks, William pgpVPmLQq3L4K.pgp Description: PGP signature
[gentoo-dev] [RFC] ebuild function to show package changelog
Hello all, [Speaking as user] I find myself many times stumbling through package ChangeLogs to see what is new/changed after a emerge -u world. As some of you might agree, this is time consuming. What do you people think on a new pkg_changelog function that would instruct the ebuild how to retrieve this kind of information from the package? Most of packages have a somewhat standard place for it in the source tree, so I guess a default pkg_changelog function could, in theory, be implemented. This function could be then called at user request by means of e.g. emerge --showchangelog or at the end of emerge update (controlled through a FEATURES="show-changelog" or something). I know we are all busy with a lot of things and I know what Gentoo don't really need right now is more cruft in the ebuilds (just think on QA!). Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
[gentoo-dev] Qt3 mask breaks significant science packages
It would appear that the pending (0321) mask of Qt3 will break sci-misc/qcad, sci-chemistry/xdrawchem and x11-misc/glunarclock. These are fairly significant science packages for which there are no current (qt4) or "equivalent" packages. While on one hand it may not do much harm to mask Qt3 based games packages (which I believe has already been done), it is entirely another thing when one goes masking significant science packages for which there may be no substitutes (e.g. qcad and xdrawchem). So, an end user (e.g. a Gentoo user who is not a Gentoo developer) is forced to ask: a) Has research been done to determine whether there are replacements for these packages and why aren't they suggested in the mask comments? b) If one is forced to run Qt3 in order to support these older packages, is there *good* documentation on how to do this (and why isn't this suggested in the mask comments)? While I am in general in favor of migrating to the most recent packages, there are cases where packages will still work reliably well with older libraries (and would likely work forever if there were "static" build options). So before there is a rush to remove ebuilds it should be asked whether it is possible to produce a static build and/or whether there is a clear path provided for the retention of "legacy" packages? Thank you, Robert Bradbury
Re: [gentoo-dev] Re: Split desktop profile patches & news item for review
On Friday 12 March 2010 10:36:57 Mart Raudsepp wrote: > On Thu, 2010-03-11 at 23:20 +0100, Ben de Groot wrote: > > On 11 March 2010 21:20, Mart Raudsepp wrote: > > > On Thu, 2010-03-11 at 02:36 +0100, Ben de Groot wrote: > > >> Seeing as there were no further comments, I think we are good to go! > > > > > > I suggest reading my comments... > > > > Unless I missed something, you didn't make any comments on this > > thread. > > The subthread got renamed to more fit its purpose. > > > If you mean the thread you started that tangentially took off from this > > one, about eselect profile improvements: I support that proposal, > > but it will take some time to get implemented. Is anyone already > > working on that? > > > > In the meantime I see no reason for that to halt or postpone the > > current desktop profile improvements as prepared by Theo. > > I argued that it's a bad idea to add yet more profiles, when we could > avoid that (while even improving things additionally). > > But I guess I'll have to bring some direct points why I think > implementing the alternative as I described ASAP is better than ever > doing this gnome/kde subprofile thing: > > * The split desktop profile plan retroactively modifies 2008.0 and 10.0 > profiles. Not a good thing for obvious reasons. (Of course the > subprofiles could also be added together with a new release, as proposed > for the alternative idea) > * Adding yet more subprofiles, increasing repoman and pcheck time, > possibly confusing users (migration things; changing USE flags in a > perceived stable release profile leading to unexpected --newuse > triggering, etc) > * Making it harder to get both GNOME and KDE things out of a profile > (though the common things in desktop profile right now is quite > suboptimal for GNOME) > * Putting the problem of suboptimal subprofiles handling under the > carpet again, greatly reducing the motivation for people to work on the > alternative better proposal 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. Maybe I'll find time to prepare something there, but I can't promise. Now, to reply to Mart: 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). To sum up: 1) Not oblious to me? / Not bad from my point of view? 2) I doubt users will be conflicted, I'll benchmark repoman and hit back 3) agreed, but i don't see a problem there 4) I'll be the motivator for this :) -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Teams blog.tampakrap.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Split desktop profile patches & news item for review
On Thu, 2010-03-11 at 23:20 +0100, Ben de Groot wrote: > On 11 March 2010 21:20, Mart Raudsepp wrote: > > On Thu, 2010-03-11 at 02:36 +0100, Ben de Groot wrote: > >> Seeing as there were no further comments, I think we are good to go! > > > > I suggest reading my comments... > > Unless I missed something, you didn't make any comments on this > thread. The subthread got renamed to more fit its purpose. > If you mean the thread you started that tangentially took off from this > one, about eselect profile improvements: I support that proposal, > but it will take some time to get implemented. Is anyone already > working on that? > > In the meantime I see no reason for that to halt or postpone the > current desktop profile improvements as prepared by Theo. I argued that it's a bad idea to add yet more profiles, when we could avoid that (while even improving things additionally). But I guess I'll have to bring some direct points why I think implementing the alternative as I described ASAP is better than ever doing this gnome/kde subprofile thing: * The split desktop profile plan retroactively modifies 2008.0 and 10.0 profiles. Not a good thing for obvious reasons. (Of course the subprofiles could also be added together with a new release, as proposed for the alternative idea) * Adding yet more subprofiles, increasing repoman and pcheck time, possibly confusing users (migration things; changing USE flags in a perceived stable release profile leading to unexpected --newuse triggering, etc) * Making it harder to get both GNOME and KDE things out of a profile (though the common things in desktop profile right now is quite suboptimal for GNOME) * Putting the problem of suboptimal subprofiles handling under the carpet again, greatly reducing the motivation for people to work on the alternative better proposal -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://blogs.gentoo.org/leio signature.asc Description: This is a digitally signed message part
