Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 699422 (libxcrypt-migration) - sys-libs/glibc: switch to libxcrypt as libcrypt.so.1 (or .so.2) provider
Summary: sys-libs/glibc: switch to libxcrypt as libcrypt.so.1 (or .so.2) provider
Status: IN_PROGRESS
Alias: libxcrypt-migration
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: Gentoo Toolchain Maintainers
URL: https://wiki.gentoo.org/wiki/Project:...
Whiteboard: Migration pushed to tree in ~arch
Keywords: PullRequest
Depends on: 798963 799131 802210 749933 796722 798468 799707 801403 802207 802222 802267 802648 802807 804085 805347
Blocks:
  Show dependency tree
 
Reported: 2019-11-06 07:27 UTC by Sergei Trofimovich (RETIRED)
Modified: 2021-08-21 15:17 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Trofimovich (RETIRED) gentoo-dev 2019-11-06 07:27:16 UTC
glibc-2.28 allows you to disable libcrypt.so.1 and it's header:

* We have tentative plans to hand off maintenance of the passphrase-hashing
  library, libcrypt, to a separate development project that will, we hope,
  keep up better with new passphrase-hashing algorithms.  We will continue
  to declare 'crypt' in <unistd.h>, and programs that use 'crypt' or
  'crypt_r' should not need to change at all; however, distributions will
  need to install <crypt.h> and libcrypt from a separate project.

  In this release, if the configure option --disable-crypt is used, glibc
  will not install <crypt.h> or libcrypt, making room for the separate
  project's versions of these files.  The plan is to make this the default
  behavior in a future release.

https://github.com/besser82/libxcrypt provides a substitute in various forms (ABI compatible and not compatible).

We need to come up with a transition plan to keep user's systems working while moving to a new library.
Comment 1 Patrick McLean gentoo-dev 2019-11-06 07:35:04 UTC
A package.use.force-ed "crypt" USE flag could be useful in testing transition plans, and hopefully come up with one that breaks the least things.

We could also do some tinderbox runs with it turned off to find packages that would need their dependencies updated.
Comment 2 Sergei Trofimovich (RETIRED) gentoo-dev 2019-11-06 07:42:45 UTC
A few immediate requirements I see are:
1. /lib64/libcrypt.so.1 (amd64) should be provided either by glibc or by libxcrypt
2. have a dependency story: what should clients depend on? Some options are:
  - depend on glibc (glibc has an RDEPEND). rebuild information will not be propagated if/when libxcrpt changes ABI
  - depend on libxcrypt explicitly
  - depend on a virtual. virtual will need to provide ABI information
3. transition of ownership from glibc to libxcrypt must not break running applications. that can be done either by keeping libcrypt.so.1 in glibc for a while or by installing libcrypt.so.1 from libxcrypt
4. other libcs will need a story around symbol ownership: for example musl provides crypt() as part of libc.so. I'm not sure it there is a way to disable it.
Comment 3 Sergei Trofimovich (RETIRED) gentoo-dev 2019-11-06 20:06:46 UTC
5. There needs to be clear expectation of (in)compatibility switching libcrypt.so.1 across providers: are they 1:1 compatible or not. AFAIU the current state is that libxcrypt is a superset of glibc.
Comment 4 Larry the Git Cow gentoo-dev 2019-11-06 20:10:42 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=95fbc62a625a8025f3317e6ddd3b5c431a0968c8

commit 95fbc62a625a8025f3317e6ddd3b5c431a0968c8
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-11-06 20:10:23 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-11-06 20:10:36 +0000

    sys-libs/glibc: introduce USE=+crypt
    
    Today libcrypt.so.1 is provided by glibc. Eventually glibc will
    stop providing it in favoud of external providers like libcrypt.
    
    USE=crypt exposes a knob to disable libcrypt.so.1 installation.
    Use at your own risk. There currently is no replacement yet in
    Gentoo.
    
    Bug: https://bugs.gentoo.org/699422
    Package-Manager: Portage-2.3.78, Repoman-2.3.17
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 sys-libs/glibc/glibc-2.30-r2.ebuild | 3 ++-
 sys-libs/glibc/metadata.xml         | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd4520d0493793c95dcfd23d0c10adc2cbc4b79a

commit dd4520d0493793c95dcfd23d0c10adc2cbc4b79a
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-11-06 20:07:01 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-11-06 20:10:35 +0000

    profiles/base/package.use.force: use.force glibc[crypt]
    
    This will allow dropping bundled crypt by early adopters.
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 profiles/base/package.use.force | 7 +++++++
 1 file changed, 7 insertions(+)
Comment 5 Michael 'veremitz' Everitt 2019-11-08 22:44:25 UTC
As regards to musl, I wrote to the mailing-list, and this was the reply: https://www.openwall.com/lists/musl/2019/11/08/10 . Somewhat out of my depth here, if someone wants to pick up the baton .. ;)
Comment 6 Sergei Trofimovich (RETIRED) gentoo-dev 2020-02-07 08:33:38 UTC
Practically toolchain@ does not drive the transition.

None of the questions of #comment3 / #comment4 were answered here or in https://archives.gentoo.org/gentoo-dev/message/94a9934d91472fcc48f54ee1084cab1e. 

It makes it very hard for me to reason about interaction of libxcrypt with glibc or other libcs.

Closing as OBSOLETE for toolchain@.
Comment 7 Andreas K. Hüttel archtester gentoo-dev 2020-04-23 21:07:56 UTC
> None of the questions of #comment3 / #comment4 were answered here or in
> https://archives.gentoo.org/gentoo-dev/message/
> 94a9934d91472fcc48f54ee1084cab1e. 

I'll have a look and prepare. Feel free to refer questions to me.
Comment 8 Andreas K. Hüttel archtester gentoo-dev 2021-01-01 16:41:14 UTC
OK trying to summarize the current state here:

> 1. /lib64/libcrypt.so.1 (amd64) should be provided either by glibc or by
> libxcrypt

It is provided by sys-libs/glibc[crypt] and by sys-libs/libxcrypt[compat]

I suspect libxcrypt installs into /usr/lib64 though.

> 2. have a dependency story: what should clients depend on? Some options are:
>   - depend on glibc (glibc has an RDEPEND). rebuild information will not be
> propagated if/when libxcrpt changes ABI
>   - depend on libxcrypt explicitly
>   - depend on a virtual. virtual will need to provide ABI information

Currently we have a virtual virtual/libcrypt

Slot 1: 
Installs libcrypt.so.1 and corresponding headers via glibc

Slot 2:
Installs libcrypt.so.2 and corresponding headers via libxcrypt
Makes no statement whether libcrypt.so.1 is installed, but it cannot be provided by glibc, only by libxcrypt.
(The virtual requests libxcrypt[system], which requires glibc[-crypt]. [system] controls where the library header files go, directly into include or in a subdir.)

> 3. transition of ownership from glibc to libxcrypt must not break running
> applications. that can be done either by keeping libcrypt.so.1 in glibc for
> a while or by installing libcrypt.so.1 from libxcrypt

This can be achieved via enabling the compat useflag of libxcrypt (which installs libcrypt.so.1). 

Now the precise transition process (emerge rebuild sequence) is a more interesting question. If preserved-libs works, that should be no problem though.

> 4. other libcs will need a story around symbol ownership: for example musl
> provides crypt() as part of libc.so. I'm not sure it there is a way to
> disable it.

The reply from musl upstream linked in comment #5: We dont care. Feel free to load libxcrypt and that way shadow our internal implementation.

> 5. There needs to be clear expectation of (in)compatibility switching
> libcrypt.so.1 across providers: are they 1:1 compatible or not. AFAIU the
> current state is that libxcrypt is a superset of glibc.

Correct. Current state:

* Binaries built against glibc[crypt] should work just fine with libxcrypt[compat].
* Binaries built against libxcrypt will link against libcrypt.so.2

This means switching back from libxcrypt to glibc is only possible via preserved-libs etc. 

==

@chutzpah: could you please proofread this whether I summarized it correctly?
Comment 9 Patrick McLean gentoo-dev 2021-01-04 19:17:33 UTC
(In reply to Andreas K. Hüttel from comment #8)
> OK trying to summarize the current state here:
> 
> > 1. /lib64/libcrypt.so.1 (amd64) should be provided either by glibc or by
> > libxcrypt
> 
> It is provided by sys-libs/glibc[crypt] and by sys-libs/libxcrypt[compat]
> 
> I suspect libxcrypt installs into /usr/lib64 though.

sys-libs/libxcrypt[compat] installs 
libcrypt.so.1 to /lib64 (along with libcrypt.so.2)

> > 2. have a dependency story: what should clients depend on? Some options are:
> >   - depend on glibc (glibc has an RDEPEND). rebuild information will not be
> > propagated if/when libxcrpt changes ABI
> >   - depend on libxcrypt explicitly
> >   - depend on a virtual. virtual will need to provide ABI information
> 
> Currently we have a virtual virtual/libcrypt
> 
> Slot 1: 
> Installs libcrypt.so.1 and corresponding headers via glibc
> 
> Slot 2:
> Installs libcrypt.so.2 and corresponding headers via libxcrypt
> Makes no statement whether libcrypt.so.1 is installed, but it cannot be
> provided by glibc, only by libxcrypt.
> (The virtual requests libxcrypt[system], which requires glibc[-crypt].
> [system] controls where the library header files go, directly into include
> or in a subdir.)
> 
> > 3. transition of ownership from glibc to libxcrypt must not break running
> > applications. that can be done either by keeping libcrypt.so.1 in glibc for
> > a while or by installing libcrypt.so.1 from libxcrypt
> 
> This can be achieved via enabling the compat useflag of libxcrypt (which
> installs libcrypt.so.1). 

Just to note here, the compat useflag of libxcrypt is on by default.

> 
> Now the precise transition process (emerge rebuild sequence) is a more
> interesting question. If preserved-libs works, that should be no problem
> though.

preserved-libs does detect libcrypt.so.1 and preserve it if necessary, though as I note above the compat useflag on libxcrypt is on by default, so it will install libcrypt.so.1.

> > 4. other libcs will need a story around symbol ownership: for example musl
> > provides crypt() as part of libc.so. I'm not sure it there is a way to
> > disable it.

virtual/libcrypt:2 currently won't pull in libxcrypt on musl systems (and uclibc systems).

> The reply from musl upstream linked in comment #5: We dont care. Feel free
> to load libxcrypt and that way shadow our internal implementation.
> 
> > 5. There needs to be clear expectation of (in)compatibility switching
> > libcrypt.so.1 across providers: are they 1:1 compatible or not. AFAIU the
> > current state is that libxcrypt is a superset of glibc.
> 
> Correct. Current state:
> 
> * Binaries built against glibc[crypt] should work just fine with
> libxcrypt[compat].
> * Binaries built against libxcrypt will link against libcrypt.so.2
> 
> This means switching back from libxcrypt to glibc is only possible via
> preserved-libs etc. 
> 
> ==
> 
> @chutzpah: could you please proofread this whether I summarized it correctly?

I noted a couple of clarifications and corrections above.
Comment 10 Larry the Git Cow gentoo-dev 2021-06-17 05:03:44 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4e2b8599caede5cdcb747d7505ffae04144d7efe

commit 4e2b8599caede5cdcb747d7505ffae04144d7efe
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-06-17 04:23:18 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-06-17 05:03:17 +0000

    sys-libs/libxcrypt: assign to toolchain@
    
    Switch to toolchain@ as maintainer given this is soon(?) going
    to replace a core part of glibc (libcrypt).
    
    hardened@ is a quiet, less-well-defined project which makes it
    less suitable for an important package.
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/libxcrypt/metadata.xml | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)
Comment 11 Larry the Git Cow gentoo-dev 2021-06-18 22:51:01 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=929025d74438f10d7b9d9f79d2002a953eb89aba

commit 929025d74438f10d7b9d9f79d2002a953eb89aba
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-06-18 22:47:31 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-06-18 22:50:12 +0000

    profiles: add note to libxcrypt mask(s) to treat with care for non-glibc
    
    We'll need to keep the masks for non-glibc (musl, uclibc{,-ng}, ...) so
    make a note of it to prevent an issue down the line.
    
    Reported-by: Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com>
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/base/package.use.force | 4 ++--
 profiles/base/package.use.mask  | 1 +
 profiles/package.mask           | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)
Comment 12 Larry the Git Cow gentoo-dev 2021-06-24 22:02:01 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0aba872326b1a2fd8fab415959bf1759f2b0a635

commit 0aba872326b1a2fd8fab415959bf1759f2b0a635
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-06-24 22:01:26 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-06-24 22:01:35 +0000

    virtual/libcrypt: destabilize 2
    
    Needed to avoid accidents when we do the unmasking in the future.
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 virtual/libcrypt/libcrypt-2.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 13 Larry the Git Cow gentoo-dev 2021-06-26 23:09:37 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4cc70444a0077f9b807593ab322d05a6b3737666

commit 4cc70444a0077f9b807593ab322d05a6b3737666
Author:     Georgy Yakovlev <gyakovlev@gentoo.org>
AuthorDate: 2021-06-25 05:24:12 +0000
Commit:     Georgy Yakovlev <gyakovlev@gentoo.org>
CommitDate: 2021-06-26 23:08:22 +0000

    metadata/install-qa-check.d: add virtual/libcrypt dep check
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>

 metadata/install-qa-check.d/60libcrypt-deps | 38 +++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
Comment 14 Larry the Git Cow gentoo-dev 2021-06-28 01:31:52 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6aeaf45b893a4047095067fcfc0e52f5f50afb32

commit 6aeaf45b893a4047095067fcfc0e52f5f50afb32
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-06-28 01:30:00 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-06-28 01:31:43 +0000

    profiles: change virtual/libcrypt mask to ~ prefix
    
    This is needed to ensure users don't have obsolete >= unmasks
    in their configurations which might, in future, be used
    for other purposes (like disabling compatibility mode, even if
    that's indefinitely masked).
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/package.mask | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 15 Michael 'veremitz' Everitt 2021-06-28 18:29:00 UTC
ago,

might I suggest instead of blocking this bug with a load of spam entries from your testing system, that perhaps you use the Tracker bug 798963 .

Thank you
Comment 16 Agostino Sarubbo gentoo-dev 2021-06-28 18:35:45 UTC
(In reply to Michael 'veremitz' Everitt from comment #15)
> ago,
> 
> might I suggest instead of blocking this bug with a load of spam entries
> from your testing system, that perhaps you use the Tracker bug 798963 .
> 
> Thank you

Bugs were filed before read irc messages were I was advised.
Comment 17 Sam James archtester gentoo-dev Security 2021-07-01 00:02:48 UTC
News item posted: https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=204d52b41581306d7fa30dd0634c581b18b8eedc.

Migration slated for 14th July.
Comment 18 Larry the Git Cow gentoo-dev 2021-07-02 02:30:12 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e165e102e112609de700e78b2fb6d4145ab4a6fe

commit e165e102e112609de700e78b2fb6d4145ab4a6fe
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-07-01 04:08:32 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-07-02 02:27:00 +0000

    sys-libs/libxcrypt: switch to pre-generated autotools tarballs
    
    There are actually *two* circular dependencies involving Perl:
    
    1) Use self-generated (for now) `make dist` tarballs to avoid a circular
       dependency with libxcrypt->automake->perl->libxcrypt.
    
       (Thanks juippis and floppym! We noticed this because juippis hit an
       interesting edge case when using binpkgs.)
    
    2) We initially tried to pre-generate the results of a Perl tool called
       during `./configure` in order to avoid unconditionally needing
       Perl.
    
       (I thought we could do this because the input is constant for all of the
       Gentoo build variants - for now.
    
       I later realised there's other Perl usage which we're stuck with
       for now without pre-generating a *lot*.)
    
       (Thanks mattst88! We noticed this while digging into suggestions
       for upstream.)
    
    So, for now, we're just fixing 1), and adding a BDEPEND on Perl for 2) to
    make it explicit.
    
    (Both best explained within the comments of the ebuild.)
    
    Bug: https://bugs.gentoo.org/699422
    Closes: https://github.com/gentoo/gentoo/pull/21493
    Reported-by: Joonas Niilola <juippis@gentoo.org>
    Reported-by: Mike Gilbert <floppym@gentoo.org>
    Reported-by: Matt Turner <mattst88@gentoo.org>
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/libxcrypt/Manifest                |  4 +-
 sys-libs/libxcrypt/libxcrypt-4.4.20.ebuild | 80 +++++++++++++++++++++++-------
 sys-libs/libxcrypt/libxcrypt-4.4.23.ebuild | 80 +++++++++++++++++++++++-------
 3 files changed, 126 insertions(+), 38 deletions(-)
Comment 19 Larry the Git Cow gentoo-dev 2021-07-05 23:46:49 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=3bd3959aa328c89f1ef959bfc342acef117c28a4

commit 3bd3959aa328c89f1ef959bfc342acef117c28a4
Author:     Alexey Sokolov <sokolov@google.com>
AuthorDate: 2021-07-01 22:49:22 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-07-05 23:46:43 +0000

    2021-06-30-libxcrypt-migration: Translate libxcrypt news to Russian
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Alexey Sokolov <sokolov@google.com>
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-06-30-libxcrypt-migration.ru.txt          | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)
Comment 20 Larry the Git Cow gentoo-dev 2021-07-14 20:46:09 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f79a445a9d0cfeec8ff47d591b3f76cbe2e8b86

commit 6f79a445a9d0cfeec8ff47d591b3f76cbe2e8b86
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2021-07-14 18:48:11 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2021-07-14 20:45:57 +0000

    package.mask: unmask virtual/libcrypt-2, except on musl/uclibc
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 profiles/features/musl/package.mask   | 4 ++++
 profiles/features/uclibc/package.mask | 4 ++++
 profiles/package.mask                 | 5 -----
 3 files changed, 8 insertions(+), 5 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4ced298fd259cbd089f994e084b30a58718b37fe

commit 4ced298fd259cbd089f994e084b30a58718b37fe
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2021-07-14 18:47:12 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2021-07-14 20:45:54 +0000

    package.use.{mask,force}: adapt for libxcrypt transition, except musl/uclibc
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 profiles/base/package.use.force            |  8 ++++----
 profiles/base/package.use.mask             | 10 ++++++----
 profiles/features/musl/package.use.force   |  4 ++++
 profiles/features/musl/package.use.mask    |  4 ++++
 profiles/features/uclibc/package.use.force |  6 ++++++
 profiles/features/uclibc/package.use.mask  |  4 ++++
 6 files changed, 28 insertions(+), 8 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d0633cc281cb8beb325beaa9627c9858c20fdd5

commit 3d0633cc281cb8beb325beaa9627c9858c20fdd5
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2021-07-14 18:41:34 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2021-07-14 20:45:51 +0000

    sys-libs/glibc: ~arch revision bump without changes
    
    Bug: https://bugs.gentoo.org/699422
    Package-Manager: Portage-3.0.20, Repoman-3.0.3
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 sys-libs/glibc/glibc-2.33-r2.ebuild | 1520 +++++++++++++++++++++++++++++++++++
 1 file changed, 1520 insertions(+)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1af401d6306a20c90bea3f3c05bf6c4d6e74529

commit d1af401d6306a20c90bea3f3c05bf6c4d6e74529
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2021-07-14 18:40:11 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2021-07-14 20:45:48 +0000

    sys-libs/libxcrypt: Revision bump without changes
    
    Bug: https://bugs.gentoo.org/699422
    Package-Manager: Portage-3.0.20, Repoman-3.0.3
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 sys-libs/libxcrypt/libxcrypt-4.4.23-r1.ebuild | 207 ++++++++++++++++++++++++++
 1 file changed, 207 insertions(+)
Comment 21 Larry the Git Cow gentoo-dev 2021-07-22 23:41:21 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=0d11e58acccb28e8371d53ed53806a8a2d7b16be

commit 0d11e58acccb28e8371d53ed53806a8a2d7b16be
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-07-20 21:28:48 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-07-22 23:41:12 +0000

    2021-07-21-libxcrypt-migration: new news item for libxcrypt migration changes
    
    This amends the previous news item to include more information
    about PAM issues.
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-06-30-libxcrypt-migration.ru.txt          | 47 ----------------------
 .../2021-07-23-libxcrypt-migration.en.txt          |  4 +-
 2 files changed, 2 insertions(+), 49 deletions(-)
Comment 22 Larry the Git Cow gentoo-dev 2021-07-29 21:50:26 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=1d2f17df23f2245cd51da75b0c9ca8bc12bdf7d0

commit 1d2f17df23f2245cd51da75b0c9ca8bc12bdf7d0
Author:     Alexey Sokolov <sokolov@google.com>
AuthorDate: 2021-07-29 21:43:06 +0000
Commit:     Stefan Strogin <steils@gentoo.org>
CommitDate: 2021-07-29 21:49:02 +0000

    2021-07-23-libxcrypt-migration: add updated Russian translation
    
    Bug: https://bugs.gentoo.org/699422
    Signed-off-by: Alexey Sokolov <sokolov@google.com>
    Signed-off-by: Stefan Strogin <steils@gentoo.org>

 .../2021-07-23-libxcrypt-migration.ru.txt          | 67 ++++++++++++++++++++++
 1 file changed, 67 insertions(+)