Re: [gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
On 13/06/13 07:58, Michał Górny wrote: Dnia 2013-06-13, o godz. 01:22:11 Samuli Suominen ssuomi...@gentoo.org napisał(a): what $subject says, add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938) http://bugs.gentoo.org/472938 ie. the pkg-config file shipped *now* in portage is a hack from me to postpone this pretty tired so more eyes is cool ;) You mean http://thread.gmane.org/gmane.linux.gentoo.devel/85258 ? I think you've got to convince ulm in the first place. His concerns was actually already covered by the first post and the linked bug: This is required for smooth migration path from old to new directories. Back when the old thread happened, there was only one possible value for completions dir, now there is two. And nothing prevents upstream adding/changing the values in the .pc file yet again for next release, this should be dynamic -- just like $(get_udevdir), $(get_libdir) etc.
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On Thu, Jun 13, 2013 at 6:56 AM, Alexander V Vershilov alexander.vershi...@gmail.com wrote: The main point that haskell ecosystem is very breaky and only latest version is supported, so the safest path is to be on a bleeding edge and patch inconsistent applications. So if one package gets updated then commonly we need to fix its reversed deps, if it were in tree than we would be involved into stabilization process and in the end will delay updating deps, and the difficulty of tracking all version variant will be much higher than no, at the end the quality of the packages in tree will fall. Really we can _guarantee_ that everything work in overlay but there is either no technical or bureaucracy reasons that prevent from fixing as soon as possible. Still seems like working in gentoo-x86 without doing stabilization would cover most of those bases. Working in the unstable main tree is still a lot better than keeping stuff out there in an overlay, IMO. Cheers, Dirkjan
Re: [gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
On Thu, 13 Jun 2013, Samuli Suominen wrote: On 13/06/13 07:58, Michał Górny wrote: Dnia 2013-06-13, o godz. 01:22:11 Samuli Suominen ssuomi...@gentoo.org napisał(a): what $subject says, add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938) http://bugs.gentoo.org/472938 ie. the pkg-config file shipped *now* in portage is a hack from me to postpone this pretty tired so more eyes is cool ;) You mean http://thread.gmane.org/gmane.linux.gentoo.devel/85258 ? I think you've got to convince ulm in the first place. His concerns was actually already covered by the first post and the linked bug: This is required for smooth migration path from old to new directories. Back when the old thread happened, there was only one possible value for completions dir, now there is two. And nothing prevents upstream adding/changing the values in the .pc file yet again for next release, this should be dynamic -- just like $(get_udevdir), $(get_libdir) etc. Nothing is covered. If you change the installation dir for the completion modules, then eselect bashcomp won't be able to find them any more. So you need a transition plan. Ulrich
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
Am 13.06.2013 07:44, schrieb Michał Górny: Dnia 2013-06-12, o godz. 13:23:04 Michael Orlitzky mich...@orlitzky.com napisał(a): We need worse support for overlays, i.e. no. Having to use 3 overlays defeats the purpose of a QA'd tree. Everything in an (official) overlay should be in package.mask instead. The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. Sunrise is not that good example. I liked to use it as an example but over time you start to see how degenerated it becomes. It seems that the bond between people is pretty poor there, and many of the packages lack proper maintenance. Some of them simply don't build at all and wait for a random Sunrise user to fix them. Then they lay unmaintained once again, and the story repeats. Then the policies in sunrise need to be more strict: If it is mentioned in the bug, that the version in sunrise does not build anymore, it should be dropped from sunrise if there is no fix in some timeframe [1]. Of course this puts more workload on the sunrise-team as they have to monitor the bugs and respond accordingly. - René [1] Dunno, perhaps two weeks if noone responds will fix it, four weeks else.
Re: [gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
On 13/06/13 09:59, Ulrich Mueller wrote: On Thu, 13 Jun 2013, Samuli Suominen wrote: On 13/06/13 07:58, Michał Górny wrote: Dnia 2013-06-13, o godz. 01:22:11 Samuli Suominen ssuomi...@gentoo.org napisał(a): what $subject says, add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938) http://bugs.gentoo.org/472938 ie. the pkg-config file shipped *now* in portage is a hack from me to postpone this pretty tired so more eyes is cool ;) You mean http://thread.gmane.org/gmane.linux.gentoo.devel/85258 ? I think you've got to convince ulm in the first place. His concerns was actually already covered by the first post and the linked bug: This is required for smooth migration path from old to new directories. Back when the old thread happened, there was only one possible value for completions dir, now there is two. And nothing prevents upstream adding/changing the values in the .pc file yet again for next release, this should be dynamic -- just like $(get_udevdir), $(get_libdir) etc. Nothing is covered. If you change the installation dir for the completion modules, then eselect bashcomp won't be able to find them any more. So you need a transition plan. Sorry if I wasn't clear: http://bugs.gentoo.org/show_bug.cgi?id=472938#c1 I think we should eventually get rid of the eselect module and load everything dynamically. So what is left, after committing those posted diff's: - Removal of bash-completion specific snippets from app-admin/eselect as it's no-op with the new way. This is more of a matter of cleanup after rest of the work is done. Although, if you want something more complex, then by all means... - Postinstallation instructions to the new bash-completion to run qfile combination with emerge to re-emerge packages to move files to correct directory. Trivial to accomplish. Dunno why I didn't already put it to the diff. As in, there is a complete transition plan in place far as I can see. I succesfully migrated already locally.
Re: [gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
On Thu, 13 Jun 2013, Samuli Suominen wrote: http://bugs.gentoo.org/show_bug.cgi?id=472938#c1 I think we should eventually get rid of the eselect module and load everything dynamically. How do you enable and disable completion modules without the eselect module? Ulrich
Re: [gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
On 13/06/13 12:14, Ulrich Mueller wrote: On Thu, 13 Jun 2013, Samuli Suominen wrote: http://bugs.gentoo.org/show_bug.cgi?id=472938#c1 I think we should eventually get rid of the eselect module and load everything dynamically. How do you enable and disable completion modules without the eselect module? Ulrich The upstream way... To disable sys-fs/udisks:2 bash-completion file 'udisksctl' from completing, user would add: complete -r udisksctl to eg. his ~/.bashrc Like for example here, https://mknowles.com.au/wordpress/2012/09/22/how-to-stop-bash-from-completing-mount-dev-commands/
Re: TLDR: rant in support of overlays (was: Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays)
On Wed, 12 Jun 2013 15:31:57 -0700 Greg Turner g...@malth.us wrote: Anyhow, isn't the gentoo-x86 tree already plenty big enough, without every single overlay's ebuilds and eclasses in there too? Personally, I'm inclined to wish it was smaller, even if that meant more stuff was pushed into overlays Actually, this is something I expected to happen soon after we got overlays but for some reason it haven't. I imagine we would not have a single gx86 official tree but rather a bunch of official overlays. For basic installation one would need just the system overlay. Then everypony could add official overlay for KDE, or gnome or whatnot as one desires. I haven't thought this through in any way but it feels like better design.
[gentoo-dev] Re: TLDR: rant in support of overlays (was: Re: Over-reliance of Gentoo projects on overlays)
yac posted on Thu, 13 Jun 2013 12:15:26 +0200 as excerpted: On Wed, 12 Jun 2013 15:31:57 -0700 Greg Turner g...@malth.us wrote: Anyhow, isn't the gentoo-x86 tree already plenty big enough, without every single overlay's ebuilds and eclasses in there too? Personally, I'm inclined to wish it was smaller, even if that meant more stuff was pushed into overlays Actually, this is something I expected to happen soon after we got overlays but for some reason it haven't. I imagine we would not have a single gx86 official tree but rather a bunch of official overlays. For basic installation one would need just the system overlay. Then everypony could add official overlay for KDE, or gnome or whatnot as one desires. I haven't thought this through in any way but it feels like better design. Someone else already mentioned the problem with that. At least currently, only the official tree is tested against, so at least in theory it's quite easy to have conflicts between overlays, and it's certainly much more likely to have packages broken for some usage as they simply haven't been tested against packages in that overlay. The more overlays, the more likely the conflicts and breakage. The obvious way around that is to have a set of blessed overlays that get tested against, much like the main tree (only) today. However, that seriously complexifies (good) testing as now every dev has to pull down the whole set of blessed overlays instead of just the main tree plus whatever overlays he happens to work on (with some devs doing no overlays at all), as is the case now. The last thing we should be doing is throwing additional roadblocks into the way of reasonable testing, and I believe that's why the split you expected hasn't happened -- people realize that and decide the main tree's the best idea after all. Tho CVS is a enough of a pain that I'm sure that alone keeps some packages and potential devs away. Once it's git, that problem too will disappear, and there will be less pressure to split off overlays than there is now. -- 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] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
Dnia 2013-06-13, o godz. 12:05:08 Samuli Suominen ssuomi...@gentoo.org napisał(a): - Postinstallation instructions to the new bash-completion to run qfile combination with emerge to re-emerge packages to move files to correct directory. Trivial to accomplish. Dunno why I didn't already put it to the diff. With new enough portage, you can simply do: emerge -1 /usr/share/bash-completion I think that should be the way suggested to users. But that's just a side note, so we don't miss it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
Dnia 2013-06-13, o godz. 01:22:11 Samuli Suominen ssuomi...@gentoo.org napisał(a): what $subject says, add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938) http://bugs.gentoo.org/472938 ie. the pkg-config file shipped *now* in portage is a hack from me to postpone this pretty tired so more eyes is cool ;) I've talked with ulm and got an agreement to commit the initial get_bashcompdir(). I've used the patch that I once submitted to the ml as its minimal change. I'll get to committing parts of your patch in a week or so, after more eyes see them. If you'd like, please split it into functional parts (like 1. pkg-config, 2. helpersdir, etc.) and rebase on top of current code. In any case, we can already start moving packages to use $(get_bashcompdir), so they're prepared for the eventual migration. But the actual details need to be discussed, as was pointed out. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On Tue, Jun 11, 2013 at 02:15:29PM +0200, Alex Legler wrote: On 11.06.2013 13:05, Theo Chatzimichos wrote: On Tuesday, June 11, 2013 12:20:20 Sven Vermeulen wrote: Jason A. Donenfeld zx...@gentoo.org wrote: On Sun, Jun 9, 2013 at 4:22 PM, Alex Legler a...@gentoo.org wrote: - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an initial wiki version of the document What is the current status of such a tool? It is a script (xslt) that can be used with xsltproc to convert large chunks into wiki style. It isn't perfect though thus still requires manual review, but it is doable. I *think* I committed one to the repo a while ago. If not, I'll do so soon (I have one in my own repo just for this purpose). How about an ebuild please? Optional. I intend to expose this as a web site/service. I've committed my draft XSL to the gentoo/xml/htdocs/xsl location, named guidexml2wiki.xsl. It still requires some updates that I'll work on soon (such as handling internal links) as I'll be using it more and more for the guides on gentoo.org/doc/en to move to the wiki as well. ProjectXML generates towards GuideXML, so should be usable chained. But as mentioned, it's a draft, and if you don't like it I don't mind at all ;-) Wkr, Sven Vermeulen PS An ebuild for a single stylesheet seems like overkill to me, but i've been proven incorrect in the past...
[gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, At the beginning of July, the KDE team will be removing EAPI 0/1 support from cmake-utils.eclass and inlining the functions from base.eclass in order to remove that inherit [1]. The modified eclass is currently available in the KDE overlay. There is one package [2] remaining in-tree which has EAPI2 which will be handled soon, but please update any overlay packages using the eclass. I have also added a deprecation warning to the in-tree cmake-utils.eclass for packages using EAPI 0/1. Chris Reffett [1] https://bugs.gentoo.org/show_bug.cgi?id=459678 [2] https://bugs.gentoo.org/show_bug.cgi?id=460572 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlG6PmRfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QIkgCfV+VLuCg3bC880EhaTiol4ggB jhQAoJaBwxZHwH9l4g48olShsnWDZBos =qeh9 -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support
At the beginning of July, the KDE team will be removing EAPI 0/1 support from cmake-utils.eclass and inlining the functions from base.eclass in order to remove that inherit [1]. So, instead of fixing what you consider wrong in base.eclass, you inline it so that if someone improves base.eclass he has to do it for cmake-utils too?
Re: [gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/13/2013 06:37 PM, Alexis Ballier wrote:
At the beginning of July, the KDE team will be removing EAPI 0/1
support from cmake-utils.eclass and inlining the functions from
base.eclass in order to remove that inherit [1].
So, instead of fixing what you consider wrong in base.eclass, you
inline it so that if someone improves base.eclass he has to do it
for cmake-utils too?
We did not actually inline most of the complicated logic from
base.eclass, as to the best of my knowledge epatch itself will handle
all of the corner cases that base_src_prepare covers. The new patching
code essentially consists of [[ ${PATCHES[@]} ]] epatch
${PATCHES[@]}; epatch_user. As for the reason for the change, the
request and rationale can be seen in the first bug that I linked in
the email.
Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iKYEARECAGYFAlG6TDVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1S3SACgitmH0FVRUNwmJE9e/4JmrwqV
ucwAnj+/+V9ECy9OoCK6eDqSsuiiTgDU
=5QKk
-END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support
On Thu, 13 Jun 2013 18:48:21 -0400
Chris Reffett creff...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/13/2013 06:37 PM, Alexis Ballier wrote:
At the beginning of July, the KDE team will be removing EAPI 0/1
support from cmake-utils.eclass and inlining the functions from
base.eclass in order to remove that inherit [1].
So, instead of fixing what you consider wrong in base.eclass, you
inline it so that if someone improves base.eclass he has to do it
for cmake-utils too?
We did not actually inline most of the complicated logic from
base.eclass, as to the best of my knowledge epatch itself will handle
all of the corner cases that base_src_prepare covers. The new patching
code essentially consists of [[ ${PATCHES[@]} ]] epatch
${PATCHES[@]}; epatch_user.
that kind of stuff sounds more like it should be factorized rather than
copied all around; be it base.eclass, an EAPI, or another eclass I
don't really care.
there's also a base_src_install_docs call in current cmake-utils.eclass
Alexis.
