Re: [gentoo-dev] Re: sys-boot/plymouth needs major fixes/maintainer

[M. J. Everitt]

On 05/08/17 03:16, Michael Palimaka wrote:
> On 08/05/2017 12:37 AM, Mart Raudsepp wrote:
>> On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
>>> I am looking into this for openrc. I copied it over to my personal
>>> overlay.
>> Ok, how about I mark myself as maintainer then and add you as co
>> -maintainer for OpenRC aspects, and you can e-mail me fixes for openrc
>> or otherwise?
>> sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too
>> still, right?
>>
>> I'm not sure about
>> kde-plasma/breeze-plymouth
>> kde-plasma/plymouth-kcm
>> do you use KDE/Plasma to care for those too?
> These two are still maintained by KDE team, they just got masked
> (without asking by the way...) because they depend on plymouth.
>
You mean to say treecleaners and QA should actually contact maintainers
before wielding their chainsaws ??  Musta missed that policy doc ...



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: sys-boot/plymouth needs major fixes/maintainer

[Michael Palimaka]

On 08/05/2017 12:37 AM, Mart Raudsepp wrote:
> On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
>> I am looking into this for openrc. I copied it over to my personal
>> overlay.
> 
> Ok, how about I mark myself as maintainer then and add you as co
> -maintainer for OpenRC aspects, and you can e-mail me fixes for openrc
> or otherwise?
> sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too
> still, right?
> 
> I'm not sure about
> kde-plasma/breeze-plymouth
> kde-plasma/plymouth-kcm
> do you use KDE/Plasma to care for those too?

These two are still maintained by KDE team, they just got masked
(without asking by the way...) because they depend on plymouth.

[gentoo-portage-dev] [PATCH v2] repoman commit: Support --bug (-b) and --closes (-c) for git footer

[Michał Górny]

Support two new options: --bug (-b) and --closes (-c) to add a plain
'Bug' reference and a 'Closes' footer for a GitHub pull request. Both
options can be specified multiple times, resulting in multiple footer
tags being written.

The --bug option accepts either a Gentoo Bugzilla bug number or an URL
to any bug tracker. In the latter case, it performs two trivial
transformations automatically: replaces long 'show_bug.cgi' Bugzilla
URLs with the short 'https://bugs.gentoo.org/NN', and forces
https:// for a few known services.

The --closes option accepts either a GitHub Gentoo repository pull
request number or an URL to any pull request (or bug) that uses
the 'Closes' tag. In the latter case, https:// is forced for a few known
services.

Changes in v2: use urlparse instead of regexps

---
 repoman/pym/repoman/actions.py   | 45 
 repoman/pym/repoman/argparser.py | 16 +-
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/repoman/pym/repoman/actions.py b/repoman/pym/repoman/actions.py
index 00bb5b2ca..8299ed0fe 100644
--- a/repoman/pym/repoman/actions.py
+++ b/repoman/pym/repoman/actions.py
@@ -14,6 +14,11 @@ import tempfile
 import time
 from itertools import chain
 
+try:
+   from urllib.parse import parse_qs, urlsplit, urlunsplit
+except ImportError:
+   from urlparse import parse_qs, urlsplit, urlunsplit
+
 from _emerge.UserQuery import UserQuery
 
 from repoman._portage import portage
@@ -324,6 +329,13 @@ class Actions(object):
return (changes.new, changes.changed, changes.removed,
changes.no_expansion, changes.expansion)
 
+   https_bugtrackers = frozenset([
+   'bitbucket.org',
+   'bugs.gentoo.org',
+   'github.com',
+   'gitlab.com',
+   ])
+
def get_commit_footer(self):
portage_version = getattr(portage, "VERSION", None)
gpg_key = self.repoman_settings.get("PORTAGE_GPG_KEY", "")
@@ -345,9 +357,42 @@ class Actions(object):
 
# Common part of commit footer
commit_footer = "\n"
+   for bug in self.options.bug:
+   # case 1: pure number NN
+   if bug.isdigit():
+   bug = 'https://bugs.gentoo.org/%s' % (bug, )
+   else:
+   purl = urlsplit(bug)
+   qs = parse_qs(purl.query)
+   # case 2: long Gentoo bugzilla URL to shorten
+   if (purl.netloc == 'bugs.gentoo.org' and
+   purl.path == '/show_bug.cgi' and
+   tuple(qs.keys()) == ('id',)):
+   bug = urlunsplit(('https', purl.netloc,
+   qs['id'][-1], '', 
purl.fragment))
+   # case 3: bug tracker w/ http -> https
+   elif (purl.scheme == 'http' and
+   purl.netloc in 
self.https_bugtrackers):
+   bug = urlunsplit(('https',) + purl[1:])
+   commit_footer += "Bug: %s\n" % (bug, )
+
+   for closes in self.options.closes:
+   # case 1: pure number 
+   if closes.isdigit():
+   closes = 
'https://github.com/gentoo/gentoo/pull/%s' % (closes, )
+   else:
+   purl = urlsplit(closes)
+   # case 2: bug tracker w/ http -> https
+   if purl.netloc in self.https_bugtrackers:
+   closes = urlunsplit(('https',) + 
purl[1:])
+   commit_footer += "Closes: %s\n" % (closes, )
+
if dco_sob:
commit_footer += "Signed-off-by: %s\n" % (dco_sob, )
 
+   print(commit_footer)
+   raise SystemExit(666)
+
# Use new footer only for git (see bug #438364).
if self.vcs_settings.vcs in ["git"]:
commit_footer += "Package-Manager: Portage-%s, 
Repoman-%s" % (
diff --git a/repoman/pym/repoman/argparser.py b/repoman/pym/repoman/argparser.py
index 2d56a87e6..f32972288 100644
--- a/repoman/pym/repoman/argparser.py
+++ b/repoman/pym/repoman/argparser.py
@@ -1,5 +1,5 @@
 # repoman: Argument parser
-# Copyright 2007-2014 Gentoo Foundation
+# Copyright 2007-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 """This module contains functions used in Repoman to parse CLI arguments."""
@@ -58,6 +58,20 @@ def parse_args(argv, qahelp, repoman_default_opts):
help='Request a confirmation before commiting')
 

Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Mart Raudsepp]

On R, 2017-08-04 at 16:43 +0200, Lars Wendler wrote:
> On Fri, 04 Aug 2017 17:37:15 +0300 Mart Raudsepp wrote:
> 
> > On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
> > > I am looking into this for openrc. I copied it over to my
> > > personal
> > > overlay.  
> > 
> > Ok, how about I mark myself as maintainer then and add you as co
> > -maintainer for OpenRC aspects, and you can e-mail me fixes for
> > openrc
> > or otherwise?
> 
> Last time I checked, plymouth-0.9.x had a hard requirement for
> systemd
> to work. From what I remember, making 0.9.x versions work with openrc
> might become a hard to solve task.
> 

If Lucas concludes that, I guess he could maintain a restored 0.8.x,
while there's 0.9.x systemd version maintained by me and hopefully
others (help still welcome, I'm still waiting on bug 613222, but might
be able to convert another machine earlier to plymouth).

Personally I've always connected plymouth with systemd and I'm
surprised some open OpenRC bugs were triggering treecleaning, but yes,
having a maintainer is always good as there are some service bug open
too, but so it is for the countless other maintainer-needed packages we
have around.


Mart

Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Lars Wendler]

On Fri, 04 Aug 2017 17:37:15 +0300 Mart Raudsepp wrote:

>On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
>> I am looking into this for openrc. I copied it over to my personal
>> overlay.  
>
>Ok, how about I mark myself as maintainer then and add you as co
>-maintainer for OpenRC aspects, and you can e-mail me fixes for openrc
>or otherwise?

Last time I checked, plymouth-0.9.x had a hard requirement for systemd
to work. From what I remember, making 0.9.x versions work with openrc
might become a hard to solve task.

>sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too
>still, right?
>
>I'm not sure about
>kde-plasma/breeze-plymouth
>kde-plasma/plymouth-kcm
>do you use KDE/Plasma to care for those too?
>
>

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpgPTkgVmXwH.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Mart Raudsepp]

On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
> I am looking into this for openrc. I copied it over to my personal
> overlay.

Ok, how about I mark myself as maintainer then and add you as co
-maintainer for OpenRC aspects, and you can e-mail me fixes for openrc
or otherwise?
sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too
still, right?

I'm not sure about
kde-plasma/breeze-plymouth
kde-plasma/plymouth-kcm
do you use KDE/Plasma to care for those too?

Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Lucas Ramage]

I am looking into this for openrc. I copied it over to my personal overlay.

On Fri, Aug 4, 2017, 10:17 AM Mart Raudsepp  wrote:

> On K, 2017-07-26 at 11:56 +0200, Pacho Ramos wrote:
> > sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions
> > where having
> > important bugs that were fixed in 0.9.x, but 0.9 is also plenty of
> > issues. Then,
> > either this is adopted by someone able to handle all that issues or
> > we will need
> > to finally treeclean (and drop its support for dependant packages)
>
> So despite this thread, this got suddenly p.masked.
>
> It seems most issues are related to usage with OpenRC, plus some
> stopping issue with sddm.
>
> I can soon look into the systemd aspects, but are there anyone
> interested in the openrc use case, to help out there?
>
>
> Mart
>
>

Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Mart Raudsepp]

On K, 2017-07-26 at 11:56 +0200, Pacho Ramos wrote:
> sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions
> where having
> important bugs that were fixed in 0.9.x, but 0.9 is also plenty of
> issues. Then,
> either this is adopted by someone able to handle all that issues or
> we will need
> to finally treeclean (and drop its support for dependant packages)

So despite this thread, this got suddenly p.masked.

It seems most issues are related to usage with OpenRC, plus some
stopping issue with sddm.

I can soon look into the systemd aspects, but are there anyone
interested in the openrc use case, to help out there?


Mart

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

[Peter Stuge]

Michael Orlitzky wrote:
> All this is to say that "easy to read" is in the eye of the beholder.
> For ebuilds in the tree, the beholder is usually the maintainer, which
> is why I think the choice should be left up to him.

I think what mgorny says is that locality of ebuilds is an important factor.


> Our ebuilds are bash programs, and in source code, "as little
> duplication as possible" is a strong contributor to "easy to read."

Here's an idea: Could a little bit of automated (but obviously checked!)
de-duplication be made [an optional] part of adding an ebuild into the
tree, and please everyone?


//Peter

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

[Michael Orlitzky]

On 08/04/2017 02:50 AM, Michał Górny wrote:
> 
> Why is it fine for you to handicap everyone else for your personal
> laziness? As it's been told more than once, you write ebuild *once*,
> people read it *multiple times*.

Look, I'm sorry if I've been overly confrontational. I emailed angry and
I know better. There's obviously two opinions on this and I don't want
to make your life any harder, either.

The write-once read-many discussion comes down to what you think is
easier to read, which can either mean literally read, or to develop on
top of. When verifying the URL in a submitted ebuild, I agree that the
no-variable form is easier to read and has the advantage that you can
just click the link on github to see if it works.

But on the other hand, in some of my own ebuilds, I find e.g.

  HOMEPAGE="https://github.com/${GITHUB_USER}/${PN};

easier to read than the long expanded string -- it's obviously correct.

And, if I have two otherwise-identical ebuilds for PECL packages (whose
homepage is set in an eclass), then I would rather not have the HOMEPAGE
show up in a diff of the two. Having the whole thing abstracted in an
eclass makes it easier to maintain these packages.

All this is to say that "easy to read" is in the eye of the beholder.
For ebuilds in the tree, the beholder is usually the maintainer, which
is why I think the choice should be left up to him. Our ebuilds are bash
programs, and in source code, "as little duplication as possible" is a
strong contributor to "easy to read."


> When reviewing pull requests, submitted ebuilds etc. I *have to* verify
> this stuff. I don't have time to copy everything to a local tree just to
> get some random tool process it correctly and give me the value I need.
> Just to figure out there's some trivial issue that blocks any further
> progress, and I will have to do this again, and again, and again.
> Because someone thinks it's cool to save 5 bytes in variable references

On 08/04/2017 02:51 AM, Ulrich Mueller wrote:
> All very well, but it requires the ebuild to a) be parseable by the
> package manager and b) already exist inside of an ebuild repository.
> Which is for example not the case for a user contributed ebuild
> attached to bugzilla.


The two use cases cited above apply only to ebuilds outside of the tree,
but the proposed rule applies only to ebuilds inside of the tree.

Ultimately, you do need to add the ebuild to your local tree. If the
package manager can't even source it, you have bigger problems than the
HOMEPAGE. And even if everyone kept variables out of HOMEPAGE, you would
still need to verify things like SRC_URI with the help of the package
manager.

Your workflow is whatever it is and I'm not going to tell you it's wrong
or go out of my way to make it harder, and all I want is the same
consideration. You're never going to read my ebuilds, but I have to work
with them every day. And if you wanted to instate a rule for user
submissions, I wouldn't have a problem with that.

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

[Ulrich Mueller]

> On Thu, 3 Aug 2017, Michael Orlitzky wrote:

> On 08/03/2017 06:33 PM, Ulrich Mueller wrote:
>> It did, even back in 2004:
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0=1.10=markup#l534

> You got me, but now we can see where that text came from and it
> proves my original point that the last line was added as an
> afterthought and isn't any sort of policy:

>   https://bugs.gentoo.org/show_bug.cgi?id=73272

Huh? We don't know if these changes result from a previous discussion,
or codify best practice at the time. Given that the comment says
"consolidate [...] into the Ebuild HOWTO" I would assume that they
don't appear out of the blue there.

Besides, something that sits in the handbook and devmanual uncontested
since more than a decade certainly is a policy.

> Which is good, because it's a silly rule, and hundreds of ebuilds in
> the tree wisely ignore it.

> Why single out HOMEPAGE? I might like to copy/paste the econf
> arguments, so should we forbid the use of $(use_enable foo) and
> force everyone to use "if" statements? Of course not; if you need
> the value of HOMEPAGE (or anything else), there are more intelligent
> ways to get it than opening up the ebuild, digging though the source
> code, and manually performing the variable substitutions that the
> programming language is there to do for us.

> Use the metadata, use eix, use emerge --search, write an echo
> statement into the ebuild, whatever. Don't handicap everyone so that
> you can treat their source code as part of your user interface.

All very well, but it requires the ebuild to a) be parseable by the
package manager and b) already exist inside of an ebuild repository.
Which is for example not the case for a user contributed ebuild
attached to bugzilla.

Ulrich


pgpfp4wYjo1do.pgp
Description: PGP signature

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

[Michał Górny]

On czw, 2017-08-03 at 23:24 -0400, Michael Orlitzky wrote:
> On 08/03/2017 06:33 PM, Ulrich Mueller wrote:
> > > > > > > On Thu, 3 Aug 2017, Michael Orlitzky wrote:
> > > The developer handbook that I just said didn't mention variables in
> > > HOMEPAGE at all.
> > 
> > It did, even back in 2004:
> > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0=1.10=markup#l534
> > 
> 
> You got me, but now we can see where that text came from and it proves
> my original point that the last line was added as an afterthought and
> isn't any sort of policy:
> 
>   https://bugs.gentoo.org/show_bug.cgi?id=73272
> 
> Which is good, because it's a silly rule, and hundreds of ebuilds in the
> tree wisely ignore it.

There's a significant difference between being unaware of a policy
and intentionally disrespecting it. Now that you've been made aware, we
can start pursuing it.

> Why single out HOMEPAGE? I might like to copy/paste the econf arguments,
> so should we forbid the use of $(use_enable foo) and force everyone to
> use "if" statements? Of course not; if you need the value of HOMEPAGE
> (or anything else), there are more intelligent ways to get it than
> opening up the ebuild, digging though the source code, and manually
> performing the variable substitutions that the programming language is
> there to do for us.
> 
> Use the metadata, use eix, use emerge --search, write an echo statement
> into the ebuild, whatever. Don't handicap everyone so that you can treat
> their source code as part of your user interface.

Why is it fine for you to handicap everyone else for your personal
laziness? As it's been told more than once, you write ebuild *once*,
people read it *multiple times*.

When reviewing pull requests, submitted ebuilds etc. I *have to* verify
this stuff. I don't have time to copy everything to a local tree just to
get some random tool process it correctly and give me the value I need.
Just to figure out there's some trivial issue that blocks any further
progress, and I will have to do this again, and again, and again.
Because someone thinks it's cool to save 5 bytes in variable references.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part