[gentoo-portage-dev] Signing off patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 We have quite a few dedicated developers now. To ensure that good taste is exercised, and that best practices are followed, patches should be signed. My proposals: Signed-off-by: Wrote (a substantial portion of) the patch Reviewed-by: Reviewed the patch thoroughly Tested-by: Tested the patch thoroughly Acked-by: Approved the concept but did not read the patch in detail (typically used by the maintainer of a specific portion, or our lead) Suggested-by: Designed the implementation Reported-by: Reported the bug/feature request These suggestions all stem from the Linux project. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLX3JsACgkQRtClrXBQc7VhEQD9FKmFbyf9zxl+hLylkhQN/kv6 o3DSM4xBr9fH4+1eokYA/3MbFLtDpli311d6ZqGD17kGLfz5wNj+5kPRATbiC256 =cJNe -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Signing off patches
On Thu, Jan 16, 2014 at 5:20 AM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 We have quite a few dedicated developers now. To ensure that good taste is exercised, and that best practices are followed, patches should be signed. I'm confused, are you proposing all patches have all of these fields? Or we should simply cherry-pick the fields we think are useful? My proposals: Signed-off-by: Wrote (a substantial portion of) the patch Reviewed-by: Reviewed the patch thoroughly Tested-by: Tested the patch thoroughly Acked-by: Approved the concept but did not read the patch in detail (typically used by the maintainer of a specific portion, or our lead) Suggested-by: Designed the implementation Reported-by: Reported the bug/feature request These suggestions all stem from the Linux project. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLX3JsACgkQRtClrXBQc7VhEQD9FKmFbyf9zxl+hLylkhQN/kv6 o3DSM4xBr9fH4+1eokYA/3MbFLtDpli311d6ZqGD17kGLfz5wNj+5kPRATbiC256 =cJNe -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Signing off patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/01/14 17:45, W. Trevor King wrote: I love Signed-off-by, but in all projects where I've seen it used it means the signer is agreeing to some form of a Developer's Certificate of Origin [1]. Without such a DCO, I think the usual commit author is sufficient. I agree. However, it might be prudent to introduce a DCO. After all, copyright is assigned to the Gentoo Foundation. Co-authors can be listed with Assisted-by: Sure. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLYEW4ACgkQRtClrXBQc7WMaAD6Ar5ut5Xs6i1Z3XISV0xXdHQg F/TCNHyJVB6ORe1ZsCIA/0hesVEs4DB0QnIcRIthUniQfiBUG8qn+L9EvWmrsq8r =rfUr -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Signing off patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/01/14 17:41, Alec Warner wrote: I'm confused, are you proposing all patches have all of these fields? Or we should simply cherry-pick the fields we think are useful? Nearly all patches should have Signed-off-by. The others are situational. We should strive to always have an Acked-by from the team lead. Reviewed-by should be present on all non-trivial patches. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLYEJEACgkQRtClrXBQc7XuQgD/dGEgjCpW+CgqOYvgkwK2OaU6 +auzTl4uAwhhZnM/7ukA/0+E5g9jZd/MtDMLL5qyFnTwMJqRZmPVyGj6N/GVoz7U =lVht -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Signing off patches
On Thu, Jan 16, 2014 at 06:05:50PM +0100, Alexander Berntsen wrote: On 16/01/14 17:45, W. Trevor King wrote: I love Signed-off-by, but in all projects where I've seen it used it means the signer is agreeing to some form of a Developer's Certificate of Origin [1]. Without such a DCO, I think the usual commit author is sufficient. I agree. However, it might be prudent to introduce a DCO. After all, copyright is assigned to the Gentoo Foundation. If you add a DCO (and I'd certainly think that would be prudent if you require copyright assignment), then you probably don't need a separate Assisted-by. Anyone with enough co-authorship to matter will be using a Signed-off-by. 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/01/14 18:24, Jesus Rivero (Neurogeek) wrote: So, how would this work with emails to this list, exactly? An email should be sent any time one of those fields is changed? That's not necessary, in my opinion. We already send emails, looks OK to me and similar. And most patches don't really need more than one review and an ACK by the lead. Do you have a more detailed plan on how would this work? Not really. We're small enough to do this organically and on a per-case basis. But basically, if someone authors a non-trivial patch, that person should *never* push themselves. Whoever reviews it should push it, adding the Reviewed-by field. The reviewer should also get an ACK by the team lead (via IRC or whatever) and add that to the commit before pushing. In a bigger project (or with a team lead with a lot of free time...), I would argue that the reviewer should send the new commit, with the Reviewed-by field added, to the team lead, which then adds the Acked-by field themselves, before pushing. I'm not convinced the benefits of this extra step outweighs the drawback in the overhead of this small community of ours. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLYGpkACgkQRtClrXBQc7WA4AEAmghIHMkNxiqJ79CONZzs/k/u t0QoASddzlSruejiVaQA+QFOdbgMaA59hf9DInPAgpG7Kc6fbFENgkZn4jEY9NAq =CrCK -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Signing off patches
On Thu, Jan 16, 2014 at 12:44 PM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/01/14 18:24, Jesus Rivero (Neurogeek) wrote: So, how would this work with emails to this list, exactly? An email should be sent any time one of those fields is changed? That's not necessary, in my opinion. We already send emails, looks OK to me and similar. And most patches don't really need more than one review and an ACK by the lead. Do you have a more detailed plan on how would this work? Not really. We're small enough to do this organically and on a per-case basis. But basically, if someone authors a non-trivial patch, that person should *never* push themselves. Whoever reviews it should push it, adding the Reviewed-by field. The reviewer should also get an ACK by the team lead (via IRC or whatever) and add that to the commit before pushing. Gotcha!, that makes sense to me. In a bigger project (or with a team lead with a lot of free time...), I would argue that the reviewer should send the new commit, with the Reviewed-by field added, to the team lead, which then adds the Acked-by field themselves, before pushing. I'm not convinced the benefits of this extra step outweighs the drawback in the overhead of this small community of ours. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLYGpkACgkQRtClrXBQc7WA4AEAmghIHMkNxiqJ79CONZzs/k/u t0QoASddzlSruejiVaQA+QFOdbgMaA59hf9DInPAgpG7Kc6fbFENgkZn4jEY9NAq =CrCK -END PGP SIGNATURE- Thanks, -- Jesus Rivero (Neurogeek) Gentoo Developer
[gentoo-portage-dev] Re: Signing off patches
Alexander Berntsen posted on Thu, 16 Jan 2014 18:44:57 +0100 as excerpted: On 16/01/14 18:24, Jesus Rivero (Neurogeek) wrote: So, how would this work with emails to this list, exactly? An email should be sent any time one of those fields is changed? That's not necessary, in my opinion. We already send emails, looks OK to me and similar. And most patches don't really need more than one review and an ACK by the lead. Do you have a more detailed plan on how would this work? Not really. We're small enough to do this organically and on a per-case basis. But basically, if someone authors a non-trivial patch, that person should *never* push themselves. Whoever reviews it should push it, adding the Reviewed-by field. The reviewer should also get an ACK by the team lead (via IRC or whatever) and add that to the commit before pushing. On the btrfs list, comments on patches often have wording to the effect: After taking care of those issues, you can add my reviewed-by. Looks fine to me, reviewed-by (or acked-by if more appropriate). If it's a preliminary review/ack, meanwhile, those will be missing. Also, presumably (I don't do IRC) people can get acks (or reviews if there has been more detailed correspondence previously) on IRC. Obviously reported-by doesn't need explicit permission, and tested-by (from a reporter's angle) the same, if it is said to work with the patch. Tested-by done by folks running the regression tests, etc, obviously get explicit permission in the form of their reports on those tests. If there were issues and there's a v2, v3, etc, these include the various bylines as part of the revision. If the patch is considered ready to go as-is, they'll be added at the final commit, which can be made by the author if they have commit access, or a dev with access if not. And one final note: A signed-off-by is a useful indicator of a patch that an author considers ready to go, pending review, etc. Lack of that (from a seasoned submitter who is familiar with the process) can be an indication that the author believes the patch is or may be preliminary, and they're not yet ready for integration-tree inclusion or final review, tho they usually say as much in the patch description as well. -- 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-portage-dev] Re: Signing off patches
On Thu, Jan 16, 2014 at 07:54:57PM +, Duncan wrote: And one final note: A signed-off-by is a useful indicator of a patch that an author considers ready to go, pending review, etc. Lack of that (from a seasoned submitter who is familiar with the process) can be an indication that the author believes the patch is or may be preliminary, and they're not yet ready for integration-tree inclusion or final review, tho they usually say as much in the patch description as well. You can also use: $ git format-patch --subject-prefix RFC … to mark preliminary patches with [RFC] tags in the subject. It also works with versions: $ git format-patch --subject-prefix RFC -v2 … will generate [RFC v2] tags. Once you think it's mergable, drop the --subject-prefix to get [PATCH] tags. 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] Helping out
Here is another one. This is the first patch mentioned here that touches
the dependency resolver. I'd be nice if we had more people with the
ability to work on it. So if you're interested in that, take a look.
Bug 498122 - portage-2.2.8 takes nearly twice as long to calculate
dependencies for world update
The problem with the patch mentioned in that bug is, that from there on
metadata access (specifically USE needs to be computed) is required to
search for slot operator rebuilds.
I expect that the metadata access can be avoided in most cases. To fix
this bug, I suggest to implement a check that decides if the metadata
access is required.
Here are some hints.
Take a look at the first block of the patch. It's about computing the
'atoms' variable. This variable is a set of all atoms in all *DEPEND
strings of some package ('replacement_parent').
This list is later searched for atoms for which atom.cp is equal to
dep.atom.cp (and which aren't blockers).
Before this patch the whole content of the *DEPEND string was added to
'atoms'. An example:
DEPEND=x? ( cat/foo ) would always result in atoms = {cat/foo}, even
if the use flag 'x' was disabled for the package.
The leads to problems in the following case:
DEPEND=x? ( =cat/foo-1 ) !x? ( =cat/foo-2 ).
The code later in the function tries to find a package that matches all
atoms in 'atoms'. Obviously there cannot be any package that satisfies
both =cat/foo-1 and =cat/foo-2 at the same time.
And this is not necessary at all here, because of the way the DEPEND is
written. After evaluating the use conditionals there is always one atom
left. But to figure this out, you need to know USE (the set of enabled
use flags).
Since computing USE is expansive, we'd like to avoid computing it.
Consider the following example:
We're searching for atoms with atom.cp == cat/foo:
DEPEND=cat/foo x? ( cat/bar )
No use conditional influences the set of atoms in this DEPEND for which
atom.cp == cat/foo. There's no point in evaluation them and in
consequence there's no point of computing USE.
I propose to implement a function* that maps (package, cp) to the set of
atoms in the *DEPEND of package for which atom.cp == cp (and which
aren't blockers).
This function should:
* First decide if evaluating USE is necessary or not
* Then evaluate the conditionals if required
* Compute and return the set of atoms with atom.cp == cp.
This function should cache its results. For the case without USE, the
cache should be part of self._frozen_config (contains stuff that never
changes). For the case that needs USE, it should be in
self._dynamic_config (contains stuff that may change between
backtracking steps).
For the implementation of the check you'll want to look at the functions
in portage.dep, specifically paren_reduce (ignore the deprecation
warning, we may have to remove that).
Feel free to ask questions here or on IRC.
hf :)
Re: [gentoo-portage-dev] [PATCH 1/3] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
On Wed, 15 Jan 2014 17:44:15 -0800 Alec Warner anta...@gentoo.org wrote: On Wed, Jan 15, 2014 at 4:07 PM, Tom Wijsman tom...@gentoo.org wrote: --- bin/repoman | 53 + man/repoman.1 | 4 2 files changed, 57 insertions(+) I urge you to not author new checks like this. /usr/bin/repoman is already a mess. Write these checks as functions, put them in a different file, and just call them from the giant messy loop. At least that way the checks are self contained (great for avoiding things like variable re-use or shadowing). My plan is to first work a bit on repoman to get to know it, then when knowing better where everything is work on refactoring it. If I start to refactor right away, or start adding random files without knowing where everything is; I would create a more broken design than it is. Don't worry, I plan on a fully refactored Portage as well as good practices when adding new checks; which will definitely become necessary as we go forward. There's ~80 bugs, imagine all the code that that would bring; definitely don't want those files to grow much longer. -- 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 1/3] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/01/14 22:18, Tom Wijsman wrote: My plan is to first work a bit on repoman to get to know it, then when knowing better where everything is work on refactoring it. That, along with I'll use this ugly short cut, but only this one time!, is what they all say. Plans change. Things happen. If I start to refactor right away, or start adding random files without knowing where everything is; I would create a more broken design than it is. Yes. Please think before you start hammering your keyboard. The keyboard is just a means to an end. Don't worry, I plan on a fully refactored Portage as well as good practices when adding new checks; which will definitely become necessary as we go forward. We have to worry. Because, as mentioned, plans change; things happen. Please do not push this patch. And please do not carry on with this mentality of yes, I know what I am doing is wrong, but I'll fix it eventually, some day, I promise. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLYTd4ACgkQRtClrXBQc7VNmQD+KhIxhOAC4/IPB4hn+ugL1NIH zNtPtTObzBMIivybstQBAISvE55N7Gb7hh6os+pZcvVilVqhhQP/V3b1RIk9tC2j =0lAa -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 1/3] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
On Thu, 16 Jan 2014 08:03:03 +0100
Sebastian Luther sebastianlut...@gmx.de wrote:
Am 16.01.2014 01:07, schrieb Tom Wijsman:
---
bin/repoman | 53
+ man/repoman.1
| 4 2 files changed, 57 insertions(+)
diff --git a/bin/repoman b/bin/repoman
index d1542e9..9b703dc 100755
--- a/bin/repoman
+++ b/bin/repoman
@@ -36,6 +36,9 @@ pym_path =
osp.join(osp.dirname(osp.dirname(osp.realpath(__file__))), pym)
sys.path.insert(0, pym_path) import portage
portage._internal_caller = True
+
+from portage._sets.profiles import PackagesSystemSet
+system_set_atoms =
PackagesSystemSet(portage.settings.profiles).getAtoms()
portage._disable_legacy_globals()
You should be using repoman_settings instead of portage.settings.
If I understand correctly, that is this URL?
http://dev.gentoo.org/~zmedico/portage/doc/api/portage.repository.config-module.html
How do I get the @system set out of that?
Considering the later use
Which use?
you don't need PackagesSystemSet set here,
just use a set.
Okay, thus I need to create some kind of set object here (I don't see
one in the list of http://dev.gentoo.org/~zmedico/portage/doc/api/
though) and then specify that it would be the @system set? Which class?
And use atom.cp instead of the atoms.
So, if I understood correctly; using list comprehension, I directly
transform the getAtoms() to a list of atom.cp's... Okay, good idea.
try:
@@ -300,6 +303,7 @@ qahelp = {
inherit.missing: Ebuild uses functions from an eclass
but does not inherit it, inherit.unused: Ebuild inherits an
eclass but does not use it, java.eclassesnotused: With
virtual/jdk in DEPEND you must inherit a java eclass,
+ unpack.DEPEND.missing: A rare archive format was used
in SRC_URI, but its package to unpack it is missing in DEPEND.,
wxwidgets.eclassnotused: Ebuild DEPENDs on x11-libs/wxGTK
without inheriting wxwidgets.eclass, KEYWORDS.dropped: Ebuilds
that appear to have dropped KEYWORDS for some arch,
KEYWORDS.missing: Ebuilds that have a missing or empty KEYWORDS
variable, @@ -399,6 +403,7 @@ qawarnings =
set(( metadata.warning, portage.internal,
repo.eapi.deprecated, +unpack.DEPEND.missing,
usage.obsolete,
upstream.workaround,
LIVEVCS.stable,
@@ -479,6 +484,25 @@ ruby_deprecated = frozenset([
ruby_targets_ree18,
])
+# TODO: Add functionality to support checking for deb2targz on
platforms where +# GNU binutils is absent; see PMS 5, section
11.3.3.13. +archive_formats = {
+ \.7[zZ]:app-arch/p7zip,
+ \.(bz2?|tbz2):app-arch/bzip2,
+ \.jar:app-arch/unzip,
+ \.(LH[aA]|lha|lzh):app-arch/lha,
+ \.lzma:app-arch/lzma-utils,
+ \.(rar|RAR):app-arch/unrar,
+ \.(tar(\.(bz2?|gz|Z))?|tbz2|t[bg]z)?:app-arch/tar,
+ \.(gz|tar\.Z|t[bg]z|[zZ]):app-arch/gzip,
+ \.(zip|ZIP):app-arch/unzip,
+}
+
+archive_formats_eapi_3_to_5 = {
+ \.tar.xz:app-arch/tar,
+ \.xz:app-arch/xz-utils,
+}
+
metadata_xml_encoding = 'UTF-8'
metadata_xml_declaration = '?xml version=1.0 encoding=%s?' %
\ (metadata_xml_encoding,)
@@ -1559,6 +1583,7 @@ for x in effective_scanlist:
fetchlist_dict = portage.FetchlistDict(checkdir,
repoman_settings, portdb) myfiles_all = []
src_uri_error = False
+ needed_unpack_depends = {}
for mykey in fetchlist_dict:
try:
myfiles_all.extend(fetchlist_dict[mykey])
@@ -1573,7 +1598,22 @@ for x in effective_scanlist:
stats[SRC_URI.syntax] += 1
fails[SRC_URI.syntax].append(
%s.ebuild SRC_URI: %s %
(mykey, e)) +
+ # Compare each SRC_URI entry against
archive_formats; if one of the
+ # extensions match, we remember which archive
depends are needed to
+ # check them later on.
+ needed_unpack_depends[mykey] = []
+ for file_extension in archive_formats or \
+ ((re.match('[345]$', eapi) is not None) \
Use portage.eapi for the line above.
Why? 'eapi' is the EAPI of the ebuild, what is wrong with that?
You may have to add a new function to portage.eapi.
What would the purpose of that function be?
+ and file_extension in
archive_formats_eapi_3_to_5):
+ for entry in fetchlist_dict[mykey]:
+ if re.match('.*%s$' %
file_extension, entry) is not None:
+ format =
archive_formats[file_extension]
As these regex are used frequently, they should be compiled using
re.compile.
I know, but it contains %s; but, I'll look if I can make a list of
regex, one for each file extension. Or rather, I'll first try to instead
match the last characters of the string using a substring without
having to create a regex at all, which should be even faster.
+
Re: [gentoo-portage-dev] [PATCH 1/3] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Your ill-placed attempts at being clever are missing the point. Portage is a mess. We don't need it to become more messy to the point of maintainability. Yes, no one fixing bugs (because they are all designing a grand redesign of Portage) would be bad. However, this is not likely to happen. It hasn't happened before. And now we have a bunch of great new volunteers. Sebastian even *told* you specifically how to do this properly. So please do. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLYW7QACgkQRtClrXBQc7WgOwEAqOuBXIMZyWbXRyY9VQEbwDCg tXmXa266YsSYgqRNlDMBAJTq9pyOvIhqhRPjLTrlA3EodPUSiDY5wRlMjSZ08xeE =WljA -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 1/3] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 16 Jan 2014 23:22:44 +0100 Alexander Berntsen alexan...@plaimi.net wrote: Your ill-placed attempts at being clever are missing the point. Why are they missing the point? Portage is a mess. We don't need it to become more messy to the point of maintainability. How do we plan to fix that? Yes, no one fixing bugs (because they are all designing a grand redesign of Portage) would be bad. Do you agree? However, this is not likely to happen. Why do you think so? It hasn't happened before. It could happen in the future. And now we have a bunch of great new volunteers. Yes, we do. Sebastian even *told* you specifically how to do this properly. Where did he? So please do. Why? - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS2GT9AAoJEJWyH81tNOV95ukH+wZ0yB4KOgfOd6z90cpYC0Ec 4RLK8HbKVYIIytxnnhR5Ny/BR5/ANlOYQDIFUytkJyKNmVPx3nP6kY+wHD5qOYkF 3DlJpxRy6wx/E43+wpvVv+dSNDHxkvyy8OeZ5QuAcFi1oYaeYdctfOU4/URihGzO MjA5h0ydQ8CcHoTMkJsFjS7wL3HdSy1m1SRh9kiOuOr9hz4HqOImjJQ1/6Yb38uS MVewW2oMEnEB99UANB5CswZHvvHcxU6d4hSmKlL1DfEuEq8hodM552n+WqpTgRhW YzLmhUFqe0fkS9p4wAa5tPDB8O34P+nEvSAwtVqDFwqJmX0+H+r2INp7LJmDARo= =FaJT -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 1/3] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909).
On Wed, 15 Jan 2014 17:44:15 -0800 Alec Warner anta...@gentoo.org wrote: Write these checks as functions Will do in v2, might also look into whether this part of the code can be refactored already into its own file; having it similar to the structure we have in Checks.py. We could then name Checks.py as SyntaxChecks.py and name this new file for the metadata checks of the loop as MetadataChecks.py; then later, we can look into creating VCSDiffChecks.py. Given that these files could grow, we will probably want to split the files up and put the split up files into directories like checks/syntax/, checks/metadata/ and so on. I really would love to see repoman refactored, redesigned and/or rewritten; but it is to soon for me to do this the most wise way, as I need to understand the code. I plan to do this 2 - 4 weeks from now. -- 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
