Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item

2021-05-03 Thread Sam James


> On 3 May 2021, at 21:18, Michał Górny  wrote:
> 
> On Mon, 2021-05-03 at 19:06 +0100, Sam James wrote:
>> [snip]
> 
> I want to avoid it on the top, so people don't do it prematurely before
> reading their options.
> 

Good point - and I can’t complain, given I partly made that comment earlier ;)

LGTM then.

> --
> Best regards,
> Michał Górny



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item

2021-05-03 Thread Michał Górny
On Mon, 2021-05-03 at 19:06 +0100, Sam James wrote:
> 
> > On 2 May 2021, at 23:04, Michał Górny  wrote:
> > [snip]
> > +Upgrade commands
> > +
> > +The Python 3.8 cleanup requires that Python 3.8 is removed from complete
> > +dependency trees in batch.  If some of the installed packages using
> > +an older Python version are not triaged for the upgrade, the package
> > +manager will throw dependency conflicts.  This makes it important that
> > +the upgrade is carried via a --deep --changed-use @world upgrade,
> > +as well as that any stray packages are removed prior to it, e.g.:
> > +
> > +emerge --depclean
> > +emerge -1vUD @world
> > +emerge --depclean
> 
> 
> Only suggestion: we put this at the top and suggest people do it immediately
> on the switchover day, and ideally beforehand to minimise possible conflicts
> (so their system is in good state beforehand).

I want to avoid it on the top, so people don't do it prematurely before
reading their options.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] Packages up for grabs: x11-misc/arandr

2021-05-03 Thread Conrad Kostecki

Am 03.05.2021 um 02:45 schrieb Jonas Stein:

the following packages are up for grabs after dropping
desktop-misc:

x11-misc/arandr
https://packages.gentoo.org/packages/x11-misc/arandr


I will take it.




Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item

2021-05-03 Thread Sam James



> On 2 May 2021, at 23:04, Michał Górny  wrote:
> [snip]
> +Upgrade commands
> +
> +The Python 3.8 cleanup requires that Python 3.8 is removed from complete
> +dependency trees in batch.  If some of the installed packages using
> +an older Python version are not triaged for the upgrade, the package
> +manager will throw dependency conflicts.  This makes it important that
> +the upgrade is carried via a --deep --changed-use @world upgrade,
> +as well as that any stray packages are removed prior to it, e.g.:
> +
> +emerge --depclean
> +emerge -1vUD @world
> +emerge --depclean


Only suggestion: we put this at the top and suggest people do it immediately
on the switchover day, and ideally beforehand to minimise possible conflicts
(so their system is in good state beforehand).

Thank you for making the changes I suggested (especially given I didn’t
send a patch and they were quite involved).

Looks good!

> -- 
> 2.31.1
> 
> 




Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item

2021-05-03 Thread Sam James



> On 2 May 2021, at 22:46, Michał Górny  wrote:
> 
> On Fri, 2021-04-30 at 01:50 +0100, Sam James wrote:
>> 
>> [snip]
> 
> I've applied most of your suggestions... and feel like this still needs
> more work.  I'll try to make it clearer what all options are, and how to
> use them.

This looks pretty good to me, but I’ll look on the other one now and offer any
suggestions.
> 
> -- 
> Best regards,
> Michał Górny
> 
> 
> 




Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item

2021-05-03 Thread Sam James



> On 30 Apr 2021, at 08:23, Joonas Niilola  wrote:
> 
> 
> 
> On 30.4.2021 3.50, Sam James wrote:
>>> On 29 Apr 2021, at 22:01, Michał Górny  wrote:
>>> 
>>> +
>>> +
>>> +You can also switch to Python 3.9 earlier by setting:
>>> +
>>> +*/* PYTHON_TARGETS: -* python3_9
>>> +*/* PYTHON_SINGLE_TARGET: -* python3_9
>>> +
>>> +If you choose to follow this or the previous approach, you may want to
>>> +remove the package.use overrides after the switch or just leave them
>>> +in place to protect your system from the next automatic upgrade
>>> +of Python.
>>> +
>> “It is especially important you do not forget IF you choose to add this,
>> because it interferes with the natural rolling-with-the-defaults."
>> 
> 
> No offense, but your suggestion isn't an improvement here :P maybe the
> 2nd part (after ,) makes sense and should be added, but the first part
> of that sentence is a bit hard to read.

It’s usually easier if you offer an explicit suggestion to help understand the 
problem:

“Avoid setting these if you can because it will require mandatory intervention 
in future.”?

> 
> -- juippis
> 
> 




[gentoo-dev] Packages up for grabs: x11-misc/x2x

2021-05-03 Thread Jonas Stein

Dear all

the following packages are up for grabs after dropping
desktop-misc:

x11-misc/x2x
https://packages.gentoo.org/packages/x11-misc/x2x

There is an open bug and one version bump request
https://bugs.gentoo.org/754132

--
Best,
Jonas



Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: include riscv bitness in tc-arch

2021-05-03 Thread David Michael
On Mon, May 3, 2021 at 4:41 AM Sergei Trofimovich  wrote:
> On Sun, 02 May 2021 18:22:43 -0400 fedora@gmail.com wrote:
> > This makes tc-arch identify RISC-V systems as either "riscv64" or
> > "riscv32".  It will still return "riscv" for the kernel arch or if
> > bitness is not given in the host triplet.
>
> tc-arch returns portage's ARCH= value based on passed tuple.
> There are no ARCH=riscv32 or ARCH=riscv64 in Gentoo. Only ARCH=riscv.

Okay, then I will remap it directly in meson instead.

Thanks.

David



[gentoo-dev] [PATCH] meson.eclass: include riscv bitness in cpu_family

2021-05-03 Thread fedora . dm0
This makes cpu_family identify RISC-V systems as either "riscv64"
or "riscv32" to match the given tuple, or it will leave it as
"riscv" when the tuple has an unknown cpu field.

This fixes the expected values of cpu_family in meson projects:
https://mesonbuild.com/Reference-tables.html#cpu-families

Signed-off-by: David Michael 
---
 eclass/meson.eclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index d0ce5adb355..e9c651fdeda 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -142,6 +142,11 @@ _meson_get_machine_info() {
case ${cpu_family} in
amd64) cpu_family=x86_64 ;;
arm64) cpu_family=aarch64 ;;
+   riscv)
+   case ${tuple} in
+   riscv32*) cpu_family=riscv32 ;;
+   riscv64*) cpu_family=riscv64 ;;
+   esac ;;
esac
 
# This may require adjustment based on CFLAGS
-- 
2.26.3



[gentoo-dev] CI and be CC'ed in a bug report

2021-05-03 Thread Agostino Sarubbo
Hello,

I've noticed that it's been in vogue lately say "as you were asked many times" 
when there is something to say.

Well, this often (always?) happens without a reference but I don't care.


As asked by sam, CI should CC people that are breaking stuff with their 
commits, see:
https://cutt.ly/Wbx08SQ

However since there are message like this: https://cutt.ly/vbx2qv2 I'm giving 
a public explanation about what is happening:

1) Compilation of package 'A' works as expected
2) A new major change is introduced (gcc/glibc/binutils)
3) The CI system always runs an updated system, then it uses latest ~arch 
versions
4) Someone touches the package by introducing a simple comment in the ebuild
5) Since the ebuild was touched, the CI tries to compile it
6) Package 'A' fails to compile because of GCC-11 and not because of the 
comment added into the ebuild.

This happens mostly when the entire tree has not been 'tinderboxed' with the 
new major change.

So Mikle, I have nothing to fix.


For the record, if you want to request a change, you should send at least an 
email or open a ticket.

Send a message somewhere (mostly IRC) and say "as you were asked many times" 
just seems to be unproductive (or unprofessional, it depends on the point of 
view)

As a side note, as written before and reminder:
who does not want to receive email/reports from tinderbox and ci may request 
to be in the exclusion list.


Agostino





Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: include riscv bitness in tc-arch

2021-05-03 Thread Sergei Trofimovich
On Sun, 02 May 2021 18:22:43 -0400
fedora@gmail.com wrote:

> This makes tc-arch identify RISC-V systems as either "riscv64" or
> "riscv32".  It will still return "riscv" for the kernel arch or if
> bitness is not given in the host triplet.

tc-arch returns portage's ARCH= value based on passed tuple.
There are no ARCH=riscv32 or ARCH=riscv64 in Gentoo. Only ARCH=riscv.

You probably need to map gentoo's ABI USE to upstream's ABI flag.
But it's not clear from your description what effect you intend to achieve.

> This fixes the expected values of cpu_family in meson projects:
> https://mesonbuild.com/Reference-tables.html#cpu-families

I'm not sure what meson's `cpu_family` is. Is it something that should
affect -march=/-mabi=? Please state your intent explicitly. The fix does
not look correct.

> Signed-off-by: David Michael 
> ---
> 
> Hi,
> 
> When building systemd from Git, it now relies on the "stable" cpu_family
> value for riscv64[0].  Meson gets this value from tc-arch.  From a quick
> grep, it looked like the only place that compared tc-arch output with
> "riscv" was toolchain.eclass, but there may be some other subtle issue I
> haven't encountered.  Does this look okay to apply?
> 
> Thanks.
> 
> David
> 
> [0] 
> https://github.com/systemd/systemd/commit/a00ff2e1b596f0d08d32b8ca9cefe8aca1212604
> 
>  eclass/toolchain-funcs.eclass | 10 +-
>  eclass/toolchain.eclass   |  2 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 267cf5cfce3..5dd6dcbd658 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -687,7 +687,15 @@ ninj() { [[ ${type} == "kern" ]] && echo $1 || echo $2 ; 
> }
>   echo ppc
>   fi
>   ;;
> - riscv*) echo riscv;;
> + riscv*)
> + if [[ ${type} != "kern" && ${host} == riscv32* ]] ; then
> + echo riscv32
> + elif [[ ${type} != "kern" && ${host} == riscv64* ]] ; 
> then
> + echo riscv64
> + else
> + echo riscv
> + fi
> + ;;
>   s390*)  echo s390;;
>   score*) echo score;;
>   sh64*)  ninj sh64 sh;;
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index f41ce22c591..b1d2e671917 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -1084,7 +1084,7 @@ toolchain_src_configure() {
>   # https://gcc.gnu.org/PR93157
>   [[ ${CTARGET} == powerpc64-*-musl ]] && confgcc+=( 
> --with-abi=elfv2 )
>   ;;
> - riscv)
> + riscv*)
>   # Add --with-abi flags to set default ABI
>   confgcc+=( --with-abi=$(gcc-abi-map ${TARGET_DEFAULT_ABI}) )
>   ;;
> -- 
> 2.26.3
> 
> 


-- 

  Sergei