Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 09-11-2020 19:38:28 +, Alexey Sokolov wrote: > Hi Fabian > I tried to migrate my prefix to 17.1, and there are issues. > > 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an > error "/usr/lib is a real directory! was the migration done already?" I think unsymlink-lib doesn't have Prefix support, but in addition, what unsymlink-lib is trying to achieve, is not a thing perhaps on Prefix. A prefix system (at least all of mine) doesn't have libXX or lib/XX (a.k.a. multilib) directories. The /usr-split was long ago removed, and thus what we have is: lib -> usr/lib Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does not exist on Prefix systems. Since Prefix is non-multilib by design*, I wonder if unsymlink-lib is necessary in the best case, but going to break the Prefix system in the worst case. What instructed you to perform the migration? Was it the news-item? I don't think it should apply for Prefix profiles, and perhaps we should be happy the tool won't work. * non-multilib is a decision dating back a decade or so, which means effectively any Prefix install you encounter should be non-multilib > 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend > usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] > [--rollback] [--finish] [--force-rollback] > [--resume-finish] [-P PREFIX] [--hardlink] > unsymlink-lib: error: Requested action requires root privileges > > Well, I worked it around by adding "is_root = True" to unsymlink-lib Did it do anything to your system like creating a lib64 directory? Does anything work (because I have doubts on whether your system can still find the libs in there now). > > 3) Step 9 (Rebuild gcc) fails: > configure:4372: checking whether the C compiler works > > > > configure:4394: x86_64-pc-linux-gnu-gccconftest.c >&5 > > > > /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as: > error while loading shared libraries: > libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared Something like this I was suspecting. Can you still rollback? If you can, I'd try that and hope it restores your system in working order. For any Prefix user, DO NOT run unsymlink-lib, I believe you should NOT NEED IT! Thanks, Fabian > object file: No such file or directory > configure:4398: $? = 1 > > > > configure:4436: result: no > > The file exists: > $ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so > /home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so > > -- > Best regards, > Alexey "DarthGandalf" Sokolov > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Python 3.8 migration reminder
Hello, developers. The Python team would like to remind you that the switch to Python 3.8 as the default target is planned for 2020-12-01. Please make sure to migrate your packages to give our users a better transition experience. The migration list is at [1], stabilization is at [2]. In other reminders: a. Python 2.7->3 (except for build-time use without dependencies) migration deadline is 2021-01-01. At that point, the remaining packages (read: renpy) will be last rited. Once it's gone, the old versions of any other packages not yet cleaned up (if any) will be removed and the target will be disabled except for python-any-r1. b. Python 3.6->3.7 migration deadline is also 2021-01-01. The remaining packages [3] (stablereq list at [4]) will be last rited then, or have their Python support removed. Once they're gone, python3_6 target will probably be removed (it's already PITA due to IPython stack removing support for Python 3.6). c. With big thanks to Sam for taking care of it, Python 3.9.0 is now stable and the target is now unmasked. I think it's the first time we manage it one month after the release and hopefully it'd make things easier in the future. We don't have any planned dates but maybe we could switch to 3.9 mid-2021, as we're initially planning to kill 3.7 then. Nice migration lists for 3.8->3.9 at [5], [6]. The full timeline can be found at [7]. Thanks and enjoy! [1] https://qa-reports.gentoo.org/output/gpyutils/37-to-38.txt [2] https://qa-reports.gentoo.org/output/gpyutils/37-to-38-stablereq.txt [3] https://qa-reports.gentoo.org/output/gpyutils/37-to-38.txt [4] https://qa-reports.gentoo.org/output/gpyutils/37-to-38-stablereq.txt [5] https://qa-reports.gentoo.org/output/gpyutils/38-to-39.txt [6] https://qa-reports.gentoo.org/output/gpyutils/38-to-39-stablereq.txt [7] https://wiki.gentoo.org/wiki/Project:Python/Implementations -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
07.11.2020 12:56, Fabian Groffen пишет: > On 07-11-2020 11:42:44 +, Alexey Sokolov wrote: >> 22.10.2020 20:16, Andreas K. Hüttel пишет: >>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: > Users frequently are choosing the wrong profile versions in new installs > and accidentally downgrading to 17.0 with some saying they see it first. > > A simple reordering could help new installs. >>> >>> Independent of this useful change, it's probably time to deprecate the >>> amd64 >>> 17.0 profiles! >>> >> >> Prefix bootstrap script still makes new installations to use it > > This should be solved with > > b0445c0a8dd6d2f792c5bb088b154aca53868353 > a9c478dc881ee18fefc7342da994b00e60eaad8e > > on gentoo.git and > > 0d7f6b6eb00d0f51f35019846b8f79048b30be93 > > on prefix.git. > > Thanks, > Fabian > > Hi Fabian I tried to migrate my prefix to 17.1, and there are issues. 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an error "/usr/lib is a real directory! was the migration done already?" 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] [--rollback] [--finish] [--force-rollback] [--resume-finish] [-P PREFIX] [--hardlink] unsymlink-lib: error: Requested action requires root privileges Well, I worked it around by adding "is_root = True" to unsymlink-lib 3) Step 9 (Rebuild gcc) fails: configure:4372: checking whether the C compiler works configure:4394: x86_64-pc-linux-gnu-gccconftest.c >&5 /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as: error while loading shared libraries: libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared object file: No such file or directory configure:4398: $? = 1 configure:4436: result: no The file exists: $ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so /home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH 0/1] depend.apache.eclass: support EAPI-7
On 2020-11-03 20:04, Michael Orlitzky wrote: It's likely broken in EAPI=7, because it was in EAPI=6: https://bugs.gentoo.org/616612 I left a comment there with a proposal for how to fix it, but I haven't thought about it much since then. Indeed, by default this is broken - but in exactly the same way as with EAPI-6, and at least the main issue mentioned in this bug can be addressed by the same workaround. In the long run it would IMHO very much make sense to retire this eclass, looks like it will still take a while though... I might have a look at it but only once I've got Lua and NodeJS taken care of. In the meantime, patch merged. -- MS OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On 11/9/20 5:59 PM, Kent Fredric wrote: > Historical context probably matters here. > > That's a very old statement. > > Partly from the era when Gentoo was "cool" and when "ricing" was a thing. > > At the time, upstream was inundated with absurd requests like "oh noes, > I disabled CXX Exceptions, and the code broke, upstream is wrong!". > > Whatever we did, or upstream did, the absurd complaints have gone away. > Yep, I posted the link more as a joke rather than an actual complaint... but the entry is visible in every machine with urxvt installed while being outdated already. Not that urxvt has recent releases either, but it'd be nice if you could update it for the next one. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On Mon, 9 Nov 2020 12:15:07 +0200 Jaco Kroon wrote: > You mentioned working raport with upstream? Can we rely on that to at > the very least get them to update that to "due to the way Gentoo > functions we request that you first file issues with the Gentoo > repository rather than directly with rxvt-unicode? That is pure and > outright slander, and whilst I "get" (to an extent) and GNU/Linux > statement - he should then have the same issue with RedHat Enterprise > GNU/Linux. Or with "Debian" and "CentOS" for that matter which does not > contain "GNU/Linux" in the name. Alternatively if there is no issue > with that then perhaps we should consider just being "Gentoo" ... Historical context probably matters here. That's a very old statement. Partly from the era when Gentoo was "cool" and when "ricing" was a thing. At the time, upstream was inundated with absurd requests like "oh noes, I disabled CXX Exceptions, and the code broke, upstream is wrong!". Whatever we did, or upstream did, the absurd complaints have gone away. But I'll see what I can wrangle :) pgpfy7l8eNo37.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-11-08 23:59 UTC
On Mon, Nov 9, 2020 at 2:24 AM Ulrich Mueller wrote: > > On Mon, 09 Nov 2020, Robin H Johnson wrote: > > > The attached list notes all of the packages that were added or removed > > from the tree, for the week ending 2020-11-08 23:59 UTC. > > > [...] > > > app-editors/emacs > 20150808-20:49 robbat2 56bd759df1d > > Not really ... > > This is broken for the second week in a row now. Could you suspend these > messages please, until the problem is fixed? > This is an infra job, I've disabled it for now. -A > > Ulrich >
[gentoo-dev] Debian Tools Project packages up for grabs
Hi, all. The following packages are up for grabs as the Debian Tools Project has no active members. All packages have been dropped to maintainer-needed. Enjoy. app-crypt/libmd dev-util/debhelper net-misc/apt-cacher-ng -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/typing
# Michał Górny (2020-11-09) # Python 2 backport. Last revdep masked. # Removal in 30 days. Bug #753725. dev-python/typing -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-python/cheetah
# Michał Górny (2020-11-09) # Dead Python 2 package. Replaced by dev-python/cheetah3. The last # mongodb versions needing it are masked now. # Removal in 30 days. Bug #753722. dev-python/cheetah -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On November 9, 2020 1:54:33 PM GMT+02:00, Peter Stuge wrote: >Andreas K. Hüttel wrote: >> it's probably time to deprecate the amd64 17.0 profiles! > >I for one am not so excited about the amd64 17.1 profiles. On the >surface >it appeared to me that one developer has "taken over" just about >everything, >which (regardless of the individual) can't be a good thing.. > Please wait a bit longer, I'm still working on my evil world domination plans! 😎 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On November 9, 2020 6:54:33 AM EST, Peter Stuge wrote: >Andreas K. Hüttel wrote: >> it's probably time to deprecate the amd64 17.0 profiles! > >I for one am not so excited about the amd64 17.1 profiles. On the >surface >it appeared to me that one developer has "taken over" just about >everything, >which (regardless of the individual) can't be a good thing.. > What does this even mean? > >Jaco Kroon wrote: >> ...just wondering where the lib32 => lib symlink comes from now. > >baselayout contains a conversion to/from lib symlink(s). > > >Kind regards > >//Peter -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] A feedback about the CI bug reporting system
On lunedì 9 novembre 2020 13:13:19 CET Marek Szuba wrote: > I think this might be the case of a "silent majority, vocal minority" > scenario. For the record: I for one have found your tinderbox bugs very > useful, not in the least because you test unusual configurations my own > build testing does not cover. There have been glitches - but IMHO very > few of them, and human operators make mistakes too. > > I still very much wish your tickets were tagged in a way which would > make it possible to separate failures from QA notices (especially those > that show up during normal emerge runs, such as that suspected > DISTUTILS_USE_SETUPTOOLS mismatches), though. I really do not need > e-mail notifications about the latter, looking them up via my p.g.o page > is quite sufficient. Hello Marek and thank you for the feedback. Ftr DISTUTILS_USE_SETUPTOOLS has been disabled for a while but I think we can use a tag in WHITEBOARD to meet your needs. I think it has been used in the past and it doesn't hurt have it. Agostino
Re: [gentoo-dev] A feedback about the CI bug reporting system
On 2020-11-07 12:30, Agostino Sarubbo wrote: What looks strange is that ci/tinderbox opened ~4700 bugs, sure, there are invalid/duplicate bugs but the majority are fixed so in my opinion they were useful, but looking at the mailing list feedback looks to be a completely crap. I think this might be the case of a "silent majority, vocal minority" scenario. For the record: I for one have found your tinderbox bugs very useful, not in the least because you test unusual configurations my own build testing does not cover. There have been glitches - but IMHO very few of them, and human operators make mistakes too. I still very much wish your tickets were tagged in a way which would make it possible to separate failures from QA notices (especially those that show up during normal emerge runs, such as that suspected DISTUTILS_USE_SETUPTOOLS mismatches), though. I really do not need e-mail notifications about the latter, looking them up via my p.g.o page is quite sufficient. -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
Andreas K. Hüttel wrote: > it's probably time to deprecate the amd64 17.0 profiles! I for one am not so excited about the amd64 17.1 profiles. On the surface it appeared to me that one developer has "taken over" just about everything, which (regardless of the individual) can't be a good thing.. Jaco Kroon wrote: > ...just wondering where the lib32 => lib symlink comes from now. baselayout contains a conversion to/from lib symlink(s). Kind regards //Peter
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 2020-11-09 12:09, Jaco Kroon wrote: equery has some answers that there are still stuff installed into /usr/lib32 (which will likely clear over time, and the symlink will be unmerged). There is this one potential pitfall down the line that I'm seeing, fairly certain this would have been covered and that a remerge of glibc will fix this: As a matter of fact the complete migration procedure (including cleaning up lib32 symlinks) was described in the news items introducing 17.1, for instance "2019-06-05-amd64-17-1-profiles-are-now-stable". In short, run emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32 and the lib32 symlinks should go. -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
Hi Ulrich, On 2020/11/09 12:59, Ulrich Mueller wrote: >> On Mon, 09 Nov 2020, Jaco Kroon wrote: >> What is the actual "target" objective with the change? I would have >> expected (not being one to follow this too closely): >> lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts). >> lib32/ - 32-bit specific stuff (libs for 32-bit). >> lib64/ - 64-bit specific stuff (libs for 64-bit). > It is explained here: > https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout#Rationale Thank you, that makes a lot of sense and answers all my questions ...just wondering where the lib32 => lib symlink comes from now. So if anybody else ends up wondering: jkroon@plastiekpoot ~ $ ls -lah /lib32 /usr/lib32 /usr/local/lib32 ls: cannot access '/usr/local/lib32': No such file or directory lrwxrwxrwx 1 root root 3 Nov 9 10:02 /lib32 -> lib lrwxrwxrwx 1 root root 3 Nov 9 10:02 /usr/lib32 -> lib equery has some answers that there are still stuff installed into /usr/lib32 (which will likely clear over time, and the symlink will be unmerged). There is this one potential pitfall down the line that I'm seeing, fairly certain this would have been covered and that a remerge of glibc will fix this: jkroon@plastiekpoot ~ $ equery belongs /lib32 /usr/lib32 ... sys-libs/glibc-2.32-r2 (/lib -> lib64) So job well done to the implementation team!! Great work thank you! Kind Regards, Jaco
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
> On Mon, 09 Nov 2020, Jaco Kroon wrote: > What is the actual "target" objective with the change? I would have > expected (not being one to follow this too closely): > lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts). > lib32/ - 32-bit specific stuff (libs for 32-bit). > lib64/ - 64-bit specific stuff (libs for 64-bit). It is explained here: https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout#Rationale signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
Hi,
Having just completed the migration on two systems I found some things
which concerns me:
1. A default/linux/amd64/17.0/desktop to
default/linux/amd64/17.1/desktop. This differs from the no-multilib in
that there are symlinks now for the various lib32 to lib. No such
symlinks on the no-mulilib systems (this makes sense, but why is lib32 a
symlink back to lib/)
2. If /usr/local/lib* doesn't exist the script bails out. This only
happened on one of the two systems I did now, specifically the
default/linux/amd64/17.0/no-multilib =>
default/linux/amd64/17.1/no-multilib one. Other systems I've just
checked seems to already have this by virtue of
/usr/local/lib{64,32}/.keep existing, but no owners of the files, so
this could be sheer dump luck. Which is never good. Sorted by manually
creating lib32 and creating the symlink as instructed. Post migrate
there is a lib/ and lib64/ folder. The complaint on this was about
/usr/local/lib32 if I recall correctly
What is the actual "target" objective with the change? I would have
expected (not being one to follow this too closely):
lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts).
lib32/ - 32-bit specific stuff (libs for 32-bit).
lib64/ - 64-bit specific stuff (libs for 64-bit).
What am I missing?
Kind Regards,
Jaco
On 2020/10/22 21:16, Andreas K. Hüttel wrote:
> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>> Users frequently are choosing the wrong profile versions in new installs
>>> and accidentally downgrading to 17.0 with some saying they see it first.
>>>
>>> A simple reordering could help new installs.
> Independent of this useful change, it's probably time to deprecate the amd64
> 17.0 profiles!
>
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-11-08 23:59 UTC
> On Mon, 09 Nov 2020, Robin H Johnson wrote: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2020-11-08 23:59 UTC. > [...] > app-editors/emacs > 20150808-20:49 robbat2 56bd759df1d Not really ... This is broken for the second week in a row now. Could you suspend these messages please, until the problem is fixed? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
Hi, On 2020/11/09 08:46, Joonas Niilola wrote: > > On 11/9/20 12:17 AM, Kent Fredric wrote: >> On Wed, 4 Nov 2020 17:34:07 +0100 >> Marek Szuba wrote: x11-terms/rxvt-unicode >>> Will co-maintain this one with conikost, don't mind being listed as >>> primary maintainer. >> If you strike an issue that you think should be followed upstream, rope >> me in. (put me on the bottom of the maintainer list if you want) >> >> I'm not interested in maintaining it directly, but I use it, and do >> have workable rapport with upstream :) > http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.man.in?revision=1.130&view=markup#l176 > > I find this an issue WITH the upstream... Whilst I use rxvt-unicode myself I can't help but agree with Joonas. You mentioned working raport with upstream? Can we rely on that to at the very least get them to update that to "due to the way Gentoo functions we request that you first file issues with the Gentoo repository rather than directly with rxvt-unicode? That is pure and outright slander, and whilst I "get" (to an extent) and GNU/Linux statement - he should then have the same issue with RedHat Enterprise GNU/Linux. Or with "Debian" and "CentOS" for that matter which does not contain "GNU/Linux" in the name. Alternatively if there is no issue with that then perhaps we should consider just being "Gentoo" ... Also happy to help with solving issues if/when they occur, granted the only X development experience I've got is via Qt3 at the time ... so happy to help, so not sure how much help I'll be, but happy to help with testing. Welcome to CC me on bugs. Kind Regards, Jaco
