Re: [gentoo-dev] pkgdev: an alternative to `repoman commit`

2021-02-27 Thread Louis Sautier

On 27/02/2021 15:50, Tim Harder wrote:

Hi all,

Finally responding to all the requests, I've hacked up an initial
alternative to repoman's commit functionality in the form of pkgdev [1]
that uses pkgcheck's API behind the scenes. The project is meant to grow
into a collection of tools for Gentoo development and maintenance, but
initially supports `pkgdev commit` and `pkgdev push` that should work
for a basic git workflow on ebuild repos.

In essence, `pkgdev commit` wraps `git add` and `git commit`
functionality along with supporting GLEP 66 style message prefixes for
any committed files across an ebuild repo. Package manifests are also
regenerated and added automatically for any targeted pkg commits.

QA scanning is done on `pkgdev push` (not per `pkgdev commit` call) so
knowing/learning how to interactively `git rebase` is currently
essential to the workflow. Probably the main thing lacking is good docs
for the workflow that pkgdev envisions as it differs slightly from the
one used with repoman.

Feel free to respond with questions, ideas, or flames. If you want to
give it a shot, I believe a live ebuild for it has already been added to
the tree at dev-util/pkgdev. Also, please open issues on the upstream
project if you run into bugs or have feature requests.



Hi Tim,
That's really nice, thanks!
I just tested it and it seems really nice, I just need to adjust to the 
new workflow.
Could you make "push -v" a bit more verbose ? I initially forgot to 
rebase and couldn't see the error message from the remote. I guess this 
also means that the current code will hide messages from hooks such as 
changes made to Bugzilla.



Description: OpenPGP digital signature

Re: [gentoo-dev] Stabilisation of app-admin/ansible-2.10.0

2020-09-15 Thread Louis Sautier
On 15/09/2020 12:03, Marek Szuba wrote:
> Dear Matthew,
> I notice that you have recently stabilised app-admin/ansible-2.10.0 in
> Gentoo. Ansible upstream has introduced in that version major changes to
> their project structure [1] which given the current state of Ansible
> packaging in Gentoo can be considered severely breaking for our users.
> Therefore, please:
>  1. Revert stabilisation of 2.10.0, and
>  2. Either
>* by no means remove 2.9.12 from the tree for the time being, and
> before attempting to stabilise 2.10+ again either prepare a news item
> warning the users about upcoming breaking changes or package a suitable
> set of formerly-core modules; or
>* simply pull the current incarnation of 2.10.0 from the tree and
> only reintroduce it once the ansible (*not* ansible-base) on PyPI has
> actually been upgraded to 2.10.
> Explanation for the ML:
> Starting with version 2.10, the upstream package previously known as
> ansible is formally known as "ansible-base" and only provides the bare
> minimum of functionality - the core programs, some documentation, and a
> tiny subset of modules and plugins to allow for a functioning
> controller. All the other modules which were previously part of core
> ansible (see [2]) are now independent modules.
> Note that this only pertains to upstream packages of Ansible released on
> GitHub. On PyPI, "ansible" will continue to bundle the "core" modules;
> this is explicitly mentioned in several places in [1]. The problem is,
> =app-admin/ansible-2.10.0 has quietly replaced pypi:ansible with
> pypi:ansible-base in SRC_URI. This may or may not have had something to
> do with the fact pypi:ansible has not been updated to 2.10.0 yet (for
> now it's only pre-releases for that branch).
> References:
> [1]
> [2]
If they are indeed going to release a "normal" version with core
modules, I'm in favour of separating ansible and ansible-base, which is
what upstream did in its PPA.

That would mean removing ansible 2.10 from the tree and re-adding it as
ansible-base 2.10.

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/args

2020-09-13 Thread Louis Sautier
# Louis Sautier  (2020-09-13)
# Masked for removal in 30 days, unmaintained, no more revdeps.

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/meld3

2020-09-11 Thread Louis Sautier
# Louis Sautier  (2020-09-12)
# Masked for removal in 30 days, unmaintained, no revdeps.
# Former dependency of app-admin/supervisor.

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/pysendfile

2020-09-10 Thread Louis Sautier
# Louis Sautier  (2020-09-10)
# Masked for removal in 30 days, no revdeps.
# All former consumers now use os.sendfile available in Python >= 3.3.

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/backports-unittest-mock

2020-09-09 Thread Louis Sautier
# Louis Sautier  (2020-09-09)
# Masked for removal in 30 days, no revdeps.
# Backport of a module included in Python >= 3.3.

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/flask-appconfig

2020-09-04 Thread Louis Sautier
# Louis Sautier  (2020-09-04)
# Masked for removal in 30 days, no revdeps. Dependency of
# previously removed dev-python/flask-bootstrap

Description: OpenPGP digital signature

Re: [gentoo-dev] Improving warnings on packages.g.o

2020-08-27 Thread Louis Sautier
On 27/08/2020 12:37, Max Magorsch wrote:
> On Thu, Aug 27, 2020 at 12:10 PM Alexis Ballier  wrote:
>> Any plans on using the remoteid from metadata.xml ?
>> It's likely to be much more accurate since people have been filling
>> those manually for some time now ;)
> I think we could use the remoteid in future to improve the repology
> warnings. However, I am not fully convinced that we can completely
> replace the repology check using the remoteid, as a simple grep shows,
> that currently 9873 packages contain at least one remote id. That's
> just half of our packages in the tree. So I could imagine that we do
> use the remoteid whenever it is available and otherwise fall back on
> the repology data. However, for this to work we would need to things
> imo:
> 1) Get the latest version available given the remoteid
> 2) Compare the latest version available with our latest version
> It's especially the second part that I think is not done that quickly.
> However, if anyone is interested in coming up with some logic / code
> for this, any contributions are highly welcome.
Another cool addition, thanks :)

While we're on the topic of remoteid, could you please add links for
those somewhere in the package page?
I opened a bug for this a long time ago and I think it would be a nice
addition to the HOMEPAGE URL:

Description: OpenPGP digital signature

Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Louis Sautier
On 27/05/2020 15:22, Guilherme Amadio wrote:
> Hi,
> On Wed, May 27, 2020 at 02:45:29PM +0200, Toralf Förster wrote:
>> On 5/27/20 2:16 PM, Thomas Deutschmann wrote:
>>> The problem when doing review on Github
>>> for me is, that we usually create new revisions. Therefore we don't see
>>> what's changed in new revision versus previous revision. 
>> That's my main concern with the current behaviour: a "git diff" often 
>> doesn't show a diff against the previous (ebuild) file, it shows a diff 
>> against /dev/null :-/
> Indeed, on GitHub it is hard to review, but locally you can add
> [diff]
> algorithm = patience
> to your .gitconfig, and that should help with the diffs even when
> the revision changes by moving the file. When copying, it probably
> won't help.
> We could also try as a policy to split the revision bump from the
> changes, i.e. bump the revision in the first commit, then apply the
> changes in a second one. That way, one can click on the right commit
> to see the differences only, even on GitHub. Then we can squash when
> merging locally, since we don't click merge on GitHub anyway.
> Cheers,
> -Guilherme

That looks like it could lead to errors when merging if the committer
forgets to squash the two commits.

Whether it is on GitHub or another platform, it is probably possible to
have a bot compute the diff with the previous version every time a
commit is pushed to a PR and add that as a comment.

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/flask-bootstrap

2020-04-20 Thread Louis Sautier
# Louis Sautier  (2020-04-20)
# No revdeps, no release in 3 years, doesn't support Bootstrap 4.
# Removal in 30 days.

Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 2/2] acct-user/unifi: New user for net-wireless/unifi

2019-08-04 Thread Louis Sautier
On 04/08/2019 20:11, Conrad Kostecki wrote:
> Package-Manager: Portage-2.3.70, Repoman-2.3.16
> Signed-off-by: Conrad Kostecki 
> ---
>  acct-user/unifi/metadata.xml   | 22 ++
>  acct-user/unifi/unifi-0.ebuild | 15 +++
>  2 files changed, 37 insertions(+)
>  create mode 100644 acct-user/unifi/metadata.xml
>  create mode 100644 acct-user/unifi/unifi-0.ebuild
> diff --git a/acct-user/unifi/metadata.xml b/acct-user/unifi/metadata.xml
> new file mode 100644
> index 000..57ba2066974
> --- /dev/null
> +++ b/acct-user/unifi/metadata.xml
> @@ -0,0 +1,22 @@
> +
> +;>
> +
> + 
> +
> + Ben Kohler
> + 
> + 
> +
> + Conrad Kostecki
> + 
> + 
> +
> + Proxy Maintainers
> + 
> + 
> + UniFi is a management controller software for Ubiquiti UniFi 
> APs.
> + It's purpose is to configure and monitor all those APs.

"Its purpose", I just fixed it inside the main package's metadata.xml:

> + Also all kind of statistics are collected, which can be 
> accessed through UniFi.
> + There is also an internal RADIUS server, which can be used for 
> WPA2-Enterprise.
> + 
> +
> diff --git a/acct-user/unifi/unifi-0.ebuild b/acct-user/unifi/unifi-0.ebuild
> new file mode 100644
> index 000..0f750e70188
> --- /dev/null
> +++ b/acct-user/unifi/unifi-0.ebuild
> @@ -0,0 +1,15 @@
> +# Copyright 2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit acct-user
> +
> +DESCRIPTION="A user for the UniFi Controller"
> +
> +ACCT_USER_GROUPS=( "unifi" )
> +ACCT_USER_HOME="/var/lib/unifi"
> +ACCT_USER_HOME_OWNER="unifi:unifi"
> +ACCT_USER_ID="113"
> +
> +acct-user_add_deps

Description: OpenPGP digital signature

[gentoo-dev] [PATCH] doebuild: add missing whitespace in warning message

2018-11-11 Thread Louis Sautier

Here's a very trivial change to fix missing whitespace.

I have also filed it as a PR here:

lib/portage/package/ebuild/ | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/portage/package/ebuild/
index d0e96f34c..fbc482b43 100644
--- a/lib/portage/package/ebuild/
+++ b/lib/portage/package/ebuild/
@@ -508,8 +508,8 @@ def doebuild_environment(myebuild, mydo,
myroot=None, settings=None,
mysettings["PATH"] = p + ":" + mysettings["PATH"]
- writemsg(("Warning: %s requested but no masquerade dir"
- + "can be found in /usr/lib*/%s/bin\n") % (m, m))
+ writemsg(("Warning: %s requested but no masquerade dir "
+ "can be found in /usr/lib*/%s/bin\n") % (m, m))

if 'MAKEOPTS' not in mysettings:

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/hgtools and its reverse dependency dev-python/jaraco-utils

2018-07-08 Thread Louis Sautier
# Louis Sautier  (8 July 2018)
# Superseded, respectively by dev-python/setuptools_scm
# and dev-python/jaraco-* + dev-python/tempora.
# Removal in a month. See

Description: OpenPGP digital signature