[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/mako: ChangeLog mako-0.1.10-r1.ebuild mako-0.1.10.ebuild
On 03:27 Mon 14 Jul , Alec Warner (antarus) wrote: > antarus 08/07/14 03:27:17 > > Modified: ChangeLog > Added:mako-0.1.10-r1.ebuild > Removed: mako-0.1.10.ebuild > Log: > Add setuptools to DEPEND per bug 215140. > (Portage version: 2.2_rc1/cvs/Linux 2.6.24-gentoo-r8 i686) Could someone please explain why this requires a revision bump? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpg3Q5cvxRCi.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Mon, 14 Jul 2008 02:22:35 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Mon, 14 Jul 2008 03:13:44 +0200 > Jeroen Roovers <[EMAIL PROTECTED]> wrote: > > On Mon, 14 Jul 2008 00:43:06 +0100 > > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > > People are already doing those other things, and doing them badly, > > > because there's currently no other option. This isn't some > > > hypothetical future requirement. > > > > When you wrote "doing them badly", did you mean to imply doing > > something else than GLEP 55, or were you just slagging off whoever > > implemented eblits in sys-libs/glibc? > > As much as you like to try to find some way of taking offence at > everything I write, no, there's no slagging off in there. I'm sorry to say this, but I actually do take offence at most things you write. > As you know fine well, implementing what clearly should be Please stop assuming people know everything you know and/or that people should know everything you know. This is a public forum where you should undertake to explain yourself fully instead of referring vaguely to an unknown set of morals and then suggesting another party should address whatever conflicts with that. It is a particularly subtle variant of the classic straw man that you regularly wield, and it is one of those things that often makes me take offence at what you write. > package manager provided functionality as hacks in an ebuild is never > going to give a nice, elegant solution. However, if package manager > functionality isn't available and can't become available quickly, it > might be the only solution until such functionality can come along. So it's not "doing them badly", it's currently the only solution and you haven't provided any arguments against this only solution as yet. > And making sure such functionality can come along is at least partly > the Council's responsibility. So that's one count of "nice, elegant", and apparently that is what you feel opposes "doing them badly"? > > In other words perhaps, is it your opinion that GLEP 55 needs to be > > implemented because sys-libs/glibc requires an immediate rewrite? > > Are there any bug reports that would be good examples of why this > > new implementation is warranted? > > GLEP 55 wouldn't even allow an immediate rewrite of glibc because new > EAPIs can't easily be used on system packages. Oh. You just shot down your only real world example (eblit versus GLEP 55). If you have any more, I'd happily have a look at them, as would anyone else worrying about the consequences of having GLEP 55 implemented. > So no. Instead, GLEP 55 would allow a future EAPI to introduce a > proper per-package eclass-like solution at the package manager level, > which could then over time be phased into glibc, and over less time > be phased into other packages that would make use of it. That's the > nice thing about the GLEP -- it allows the phased introduction of a > larger class improvements without major upheaval. [Class _of_ improvements, I guess.] Please provide an example of what that process would look like. You've always been good at these "we have ebuild 1, then ebuild 2 comes along, depending on ebuild 3 [...]" games, so please explain what we'd end up with in a hypothetical GLEP 55 compliant gentoo-x86/sys-libs/glibc, with "build files" (formerly ebuilds) getting added, removed, keyworded, package.masked and so on. What _I_ envision now is a motley crew of EAPI suffixed "build files" processing through gentoo-x86/sys-libs/glibc over time. Surely it would look a right mess every time you needed to go into that directory (particularly not in a role as any package manager's user or developer, but as a "build file" developer browsing through those files). What GLEP 55 fails to address right now is the very development process it is seemingly supposed to alleviate. It addresses the issue of EAPI implementation from the viewpoint of the package manager's developer, but it doesn't begin to address the viewpoint of the package maintainer or architecture developer at all. It looks to me like a lot of problems are moved out of the package manager(s) and into this already huge tree of files, with different EAPI-suffixed files addressing different problems, and that indicate be a non-trivial increase in the number of files in the tree - files which would address the equal purpose of installing exactly one =cat/pkg-ver. In other words, disregarding its other real world deficiencies like an immediate goal, GLEP 55 fails to describe a keywording policy for architecture developers and it fails to describe a "build file" addition (bump) policy for package maintainers. I grant you that on the surface it really does look nice and elegant. JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Mon, 14 Jul 2008 03:13:44 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > On Mon, 14 Jul 2008 00:43:06 +0100 > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > People are already doing those other things, and doing them badly, > > because there's currently no other option. This isn't some > > hypothetical future requirement. > > When you wrote "doing them badly", did you mean to imply doing > something else than GLEP 55, or were you just slagging off whoever > implemented eblits in sys-libs/glibc? As much as you like to try to find some way of taking offence at everything I write, no, there's no slagging off in there. As you know fine well, implementing what clearly should be package manager provided functionality as hacks in an ebuild is never going to give a nice, elegant solution. However, if package manager functionality isn't available and can't become available quickly, it might be the only solution until such functionality can come along. And making sure such functionality can come along is at least partly the Council's responsibility. > In other words perhaps, is it your opinion that GLEP 55 needs to be > implemented because sys-libs/glibc requires an immediate rewrite? Are > there any bug reports that would be good examples of why this new > implementation is warranted? GLEP 55 wouldn't even allow an immediate rewrite of glibc because new EAPIs can't easily be used on system packages. So no. Instead, GLEP 55 would allow a future EAPI to introduce a proper per-package eclass-like solution at the package manager level, which could then over time be phased into glibc, and over less time be phased into other packages that would make use of it. That's the nice thing about the GLEP -- it allows the phased introduction of a larger class improvements without major upheaval. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Mon, 14 Jul 2008 00:43:06 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > People are already doing those other things, and doing them badly, > because there's currently no other option. This isn't some > hypothetical future requirement. When you wrote "doing them badly", did you mean to imply doing something else than GLEP 55, or were you just slagging off whoever implemented eblits in sys-libs/glibc? In other words perhaps, is it your opinion that GLEP 55 needs to be implemented because sys-libs/glibc requires an immediate rewrite? Are there any bug reports that would be good examples of why this new implementation is warranted? JeR -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-07-13 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-07-13 23h59 UTC. Removals: net-zope/plonelanguagetool 2008-07-08 06:09:40 tupone net-zope/calendarx 2008-07-08 06:14:48 tupone Additions: virtual/texi2dvi2008-07-07 16:54:10 ulm dev-python/mpmath 2008-07-08 04:10:15 grozin x11-libs/liboglappth2008-07-08 07:08:00 dberkholz net-proxy/ratproxy 2008-07-08 19:57:42 drizzt app-emulation/kvm 2008-07-09 00:21:56 dang sci-biology/ApE 2008-07-09 03:35:51 je_fro net-firewall/arno-iptables-firewall 2008-07-10 20:09:50 wolf31o2 dev-java/squareness-jlf 2008-07-12 09:41:28 serkan media-sound/entagged-tageditor 2008-07-12 09:47:13 serkan dev-tex/oesch 2008-07-12 09:58:55 aballier -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-zope/plonelanguagetool,removed,tupone,2008-07-08 06:09:40 net-zope/calendarx,removed,tupone,2008-07-08 06:14:48 Added Packages: virtual/texi2dvi,added,ulm,2008-07-07 16:54:10 dev-python/mpmath,added,grozin,2008-07-08 04:10:15 x11-libs/liboglappth,added,dberkholz,2008-07-08 07:08:00 net-proxy/ratproxy,added,drizzt,2008-07-08 19:57:42 app-emulation/kvm,added,dang,2008-07-09 00:21:56 sci-biology/ApE,added,je_fro,2008-07-09 03:35:51 net-firewall/arno-iptables-firewall,added,wolf31o2,2008-07-10 20:09:50 dev-java/squareness-jlf,added,serkan,2008-07-12 09:41:28 media-sound/entagged-tageditor,added,serkan,2008-07-12 09:47:13 dev-tex/oesch,added,aballier,2008-07-12 09:58:55 Done.
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 16:37:35 -0700 "Alec Warner" <[EMAIL PROTECTED]> wrote: > I don't require any of those things, but maybe other people do and If > so; they should probably come > to the meeting or otherwise make themselves known because they were > not at the previous meeting. http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/files/eblits/ I presume you're aware of that. People are already doing those other things, and doing them badly, because there's currently no other option. This isn't some hypothetical future requirement. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, Jul 13, 2008 at 4:21 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 13 Jul 2008 16:16:23 -0700 > "Alec Warner" <[EMAIL PROTECTED]> wrote: >> As far as could be determined by the members at the meeting there no >> compelling examples in Gentoo who to change or add global scope >> functions in future EAPIs. As such those problems as stated are not >> in scope for Gentoo because Gentoo is not attempting to do those >> things at this time. > > You mean you don't want per-category/package eclasses, or eclasses that > can indicate that they only work with some EAPIs, or eclasses that can > indicate that they're being used incorrectly, or the death of > EXPORT_FUNCTIONS? All of these have been discussed as desirable future > extensions. I don't require any of those things, but maybe other people do and If so; they should probably come to the meeting or otherwise make themselves known because they were not at the previous meeting. The GLEP as written is not convincing; it doesn't say 'I am trying to do X with Gentoo and cannot because of this restriction.' It says 'In the future someone may want to do X and they won't be able to because of this restriction so lets try to remove the restriction now.' This is an admirable goal mind you; but it is my opinion that there are more concrete features that we could implement for benefits now rather than talk about what could be. I chatted briefly with peper on IRC about this (as he was the original GLEP author) so when he gets time he said he had some examples to provide. > > -- > Ciaran McCreesh > -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 16:16:23 -0700 "Alec Warner" <[EMAIL PROTECTED]> wrote: > As far as could be determined by the members at the meeting there no > compelling examples in Gentoo who to change or add global scope > functions in future EAPIs. As such those problems as stated are not > in scope for Gentoo because Gentoo is not attempting to do those > things at this time. You mean you don't want per-category/package eclasses, or eclasses that can indicate that they only work with some EAPIs, or eclasses that can indicate that they're being used incorrectly, or the death of EXPORT_FUNCTIONS? All of these have been discussed as desirable future extensions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, Jul 13, 2008 at 4:16 PM, Alec Warner <[EMAIL PROTECTED]> wrote: > On Sun, Jul 13, 2008 at 3:52 PM, Ciaran McCreesh > <[EMAIL PROTECTED]> wrote: >> On Sun, 13 Jul 2008 00:11:18 -0700 >> Donnie Berkholz <[EMAIL PROTECTED]> wrote: >>> GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may >>> be, but that's unclear until it's been revised. >> >> Which part of the 'Problem' section in the GLEP didn't you understand? >> Do you seriously consider not being able to add or change global scope >> functions in future EAPIs to be a non-issue, or were you ignoring those >> two bullet points? > > I understood both. > > As far as could be determined by the members at the meeting there no > compelling examples in Gentoo who to change or add global scope functions > in future EAPIs. As such those problems as stated are not in scope for Gentoo > because Gentoo is not attempting to do those things at this time. ugh, s/who// > >> >> -- >> Ciaran McCreesh >> > -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/hylafax: ChangeLog hylafax-4.4.4.ebuild
On 23:05 Sun 13 Jul , Steve Arnold (nerdboy) wrote:
> 1.1 net-misc/hylafax/hylafax-4.4.4.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/hylafax/hylafax-4.4.4.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/hylafax/hylafax-4.4.4.ebuild?rev=1.1&content-type=text/plain
> src_compile() {
> # gcc standard C++ header changes
> if [ $(gcc-major-version) -eq 4 ] && [ $(gcc-minor-version) -ge 3 ] ;
> then
> sed -i -e 's:"new.h"::g' configure util/Types.h || die "sed
> failed"
> sed -i -e 's:"iostream.h":\n using namespace std;:g' \
> configure || die "sed failed"
> fi
Has a patch been sent upstream for this?
> if use html; then
> my_conf="${my_conf} --with-HTML=yes"
> else
> my_conf="${my_conf} --with-HTML=no"
> fi
Does this work?
my_conf="${my_conf} $(use_with html HTML)"
> #--enable-pam isn't valid
> use pam || my_conf="${my_conf} $(use_enable pam)"
Might avoid some confusion with just --disable-pam since --enable
doesn't work.
> # eval required for quoting in ${my_conf} to work properly, better way?
> eval ./configure --nointeractive ${my_conf} || die "./configure failed"
That's kinda gross. What exactly is the problem?
> emake -j1 || die "emake failed"
Have you filed an upstream bug about parallel build being broken?
> generate_files # in this case, it only generates the env.d entry
>
> einfo "Adding env.d entry for Hylafax"
> doenvd 99${P}
doenvd doesn't die on failure.
> einfo "Adding init.d entry for Hylafax"
> newinitd "${FILESDIR}"/${PN}-4.2 ${PN}
Neither does newinitd.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpLx32MeL6SE.pgp
Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, Jul 13, 2008 at 3:52 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 13 Jul 2008 00:11:18 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: >> GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may >> be, but that's unclear until it's been revised. > > Which part of the 'Problem' section in the GLEP didn't you understand? > Do you seriously consider not being able to add or change global scope > functions in future EAPIs to be a non-issue, or were you ignoring those > two bullet points? I understood both. As far as could be determined by the members at the meeting there no compelling examples in Gentoo who to change or add global scope functions in future EAPIs. As such those problems as stated are not in scope for Gentoo because Gentoo is not attempting to do those things at this time. > > -- > Ciaran McCreesh > -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-mobilephone/galicesms: ChangeLog galicesms-1.62.ebuild
On 15:17 Sat 12 Jul , Alin Nastac (mrness) wrote:
> 1.1 app-mobilephone/galicesms/galicesms-1.62.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-mobilephone/galicesms/galicesms-1.62.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-mobilephone/galicesms/galicesms-1.62.ebuild?rev=1.1&content-type=text/plain
> src_install() {
> dobin "${PN}"
> }
dobin doesn't die on failure.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpJteFp3kTVP.pgp
Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-mathematics/axiom: ChangeLog axiom-200805.ebuild
On 14:37 Sat 12 Jul , Markus Dittrich (markusle) wrote:
> 1.1 sci-mathematics/axiom/axiom-200805.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-mathematics/axiom/axiom-200805.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-mathematics/axiom/axiom-200805.ebuild?rev=1.1&content-type=text/plain
> src_compile() {
> # lots of strict-aliasing badness
> append-flags -fno-strict-aliasing
>
> ./configure || die "Failed to configure"
If econf works, could you add a comment saying so?
> # use gcl 2.6.7
> sed -e "s:GCLVERSION=gcl-2.6.8pre$:GCLVERSION=gcl-2.6.7:" \
> -i Makefile.pamphlet Makefile \
> || die "Failed to select proper gcl"
>
> # fix libXpm.a location
> sed -e "s:X11R6/lib:$(get_libdir):g" -i Makefile.pamphlet \
> || die "Failed to fix libXpm lib paths"
>
> # Let the fun begin...
> AXIOM="${S}"/mnt/linux emake -j1 || die
Is there an upstream bug failed about parallel builds?
> src_install() {
> make DESTDIR="${D}"/opt/axiom
> COMMAND="${D}"/opt/axiom/mnt/linux/bin/axiom install \
> || die 'Failed to install Axiom!'
Use emake, please.
>
> mv "${D}"/opt/axiom/mnt/linux/* "${D}"/opt/axiom
> rm -fr "${D}"/opt/axiom/mnt
Might want `|| die` for both of those, and anything else that sucks if it fails.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpOG2D42YyLI.pgp
Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 00:11:18 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may > be, but that's unclear until it's been revised. Which part of the 'Problem' section in the GLEP didn't you understand? Do you seriously consider not being able to add or change global scope functions in future EAPIs to be a non-issue, or were you ignoring those two bullet points? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 10 July 2008
Donnie Berkholz wrote: Hi all, Here is the summary from Thursday's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. With regard to GLEP 56. I've posted the necessary DTD changes, some documentation changes (the old documentation patches need to be updated to whats currently in CVS because some commits occurred between when they were created and now), and the repoman patches to the bug [1]. My patches to repoman have already been committed to Portage trunk so they'll appear in 2.2_rc2. pkgcore is being updated this weekend for pcheck to support the new syntax according to ferringb. No one has gotten back to me on paludis so I'm not sure about that status. With regard to the DTD, it's a small change to allow the tag, the rest are there already. As far as the docs team knows, neysx is the only one that can commit to them. He's gone until September. So we might need someone from infra to give another doc's team member the access to make that commit. Betelgeuse is committing the documentation patches as I update them for the Gentoo Development Handbook. Halcy0n made a few requested updates to the Gentoo Developer Manual. So that front is moving forward well. I'll be working with robbat2 when he gets some free time this week on getting the infra script I hacked up in place. All and all I'd say we're moving forward on marking this GLEP as Final pretty soon. Biggest project left for me is to copy the current use.local.desc bits into the respective metadata.xml's of each package. If maintainers want to help, that'd be awesome. [1] http://bugs.gentoo.org/show_bug.cgi?id=199788 -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 00:11:18 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > dberkholz: with GLEP 55 EAPI X can add the support for > scm > dberkholz: and older Portage versions work just fine I thought we established that EAPI (no matter how it's defined) only controls ebuild _contents_ ... Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] wget abuse of sources.g.o must stop
Robin H. Johnson demis ki:: Pursuant to the above, the any useragent matching /^Wget/ will be blocked from the 'gentoo' and 'gentoo-x86' repos of sources.gentoo.org as of July 14th. Either change to using the proper anonymous service, or change your useragent to describe what you are doing with the service, so that I can specifically ban your user-agent if it's causing too much load. I think a post on planet gentoo and/or gentoo.org would be beneficial. -- Gokdeniz Karadag -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
Here are quick updates on the topics we didn't discuss in detail during the council meeting. On 01:40 Wed 09 Jul , Donnie Berkholz wrote: > Appeals of spb, rbrown, & philantrop We are actively discussing the appeals and will get decisions out ASAP. > Meeting frequency & time We're moving to shorter biweekly meetings. The next one will be July 24. > User Relations authority Discussion is happening on gentoo-council. > Extent of Code of Conduct enforcement I will post this to gentoo-council tomorrow. I haven't had a chance yet to put together a useful summary post for starting the thread. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpUSTr58UJDb.pgp Description: PGP signature
[gentoo-dev] Council meeting summary for 10 July 2008
Hi all, Here is the summary from Thursday's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com Quick summary = GLEP 54: There were numerous questions that apparently were not brought up on the mailing list in advance or were not addressed. GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may be, but that's unclear until it's been revised. GLEP 56: Approved. Cardoe will get repoman changes made, followed by a server-side script to generate use.local.desc from metadata.xml. The meeting wrapped up in under 1 hour again. We still need to work harder to push more discussion and questions to the mailing list, though. Topics == GLEP 54 --- Preparation: Post your opinion to the -dev thread "A few questions to our nominees" 4+ hours before the meeting. Last month: dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml lu_zero: http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml Goal: Status check at meeting to see who's ready to vote. Vote on-list no later than July 17. dberkholz: with GLEP 55 EAPI X can add the support for scm dberkholz: and older Portage versions work just fine dberkholz: In general I oppose adding things to EAPI 0 < lu_zero@> dberkholz problem: if you have -scm installed < lu_zero@> and then switch to a pm not knowing it < lu_zero@> you have a nice recipe for inconsistency < Halcy0n@> I would really like to see a list of features that we would end up having after implementing this GLEP. The GLEP mentions possible enhancements, but I'd like to see what we would have planned if we go forward with this change. < Halcy0n@> Well, it only mentions one enhancement, I'd like to see what else we could do to judge if it is worth it. Halcy0n@> Betelgeuse: yes, I know there are some things we could do, but I'd like to see a more extensive list of possibilities, what are other possible ways of doing this (like a metadata tag for the ebuild), and why those other methods aren't sufficient. < dberkholz@> i think the point here is that the glep should address what made its implementation superior to other possible ones, which it also describes < dberkholz@> ok, i've noted the issues raised here < dberkholz@> once they're address, the glep can be revised and we'll consider it again Summary: Specific questions and requests are above. GLEP 55 --- Preparation: Post your opinion to the -dev thread "GLEP 55" 4+ hours before the meeting. Last month: dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml Goal: Status check at meeting to see who's ready to vote. Vote on-list once we're ready. But I don't see the use of accepting it before we a) Portage has something that would make use of it b) some other pkg manager is made official < Halcy0n@> So, can we vote on postponing a GLEP of this nature until another glep requires such changes? Summary: On hold pending a concrete requirement for it. GLEP 54 may be, but that's unclear until it's been revised. GLEP 56 --- Preparation: Post your opinion to the -dev thread "[GLEP56] USE flag descriptions in metadata" 4+ hours before the meeting. (Cardoe: Did the requested updates ever get made?) Last month: dberkholz: http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml Goal: Status check at meeting to see who's ready to vote. Vote on-list no later than July 17, if requested changes are made. Requested changes were made: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1&r2=1.2Well the first step of making that portion happen is going to be to add a check to repoman that if use.local.desc is not present in the repo, do new QA check. Once that's in place that developers can use, then the infra script will happen. I've already discussed it with the Portage folks and the infra folks. Summary: Approved. Roll call = (here, proxy [by whom] or slacker?) betelgeuse here dberkholz here dertobi123 here flameeyes here halcy0n here jokey here lu_zero here pgpkuFMGXukZ5.pgp Description: PGP signature
