Re: [gentoo-dev] Projects and simple guides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | Donnie Berkholz wrote: | |Lance Albertson wrote: || What if instead of having proj/en we did herd/en on www? Of course, that || doesn't help the whole GuideXML is hard bit. I like the idea of using || RST, but it doesn't seem very scalable at this time. Maybe, instead of || that, we created some kind of development site for herds (maybe || herds.g.o). Could be a place where herds put up status updates, specific || docs, draft docs, etc. Once things get established on that site, docs || could get moved to GDP if it were logical to do. | |Really every herd should be either part of a project or in the process |of creating a new one for themselves by now. There's no excuse, since |the block on creating new projects disappeared. | | | The question I ask is ... does every herd have a project it fits under? | I doubt it. And if it doesn't, is it really considered a project? Or is | that just a generic name given now? I guess a see a distinction between | herds and projects that our current documentation url layout doesn't | cover it well. To me, it should have its own herd/fooherd layout | (example being www.gentoo.org/herd/en/netmon). Otherwise you're going to | confuse our users into thinking that herds are projects when they're | really just herds. Granted, some herds may be just a project, but I'm | mainly after the herds that have no real project to fit under. | | I understand the block was lifted for projects, but that doesn't mean | herds should all should fit underneath proj/. I agree. What I meant is that herds should be grouping together to form new projects if they don't fit in an existing one; not that they should create one project per herd. | I think we should open up | a similar space just for herds. I disagree -- they should all be able to fit into some project. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDw2znXVaO67S1rtsRAo7hAKC2yYmsZdDV0AUxf8H8ucXdI4GH8wCgzrIm itfdvfs5OSPLiEj13RmMxzs= =BdR+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Projects and simple guides
Brian Harring posted [EMAIL PROTECTED], excerpted below, on Mon, 09 Jan 2006 09:29:15 -0800: Where exactly did I ask for universal r/w? I've seen a lot of args against this based upon joe idiot will screw up the page. What I'm after is non gentoo personnel capable of handling the docs- does that mean everyone? No. It means people not minting people just so we can have them do a bit of doc work, essentially, nuking the overhead. Simply screwing the page may happen, but it's not the worst problem these days. Link-spamming gets that dubious honor, I believe. If it's visible to Google, and it's possible to subvert access control to get access, you're simply /begging/ for uncontrollable link spamming. However non-gentoo personnel is to be interpreted, this IMO has to be considered, as it has certainly ruined many other projects, and forced capcha implementation on others. Of course, I'm sure infra is already on it, but if we fail to account for it in discussing the idea, the solution chosen might not be the best one possible. BTW, if I'm not mistaken, it's exactly this sort of half-dev issue that the AT position was to be a solution to. The issues are much the same, and to a large degree have already been hashed out or failing that, at least discussed. Perhaps the amd64 folks and/or hparker could comment. +1 on the RST idea as well, for what a user vote may be worth. Ciaran has made excellent use of it with his GLEP work. For what my opinion's worth, there's no other person who could steer a complicated and therefore implementation controversial GLEP such as that thru the process better than he. In all aspects he has done a better job than I would have thought possible, literally, had I not seen him doing it. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
Donnie Berkholz wrote: Sven Vermeulen wrote: | We have already received many bugs for documentation in /proj/* which is | not GDPs. I had no issue with this as I hoped this would be a transient | state where the documentation is eventually handed over to the GDP so that | both the project /and/ GDP can further maintain the documents. Seems like what would be useful is a metadata.xml-type thing for guides, so they're assigned properly. That's only a Bugzilla issue. When user finds a bug somewhere under /proj/en, the natural way is to consider it an issue in documentation for users, hence it got assigned to docs-team. There's already a bug opened [1] waiting for the final decision. [1] https://bugs.gentoo.org/show_bug.cgi?id=115924 Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout 1.12 and runlevel changes Was: init scripts and custom signals
On Tuesday 10 January 2006 08:19, Duncan wrote: Roy Marples posted [EMAIL PROTECTED], excerpted below, on Mon, 09 Jan 2006 12:32:32 +: baelayout-1.12 is a bit more strict about things. If you ask something to --stop it stops regardless. Creating a new subthread on a slightly different subtopic, tho still initscripts/baselayout. I've noticed that with baselayout-1.12 (not sure on 1.12 as I didn't notice it, tho that might mean it's new behavior), changing runlevels stops, then restarts, services that are in both runlevels. At least RH style initscripts simply keep running services that exist in both the old and new runlevels, as they aren't in the kill-list, only the start-list. Is it intended behavior on Gentoo to force them to stop, only to restart them on the new runlevel, when they exist in both? Nope, that's an error. I think I have a patch that addresses that. I've also noticed that there is a lot of stuff in runscript.sh that doesn't need to be there anymore as rc now handles more of the ordering and dependency. Leaving runscript.sh with just what it needs means it's a whole load lighter :) -- Roy Marples [EMAIL PROTECTED] Gentoo Linux Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
On Tue, 2006-01-10 at 01:17 -0600, Lance Albertson wrote: I understand the block was lifted for projects, but that doesn't mean herds should all should fit underneath proj/. I think we should open up a similar space just for herds. I think that would be a wonderful idea. What would we do about herds that are a project? Simply throw in a redirect under the herd name to the project name? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Projects and simple guides
Chris Gianelloni said: Really, I think that the number of bugs the GDP gets is probably fairly minimal for project-based documentation. Perhaps we could have something added to the project dtd that adds a little blurb at the bottom to file bugs for project documentation against the project itself? I really don't know if that would help or not, but it is an idea. The amount of bugs isn't the problem, but it does serve as a warning event to show the user how fragmented a project goal can be. In this case, not even all documentation is handled by the documentation team. Wkr, Sven Vermeulen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
Chris Gianelloni wrote: On Tue, 2006-01-10 at 01:17 -0600, Lance Albertson wrote: I understand the block was lifted for projects, but that doesn't mean herds should all should fit underneath proj/. I think we should open up a similar space just for herds. I think that would be a wonderful idea. What would we do about herds that are a project? Simply throw in a redirect under the herd name to the project name? Unless they already reside inside the /proj level, I don't want to get into the habit of managing a bunch of redirects. The key thing here is that we have a clear place to look for such herds. If they are a project, then keep them in the project area. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A New Linux Way
On Tue, 2006-01-10 at 07:49 -0500, Chris Gianelloni wrote: On Tue, 2006-01-10 at 03:40 +, Mark Stewart wrote: Please contact me if you are interested. I am interested in hearing more. Stupid Reply-To munging... Anyway, I'll let you guys know if there's anything actually worth hearing from this guy. I tend to take the approach of at least contacting someone that puts up this kind of offer before immediately dismissing them. After all, it could be a good way to get money for the Foundation (bounties, or some such). -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: baselayout 1.12 and runlevel changes Was: init scripts and custom signals
On Tuesday 10 January 2006 17:11, Duncan wrote: So that means don't bother filing a bug, then, as you are already working on it? The fix is already comitted to our svn repo. File a bug if it still doesn't work when baselayout-1.12.0_pre14 hits portage. Thanks -- Roy Marples [EMAIL PROTECTED] Gentoo Linux Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
Grant Goodyear wrote: [Tue Jan 10 2006, 11:09:15AM EST] As an aside, it's ciarnanm has already put work in on developing an RST to guidexml converter, so I wouldn't worry too much about RST not scaling. Could that be used dynamically on the server? The last time I was familiar with the gentoo.org server, it was running axkit and dynamically generating HTML from the GuideXML. Is it a relatively simple matter to support .rst files in the same manner? A related question: How hard would it be to enable the dynamic generation for dev.gentoo.org/~users? That would make development of RST or GuideXML documents *much* simpler, since we could just work on the file in our public_html and test render it by accessing through a web browser. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpF7KHOmWDtC.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Hi Donnie, On 1/10/06, Donnie Berkholz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I don't want to get into the habit of inconsistency and finding herds in | two different locations. To clarify, add an either onto the end of that. | Thanks, | Donnie Don't you think that maybe you're trying to bash square pegs into round holes just for the sake of some sort of order that perhaps doesn't actually benefit anyone at all? Where did the requirement that a herd has to be part of a larger project come from? GLEP 39's crystal clear that we don't need a project to cover every peice of work that Gentoo devs do. Herds aren't even mentioned in there :) Why not just let herds carry on creating entries under /proj/en/? If they're part of a larger project, that project can just link to the herd's page. Our directory structure doesn't have to reflect a biological classification tree :) Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Package moves in overlays
Ok, Well, what if instead we were to try and treat the overlay trees as exactly that, overlays. So the moves were used from the lowest layer (ie the main tree) unless a higher up layer overrode them, could that work? It would mean effectively that the overlay moves were global, but I guess you'd then end up losing updates to the main tree if a file like 4Q-2005 was overridden... Can anyone think of a pratical solution to this problem other than either a major rework of portage's tree handling system, or by having the two packages block each other and relying on the user to fix the tree up manually whenever this happens? Any ideas would be welcome, it's a problem I'd really like to fix. Thanks very much, Mike 5:) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Fwd: /etc/portage/profile/{pmask,arch.list, categories}
On Mon, 9 Jan 2006 10:21:49 -0500
Alec Warner [EMAIL PROTECTED] wrote:
My Apologies, KMail died, and when I restarted it it had the mail but
stripped the attachment ;)
-- Forwarded Message --
Subject: /etc/portage/profile/{pmask,arch.list, categories}
Date: Monday 09 January 2006 09:59
From: Alec Warner [EMAIL PROTECTED]
To: gentoo-portage-dev@gentoo.org
Apparently these weren't working ( not being read in ) due to a lack
of /etc/portage/profile being in Locations in config in portage.py
I split a patch for hte issue by simply adding the extra location and
fixing the odd grabfile_package calls. It seems grabfile package was
stripping the
- so it wouldn't nuke existing entries in the pmask file.
Comments welcome as usual.
The profile stacking doesn't work that way ...
$PORTDIR/profiles/ and /etc/portage aren't part of the profile
stack, /etc/portage/profile is and actually works as intended. So this
patch would actually create a bug instead of fixing one
And if you think those dirs should be part of the stacking the patch is
still wrong as it has to be done the other way round.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
signature.asc
Description: PGP signature
[gentoo-portage-dev] Patch: handle collision-protect for symlinks
Is there any feedback on my recent post? The collision-protect feature didn't recognize two files as the same, if they were symlinked. i.e. /usr/FILE and /usr/X11R6/FILE caused a collision, while X11R6 - . linked This patch for portage-2.1 should fix this. Works fine for me in all thinkable scenarios. Can you please test and/or review it? Fixing bug: http://bugs.gentoo.org/show_bug.cgi?id=80846 Thank you a lot Thomas diff -ur portage-2.1_pre3/pym/portage.py portage-2.1_pre3-r2/pym/portage.py --- portage-2.1_pre3/pym/portage.py 2005-12-31 07:24:24.0 +0100 +++ portage-2.1_pre3-r2/pym/portage.py 2006-01-03 18:10:22.0 +0100 @@ -5917,6 +5917,21 @@ if (ver.isowner(f, destroot) or ver.isprotected(f)): isowned = True break + # Look for same inodes as f in other versions = means no collision + if ver.getcontents()==None: + continue + for myf in ver.getcontents(): + if not os.path.exists(myf): + continue + if os.path.samefile(f, myf): + myrealpath = os.path.realpath(f) + if myrealpath==f: +myotherpath=myf + else: +myotherpath=f + print yellow(*)+ +myotherpath+ points to +myrealpath + isowned = True + break if not isowned: print existing file +f+ is not owned by this package stopmerge=True
[gentoo-portage-dev] making aux_get more usable for vardbapi
Currently vardbapi.aux_get only works for a subset of all auxdbkeys, as
some like KEYWORDS or DESCRIPTIOn aren't stored in vdb directly.
They are however stored in environment.bz2, but not accessible
there.
This is unintuitive and limits tools like equery or my own auxget
and metascan tools in their usability.
There are two solutions to this problem:
a) enhance vardbapi.aux_get so it can use environment.bz2
b) store more keys in vdb
Now there is a tradeoff to made: a) doesn't need space but is slow
while b) is fast but needs space, both in non-trivial amounts (runtime
increased from 1s to 9s for a metascan -i run and from 0.5s to 0.8s
for auxget -i, haven't actually checked the size increase, expect
somewhere between 1 and 10 megabytes on a typical install).
I'm attaching a patch that implements both (each in it's own hunk) as
well as a new emaint option to create the missing entries offline.
A not so obvious issue with a) is that due to the recent
storage optimizations (empty entries not being stored) it's worse than
I originally expected, as any entry missing a file will be looked up in
env.bz2 instead. Only way to avoid that would be to add special casing
in aux_get which I really dislike.
Opinions?
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
--- /home/gentoo/svn/portage/main/trunk/bin/ebuild.sh 2006-01-08 04:30:16.0 +0100
+++ /usr/lib/portage/bin/ebuild.sh 2006-01-10 18:27:15.0 +0100
@@ -914,7 +914,8 @@
for f in ASFLAGS CATEGORY CBUILD CC CFLAGS CHOST CTARGET CXX \
CXXFLAGS DEPEND EXTRA_ECONF EXTRA_EINSTALL EXTRA_MAKE \
FEATURES INHERITED IUSE LDFLAGS LIBCFLAGS LIBCXXFLAGS \
- LICENSE PDEPEND PF PKGUSE PROVIDE RDEPEND RESTRICT SLOT; do
+ LICENSE PDEPEND PF PKGUSE PROVIDE RDEPEND RESTRICT SLOT \
+ KEYWORDS HOMEPAGE SRC_URI DESCRIPTION; do
[ -n ${!f} ] echo $(echo ${!f} | tr '\n,\r,\t' ' , , ' | sed s/' \+'/' '/g) ${f}
done
echo ${USE} USE
--- /home/gentoo/svn/portage/main/trunk/pym/portage.py 2006-01-08 04:30:11.0 +0100
+++ /usr/lib/portage/pym/portage.py 2006-01-10 18:28:00.0 +0100
@@ -4501,17 +4477,32 @@
def aux_get(self, mycpv, wants):
global auxdbkeys
results = []
+ envlines = None
for x in wants:
- myfn = self.root+VDB_PATH+/+str(mycpv)+/+str(x)
- if os.access(myfn,os.R_OK):
-myf = open(myfn, r)
+ mydir = self.root+VDB_PATH+/+str(mycpv)+/
+ if os.access(mydir+str(x),os.R_OK):
+myf = open(mydir+str(x), r)
myd = myf.read()
myf.close()
-myd = re.sub([\n\r\t]+, ,myd)
-myd = re.sub( +, ,myd)
-myd = string.strip(myd)
+ # Fallback to searching environment.bz2 if no key-specific file exists
+ elif os.access(mydir+environment.bz2, os.R_OK):
+if not envlines:
+ env = os.popen(bzip2 -dcq +mydir+environment.bz2, r)
+ envlines = env.read().split(\n)
+ env.close()
+myd = [l for l in envlines if l.strip(\\').startswith(x+=)]
+if len(myd) 1:
+ raise portage_exception.CorruptionError(multiple matches for +x+ found in +mydir+environment.bz2)
+elif len(myd) == 0:
+ myd =
+else:
+ myd = myd[0].split(=,1)[1]
+ myd = myd.lstrip($).strip(\'\)
+ myd = re.sub(([nrt])+, , myd)
else:
myd =
+ myd = re.sub([\n\r\t]+, ,myd)
+ myd = re.sub( +, ,myd)
+ myd = string.strip(myd)
results.append(myd)
if EAPI in wants:
idx = wants.index(EAPI)
--- /home/gentoo/svn/portage/main/trunk/bin/emaint 2006-01-08 04:30:16.0 +0100
+++ /usr/lib/portage/bin/emaint 2006-01-10 19:29:20.0 +0100
@@ -4,7 +4,7 @@
from copy import copy
from optparse import OptionParser, OptionValueError
-
+import re
import os, portage, portage_const
class WorldHandler(object):
@@ -44,8 +44,65 @@
errors.append(portage_const.WORLD_FILE + could not be opened for writing)
return errors
+class VdbKeyHandler(object):
+ def name():
+ return vdbkeys
+ name = staticmethod(name)
+
+ def __init__(self):
+ self.list = portage.db[/][vartree].dbapi.cpv_all()
+ self.missing = []
+ self.keys = [HOMEPAGE, SRC_URI, KEYWORDS, DESCRIPTION]
+
+ for p in self.list:
+ mydir = /var/db/pkg/+p
+ ismissing = True
+ for k in self.keys:
+if os.path.exists(mydir+/+k):
+ ismissing = False
+ break
+ if ismissing:
+self.missing.append(p)
+
+ def check(self):
+ return [%s has missing keys % x for x in self.missing]
+
+ def fix(self):
+
+ errors = []
+
+ for p in self.missing:
+ mydir = /var/db/pkg/+p
+ if not os.access(mydir+/environment.bz2, os.R_OK):
+errors.append(Can't access %s % (mydir+/environment.bz2))
+ elif not os.access(mydir, os.W_OK):
+errors.append(Can't create files in %s % mydir)
+ else:
+env = os.popen(bzip2 -dcq +mydir+/environment.bz2, r)
+envlines = env.read().split(\n)
+env.close()
+for k in self.keys:
+ s = [l for l in
[gentoo-portage-dev] emaint and handling of user editable files
Hi,
Since a long time I wanted to start a project like emaint ... now there it
is :-).
Currently we have two kinds of config files for portage:
o user editable (like /etc/portage/package.*)
o not user editable (like /var/lib/portage/world, as it is rewritten all of
the time and no comments are allowed so far)
Some time ago I have written a python script [1] to check
o for packages that are installed but not stable (ie they are not contained in
package.keywords but they are ~ARCH).
o package.{keywords,unmask} for entries which are redundant (ie because we
have =x/y-1.0 in it, but x/y-2.0 is installed).
Now I have startet to integrate these two things into emaint and here come my
problems regarding these files. When using --fix I cannot simply remove the
corresponding entries from package.{keywords,unmask} as there may be comments
placed for those entries. In my case this is the date I added the packages to
package.* like:
# 2005.03.06 - 21:53:25
~app-text/pdfjam-1.20 ~amd64
# 2005.03.06 - 22:01:18
~net-wireless/bluez-bluefw-1.0 ~amd64
On the other hand it would be very nice to allow comments in the world file,
too, as I very often don't remember why I installed a package (a lib which
for example was just a dependency for lokaly installed stuff).
As I'm writing this I get the idea, that this probalby should not be part of
the world file but of portage itself with a --comment TEXT parameter :-).
So, finally, how should emaint --fix deal with comments in files?
(a) Only give a recommendation what / how to fix?
(b) Fix if there are no comments contained, otherwise only do (a)?
Thanks for your input!
take care, have fun
/christian
[1] ftp://ftp.hoenig.cc/pxs/
pgpsw5ASE518Y.pgp
Description: PGP signature
