[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
Hi,
Torsten Veller ml...@veller.net:
find ${S} -type f -name ._* -print0 | while read -rd ''
f ; do einfo Removing AppleDouble encoded Macintosh file: ${f#${S}/}
rm -f ${f}
f=${f#${S}/}
# f=${f//\//\/}
# f=${f//\./\.}
# sed -i /${f}/d ${S}/MANIFEST || die
grep -q ${f} ${S}/MANIFEST \
elog AppleDouble encoded Macintosh file in
MANIFEST: ${f#${S}/} done
}
Are those f= lines commented? And what was their purpose? Can they
be deleted?
if [[ -d ${D}/${VENDOR_LIB} ]] ; then
Haven't checked, but quotes not needed?
V-Li
--
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://gentoo.faulhammer.org/
signature.asc
Description: PGP signature
[gentoo-dev] Re: Unification of variables used within SCM eclasses
Hi,
sorry for the late reply.
Michał Górny gen...@mgorny.alt.pl:
a) Common variables - the variables which would have to be used by
various SCM eclasses as default/fallback values.
1. ESCM_DISTDIR (defaulting to PORTAGE_ACTUAL_DISTDIR/PORTDIR)
- an alternate parent dir to all SCM stores. It would be useful
if user would like to use an small file-inefficient filesystem
for main DISTDIR or rsync it with other machine (where SCM
files are not as important as the tarballs are).
Sounds reasonable, though mostly a nice-have.
2. ESCM_OFFLINE (most eclasses use it already)
- a common switch to easily switch off all network interaction.
Crucial, at least for me. :)
3. ESCM_LIVE_FAIL_IF_REPO_NOT_UPDATED (similar to the one in
git.eclass)
- a common switch to force unpack() phase to fail if no updates
were found during the pull/update.
Something better named would be great...it looks just stupid in
make.conf.
b) Common eclass-specific variables - these ones should allow user to
override above variables for single SCM.
1. E*_STORE_DIR (defaulting to ${ESCM_DISTDIR}/*-src)
- already used by few eclasses, allowing user to change
the location where SCM-specific clones are stored.
2. E*_OFFLINE (defaulting to ${ESCM_OFFLINE})
- allowing user to override global 'offline switch'. Thus, it
should also support setting 'false' value to enable network
interaction for single SCM.
3. E*_LIVE_FAIL_...
- another override for the global one.
Ok with those.
4. E*_REPO_URI
- the URI to the main repository. It might be extended to support
multiple URIs.
5. E*_REVISION
- explicit expected-revision/tag specification, preferably along
with implicit one (e.g. in ESVN_REPO_URI) deprecation.
This would allow applications to easily distinguish
between 'real' live ebuilds and snapshot ones fetching
directly from the repo.
Those are not really user settings, but defined by the using ebuild.
c) Common export variables - these ones should be exported by SCM
eclass and stored in environment.bz2 after successful emerge.
1. E*_VERSION (or _REVISION, or ...)
- the version/revision to which the package was updated. This
would be useful to determine whether the current repo is newer
than one used when merging package.
2. E*_WC_PATH
- the absolute path to the last-used clone dir (i.e.
${E*_STORE_DIR}/sth) and thus the most probable location
to perform further updates in.
Portage team should comment here, maybe. What is the use case for
this, honestly?
d) Other:
1. ESCM_CUSTOM_FETCH
- this one is not directly related to eclasses but for use of
ebuild authors. Setting this in an ebuild should notice applications
that the ebuild does use custom fetching procedures
(i.e. fetches from multiple repositories in a manner
unsupported directly by the eclass) and thus external
applications should not try to update the repository
themselves.
Use case?
V-Li
--
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://gentoo.faulhammer.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Should we disable RESOLVED LATER from bugzilla?
On 04/12/2010 02:20 AM, Ryan Hill wrote: On Thu, 8 Apr 2010 00:13:41 +0200 Christian Faulhammer fa...@gentoo.org wrote: Petteri Räty betelge...@gentoo.org: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 Not applicable to the bug above but in general our social contract says: We will not hide problems Kill REMIND and LATER, introduce Later keyword or ASSIGNED LATER. Me too.© What happens to bugs already in that state though? I would imagine they could be kept in the db as it is but just remove the options from the UI. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
On 12-04-2010 10:07:54 +0200, Christian Faulhammer wrote:
if [[ -d ${D}/${VENDOR_LIB} ]] ; then
Haven't checked, but quotes not needed?
it's within [[ ]], so no.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Who is willing to be lead?
On 2010.04.10 15:00, Markos Chandras wrote: On Saturday 10 April 2010 16:53:48 Petteri Räty wrote: As people seem to want the council to take action I offer to take action. As it's impossible for me to do everything myself I offer to act as a project manager/owner for people willing to donate their time to whatever I see worthy for Gentoo as whole like the web page redesign. Basically you tell me how many hours you have and I'll give you stuff to work on. It might not be glorious at times like cleaning up a piece of documentation but why not spend an hour a week on something that benefits the project? If people are interested, I'll work out the details. Regards, Petteri That's not a good reaction from your side. Independent projects can handle the incoming manpower themselves. [snip] -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org There are two valuable non conflicting ideas here. The second one is more obvious, so I'll address that first an show how it fits with the other. Independent projects Gentoo is an assemblage of independent projects all pretty much doing their own thing ... the council exists to handle global issues [glep39] This implies that the council works on things brought to its attention, further its purpose is not to 'lead' (whatever that might mean), rather its the glue that holds the independent projects together when they can't resolve things for themselves. The problem with this structure is that the independent projects have gaps/overlaps between them. Overlaps normally indicate wasted effort, gaps indicate something missing that does not fit into the existing projects (at least, as far as the projects are concerned). The result is that the gaps are not addressed. Petteri, writes I offer to take action. That's an offer from an individual Gentoo developer, not on behalf of the council. It doesn't matter how Petteri came to form his view that a lot of small tasks can make Gentoo better for being organised. It need not encroach on the independent projects at all. Gentoo has got to the social complexity now that it needs some middle management. The council is not permitted to provide that and Petteri has offered to try. Its really no different to putting up a project page and starting a new project. This could be a new way to get non-devs involved too. Give them a small well defined package of work to contribute ... I see it in a positive light but I don't think I can offer any time at the moment. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgpOkzLNCHxOU.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 2010.04.09 07:34, Duncan wrote: Patrick Nagel posted on Fri, 09 Apr 2010 10:42:40 +0800 as excerpted: [snip] Likewise, Gentoo's uncomfortable officially linking to something they don't control in any way, shape, or form (except to the extent that we could arguably pull his domain name for trademark reasons, if things got ugly enough, tho that'd be incredibly bad for EVERYONE, so nobody wants to go there!). [snip] -- 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 Last time I looked, his about page complies with our trade mark requirements. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgp3GJ2VlskqB.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12 April 2010 12:28, Roy Bamford neddyseag...@gentoo.org wrote: Last time I looked, his about page complies with our trade mark requirements. But ONLY his about page. Our name and logo guidelines state this needs to happen on each page: the website clearly states, on each page, that the project is no official Gentoo project by labelling itself as a news site, fan site, unofficial site or community site See http://www.gentoo.org/main/en/name-logo.xml Instead it labels itself as the Gentoo Wiki or the Gentoo Linux Wiki, suggesting to somebody who is unaware of the situation that it is an official project. -- Ben de Groot Gentoo Qt project lead developer Gentoo Wiki project lead
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12/04/2010 12:32, Ben de Groot wrote: On 12 April 2010 12:28, Roy Bamfordneddyseag...@gentoo.org wrote: Last time I looked, his about page complies with our trade mark requirements. But ONLY his about page. Our name and logo guidelines state this needs to happen on each page: the website clearly states, on each page, that the project is no official Gentoo project by labelling itself as a news site, fan site, unofficial site or community site See http://www.gentoo.org/main/en/name-logo.xml Instead it labels itself as the Gentoo Wiki or the Gentoo Linux Wiki, suggesting to somebody who is unaware of the situation that it is an official project. If you are arguing that the name is ambiguous then I think you are wrong. Gentoo knows about the unofficial wiki and knows it's mission is to help Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like litigation when trying to protect it's logo.
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12 April 2010 18:43, George Prowse george.pro...@gmail.com wrote: [...] If you are arguing that the name is ambiguous then I think you are wrong. Gentoo knows about the unofficial wiki and knows it's mission is to help Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like litigation when trying to protect it's logo. I think the argument is that the wiki is not always accurate, and if perceived as the official documentation, can put is in bad light. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12/04/2010 14:17, Arun Raghavan wrote: On 12 April 2010 18:43, George Prowsegeorge.pro...@gmail.com wrote: [...] If you are arguing that the name is ambiguous then I think you are wrong. Gentoo knows about the unofficial wiki and knows it's mission is to help Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like litigation when trying to protect it's logo. I think the argument is that the wiki is not always accurate, and if perceived as the official documentation, can put is in bad light. There is *always* a chance of that, official or otherwise
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12 April 2010 18:49, George Prowse george.pro...@gmail.com wrote: On 12/04/2010 14:17, Arun Raghavan wrote: On 12 April 2010 18:43, George Prowsegeorge.pro...@gmail.com wrote: [...] If you are arguing that the name is ambiguous then I think you are wrong. Gentoo knows about the unofficial wiki and knows it's mission is to help Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like litigation when trying to protect it's logo. I think the argument is that the wiki is not always accurate, and if perceived as the official documentation, can put is in bad light. There is *always* a chance of that, official or otherwise Which the Wiki team should really be addressing before making a world-editable wiki. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12/04/2010 14:22, Arun Raghavan wrote: On 12 April 2010 18:49, George Prowsegeorge.pro...@gmail.com wrote: On 12/04/2010 14:17, Arun Raghavan wrote: On 12 April 2010 18:43, George Prowsegeorge.pro...@gmail.comwrote: [...] If you are arguing that the name is ambiguous then I think you are wrong. Gentoo knows about the unofficial wiki and knows it's mission is to help Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like litigation when trying to protect it's logo. I think the argument is that the wiki is not always accurate, and if perceived as the official documentation, can put is in bad light. There is *always* a chance of that, official or otherwise Which the Wiki team should really be addressing before making a world-editable wiki. A simple warning should suffice: While the Gentoo community takes a large amount of care to keep the wiki's information correct, problems like deprecation of features, misinformed users and vandalism can and will always be a problem with the wiki format. If you see a problem please feel free to fix it, notify a member of the developer team or send an email to w...@gentoo.org Also adding a notice like Gentoo takes no responsibility for when you b0rk your box by setting the wrong CTARGET somewhere would be good. Those two should cover all the bases.
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 12 April 2010 15:22, Arun Raghavan ford_pref...@gentoo.org wrote: On 12 April 2010 18:49, George Prowse george.pro...@gmail.com wrote: On 12/04/2010 14:17, Arun Raghavan wrote: On 12 April 2010 18:43, George Prowsegeorge.pro...@gmail.com wrote: [...] If you are arguing that the name is ambiguous then I think you are wrong. Gentoo knows about the unofficial wiki and knows it's mission is to help Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like litigation when trying to protect it's logo. I think the argument is that the wiki is not always accurate, and if perceived as the official documentation, can put is in bad light. There is *always* a chance of that, official or otherwise Which the Wiki team should really be addressing before making a world-editable wiki. If you're talking about the offical wiki, we are addressing that problem. If you are talking about the unofficial one, I can only agree. Cheers, -- Ben de Groot Gentoo Qt project lead developer Gentoo Wiki project lead
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
Ben de Groot wrote: On 12 April 2010 15:22, Arun Raghavanford_pref...@gentoo.org wrote: On 12 April 2010 18:49, George Prowsegeorge.pro...@gmail.com wrote: On 12/04/2010 14:17, Arun Raghavan wrote: On 12 April 2010 18:43, George Prowsegeorge.pro...@gmail.comwrote: [...] If you are arguing that the name is ambiguous then I think you are wrong. Gentoo knows about the unofficial wiki and knows it's mission is to help Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like litigation when trying to protect it's logo. I think the argument is that the wiki is not always accurate, and if perceived as the official documentation, can put is in bad light. There is *always* a chance of that, official or otherwise Which the Wiki team should really be addressing before making a world-editable wiki. If you're talking about the offical wiki, we are addressing that problem. If you are talking about the unofficial one, I can only agree. Cheers, Just to add two cents worth. I rarely, very rarely, go to the unofficial Gentoo wiki. To put it simply, its not supported by the Gentoo organization itself. When it comes to my system, I want people that I know use Gentoo and understand how it works or that the info is from the official Gentoo Docs. I may be able to contribute to the official Gentoo wiki when the need arises but I doubt I would ever do that on the current unofficial wiki. Just my two cents worth for the day. Back to my hole. Dale :-) :-)
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
ZM == Zac Medico zmed...@gentoo.org writes: ZM On 04/06/2010 07:22 AM, James Cloos wrote: ZM == Zac Medico zmed...@gentoo.org writes: ZM You can configure eclass override behavior via eclass-overrides in ZM /etc/portage/repos.conf, as documented in `man portage`. , From that manpage | When using eclass-overrides, due to bug #276264, you must ensure that | your portage tree does not contain a metadata/cache/ directory. ` Which translates into eclass-orderrides are completely and entirely useless, so don't bother. ZM Well, it's roughly equivalent to the old default behavior (which you ZM apparently preferred). However, the issue is now complicated by the ZM fact that FEATURES=metadata-transfer is disabled by default, so when ZM portage goes to pull cache directly from metadata/cache/, it won't ZM be able to validate eclass changes since there are no eclass ZM timestamps saved inside metadata/cache/. Portage does not need to validate eclass changes. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
A reasonable alternative would be to have a separate variable in make.conf, such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for eclasses. In most cases, users would probably only have their own, local overlay there, and any eclasses found there should be used in preference to any in portage or in the overlay the ebuild came from, if applicable. Every time portage looks for an eclass, it should check there first (caching what it found, to save future lookups w/in that run) and just use anything it finds. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: [RFC] Gentoo Wiki Project
George Prowse posted on Mon, 12 Apr 2010 14:13:31 +0100 as excerpted: If you are arguing that the name is ambiguous then I think you are wrong. Gentoo knows about the unofficial wiki and knows it's mission is to help Gentoo and not to hinder it. Gentoo hardly makes a habit of Apple-like litigation when trying to protect it's logo. ... Which was basically my point, up-thread. Gentoo has trademarks and etc, and if it decided to go Apple (or nuclear, the term I'd have used) on the unofficial wiki (among other sites), it could. But that'd be a very bad situation for everyone involved, not just for the wiki, but for Gentoo as well. Other than that, Gentoo doesn't control the independent and unofficial gentoo-wiki, and thus doesn't feel comfortable linking to it. Quite reasonable, I think. Actually, this whole sub-thread about whether they're abiding by the current policy or not, then, wasn't my intent, and was in fact entirely unexpected. -- 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] perl eclass review - EAPI=3 + new helper eclass
On Mon, Apr 12, 2010 at 01:30:21PM -0400, James Cloos wrote: A reasonable alternative would be to have a separate variable in make.conf, such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for eclasses. In most cases, users would probably only have their own, local overlay there, and any eclasses found there should be used in preference to any in portage or in the overlay the ebuild came from, if applicable. Every time portage looks for an eclass, it should check there first (caching what it found, to save future lookups w/in that run) and just use anything it finds. repos.conf has functionality of this sort, although you'll have to consult the man page for the exact option name... ~brian pgp1GRm7vuWL5.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Gentoo Wiki Project
Dale posted on Mon, 12 Apr 2010 11:47:50 -0500 as excerpted: Just to add two cents worth. I rarely, very rarely, go to the unofficial Gentoo wiki. To put it simply, its not supported by the Gentoo organization itself. When it comes to my system, I want people that I know use Gentoo and understand how it works or that the info is from the official Gentoo Docs. I may be able to contribute to the official Gentoo wiki when the need arises but I doubt I would ever do that on the current unofficial wiki. Just my two cents worth for the day. Back to my hole. Really, the same here, altho I appreciated them when I got my netbook, and wanted to put Gentoo on it. Unfortunately, that's about the time the site did its disappearing act, and most of the information I could Google, etc, pointed back to the wiki that wasn't there any more! =:^( But the Arch-Linux forum thread and then wiki came to the rescue, tho I had to adapt some of what it said a bit more. And the gentoo-wiki page is back up, now, tho I'm not sure how it compares to what was there before the off-lining. But I'm more a newsgroups and mailing list person, not so comfortable with web forums or wikis. Perhaps that'll change with an official Gentoo wiki, perhaps not, but that's why I've not volunteered for it tho I support the idea. I don't want to pledge to help and then never get the properly rounded tuit. Better to discover that tuit by accident, and be there, then pledge to be there, and not. But I did REALLY miss them with the netbook info, that's for sure, and I definitely appreciate both the Gentoo wiki (after its return) and the Arch wiki for the info I was able to use, even more since it wasn't available for awhile! -- 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] perl eclass review - EAPI=3 + new helper eclass
On 04/12/2010 10:17 AM, James Cloos wrote: ZM == Zac Medico zmed...@gentoo.org writes: ZM On 04/06/2010 07:22 AM, James Cloos wrote: ZM == Zac Medico zmed...@gentoo.org writes: ZM You can configure eclass override behavior via eclass-overrides in ZM /etc/portage/repos.conf, as documented in `man portage`. , From that manpage | When using eclass-overrides, due to bug #276264, you must ensure that | your portage tree does not contain a metadata/cache/ directory. ` Which translates into eclass-orderrides are completely and entirely useless, so don't bother. ZM Well, it's roughly equivalent to the old default behavior (which you ZM apparently preferred). However, the issue is now complicated by the ZM fact that FEATURES=metadata-transfer is disabled by default, so when ZM portage goes to pull cache directly from metadata/cache/, it won't ZM be able to validate eclass changes since there are no eclass ZM timestamps saved inside metadata/cache/. Portage does not need to validate eclass changes. Then how do you propose that it handles metadata changes that are attributed to eclass changes? For example, see the issue they had with vmware.eclass changes in this bug: http://bugs.gentoo.org/show_bug.cgi?id=139134 -- Thanks, Zac
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On 04/12/2010 11:00 AM, Brian Harring wrote: On Mon, Apr 12, 2010 at 01:30:21PM -0400, James Cloos wrote: A reasonable alternative would be to have a separate variable in make.conf, such as ECLASS_OVERLAY_DIRS, which specifies acceptable overlays for eclasses. In most cases, users would probably only have their own, local overlay there, and any eclasses found there should be used in preference to any in portage or in the overlay the ebuild came from, if applicable. Every time portage looks for an eclass, it should check there first (caching what it found, to save future lookups w/in that run) and just use anything it finds. repos.conf has functionality of this sort, although you'll have to consult the man page for the exact option name... It's called eclass-overrides and it's been mentioned earlier in the thread. -- Thanks, Zac
