[gentoo-dev] Re: Upcoming masking of dev-lang/php-4* and packages depending on it
Marius Mauch [EMAIL PROTECTED]: On Sun, 7 Oct 2007 15:13:49 +0200 Christian Hoffmann [EMAIL PROTECTED] wrote: I'm going to p.mask =dev-lang/php-4* and all packages explicitly depending on this version of php (i.e. the whole dev-php4/ category (36 packages) and one webapp, www-apps/knowledgetree, bug 194894 [1]) next weekend (around Oct 14th). This step is necessary as there is hardly any upstream activity anymore. You should probably post that in a more user-oriented channel, like gentoo-announce and/or the forums to reduce the number of surprised users [1] Or even write a short summary for the GWN...they would be happy about it. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
On Wed, 2007-10-10 at 20:03 -0700, Alec Warner wrote: B. don't use GNU extensions in pkg_functions and have some way to export them (extract pkg_* functions from environment.bz2). Those can then be used by pre/post script in binary package manager. This is your best bet, but again mandates are ineffective. As you've no doubt noticed with quoting, people will do whatever works and the people who aim for odd targets like no GNU crap or sh compatability are going to have to do the code reviews and encourage that sort of thing. Just saying 'pre/post functions must be POSIX compatable' will get you nowhere. The point here is to sell your idea to other developers; if you can't sell it you may need to take it elsewhere. This is what I'm preaching, but for the whole ebuild not just the pre/post functions. It's a tough crowd as everyone's a zealot with their own favourite must have tools + the territorial crap which rears it's ugly head from time to time. Thanks Roy -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/evms: ChangeLog evms-2.5.5-r8.ebuild
Am Dienstag, 9. Oktober 2007 14.56:24 schrieb Doug Goldstein:
Donnie Berkholz wrote:
On 22:01 Mon 08 Oct , Doug Goldstein (cardoe) wrote:
1.1 sys-fs/evms/evms-2.5.5-r8.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r
8.ebuild?rev=1.1view=markup plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r
8.ebuild?rev=1.1content-type=text/plain
epatch ${FILESDIR}/${PV}/md_super_fix.patch
epatch ${FILESDIR}/${PV}/ntfs_unmkfs.patch
epatch ${FILESDIR}/${PV}/raid5_degrade_fix_v2.patch
epatch ${FILESDIR}/${PV}/raid5_remove_spare_fix.patch
epatch ${FILESDIR}/${PV}/raid5_remove_spare_fix_2.patch
epatch ${FILESDIR}/${PV}/raid5_algorithm.patch
epatch ${FILESDIR}/${PV}/cli_reload_options.patch
epatch ${FILESDIR}/${PV}/cli_query_segfault.patch
epatch ${FILESDIR}/${PV}/get_geometry.patch
epatch ${FILESDIR}/${PV}/BaseName.patch
epatch ${FILESDIR}/${PV}/disk_cache.patch
epatch ${FILESDIR}/${P}-as-needed.patch
epatch ${FILESDIR}/${P}-glib_dep.patch
epatch ${FILESDIR}/${P}-ocfs2.patch
epatch ${FILESDIR}/${P}-use_disk_group.patch
epatch ${FILESDIR}/${P}-pagesize.patch
This would be another good candidate for using epatch's bulk patching,
particularly if you moved the last group of patches into the PV
directory.
dev-zero?
Nope. The stuff in ${PV} are the patches upstream has on their servers, while
the others are mostly Gentoo-specific or something else. So I want them to be
separated.
And I don't see any reason to start renaming now.
Cheers,
Tiziano
--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility: Samba, PostgreSQL, cpp, Python
E-Mail : [EMAIL PROTECTED]
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/evms: ChangeLog evms-2.5.5-r8.ebuild
On 11:13 Thu 11 Oct , Tiziano Müller wrote:
Am Dienstag, 9. Oktober 2007 14.56:24 schrieb Doug Goldstein:
Donnie Berkholz wrote:
On 22:01 Mon 08 Oct , Doug Goldstein (cardoe) wrote:
1.1 sys-fs/evms/evms-2.5.5-r8.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r
8.ebuild?rev=1.1view=markup plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r
8.ebuild?rev=1.1content-type=text/plain
epatch ${FILESDIR}/${PV}/md_super_fix.patch
epatch ${FILESDIR}/${PV}/ntfs_unmkfs.patch
epatch ${FILESDIR}/${PV}/raid5_degrade_fix_v2.patch
epatch ${FILESDIR}/${PV}/raid5_remove_spare_fix.patch
epatch ${FILESDIR}/${PV}/raid5_remove_spare_fix_2.patch
epatch ${FILESDIR}/${PV}/raid5_algorithm.patch
epatch ${FILESDIR}/${PV}/cli_reload_options.patch
epatch ${FILESDIR}/${PV}/cli_query_segfault.patch
epatch ${FILESDIR}/${PV}/get_geometry.patch
epatch ${FILESDIR}/${PV}/BaseName.patch
epatch ${FILESDIR}/${PV}/disk_cache.patch
epatch ${FILESDIR}/${P}-as-needed.patch
epatch ${FILESDIR}/${P}-glib_dep.patch
epatch ${FILESDIR}/${P}-ocfs2.patch
epatch ${FILESDIR}/${P}-use_disk_group.patch
epatch ${FILESDIR}/${P}-pagesize.patch
This would be another good candidate for using epatch's bulk patching,
particularly if you moved the last group of patches into the PV
directory.
dev-zero?
Nope. The stuff in ${PV} are the patches upstream has on their servers, while
the others are mostly Gentoo-specific or something else. So I want them to be
separated.
And I don't see any reason to start renaming now.
Oh, I would've expected upstream patches to be in SRC_URI ...
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Kolab2/Gentoo project
Hi! Kolab (http://www.kolab.org) is an IMAP based groupware server that works with a variety of clients. The server is usually deployed on the OpenPKG distribution which allows to preconfigure the complex combination of postfix, cyrus imap, openldap, amavisd etc. This significantly reduces the effort for the system administrator to get the groupware server up and running. I have been working on integrating this groupware server natively into Gentoo for two years now. The kolab2 overlay provides the native server version since about one and a half years. There is still a lot of work necessary to get the upstream code into shape so that it has the necessary quality to package it in a sane way for portage. I'm working on that. The project has advanced far enough though that I feel it is a good time point to declare this a real Gentoo project. http://www.gentoo.org/proj/en/kolab/index.xml A first target of the project will be the integration of Kolab specific patches into the packages net-libs/c-client, dev-lang/php as well as net-mail/cyrus-imapd. I know there are other developers (and probably many users) interested in the Kolab server project and I'd be glad if people join the effort. Cheers, Gunnar -- Gunnar WrobelGentoo Developer __C_o_n_t_a_c_t__ Mail: [EMAIL PROTECTED] WWW: http://www.gunnarwrobel.de IRC: #gentoo-web at freenode.org _ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New projects (was: Monthly Gentoo Council Reminder...)
On 10/11/07, Torsten Veller [EMAIL PROTECTED] wrote: Last council decided: | Design phase for new projects: New projects need to post an RFC | containing information about their goals, the plan on how to | implement their goals and the necessary resources to -dev prior to | creating the project. | | This proposal was accepted with 6 members voting yes and one member | abstained from voting http://www.gentoo.org/proj/en/council/meeting-logs/20061019-summary.txt GLEP 39 was not updated and still says: | Any dev may create a new project just by creating a new page (or, more | realistically, directory and page) in gentoo/xml/htdocs/proj/en. http://www.gentoo.org/proj/en/glep/glep-0039.html This week two new subdirs were added to proj/en. (One was just added for an existing project.) Can the glepeditors update GLEP 39 to reflect the coucil decision? Maybe a new project should also be announced in -dev-announce (and GWN if they want to). I'll get to that now. -Alec Thanks. -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New projects
Alec Warner wrote: On 10/11/07, Torsten Veller [EMAIL PROTECTED] wrote: Last council decided: | Design phase for new projects: New projects need to post an RFC | containing information about their goals, the plan on how to | implement their goals and the necessary resources to -dev prior to | creating the project. | | This proposal was accepted with 6 members voting yes and one member | abstained from voting http://www.gentoo.org/proj/en/council/meeting-logs/20061019-summary.txt GLEP 39 was not updated and still says: | Any dev may create a new project just by creating a new page (or, more | realistically, directory and page) in gentoo/xml/htdocs/proj/en. http://www.gentoo.org/proj/en/glep/glep-0039.html This week two new subdirs were added to proj/en. (One was just added for an existing project.) Can the glepeditors update GLEP 39 to reflect the coucil decision? Maybe a new project should also be announced in -dev-announce (and GWN if they want to). I'll get to that now. -Alec Shouldn't it really be a new GLEP that replaced the old GLEP 39? Since the way the GLEP system works, i.e. obsoleted by GLEP ## and we typically don't edit them once their out of draft status. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Upcoming masking of dev-lang/php-4* and packages depending on it
On 2007-10-11 at 07:58 +0200, Christian Faulhammer wrote:
Marius Mauch [EMAIL PROTECTED]:
On Sun, 7 Oct 2007 15:13:49 +0200
Christian Hoffmann [EMAIL PROTECTED] wrote:
I'm going to p.mask =dev-lang/php-4* and all packages explicitly
depending on this version of php (i.e. the whole dev-php4/
category (36 packages) and one webapp, www-apps/knowledgetree,
bug 194894 [1]) next weekend (around Oct 14th). This step is
necessary as there is hardly any upstream activity anymore.
You should probably post that in a more user-oriented channel, like
gentoo-announce and/or the forums to reduce the number of
surprised users [1]
Ok, haven't seen the thread, but it's probably a very good idea to
post something to -announce / forums anyway. I'll do that later today.
We'll also move the date of masking to Oct 18th, so that the wider
userbase has one full week time to prepare for the masking as well. :)
Or even write a short summary for the GWN...they would be happy about
it.
I already submitted something on the same day I sent the
-dev{,-announce} mail.
--
Christian Hoffmann
Gentoo PHP herd
signature.asc
Description: PGP signature
Re: [gentoo-dev] integrating solaris overlay into main portage
On Wednesday 10 October 2007, Christian Parpart wrote: How do you feel with that idea? if all you're doing is adding a new KEYWORD to an ebuild, you can just do it ... you dont need permission to go around running `ekeyword` -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Upcoming masking of dev-lang/php-4* and packages depending on it
On 2007-10-10 at 22:44 -0700, Josh Saddler wrote: Since you're doing the masking, can you please help out the GDP by reviewing a few of our documents for any potential changes that must be made? Grepping for php4 shows that there are references in the following docs: The occurences of -D PHP4 in all 4 documents can safely be replaced by -D PHP5, syntactically (assuming the software in question works with php-5 as well, but the ebuilds do not depend on =php-4* explictily, so I guess it's the case here). Additionally: 1. http://www.gentoo.org/doc/en/jffnms.xml sed s:apache2-php4:apache2-php5:g sed s:/usr/share/php4:/usr/share/php5: I'm not sure about the last sentence on the page: You may also run into problems when configuring Apache to work with PHP (specially if you run both PHP4 and PHP5 on the same system). In that case, our Configuring Apache to Work with PHP4 and PHP5 guide may give you some help. Maybe removing it completely would be best? 2. http://www.gentoo.org/doc/en/apache-troubleshooting.xml This is outdated regarding php anyway: $ equery depends www-servers/apache [ Searching for packages depending on www-servers/apache... ] dev-php/phpsysinfo-2.3-r2 dev-php/phpsysinfo-2.1-r2 dev-php/mod_php-4.3.11-r2 ^^ should be dev-lang/php-5.2.4_p20070914-r2 net-www/mod_layout-4.0.1a-r1 www-servers/gorg-0.5 (then rebuild any modules you have installed) # emerge -av '=dev-php/mod_php-4.3.11-r2' ^^ same here, must be '=dev-lang/php-5.2.4_p20070914-r2' (is it really useful to specify full versions here?) '=net-www/mod_layout-4.0.1.a-r1' I know that the PHP documentation itself needs a lot of updates, too, (not only regarding masking of php-4) and I'll try to work on it in the next weeks. -- Christian Hoffmann Gentoo PHP herd signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/ncdu: ChangeLog ncdu-1.3.ebuild
* Robert Buchholz [EMAIL PROTECTED] [2007-10-08 05:53]: On Thursday, 4. October 2007, Josh Sled wrote: Wolfram Schlich [EMAIL PROTECTED] writes: * Donnie Berkholz [EMAIL PROTECTED] [2007-10-03 19:12]: On 12:43 Wed 03 Oct , Wolfram Schlich wrote: And *please*, don't send such mails to this list *and* to my address in addition. You can add a procmail rule to detect duplicates using a cache and checking Message-Id, with formail. Examples of this are all over the place. It's a useful rule to have for many reasons besides this. Yeah, but it's unpredictable *which* one of the two mails makes it first onto my system, thus the one *not* sent to the list might Sigh. It is the same message, addressed To/Cc: you and/or the list, no matter which one is delivered first. So just put all list(+private) filtering before personal filtering. That doesn't work when filtering for List-Id headers which can be nicely used with regex matching like so: [...] Yup, I *only* filter mailing lists by list related headers like List-Id: and others -- filtering list mails by To:/Cc:/Subject: headers is broken by design. My current gentoo-commits reply spamfilter looks like this: --8-- ## Gentoo spam :0 * ^From:[EMAIL PROTECTED] * ^Subject.*\[gentoo-commits\] * ! ^List-Id: /dev/null --8-- -- Regards, Wolfram Schlich [EMAIL PROTECTED] Gentoo Linux * http://dev.gentoo.org/~wschlich/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/evms: ChangeLog evms-2.5.5-r8.ebuild
On Thu, 11 Oct 2007, Tiziano M�ller wrote:
Am Dienstag, 9. Oktober 2007 14.56:24 schrieb Doug Goldstein:
Donnie Berkholz wrote:
On 22:01 Mon 08 Oct , Doug Goldstein (cardoe) wrote:
1.1 sys-fs/evms/evms-2.5.5-r8.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r
8.ebuild?rev=1.1view=markup plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r
8.ebuild?rev=1.1content-type=text/plain
epatch ${FILESDIR}/${PV}/md_super_fix.patch
epatch ${FILESDIR}/${PV}/ntfs_unmkfs.patch
epatch ${FILESDIR}/${PV}/raid5_degrade_fix_v2.patch
epatch ${FILESDIR}/${PV}/raid5_remove_spare_fix.patch
epatch ${FILESDIR}/${PV}/raid5_remove_spare_fix_2.patch
epatch ${FILESDIR}/${PV}/raid5_algorithm.patch
epatch ${FILESDIR}/${PV}/cli_reload_options.patch
epatch ${FILESDIR}/${PV}/cli_query_segfault.patch
epatch ${FILESDIR}/${PV}/get_geometry.patch
epatch ${FILESDIR}/${PV}/BaseName.patch
epatch ${FILESDIR}/${PV}/disk_cache.patch
epatch ${FILESDIR}/${P}-as-needed.patch
epatch ${FILESDIR}/${P}-glib_dep.patch
epatch ${FILESDIR}/${P}-ocfs2.patch
epatch ${FILESDIR}/${P}-use_disk_group.patch
epatch ${FILESDIR}/${P}-pagesize.patch
This would be another good candidate for using epatch's bulk patching,
particularly if you moved the last group of patches into the PV
directory.
dev-zero?
Nope. The stuff in ${PV} are the patches upstream has on their servers, while
the others are mostly Gentoo-specific or something else. So I want them to be
separated.
And I don't see any reason to start renaming now.
Still no good reason not to just call epatch once:
epatch \
list \
of \
patches \
here
Michael Sterrett
-Mr. Bones.-
[EMAIL PROTECTED]
[gentoo-dev] Possible USE=gnome abusing in ebuilds.
Hi, Recently, I've edited or bumped some ebuilds which had USE gnome in them but it was actually doing something entirely different in them, like latest edition of media-libs/raptor had USE gnome pulling in glib which it was using for unicode purposes (so USE unicode was natural choice but only gnome users had it until now) I'm not pointing or blaming anyone but next time you edit an ebuild which is using USE gnome please check what it is actually doing and note that GLIB and GTK+ is NOT gnome Thanks, drac -- [EMAIL PROTECTED] mailing list
[gentoo-dev] new category for texlive modular ebuilds?
Hi, this might be worth discussion also (and make me even more late on my schedule with merging texlive, but I knew I'd be) In my overlay I was using a dev-texlive category for the texlive modular texmf ebuilds [as a side note : dev-texlive $ ls | wc -l 79 ] that was to avoid polluting dev-tex (which would be the current most suitable category for those ebuilds), but well, both categories are fine by me. What do you think about it ? I'd say not polluting it and put them in a new category is better as it doesn't cost anything, but I might have missed something. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Upcoming masking of dev-lang/php-4* and packages depending on it
Christian Hoffmann wrote: On 2007-10-10 at 22:44 -0700, Josh Saddler wrote: Since you're doing the masking, can you please help out the GDP by reviewing a few of our documents for any potential changes that must be made? Grepping for php4 shows that there are references in the following docs: The occurences of -D PHP4 in all 4 documents can safely be replaced by -D PHP5, syntactically (assuming the software in question works with php-5 as well, but the ebuilds do not depend on =php-4* explictily, so I guess it's the case here). Additionally: 1. http://www.gentoo.org/doc/en/jffnms.xml sed s:apache2-php4:apache2-php5:g sed s:/usr/share/php4:/usr/share/php5: I'm not sure about the last sentence on the page: You may also run into problems when configuring Apache to work with PHP (specially if you run both PHP4 and PHP5 on the same system). In that case, our Configuring Apache to Work with PHP4 and PHP5 guide may give you some help. Maybe removing it completely would be best? 2. http://www.gentoo.org/doc/en/apache-troubleshooting.xml This is outdated regarding php anyway: $ equery depends www-servers/apache [ Searching for packages depending on www-servers/apache... ] dev-php/phpsysinfo-2.3-r2 dev-php/phpsysinfo-2.1-r2 dev-php/mod_php-4.3.11-r2 ^^ should be dev-lang/php-5.2.4_p20070914-r2 net-www/mod_layout-4.0.1a-r1 www-servers/gorg-0.5 (then rebuild any modules you have installed) # emerge -av '=dev-php/mod_php-4.3.11-r2' ^^ same here, must be '=dev-lang/php-5.2.4_p20070914-r2' (is it really useful to specify full versions here?) '=net-www/mod_layout-4.0.1.a-r1' I know that the PHP documentation itself needs a lot of updates, too, (not only regarding masking of php-4) and I'll try to work on it in the next weeks. Thanks for the fixes; I'll get busy committing them. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Upcoming masking of dev-lang/php-4* and packages depending on it
Josh Saddler wrote: Christian Hoffmann wrote: On 2007-10-10 at 22:44 -0700, Josh Saddler wrote: Since you're doing the masking, can you please help out the GDP by reviewing a few of our documents for any potential changes that must be made? Grepping for php4 shows that there are references in the following docs: The occurences of -D PHP4 in all 4 documents can safely be replaced by -D PHP5, syntactically (assuming the software in question works with php-5 as well, but the ebuilds do not depend on =php-4* explictily, so I guess it's the case here). Additionally: 1. http://www.gentoo.org/doc/en/jffnms.xml sed s:apache2-php4:apache2-php5:g sed s:/usr/share/php4:/usr/share/php5: I'm not sure about the last sentence on the page: You may also run into problems when configuring Apache to work with PHP (specially if you run both PHP4 and PHP5 on the same system). In that case, our Configuring Apache to Work with PHP4 and PHP5 guide may give you some help. Maybe removing it completely would be best? 2. http://www.gentoo.org/doc/en/apache-troubleshooting.xml This is outdated regarding php anyway: $ equery depends www-servers/apache [ Searching for packages depending on www-servers/apache... ] dev-php/phpsysinfo-2.3-r2 dev-php/phpsysinfo-2.1-r2 dev-php/mod_php-4.3.11-r2 ^^ should be dev-lang/php-5.2.4_p20070914-r2 net-www/mod_layout-4.0.1a-r1 www-servers/gorg-0.5 (then rebuild any modules you have installed) # emerge -av '=dev-php/mod_php-4.3.11-r2' ^^ same here, must be '=dev-lang/php-5.2.4_p20070914-r2' (is it really useful to specify full versions here?) '=net-www/mod_layout-4.0.1.a-r1' I know that the PHP documentation itself needs a lot of updates, too, (not only regarding masking of php-4) and I'll try to work on it in the next weeks. Thanks for the fixes; I'll get busy committing them. . . . fixed in CVS! signature.asc Description: OpenPGP digital signature
[gentoo-dev] Council meeting summary for 11 October 2007
Hi all, Here is the summary from today's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. Thanks, Donnie Summary of 11 October 2007 council meeting Present: all members, josejx proxying for lu_zero = What are not clear are (1) whether the Code of Conduct is in effect; (2) if so, how we enforce it. - The CoC is in effect, but it needs a new enforcement section since the proctors were disbanded. The council is sending discussion of this to the gentoo-project list, to come up with proposals for three points: - who enforces it - musikc said devrel could - tsunam said userrel could - how to enforce it - whether it's active or passive enforcement - which actions are appropriate - If the -project list does not come up with a draft, dberkholz will write one based on -project discussion to vote upon at the November council meeting. = packages.gentoo.org: https://bugs.gentoo.org/show_bug.cgi?id=187971 comment #86 from marduk on rewrite comment #90 re jokey's rewrite (comment #85) - The infrastructure team will decide the future of packages.gentoo.org. - KingTaco informed us that the current code will probably not return. Alternatives include: - http://packages.gentooext.net/ (written by jokey) - http://spaceparanoids.org/gentoo/gpnl/ (written by beandog) - http://gentoo-portage.com/ - Until we get a replacement, packages.gentoo.org will link to alternatives. It now links to a forums thread describing them. = GLEP 39: project RFC addition - We will amend the GLEP rather than writing a new one, and a note will be added saying the GLEP was amended. = When does the new council term end? - Voting will always take place the same month, as mentioned in http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52143 - If the new council is delayed, it gets a slightly shortened term. = Open floor - Where is the PMS repo? - robbat2 has imported it. It's in git. Need to ping him for details. - The channel was not moderated during the meeting and it went well. Let's try that again next time.
Re: [gentoo-dev] New projects
Glep 54 now replaces (and depends on) glep 39. Like the commit message says, the spirit of the glep was approved long ago, if you have issues with wording please to be taking it up with me so we can make it pretty (particularly the backwards compatibility section) -Love antarus On 10/11/07, Alec Warner [EMAIL PROTECTED] wrote: On 10/11/07, Doug Goldstein [EMAIL PROTECTED] wrote: Alec Warner wrote: On 10/11/07, Torsten Veller [EMAIL PROTECTED] wrote: Last council decided: | Design phase for new projects: New projects need to post an RFC | containing information about their goals, the plan on how to | implement their goals and the necessary resources to -dev prior to | creating the project. | | This proposal was accepted with 6 members voting yes and one member | abstained from voting http://www.gentoo.org/proj/en/council/meeting-logs/20061019-summary.txt GLEP 39 was not updated and still says: | Any dev may create a new project just by creating a new page (or, more | realistically, directory and page) in gentoo/xml/htdocs/proj/en. http://www.gentoo.org/proj/en/glep/glep-0039.html This week two new subdirs were added to proj/en. (One was just added for an existing project.) Can the glepeditors update GLEP 39 to reflect the coucil decision? Maybe a new project should also be announced in -dev-announce (and GWN if they want to). I'll get to that now. -Alec Shouldn't it really be a new GLEP that replaced the old GLEP 39? Since the way the GLEP system works, i.e. obsoleted by GLEP ## and we typically don't edit them once their out of draft status. Details details -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New projects
Alec Warner wrote: Glep 54 now replaces (and depends on) glep 39. Like the commit message says, the spirit of the glep was approved long ago, if you have issues with wording please to be taking it up with me so we can make it pretty (particularly the backwards compatibility section) -Love antarus you mention using Outlook in another thread and then you top post. What e-mail infraction will you commit next? Writing e-mails in all caps? Sending e-mails with blank subject lines? -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Possible USE=gnome abusing in ebuilds.
Samuli Suominen wrote: Hi, Recently, I've edited or bumped some ebuilds which had USE gnome in them but it was actually doing something entirely different in them, like latest edition of media-libs/raptor had USE gnome pulling in glib which it was using for unicode purposes (so USE unicode was natural choice but only gnome users had it until now) I'm not pointing or blaming anyone but next time you edit an ebuild which is using USE gnome please check what it is actually doing and note that GLIB and GTK+ is NOT gnome Thanks, drac Kinda like the GNOME herd does themselves? I've pointed this one out a few times just cause it annoys me... gnome-mount has USE=gnome... well... DUH! it's a gnome-volume-manager specific and GNOME Desktop specific wrapper for HAL based mounting. Obviously it's used by GNOME and only does and can function within a GNOME Destkop environment. But what does this USE flag mean? Oh, it simply means you want to build the Nautilus extension! Do we already have a USE=nautilus? Yes, yes we do. It's a local USE flag used in 3 packages, 2 of those 3 are GNOME herd packages. Either way, the Gentopia copies of gnome-mount continue to use a nautilus USE flag. Maybe someday, the light will shine. Since body language and tone do 90% of speaking and words only do 10%, I would like to just point out that the sarcasm of this e-mail is intentional but not meant to be insulting. It's merely a point highlighting the fact that a non-GNOME herd member made a request that the GNOME herd should make and the herd should stick to. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] new category for texlive modular ebuilds?
Alexis Ballier [EMAIL PROTECTED] wrote: Hi, this might be worth discussion also (and make me even more late on my schedule with merging texlive, but I knew I'd be) In my overlay I was using a dev-texlive category for the texlive modular texmf ebuilds [as a side note : dev-texlive $ ls | wc -l 79 ] that was to avoid polluting dev-tex (which would be the current most suitable category for those ebuilds), but well, both categories are fine by me. What do you think about it ? I'd say not polluting it and put them in a new category is better as it doesn't cost anything, but I might have missed something. I would have expected app-text, the current home of the other TeX interpreters, to be more appropriate than dev-tex. Then again, with 79 new ebuilds, it might be prudent to open another category. If you did that, though, I'd suggest putting texlive and the other TeX interpreters in the same category. Perhaps app-tex would be good. Would that cause much confusion, being one letter off from an existing category? On the other hand (or is this back on the first hand?), 79 new packages wouldn't be much of a splash in the 231 existing packages of app-text. -- The only time I use xp is when I need to swap a pair of letters. pgp6qfk2jmIHn.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/baselayout: ChangeLog baselayout-2.0.0_rc5.ebuild
On 15:56 Thu 11 Oct , Roy Marples (uberlord) wrote:
1.1 sys-apps/baselayout/baselayout-2.0.0_rc5.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/baselayout/baselayout-2.0.0_rc5.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/baselayout/baselayout-2.0.0_rc5.ebuild?rev=1.1content-type=text/plain
cp -p ${ROOT}usr/share/baselayout/${x} ${ROOT}etc
Two ROOT's to quote here, not just one. =)
# We need to copy svcdir if upgrading
if has_version sys-apps/${PN}-1.13.0_alpha ; then
(
. ${ROOT}etc/conf.d/rc
svcdir=${svcdir:-/var/lib/init.d}
einfo Moving state from ${ROOT}${svcdir} to
${ROOT}lib/rcscripts/init.d
cp -RPp ${ROOT}${svcdir}/* ${ROOT}lib/rcscripts/init.d
rm -rf ${ROOT}lib/rcscripts/init.d/daemons \
${ROOT}lib/rcscripts/init.d/console
umount ${ROOT}${svcdir} 2/dev/null
rm -rf ${ROOT}${svcdir}
)
Can this be done in a code block instead, or do svdir and /etc/conf.d/rc
sourcing pollute things too badly?
if has_version sys-apps/${PN}-1.13.0_alpha ; then
(
. ${ROOT}etc/conf.d/rc
svcdir=${svcdir:-/var/lib/init.d}
einfo Moving state from ${ROOT}lib/rcscripts/init.d to
${ROOT}${svcdir}
mkdir -p ${ROOT}${svcdir}
cp -RPp ${ROOT}lib/rcscripts/init.d/* ${ROOT}${svcdir}
rm -rf ${ROOT}${svcdir}/daemons
umount ${ROOT}lib/rcscripts/init.d 2/dev/null
rm -rf ${ROOT}lib/rcscripts/init.d
)
Same question. Also, could this code, as well as the other cases I
cropped out, simply be abstracted into a function instead?
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
