Re: [gentoo-dev] [PATCH v1] eclass/savedconfig.eclass: rewrite the ROFF macros
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-dev] [PATCH v1] eclass/savedconfig.eclass: rewrite the ROFF macros
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-dev] rfc: virtual/libcrypt for libcrypt.so implementation
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
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
* 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
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
>
Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation
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-dev] rfc: virtual/libcrypt for libcrypt.so implementation
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
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
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-dev] Package up for grabs: sys-apps/lsb-release
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
# 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
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
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.
