Re: [gentoo-portage-dev] [PATCH 1/3 v2] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
On Sun, 19 Jan 2014 18:43:46 -0800
Alec Warner anta...@gentoo.org wrote:
It is certainly weird (as we discussed on IRC.) I've never seen
anyone do it in any codebase I liked.
My backlog was limited so I didn't catch that discussion, feel free to
share the log; I've since increased it. There's a lot more talk than my
defaults on IRC (as well as here on the mailing list). :)
On a side note, I liked seems a too subjective way to review patches.
One of the problems is that it isn't immutable, so that earlier
callers can mess with later callers. That is not possible in vapier's
proposal, as the attributes are hidden in the function code and are
not visible to callers.
True, but do you have a better suggestion? (Not the one below)
From a quick lookup Python seems to not really provide a clean
immutable solution here; one option would be to use a frozenset, but
then one has to make classes to put into that (which are still
mutable). That is a misuse for what could just be a dictionary.
move it into the class definition.
def getNonSystemArchiveDepends(fetchlist, eapi):
...
ARCHIVERS = {
...
}
That makes it a non-static function variable? This is a regression.
I guess I am not seeing why it must be a static function variable.
Can you explain?
Because you would call re.compile for each time that function is
called; while the most recent compiled versions of re.compile are
cached, I still do not see a reason for this variable not to be static.
For the colon's in dicts thing:
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Whitespace
Okay, I will follow those guidelines.
The @system set in gentoo will ensure these are installed.
You can compare @system against the PMS and you will note that entries
are missing in @system; the @system set only covers the most popular
ones, the rest is left up to the maintainer to add to the ebuild. Thus
this enumerates all of them; as the @system set can change in the
future, we need to make the code future proof hence the @system check.
It is possible for such atom to get removed from @system later.
understand the wording of PMS (as the dependencies should be
expressed somewhere) but in general we prefer to do that in @system.
For the same reason all packages do not depend on glibc, or the
compiler, or anything else.
Things that are in @system are not complained about by this code:
if format not in system_set_atoms:
--
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] Signing off patches
On Tue, Jan 21, 2014 at 07:41:21PM +0100, Tom Wijsman wrote: On Tue, 21 Jan 2014 09:20:04 -0800 W. Trevor King wrote: On Tue, Jan 21, 2014 at 05:59:54PM +0100, Tom Wijsman wrote: On Tue, 21 Jan 2014 08:51:14 -0800 W. Trevor King wrote: On Tue, Jan 21, 2014 at 04:40:19PM +0100, Tom Wijsman wrote: On Sun, 19 Jan 2014 18:32:35 -0800 W. Trevor King wrote: No policy/suggestion/goal is going to be followed 100% of the time. This way, it seems preferable to use the mailing list when blaming. Unless some of the discussion happened on IRC. There are several possible channels for patch discussion, but only one commit message per patch. Exactly, without knowledge codification all that will continue to be a feel like, probably not, shouldn't, unless some. I don't see that as a problem. I guess I just have more faith that current devs will put in a reasonable best-effort without codification beyond “here are some conventions you may want to use”, and that future devs will be competent enough to still be productive in the face of unhelpful commit messages. If they are just mentioned at random all the time, perhaps half of them get remembered or so; the half of what is remembered gets given through to the next generation of future devs, this up to the point that it would have been a better idea to write this down than to have faith. I'm all for recording suggested conventions in DEVELOPING, but I don't think it's worth the trouble to over-specify the conditions under which each tag should be used, or to lay out consequences for cases where they're forgotten. The faith part is trusting devs to understand and apply the written suggestions, not in determining what the suggestions are. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Signing off patches
On Tue, 21 Jan 2014 11:18:39 -0800 W. Trevor King wk...@tremily.us wrote: I'm all for recording suggested conventions in DEVELOPING, but I don't think it's worth the trouble to over-specify the conditions under which each tag should be used, or to lay out consequences for cases where they're forgotten. The faith part is trusting devs to understand and apply the written suggestions, not in determining what the suggestions are. Which brings me back to my very first words of this sub thread: Either someone cares about the background of a patch or he/she doesn't. -- 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] Signing off patches
On Tue, Jan 21, 2014 at 08:22:31PM +0100, Tom Wijsman wrote: On Tue, 21 Jan 2014 11:18:39 -0800 W. Trevor King wrote: I'm all for recording suggested conventions in DEVELOPING, but I don't think it's worth the trouble to over-specify the conditions under which each tag should be used, or to lay out consequences for cases where they're forgotten. The faith part is trusting devs to understand and apply the written suggestions, not in determining what the suggestions are. Which brings me back to my very first words of this sub thread: Either someone cares about the background of a patch or he/she doesn't. That's certainly true. My initial impression was that you were against suggesting these conventions in DEVELOPING. Perhaps I missunderstood. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH v3] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.
On Monday 20 January 2014 22:53:25 Gordon Pettey wrote: If your going to make that argumint, ewe mite a's well right the documentation in LOL-1337. Encouraging bad grammar in documentation just make's thing's harder for everybody. (1) don't top post (2) you posted nothing to support your assertion that using 's to pluralize acronyms is bad grammar (3) i posted information that shows it's an accepted form so if you don't have anything useful to post, then just refrain from doing so -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH v5] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.
On Monday 20 January 2014 23:00:31 Chris Reffett wrote: + if not ro_filesystems: + return ro_filesystems + + for directory in dir_list: + for filesystem in ro_filesystems: + if filesystem == directory: + ro_filesystems_written.add(filesystem) + + return ro_filesystems_written is this just the intersection of two sets ? so all this logic could be: return ro_filesystems ^ set(dir_list) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH v2] prepman: do not compress files =128 bytes
On Thursday 21 March 2013 20:17:30 Mike Frysinger wrote: On Thursday 21 March 2013 19:25:08 James Cloos wrote: MF == Mike Frysinger vap...@gentoo.org writes: MF realistically, there are no man pages that are under 4k. look at the MF referenced bug for more details. Oh. I didn't look closely enough to notice that it was only for man; I presumed that it would apply to /usr/share/doc/ as well the subject does say prepman ;) we'll probably do something for doc too. my focus was on man. portage-2.2.8 now implements this policy for all files given to ecompress -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH 0/3] Initial fetch() refactoring
On Sunday 19 January 2014 17:46:36 Alec Warner wrote: On Sun, Jan 19, 2014 at 2:45 PM, Alexander Berntsen wrote: On 19/01/14 22:22, Sebastian Luther wrote: The usual doc string style used in portage is: text Please use that for new functions. Also make sure you don't use spaces to indent the last . As mentioned by Mike in another thread, we should use PEP 257[0]. I will convert old code to conform to this... sometime... soon... (I promise!) So if new patches could just do that right away, that would be neat. Does pylint or pyflakes point out if you mess it up? Automation for the win. the good news is that i wrote a pylintrc module for Chromium OS to enforce docstring style. the bad news is that it doesn't work with pyflakes. https://chromium.googlesource.com/chromiumos/chromite/+/master/cros/commands/lint.py what we did there was just merge it and then have people fix things up as they went rather than try to clean it all up first. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH v3 0/4] Initial fetch() refactoring
On Sunday 19 January 2014 22:26:06 W. Trevor King wrote: W. Trevor King (4): pym/portage/package/ebuild/fetch.py: Factor out _get_checksum_failure_max_tries pym/portage/package/ebuild/fetch.py: Factor out _get_fetch_resume_size pym/portage/package/ebuild/fetch.py: Factor out _get_uris pym/portage/package/ebuild/fetch.py: Flatten conditionals in _get_fetch_resume_size no need to use the full file path. a simpler prefix is fine like: ebuild: fetch: ... -mike signature.asc Description: This is a digitally signed message part.
