Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-09 Thread Fabian Groffen
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

2020-11-09 Thread Michał Górny
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?

2020-11-09 Thread Alexey Sokolov
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

2020-11-09 Thread Marek Szuba

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

2020-11-09 Thread Joonas Niilola


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

2020-11-09 Thread Kent Fredric
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

2020-11-09 Thread Alec Warner
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

2020-11-09 Thread Aaron Bauman
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

2020-11-09 Thread Michał Górny
# 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

2020-11-09 Thread Michał Górny
# 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?

2020-11-09 Thread Andreas K. Huettel



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?

2020-11-09 Thread Aaron Bauman



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

2020-11-09 Thread Agostino Sarubbo
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

2020-11-09 Thread Marek Szuba

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?

2020-11-09 Thread Peter Stuge
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?

2020-11-09 Thread Marek Szuba

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?

2020-11-09 Thread Jaco Kroon
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?

2020-11-09 Thread Ulrich Mueller
> 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?

2020-11-09 Thread Jaco Kroon
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

2020-11-09 Thread Ulrich Mueller
> 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

2020-11-09 Thread Jaco Kroon
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=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