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.
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.
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.
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.
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(+)
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 .. ;)
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@.
> 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.
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?
(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.
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(-)
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(-)
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(-)
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(+)
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(-)
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
(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.
News item posted: https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=204d52b41581306d7fa30dd0634c581b18b8eedc. Migration slated for 14th July.
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(-)
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(+)
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(+)
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(-)
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(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=c0fc80bac65a65d04ca4ce503c233d238d43d390 commit c0fc80bac65a65d04ca4ce503c233d238d43d390 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-31 21:22:33 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-31 21:25:05 +0000 2021-10-18-libxcrypt-migration-stable: tweak guidance slightly Bug: https://bugs.gentoo.org/809410 Bug: https://bugs.gentoo.org/699422 Signed-off-by: Sam James <sam@gentoo.org> .../2021-10-18-libxcrypt-migration-stable.en.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d081cb997d18d200c71e1ff394e17db2f01f38d commit 3d081cb997d18d200c71e1ff394e17db2f01f38d Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-11 21:02:52 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-11 21:02:52 +0000 sys-libs/glibc: drop Python 3.10 from PYTHON_COMPAT to avoid circular deps Needed for now to try help upgrades and avoid circular dependencies with glibc -> python -> libcrypt -> libxcrypt -> glibc -> ... Bug: https://bugs.gentoo.org/699422 Bug: https://bugs.gentoo.org/702806 Bug: https://bugs.gentoo.org/809410 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.33-r7.ebuild | 5 ++++- sys-libs/glibc/glibc-2.34-r1.ebuild | 5 ++++- sys-libs/glibc/glibc-9999.ebuild | 5 ++++- 3 files changed, 12 insertions(+), 3 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=1c4eb83b3e4a1f453d16e8a2356ddf61651b5310 commit 1c4eb83b3e4a1f453d16e8a2356ddf61651b5310 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-12 04:58:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-12 04:58:26 +0000 2021-10-18-libxcrypt-migration-stable: mention being in root shell if possible Bug: https://bugs.gentoo.org/699422 Bug: https://bugs.gentoo.org/809410 Signed-off-by: Sam James <sam@gentoo.org> .../2021-10-18-libxcrypt-migration-stable.en.txt | 5 +++++ 1 file changed, 5 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01fd1ed53bffbcb11aa1734eb0ca42d3597318f5 commit 01fd1ed53bffbcb11aa1734eb0ca42d3597318f5 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-22 06:08:11 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-22 06:28:17 +0000 profiles: mask (older) virtual/libcrypt:0/1 for glibc to ease upgrades Mask the older virtual/libcrypt subslot (which permits glibc[crypt] instead of libxcrypt) to ease upgrades. Not yet doing this for musl (need to figure that out still) or uclibc (which is going away, see news). Was on the fence about doing this given it makes it slightly more awkward to put off the upgrade if desired, but that's really discouraged at this point, and I think it's worth it to make upgrades easier for more people. This helps Portage realise it can/should upgrade to virtual/libcrypt:0/2 rather than giving very confusing blocker errors (which it often, but not always, gets past). Final push to do this was a forum post: https://forums.gentoo.org/viewtopic-t-1145602.html Bug: https://bugs.gentoo.org/699422 Bug: https://bugs.gentoo.org/809410 Signed-off-by: Sam James <sam@gentoo.org> profiles/base/package.mask | 9 +++++++++ profiles/features/musl/package.mask | 1 + profiles/features/uclibc/package.mask | 1 + 3 files changed, 11 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=8f2ad6dd0515374e473b79d6f6cbc32ac8050680 commit 8f2ad6dd0515374e473b79d6f6cbc32ac8050680 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-22 06:14:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-22 06:14:07 +0000 2021-10-18-libxcrypt-migration-stable: mention unmasking libcrypt:0/1 for delay If users want to delay the upgrade (please don't do this though), they will (shortly) need to unmask virtual/libcrypt:0/1 too. Bug: https://bugs.gentoo.org/699422 Bug: https://bugs.gentoo.org/809410 Signed-off-by: Sam James <sam@gentoo.org> .../2021-10-18-libxcrypt-migration-stable.en.txt | 1 + 1 file changed, 1 insertion(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=4cd7ab13760667cc70b151cfb592ef9868dcba70 commit 4cd7ab13760667cc70b151cfb592ef9868dcba70 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-25 00:49:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-25 00:49:07 +0000 2021-07-23-libxcrypt-migration: delete older version of libxcrypt news item We've updated the "in stable" one (the newer news item) a few times so having this one around is confusing. Bug: https://bugs.gentoo.org/809410 Bug: https://bugs.gentoo.org/699422 Signed-off-by: Sam James <sam@gentoo.org> .../2021-07-23-libxcrypt-migration.en.txt | 65 --------------------- .../2021-07-23-libxcrypt-migration.ru.txt | 67 ---------------------- 2 files changed, 132 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=b76a1d4a5fa5a0e2a81d93c086d3077da82de89b commit b76a1d4a5fa5a0e2a81d93c086d3077da82de89b Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-16 06:25:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-16 06:25:26 +0000 2021-10-18-libxcrypt-migration-stable: improve readability a bit Bug: https://bugs.gentoo.org/699422 Bug: https://bugs.gentoo.org/809410 Signed-off-by: Sam James <sam@gentoo.org> .../2021-10-18-libxcrypt-migration-stable.en.txt | 31 +++++++++++++++++----- 1 file changed, 24 insertions(+), 7 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aabea35bb6fdc0e5de5b899c0c2efa8e9570b1e1 commit aabea35bb6fdc0e5de5b899c0c2efa8e9570b1e1 Author: Adrian Ratiu <adrian.ratiu@collabora.com> AuthorDate: 2022-04-22 13:38:58 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-04-23 23:54:32 +0000 sys-libs/libxcrypt: add cross-* build support This logic is required for cross LLVM toolchains built against glibc with its libcrypt disabled because compiler-rt requires a crypt.h header for its sanitizers, leading to a circular build dependency situation: libxcrypt -> compiler-rt -> libxcrypt To break this circular dep other cross-compilation build systems like Yocto have disabled compiler-rt sanitizers entirely [1] or a crypt.h header might be copied into the compiler-rt sources. A better solution than the above two is to directly be able to build libxcrypt before compiler-rt in the cross toolchain setup steps which is what this addition enables. [1] https://github.com/kraj/meta-clang/pull/426 Bug: https://bugs.gentoo.org/699422 Co-authored-by: Sam James <sam@gentoo.org> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Closes: https://github.com/gentoo/gentoo/pull/20601 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/libxcrypt/libxcrypt-4.4.28.ebuild | 64 +++++++++++++++++++++++++----- 1 file changed, 55 insertions(+), 9 deletions(-)
Nothing to track here anymore, all done in stable.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=68061fbd8345c59ec19fbad1bf1569d55186c19a commit 68061fbd8345c59ec19fbad1bf1569d55186c19a Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-08 03:40:44 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-10 11:28:03 +0000 profiles/features/musl: set -crypt on sys-libs/musl musl will still work with its own libcrypt, but applications and libraries are starting to need a fancier libcrypt (libxcrypt) so let's disable USE=crypt by default on sys-libs/musl to have libxcrypt provide crypt.h & libcrypt.so (musl's libcrypt is included in libc.so). This brings musl in line with the changes we made for glibc a while ago. The situation with glibc is a bit different because the migration is mandatory there, while we're just strongly recommending it for musl because sys-libs/libxcrypt[-system] causes headaches (see linked PAM bug for an example, but I've also hit a similar issue with Python yesterday). Bug: https://bugs.gentoo.org/867991 Bug: https://bugs.gentoo.org/699422 Signed-off-by: Sam James <sam@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/27187 Signed-off-by: Sam James <sam@gentoo.org> profiles/features/musl/package.use | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f63e433a3db50537ff903195e7e7c90b80d68047 commit f63e433a3db50537ff903195e7e7c90b80d68047 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-08 03:23:18 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-10 11:28:03 +0000 profiles/features/musl: unmask sys-libs/libxcrypt[system] This brings musl in line with the changes we made for glibc a while ago. The situation with glibc is a bit different because the migration is mandatory there, while we're just strongly recommending it for musl because sys-libs/libxcrypt[-system] causes headaches (see linked PAM bug for an example, but I've also hit a similar issue with Python yesterday). Bug: https://bugs.gentoo.org/867991 Bug: https://bugs.gentoo.org/699422 Signed-off-by: Sam James <sam@gentoo.org> profiles/features/musl/package.mask | 5 ----- profiles/features/musl/package.use.force | 4 ++-- profiles/features/musl/package.use.mask | 2 +- 3 files changed, 3 insertions(+), 8 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4b7575b3f13e546dd2431d0ab8db699935392bdb commit 4b7575b3f13e546dd2431d0ab8db699935392bdb Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-08 03:34:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-10 11:28:03 +0000 virtual/libcrypt: add 2-r1 with support for musl This brings musl in line with the changes we made for glibc a while ago. The situation with glibc is a bit different because the migration is mandatory there, while we're just strongly recommending it for musl because sys-libs/libxcrypt[-system] causes headaches (see linked PAM bug for an example, but I've also hit a similar issue with Python yesterday). Bug: https://bugs.gentoo.org/867991 Bug: https://bugs.gentoo.org/699422 Signed-off-by: Sam James <sam@gentoo.org> virtual/libcrypt/libcrypt-2-r1.ebuild | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=777ef3df1b81456b7b733d5673b341c6b9a22d88 commit 777ef3df1b81456b7b733d5673b341c6b9a22d88 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-08 03:24:29 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-10 11:28:03 +0000 sys-libs/libxcrypt: wire up musl USE=system support This brings musl in line with the changes we made for glibc a while ago. The situation with glibc is a bit different because the migration is mandatory there, while we're just strongly recommending it for musl because sys-libs/libxcrypt[-system] causes headaches (see linked PAM bug for an example, but I've also hit a similar issue with Python yesterday). Bug: https://bugs.gentoo.org/867991 Bug: https://bugs.gentoo.org/699422 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/libxcrypt/libxcrypt-4.4.28-r2.ebuild | 304 ++++++++++++++++++++++++++ 1 file changed, 304 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fbdcef42c8f58fdd5175f2130afd56b8e42ef226 commit fbdcef42c8f58fdd5175f2130afd56b8e42ef226 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-08 03:21:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-10 11:28:02 +0000 sys-libs/musl: add USE=crypt for libxcrypt support Add USE=crypt to allow enabling/disabling crypt.h installation (to allow sys-libs/libxcrypt[system] usage). Many things are starting to want functions from libxcrypt itself (additional functions and algorithms). musl isn't removing crypt.h (and the relevant functions from its libc), unlike glibc, but we need to allow disabling the installation of crypt.h to allow libxcrypt[system] usage (which provides crypt.h & libcrypt.so instead, with more functionality). This brings musl in line with the changes we made for glibc a while ago. The situation with glibc is a bit different because the migration is mandatory there, while we're just strongly recommending it for musl because sys-libs/libxcrypt[-system] causes headaches (see linked PAM bug for an example, but I've also hit a similar issue with Python yesterday). Bug: https://bugs.gentoo.org/867991 Bug: https://bugs.gentoo.org/699422 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/musl/musl-1.2.3-r1.ebuild | 181 +++++++++++++++++++++++++++++++++++++ sys-libs/musl/musl-9999.ebuild | 10 +- 2 files changed, 190 insertions(+), 1 deletion(-)
