Re: [gentoo-dev] [PATCH v1] eclass/savedconfig.eclass: rewrite the ROFF macros

2019-11-07 Thread Michał Górny
On Thu, 2019-11-07 at 18:56 -0500, Göktürk Yüksek wrote:
> man2html cannot cope with multi-character number-register names and
> also doesn't recognize the square brackets in the '\n' escape
> sequence. This breaks the autogenerated HTML output. Rename the
> number-register from "step" to "R" and get rid of the square brackets.
> 
> Closes: https://bugs.gentoo.org/699476
> 
> Signed-off-by: Göktürk Yüksek 
> ---
>  eclass/savedconfig.eclass | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
> index dab2283fe0f..8f64c5b8edd 100644
> --- a/eclass/savedconfig.eclass
> +++ b/eclass/savedconfig.eclass
> @@ -14,20 +14,20 @@
>  # so users can modify these config files and the ebuild will take it
>  # into account as needed.
>  #
> -# @ROFF .nr step 1 1
> +# @ROFF .nr R 1 1
>  # Typically you can create your own configuration files quickly by
>  # doing:
> -# @ROFF .IP \n[step] 3
> +# @ROFF .IP \nR 3
>  # Build the package with FEATURES=noclean USE=savedconfig.
> -# @ROFF .IP \n+[step]
> +# @ROFF .IP \n+R
>  # Go into the build dir and edit the relevant configuration system
>  # (e.g. `make menuconfig` or `nano config-header.h`).  You can look
>  # at the files in /etc/portage/savedconfig/ to see what files get
>  # loaded/restored.
> -# @ROFF .IP \n+[step]
> +# @ROFF .IP \n+R
>  # Copy the modified configuration files out of the workdir and to
>  # the paths in /etc/portage/savedconfig/.
> -# @ROFF .IP \n+[step]
> +# @ROFF .IP \n+R
>  # Emerge the package with just USE=savedconfig to get the custom build.
>  
>  inherit portability

Not a ROFF expert but looks reasonable.

-- 
Best regards,
Michał Górny



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


[gentoo-portage-dev] seed emerge with old /var/db/pkg ?

2019-11-07 Thread Joakim Tjernlund
I am looking for a way to seed emerge with an older pkg db so emerge can 
calculate
which packages needs to be rebuild/upgraded in order to get to the same state 
as the system pkg db,
Is that possible?

Also, is there some tool that allows med to copy just files needed for a 
profile?
Something like "cp" /etc/portage/make.profile /my/destination



[gentoo-dev] [PATCH v1] eclass/savedconfig.eclass: rewrite the ROFF macros

2019-11-07 Thread Göktürk Yüksek
man2html cannot cope with multi-character number-register names and
also doesn't recognize the square brackets in the '\n' escape
sequence. This breaks the autogenerated HTML output. Rename the
number-register from "step" to "R" and get rid of the square brackets.

Closes: https://bugs.gentoo.org/699476

Signed-off-by: Göktürk Yüksek 
---
 eclass/savedconfig.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index dab2283fe0f..8f64c5b8edd 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -14,20 +14,20 @@
 # so users can modify these config files and the ebuild will take it
 # into account as needed.
 #
-# @ROFF .nr step 1 1
+# @ROFF .nr R 1 1
 # Typically you can create your own configuration files quickly by
 # doing:
-# @ROFF .IP \n[step] 3
+# @ROFF .IP \nR 3
 # Build the package with FEATURES=noclean USE=savedconfig.
-# @ROFF .IP \n+[step]
+# @ROFF .IP \n+R
 # Go into the build dir and edit the relevant configuration system
 # (e.g. `make menuconfig` or `nano config-header.h`).  You can look
 # at the files in /etc/portage/savedconfig/ to see what files get
 # loaded/restored.
-# @ROFF .IP \n+[step]
+# @ROFF .IP \n+R
 # Copy the modified configuration files out of the workdir and to
 # the paths in /etc/portage/savedconfig/.
-# @ROFF .IP \n+[step]
+# @ROFF .IP \n+R
 # Emerge the package with just USE=savedconfig to get the custom build.
 
 inherit portability
-- 
2.24.0




Re: [gentoo-portage-dev] [PATCH v2] install.py: ignore -Z / --context

2019-11-07 Thread Zac Medico
On 11/7/19 1:18 PM, Mike Gilbert wrote:
> The --context option accepts an optional argument, but only if it is
> passed via --context=arg. The argparse module does not deal with this
> properly.
> 
> To work around this, have argparse ignore this option, and filter out
> any remaining arguments that start with a hyphen and do not occur after
> a "--" delimiter.
> 
> Bug: https://bugs.gentoo.org/699548
> Signed-off-by: Mike Gilbert 
> ---
> 
> If there is a cleaner way to do this, suggestions are welcome.
> 
> diff --git a/bin/install.py b/bin/install.py
> index d3789ed96..495534d33 100755
> --- a/bin/install.py
> +++ b/bin/install.py
> @@ -111,12 +111,6 @@ def parse_args(args):
>   action="store_true",
>   dest="no_target_directory"
>   )
> - parser.add_argument(
> - "--context",
> - "-Z",
> - action="store",
> - dest="context"
> - )
>   parser.add_argument(
>   "--verbose",
>   "-v",
> @@ -143,11 +137,21 @@ def parse_args(args):
>   # for known options in order for argparse to correctly
>   # separate option arguments from file arguments in all
>   # cases (it also allows for optparse compatibility).
> - parsed_args = parser.parse_known_args()
> + (opts, args) = parser.parse_known_args(args)
> +
> + files = []
> + i = 0
> + while i < len(args):
> + if args[i] == "--":
> + i += 1
> + break
> + if not args[i].startswith("-"):
> + files.append(args[i])
> + i += 1
>  
> - opts  = parsed_args[0]
> - files = parsed_args[1]
> - files = [f for f in files if f != "--"] # filter out "--"
> + while i < len(args):
> + files.append(args[i])
> + i += 1
>  
>   return (opts, files)
>  
> 

Looks good. Please merge.
-- 
Thanks,
Zac



Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Zac Medico
On 11/7/19 11:52 AM, Patrick McLean wrote:
> DEPEND="
>   elibc_glibc? ( || (
>   sys-libs/glibc[crypt(+)]

If a new version of glibc will remove crypt then it needs to be
something like:

|| ( >=sys-libs/glibc-2.30-r2[crypt(-)] 

signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Patrick McLean
On Thu, 7 Nov 2019 20:40:40 +
Sergei Trofimovich  wrote:

> On Thu, 7 Nov 2019 11:52:19 -0800
> Patrick McLean  wrote:
> 
> > Given glibc upstream's tentative plans to remove libcrypt [1], I
> > think we should start working out the kinks well in advance.
> > Toolchain has already added a package.use.force-ed "crypt" USE flag
> > to sys-libs/glibc-2.30-r2 [2]. The main alternative out there is
> > libxcrypt, which I have recently bumped and added a
> > package.use.mask-ed "system" USE flag to make it provide the
> > "system" version of libcrypt.so.
> > 
> > To give us time to work out dependencies in advance, I would like to
> > propose a virtual to provide libcrypt.so, and we can gradually
> > update all users of libcrypt to {R,}DEPEND on this virtual.  
> 
> It's not clear how this virtual is supposed to work when
> sys-libs/libxcrypt actually changes ABI. Do we care about the missing
> rebuilds or we do not?

I clarified this in a reply to mgorny's message.

> 
> If we don't it's (not ideal but) fine. But it should be stated
> explicitly and consequences should be described: does
> sys-libs/libxcrypt override glibc's libcrypt.so.1 and break existing
> applications? Or we guarantee it not to happen?
> 
> > elibc_glibc? ( || (
> > sys-libs/glibc[crypt(+)]
> > sys-libs/libxcrypt[system(-)]
> > )
> > )  
> 
> Same for switching providers back and forth. For example, should we
> allow user to come back from sys-libs/libxcrypt to sys-libs/glibc?

With the current dual-library approach, switching back and fourth is
possible, but may involve a preserved-libs rebuild of recently built
packages. Portage does detect this and handle it cleanly.

> 
> > Maybe once this is in place and the obvious/common packages are
> > updated, we could request a tinderbox run to flush out what was
> > missed.  
> 
> I don't think tinderbox will find much as util-linux, shadow or any
> other low-level package will pull it in as a dependency and be
> silently available.

I suppose that is true, though we could detect via the NEEDED* files
that portage generates in the vdb (we just need _all_ packages to be
installed somewhere at some point to detect it).

> 
> I think you'll need to do extra to find those. Like, removing
> libcrypt.so to make sure linker won't find it even if libcrypt.so.1
> is available.

That is another approach, we could do some hackery in the tinderbox
once the basic system packages are there so we can detect those.

> 
> > [1]
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> > [2] https://bugs.gentoo.org/699422  
> 
> 




Re: [gentoo-dev] Last rites: net-mail/pflogsumm

2019-11-07 Thread Ralph Seichter
* Tomas Mozes:

> I'll take it: https://github.com/gentoo/gentoo/pull/13567

Thank you for stepping up for this oldie but goodie, Tomas.

-Ralph



Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Patrick McLean
On Thu, 07 Nov 2019 21:28:34 +0100
Michał Górny  wrote:

> On Thu, 2019-11-07 at 11:52 -0800, Patrick McLean wrote:
> > Given glibc upstream's tentative plans to remove libcrypt [1], I
> > think we should start working out the kinks well in advance.
> > Toolchain has already added a package.use.force-ed "crypt" USE flag
> > to sys-libs/glibc-2.30-r2 [2]. The main alternative out there is
> > libxcrypt, which I have recently bumped and added a
> > package.use.mask-ed "system" USE flag to make it provide the
> > "system" version of libcrypt.so.
> > 
> > To give us time to work out dependencies in advance, I would like to
> > propose a virtual to provide libcrypt.so, and we can gradually
> > update all users of libcrypt to {R,}DEPEND on this virtual.
> > 
> > Maybe once this is in place and the obvious/common packages are
> > updated, we could request a tinderbox run to flush out what was
> > missed.  
> 
> Are you planning to use backwards-compatible .so.1 version of
> libxcrypt, or do you plan to switch to .so.2?

The current plan would be to initially we would be install both a .so.1
with full ABI compatibility with glibc (libxcrypt supports this) and a
.so.2 that libcrypt.so symlinks to without glibc compatibility (with
USE="compat" this is the current behaviour of the ebuild). Current
packages are using the .so.1 and any new builds end up linking to the
.so.2.

Eventually we can turn off the "compat" USE flag by default, some users
might end up doing preserved-libs rebuilds, but hopefully by that time
most stuff will be using .so.2.

> > 
> > 
> > [1]
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> > [2] https://bugs.gentoo.org/699422  
> 




[gentoo-portage-dev] [PATCH v2] install.py: ignore -Z / --context

2019-11-07 Thread Mike Gilbert
The --context option accepts an optional argument, but only if it is
passed via --context=arg. The argparse module does not deal with this
properly.

To work around this, have argparse ignore this option, and filter out
any remaining arguments that start with a hyphen and do not occur after
a "--" delimiter.

Bug: https://bugs.gentoo.org/699548
Signed-off-by: Mike Gilbert 
---

If there is a cleaner way to do this, suggestions are welcome.

diff --git a/bin/install.py b/bin/install.py
index d3789ed96..495534d33 100755
--- a/bin/install.py
+++ b/bin/install.py
@@ -111,12 +111,6 @@ def parse_args(args):
action="store_true",
dest="no_target_directory"
)
-   parser.add_argument(
-   "--context",
-   "-Z",
-   action="store",
-   dest="context"
-   )
parser.add_argument(
"--verbose",
"-v",
@@ -143,11 +137,21 @@ def parse_args(args):
# for known options in order for argparse to correctly
# separate option arguments from file arguments in all
# cases (it also allows for optparse compatibility).
-   parsed_args = parser.parse_known_args()
+   (opts, args) = parser.parse_known_args(args)
+
+   files = []
+   i = 0
+   while i < len(args):
+   if args[i] == "--":
+   i += 1
+   break
+   if not args[i].startswith("-"):
+   files.append(args[i])
+   i += 1
 
-   opts  = parsed_args[0]
-   files = parsed_args[1]
-   files = [f for f in files if f != "--"] # filter out "--"
+   while i < len(args):
+   files.append(args[i])
+   i += 1
 
return (opts, files)
 
-- 
2.24.0




[gentoo-portage-dev] Re: [PATCH] emirrordist: fix DeletionTask to handle broken symlink

2019-11-07 Thread Zac Medico
On 11/7/19 1:01 PM, Zac Medico wrote:
> After rename of a nonexistent symlink target fails, detect a
> broken symlink and simply delete it.
> 
> Fixes: 0d34d89d5028 ("emirrordist: Implement mirror layout.conf support")
> Bug: https://bugs.gentoo.org/699400
> Signed-off-by: Zac Medico 
> ---
>  lib/portage/_emirrordist/DeletionTask.py | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/lib/portage/_emirrordist/DeletionTask.py 
> b/lib/portage/_emirrordist/DeletionTask.py
> index 5eb01d840..49f13ddf7 100644
> --- a/lib/portage/_emirrordist/DeletionTask.py
> +++ b/lib/portage/_emirrordist/DeletionTask.py
> @@ -28,6 +28,11 @@ class DeletionTask(CompositeTask):
>   recycle_path)
>   except OSError as e:
>   if e.errno != errno.EXDEV:
> + if 
> os.path.islink(self.distfile_path) and not os.path.exists(self.distfile_path):
> + self._delete_links()
> + self._async_wait()
> + return
> +
>   logging.error(("rename %s from 
> distfiles to "
>   "recycle failed: %s") % 
> (self.distfile, e))
>   else:
> 

Actually, I withdraw this patch since we shouldn't have a symlink here
since self.distfile_path was added:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=af9c77bd037694164755d06034a74456ec45e3ab
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


[gentoo-portage-dev] [PATCH] emirrordist: fix DeletionTask to handle broken symlink

2019-11-07 Thread Zac Medico
After rename of a nonexistent symlink target fails, detect a
broken symlink and simply delete it.

Fixes: 0d34d89d5028 ("emirrordist: Implement mirror layout.conf support")
Bug: https://bugs.gentoo.org/699400
Signed-off-by: Zac Medico 
---
 lib/portage/_emirrordist/DeletionTask.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/portage/_emirrordist/DeletionTask.py 
b/lib/portage/_emirrordist/DeletionTask.py
index 5eb01d840..49f13ddf7 100644
--- a/lib/portage/_emirrordist/DeletionTask.py
+++ b/lib/portage/_emirrordist/DeletionTask.py
@@ -28,6 +28,11 @@ class DeletionTask(CompositeTask):
recycle_path)
except OSError as e:
if e.errno != errno.EXDEV:
+   if 
os.path.islink(self.distfile_path) and not os.path.exists(self.distfile_path):
+   self._delete_links()
+   self._async_wait()
+   return
+
logging.error(("rename %s from 
distfiles to "
"recycle failed: %s") % 
(self.distfile, e))
else:
-- 
2.21.0




Re: [gentoo-portage-dev] [PATCH] install.py: ignore -Z / --context

2019-11-07 Thread Mike Gilbert
On Thu, Nov 7, 2019 at 3:31 PM Zac Medico  wrote:
>
> On 11/7/19 10:22 AM, Mike Gilbert wrote:
> > The --context option accepts an optional argument, but only if it is
> > passed via --context=arg. The argparse module does not deal with this
> > properly.
> >
> > To work around this, have argparse ignore this option, and filter out
> > any remaining arguments that start with a hyphen.
> >
> > Bug: https://bugs.gentoo.org/699548
> > Signed-off-by: Mike Gilbert 
> > ---
> >  bin/install.py | 8 +---
> >  1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/bin/install.py b/bin/install.py
> > index d3789ed96..e56475ff1 100755
> > --- a/bin/install.py
> > +++ b/bin/install.py
> > @@ -111,12 +111,6 @@ def parse_args(args):
> >   action="store_true",
> >   dest="no_target_directory"
> >   )
> > - parser.add_argument(
> > - "--context",
> > - "-Z",
> > - action="store",
> > - dest="context"
> > - )
> >   parser.add_argument(
> >   "--verbose",
> >   "-v",
> > @@ -147,7 +141,7 @@ def parse_args(args):
> >
> >   opts  = parsed_args[0]
> >   files = parsed_args[1]
> > - files = [f for f in files if f != "--"] # filter out "--"
> > + files = [f for f in files if not f.startswith("-")] # filter unknown 
> > options
> >
> >   return (opts, files)
> >
> >
>
> Technically, shouldn't we pass through any "files" that start with "-"
> and come after the "--" separator?

Ah, yes. I will revise it.



Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Sergei Trofimovich
On Thu, 7 Nov 2019 11:52:19 -0800
Patrick McLean  wrote:

> Given glibc upstream's tentative plans to remove libcrypt [1], I think
> we should start working out the kinks well in advance. Toolchain has
> already added a package.use.force-ed "crypt" USE flag to
> sys-libs/glibc-2.30-r2 [2]. The main alternative out there is libxcrypt,
> which I have recently bumped and added a package.use.mask-ed "system"
> USE flag to make it provide the "system" version of libcrypt.so.
> 
> To give us time to work out dependencies in advance, I would like to
> propose a virtual to provide libcrypt.so, and we can gradually update
> all users of libcrypt to {R,}DEPEND on this virtual.

It's not clear how this virtual is supposed to work when sys-libs/libxcrypt
actually changes ABI. Do we care about the missing rebuilds or we do not?

If we don't it's (not ideal but) fine. But it should be stated explicitly and
consequences should be described: does sys-libs/libxcrypt override
glibc's libcrypt.so.1 and break existing applications? Or we guarantee it not
to happen?

>   elibc_glibc? ( || (
>   sys-libs/glibc[crypt(+)]
>   sys-libs/libxcrypt[system(-)]
>   )
>   )

Same for switching providers back and forth. For example, should we allow
user to come back from sys-libs/libxcrypt to sys-libs/glibc?

> Maybe once this is in place and the obvious/common packages are
> updated, we could request a tinderbox run to flush out what was missed.

I don't think tinderbox will find much as util-linux, shadow or any other
low-level package will pull it in as a dependency and be silently available.

I think you'll need to do extra to find those. Like, removing libcrypt.so
to make sure linker won't find it even if libcrypt.so.1 is available.

> [1] 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> [2] https://bugs.gentoo.org/699422


-- 

  Sergei



Re: [gentoo-portage-dev] [PATCH] install.py: ignore -Z / --context

2019-11-07 Thread Zac Medico
On 11/7/19 10:22 AM, Mike Gilbert wrote:
> The --context option accepts an optional argument, but only if it is
> passed via --context=arg. The argparse module does not deal with this
> properly.
> 
> To work around this, have argparse ignore this option, and filter out
> any remaining arguments that start with a hyphen.
> 
> Bug: https://bugs.gentoo.org/699548
> Signed-off-by: Mike Gilbert 
> ---
>  bin/install.py | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/bin/install.py b/bin/install.py
> index d3789ed96..e56475ff1 100755
> --- a/bin/install.py
> +++ b/bin/install.py
> @@ -111,12 +111,6 @@ def parse_args(args):
>   action="store_true",
>   dest="no_target_directory"
>   )
> - parser.add_argument(
> - "--context",
> - "-Z",
> - action="store",
> - dest="context"
> - )
>   parser.add_argument(
>   "--verbose",
>   "-v",
> @@ -147,7 +141,7 @@ def parse_args(args):
>  
>   opts  = parsed_args[0]
>   files = parsed_args[1]
> - files = [f for f in files if f != "--"] # filter out "--"
> + files = [f for f in files if not f.startswith("-")] # filter unknown 
> options
>  
>   return (opts, files)
>  
> 

Technically, shouldn't we pass through any "files" that start with "-"
and come after the "--" separator?
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Michał Górny
On Thu, 2019-11-07 at 11:52 -0800, Patrick McLean wrote:
> Given glibc upstream's tentative plans to remove libcrypt [1], I think
> we should start working out the kinks well in advance. Toolchain has
> already added a package.use.force-ed "crypt" USE flag to
> sys-libs/glibc-2.30-r2 [2]. The main alternative out there is libxcrypt,
> which I have recently bumped and added a package.use.mask-ed "system"
> USE flag to make it provide the "system" version of libcrypt.so.
> 
> To give us time to work out dependencies in advance, I would like to
> propose a virtual to provide libcrypt.so, and we can gradually update
> all users of libcrypt to {R,}DEPEND on this virtual.
> 
> Maybe once this is in place and the obvious/common packages are
> updated, we could request a tinderbox run to flush out what was missed.

Are you planning to use backwards-compatible .so.1 version of libxcrypt,
or do you plan to switch to .so.2?

> 
> 
> [1] 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> [2] https://bugs.gentoo.org/699422

-- 
Best regards,
Michał Górny



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


[gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

2019-11-07 Thread Patrick McLean
Given glibc upstream's tentative plans to remove libcrypt [1], I think
we should start working out the kinks well in advance. Toolchain has
already added a package.use.force-ed "crypt" USE flag to
sys-libs/glibc-2.30-r2 [2]. The main alternative out there is libxcrypt,
which I have recently bumped and added a package.use.mask-ed "system"
USE flag to make it provide the "system" version of libcrypt.so.

To give us time to work out dependencies in advance, I would like to
propose a virtual to provide libcrypt.so, and we can gradually update
all users of libcrypt to {R,}DEPEND on this virtual.

Maybe once this is in place and the obvious/common packages are
updated, we could request a tinderbox run to flush out what was missed.


[1] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
[2] https://bugs.gentoo.org/699422


libcrypt-0.ebuild
Description: Binary data


Re: [gentoo-dev] Package up for grabs: sys-apps/lsb-release

2019-11-07 Thread Thomas Deutschmann
On 2019-11-07 18:57, Jeroen Roovers wrote:
> sys-apps/lsb-release - Linux Standard Base version query program
> 
> Low maintenance, but with six open bug reports.

base-system will take that package.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


[gentoo-portage-dev] [PATCH] install.py: ignore -Z / --context

2019-11-07 Thread Mike Gilbert
The --context option accepts an optional argument, but only if it is
passed via --context=arg. The argparse module does not deal with this
properly.

To work around this, have argparse ignore this option, and filter out
any remaining arguments that start with a hyphen.

Bug: https://bugs.gentoo.org/699548
Signed-off-by: Mike Gilbert 
---
 bin/install.py | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/bin/install.py b/bin/install.py
index d3789ed96..e56475ff1 100755
--- a/bin/install.py
+++ b/bin/install.py
@@ -111,12 +111,6 @@ def parse_args(args):
action="store_true",
dest="no_target_directory"
)
-   parser.add_argument(
-   "--context",
-   "-Z",
-   action="store",
-   dest="context"
-   )
parser.add_argument(
"--verbose",
"-v",
@@ -147,7 +141,7 @@ def parse_args(args):
 
opts  = parsed_args[0]
files = parsed_args[1]
-   files = [f for f in files if f != "--"] # filter out "--"
+   files = [f for f in files if not f.startswith("-")] # filter unknown 
options
 
return (opts, files)
 
-- 
2.24.0




[gentoo-dev] Package up for grabs: sys-apps/lsb-release

2019-11-07 Thread Jeroen Roovers
sys-apps/lsb-release - Linux Standard Base version query program

Low maintenance, but with six open bug reports.


Regards,
 jer



[gentoo-dev] Last rites: net-misc/openssh-blacklist

2019-11-07 Thread Thomas Deutschmann
# Thomas Deutschmann  (2019-11-07)
# EAPI 0. It's been almost a decade since that openssl bug.
# Removal in 30 days.  Bug #697218.
net-misc/openssh-blacklist


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-analyzer/zabbix

2019-11-07 Thread Tomas Mozes
On Thu, Nov 7, 2019 at 11:13 AM Vadim A. Misbakh-Soloviov 
wrote:

> I'm using zabbix, but I can't sign up as the single active maintainer,
> although, I'd be happy to co-maintain it with somebody else.
>
> BTW, @mgorny, as I see, Patrick already fixed the issue, so can we talk
> about
> unmasking and un-lastriting zabbix now?
>
>
> --
> Best regards,
> mva


It's not masked any more.


[gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-analyzer/zabbix

2019-11-07 Thread Vadim A. Misbakh-Soloviov
I'm using zabbix, but I can't sign up as the single active maintainer, 
although, I'd be happy to co-maintain it with somebody else.

BTW, @mgorny, as I see, Patrick already fixed the issue, so can we talk about 
unmasking and un-lastriting zabbix now? 


-- 
Best regards,
mva

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