Re: [gentoo-dev] Gitolite with WebHooks: testers wanted
On Mon, Mar 9, 2015 at 2:27 AM, Robin H. Johnson robb...@gentoo.org wrote: Hi all, Amongst Git migration preparations, one of the previously mentioned items was that GitHub's webhooks were very useful for many tasks. The QA team is already using them on the gentoo-portage-rsync-mirror repo, to trigger regular Travis-CI runs. In line with our policies of not depending on closed source and concerns about the persistence of GitHub, I've got an initial cut of WebHook support for Gitolite. These will probably be the primary means of interaction with external services, as we'd prefer not to give gitolite any SSH private keys to reach out to the world. It's based on the notify-webhook project [1], I also have the blessing of that author to improve his code and push generic changes to it. I'm looking for testers: Do you have a repo on gitolite AND would like pushes to trigger a webhook? If so, please file a bug for the public details. Additionally, if your hook has a username/password/secret token, please send me a GPG email with those details. Details needed: - repo path - webhook URL - webhook contenttype (json or url-encoded [default]) - webhook auth details if any (user, pass, realm, secret token) I do have plans to make it self-service later, but that will be a while coming. [1] https://github.com/metajack/notify-webhook Just some quick notes, about changes that may be needed in current github webhooks to work with our infra: - some webhooks may validate for github's IP range [1], and fail to be triggered by gentoo infra servers. - some webhooks may parse repository URLs assuming that the webhooks are triggered by github, e.g. to add some user/password/token. [1] https://help.github.com/articles/what-ip-addresses-does-github-use-that-i-should-whitelist/ []'s -- Rafael Goncalves Martinsn Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Re: Should there be a preference with qt4 and qt5 USE flags?
If qt5 is set as a USE flag, it should be preferred over a qt4 USE flag. The use explicitly opted in. Also, most software that does run with Qt5 runs better with Qt5, and supports numerous features such as better HighDPI support.
Re: [gentoo-portage-dev] [PATCH] WorldSelectedSet: fix load method for bug 542732
On Mon, 9 Mar 2015 12:32:02 -0700 Zac Medico zmed...@gentoo.org wrote: Since commit c3586c5e15c8373d08f9192713a2b03d4542faaf, the WorldSelectedSet load method does not force the set to load if it has already been loaded. Fix it to do so. Fixes: c3586c5e15c8 (WorldSelectedSet: fix breakage for bug #539746) X-Gentoo-Bug: 542732 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=542732 --- pym/portage/_sets/files.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/pym/portage/_sets/files.py b/pym/portage/_sets/files.py index 26ee094..e045701 100644 --- a/pym/portage/_sets/files.py +++ b/pym/portage/_sets/files.py @@ -221,7 +221,10 @@ class WorldSelectedSet(EditablePackageSet): self._setset.write() def load(self): - # Iterating over these sets loads them automatically. + # Iterating over these sets does not force them to load if they + # have been loaded previously. + self._pkgset.load() + self._setset.load() self._setAtoms(chain(self._pkgset, self._setset)) def lock(self): LGTM, don't know if it fixes it, but you are the expert there ;) -- Brian Dolbec dolsen
Re: [gentoo-dev] Re: Should there be a preference with qt4 and qt5 USE flags?
On 9 March 2015 at 04:17, Johannes Huber j...@gentoo.org wrote: Am Sonntag, 8. März 2015, 21:50:02 schrieb Nikos Chantziaras: On 08/03/15 21:35, Alexandre Rostovtsev wrote: On Sun, 2015-03-08 at 21:31 +0200, Nikos Chantziaras wrote: Some ebuilds in portage for Qt-based software support both Qt4 as well as Qt5. Some have +qt4 qt5 in IUSE, others have qt4 qt5. Is there a guideline for this somewhere? If a package needs Qt and thus lists: REQUIRED_USE=^^ ( qt4 qt5 ) but otherwise doesn't prefer one version over the other and both are equally well supported, should qt4 still be enabled by default? As long qt5 is testing only qt4 makes sense. This. For now, we need to prefer qt4, if there is a choice between qt4 and qt5. (Unless upstream has already abandoned the qt4 option, which makes it less of a choice, I guess.) But please set useflags for both options, so the choice is clear to the user. As soon as qt5 goes stable, I think we should switch to qt5 as default where possible. And especially when we have an at-least-one-of or an either-or required-use, we need to have one of the options set as default. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Gitolite with WebHooks: testers wanted
Hi all, Amongst Git migration preparations, one of the previously mentioned items was that GitHub's webhooks were very useful for many tasks. The QA team is already using them on the gentoo-portage-rsync-mirror repo, to trigger regular Travis-CI runs. In line with our policies of not depending on closed source and concerns about the persistence of GitHub, I've got an initial cut of WebHook support for Gitolite. These will probably be the primary means of interaction with external services, as we'd prefer not to give gitolite any SSH private keys to reach out to the world. It's based on the notify-webhook project [1], I also have the blessing of that author to improve his code and push generic changes to it. I'm looking for testers: Do you have a repo on gitolite AND would like pushes to trigger a webhook? If so, please file a bug for the public details. Additionally, if your hook has a username/password/secret token, please send me a GPG email with those details. Details needed: - repo path - webhook URL - webhook contenttype (json or url-encoded [default]) - webhook auth details if any (user, pass, realm, secret token) I do have plans to make it self-service later, but that will be a while coming. [1] https://github.com/metajack/notify-webhook -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
