Re: [gentoo-portage-dev] [PATCH] Check for and report read-only filesystems
On Friday 10 January 2014 22:07:52 Chris Reffett wrote:
Attached is a patch to test if Portage is going to write to a
read-only filesystem and print out the list of filesystems that need
to be remounted RW. This leaves ${D} intact rather than having some
files moved before hitting the RO filesystem. Fixes bug 378869. Since
git.overlays.gentoo.org is down, I haven't had the chance to rebase
this against latest, but I can resubmit if it doesn't cleanly apply.
This is my first patch to the list, so I apologize if I didn't submit
correctly.
please use `git send-email` to post patches. attaching them makes things
harder to review.
--- /dev/null
+++ b/pym/portage/util/checkwriteable.py
+ with open(/proc/mounts) as procmounts:
this won't work on non-Linux systems
also, as a general style thing, unless there's a real need for the var to have
a full name, just use f or fp
+ roregex = re.compile(r'(\A|,)ro(\Z|,)')
+ for line in procmounts:
+ if roregex.search(line.split( )[3].strip())
is not None:
+ romount = line.split( )[1].strip()
+ ro_filesystems.add(romount)
ad hoc parsing of /proc/mounts isn't a good thing. at the risk of over
engineering, there should be a func that would take care of expanding the
mount paths into a list of namedcollections (one per mount). then you simply
walk it looking at its options.
+ for directory in dir_list:
+ for filesystem in ro_filesystems:
+ if re.match(filesystem, directory):
+ ro_filesystems_written.add(filesystem)
there's no need to use re and in fact you don't want to. you're looking at
wrong strings here, not regexes.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] First draft of a portage pylint.
people have been using pyflakes of late. not that i'm against adding this.
we should have a wrapper script:
$ cat pylint
#!/bin/sh
exec pylint --rcfile ${0%/*}/pylintrc $@
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] [REV] Added support for variable expansion in source command. wrt bug #490896
cnf/make.conf.example.source_test| 7 +++ cnf/make.conf.example.source_test_after | 8 i don't think test files belong in cnf/. keep them in the same dir as the test that uses them. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote: From: Chris Reffett creff...@gentoo.org you might want to set ~/.gitconfig to have your name/email so that git sendemail uses the right info in the actual e-mail From: field + undefined_phases_re = re.compile(r'^\s*(src_configure|src_prepare)\s*\(\)') you use re.match, so technically the ^ is redundant i'd suggest merging the regex a little: r'^\ssrc_(configure|prepare)\s*\(\)' could check for pkg_pretend/pkg_info too (it's new to EAPI 4) the regex is naive and can match valid ebuilds. consider ones that handle $EAPI itself and will call the right funcs as necessary. can you check the tree to see if anyone is doing this ? if so, we should drop a note to the dev list and get them fixed up. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Mon, 13 Jan 2014 19:50:44 -0500
Mike Frysinger vap...@gentoo.org wrote:
On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote:
From: Chris Reffett creff...@gentoo.org
Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if
src_prepare/src_configure are used in EAPI 0/1
Well, I was planning to cover these bugs; seems we really need to
organize with regards to avoiding double work, as two others have got
the same happen to them. Let's synchronize it.
So, what you have done here is wrote a partial patch for this bug:
https://bugs.gentoo.org/show_bug.cgi?id=379491
Therefore I suggest you that you mention it in the commit subject.
Now that you're working on phases, I wonder whether you plan to deal
with the other bug as well:
https://bugs.gentoo.org/show_bug.cgi?id=365691
While vapier's case could be considered as valid; I think we should
consider that as a bad practice, as one could just as well put the if
inside a phase which is the much more common practice.
Can you let me know whether you would work on this one as well as to
avoid both of us doing the same work on these?
As a note, my WIP work is at the next url; there you can see the bug
numbers I've been working on (still need to revise them, properly
document the added check errors [eg. in `man repoman`] and so on).
https://github.com/TomWij/gentoo-portage-next/branches
If you do something similar, we could check whether we attempt to work
on the same bug; as to avoid clashing. (In this case I think I told
you in #gentoo-qa that I planned to do this; but well, then I can be
lucky that I've not started on it. ^^)
you might want to set ~/.gitconfig to have your name/email so that
git sendemail uses the right info in the actual e-mail From: field
Then what is the From: field that it puts separately into the e-mail
itself? Seems quite odd for these to differ; or, is the latter an
attempt to mark the author? Then why does the e-mail From: field need
to be correct? Afaik it would only use one of both, so only one of both
needs to be correct. But that would make the actual question: Which one?
+ undefined_phases_re =
re.compile(r'^\s*(src_configure|src_prepare)\s*\(\)')
you use re.match, so technically the ^ is redundant
Indeed, they match on a line basis from the beginning of the string.
i'd suggest merging the regex a little:
r'^\ssrc_(configure|prepare)\s*\(\)'
Note that the * behind the first \s was lost; so, with the redundant ^
removed and the * put back it would be:
r'\s*src_(configure|prepare)\s*\(\)'
You can then proceed further and move the re outside:
r'\s*src_(configu|prepa)re\s*\(\)'
The closing parentheses can also be removed because phase( ) is valid:
r'\s*src_(configu|prepa)re\s*\('
(We don't need to account for phase( invalid ) here; as that results
in invalid Bash syntax, which would bail out harder than our checks)
But if we would do that, it would be like:
r'\s*src_(configu|prepa)re\s*\(\s*\)'
could check for pkg_pretend/pkg_info too (it's new to EAPI 4)
+1
the regex is naive and can match valid ebuilds. consider ones that
handle $EAPI itself and will call the right funcs as necessary.
From a QA point of view it seems more preferable to move away from old
EAPIs, than to conditionally support them. The common case is that
ebuilds move from older to newer EAPI and thus would get these
functions as they get to a newer EAPI.
Is there an actual case for downgrading back to an older EAPI?
If not, conditional code that checks $EAPI has no purpose.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v3] Added support for variable expansion in source command argument in make.conf
seems reasonable, although i haven't used the shlex module myself before -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Mon, 2014-01-13 at 23:59 -0500, Mike Frysinger wrote: On Monday 13 January 2014 22:23:01 Tom Wijsman wrote: On Mon, 13 Jan 2014 19:50:44 -0500 Mike Frysinger wrote: On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote: From: Chris Reffett creff...@gentoo.org Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 Well, I was planning to cover these bugs; seems we really need to organize with regards to avoiding double work, as two others have got the same happen to them. Let's synchronize it. we have a bugzilla workflow doc posted which we'll merge once git is back up. please do not reassign portage bugs to yourself. instead, set the status to INPROGRESS. Sorry, that was me that told him to. I didn't know about a bugzilla workflow doc. Plus I didn't see it at www.gentoo.org. So it wasn't converted to the wiki. -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
