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

2021-03-11 Thread Jonas Stein

Dear all

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

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

It has 3 open tickets.

--
Best,
Jonas



Re: [gentoo-dev] Idea: User centric kernel configuration

2021-03-11 Thread Peter Stuge
Hi,

Gerion Entrup wrote:
> the Linux kernel has _a lot of_ configuration options, way too many to 
> configure them by hand.

I actually disagree strongly with that; I think it's important to
actively decide what kernels include, and I routinely do, but of
course not everyone will. I've made sure to include a kernel build
when teaching systems administration courses and would again.

As the kernel becomes more complex the threshold for the first
configuration also rises, but it's still completely possible to learn
what you need in order to successfully configure your own kernel.
I guess it's on the order of a weekend project given some basic
understanding of computer architecture and programming.


> This requires a mapping between user oriented "features" and the kernel
> internal configuration options.

So the challenge here is that the kernel is disjoint from user space,
and while the kernel API remains stable over time consumer requirements
such as "docker" or "cryptsetup" will mean different things for
different versions of particular user space software.


> Do you think that it is useful and feasible to combine these two mechanisms?

AFAIK there's no generic method for formal kernel requirements in user
space packages and there's also no sanctioned method for quering
kernel capabilities. The only thing available is /proc/config if that
was enabled in the kernel build, and there are of course reasons to
leave it out, and it only applies to the particular running kernel,
e.g. useless for cross-compilation. There, it would be possible to
read the kernel configuration file if the kernel source code is
available when the userspace package is being built, but that's not
guaranteed.

In Gentoo, linux-info.eclass provides linux_config_exists() to do all
of this, but order to become a widespread success there would have to
be one method for upstreams to maintain these requirements as part of
their packages, rather than forcing the burden on package maintainers
to repeat the same detective task in every single distribution.

I think it would be very useful to create something generic for that,
but that's certainly no small task.

And realistically I only see it succeeding if Linux Foundation decides
to push it onto the world.


> A possible way could be to automatically extract the kernel config
> flags from the wiki pages and map them to Kconfig options.

At very best that will only be valid for some particular point in time,
like current CONFIG_CHECK in ebuilds using linux_config_exists() are
only valid for particular package versions. At worst it's plain wrong
because the requirements have to be reverse-engineered downstream.


//Peter



[gentoo-dev] Idea: User centric kernel configuration

2021-03-11 Thread Gerion Entrup
Hi,

the Linux kernel has _a lot of_ configuration options, way too many to 
configure them by hand.
Many of these configuration options seem to be kernel centric (they deactivate 
a specific compilation unit, they deactivate specific source code parts).
However, my main configuration requirements as a user are mostly user space 
program or feature centric. I want to activate kernel support for a specific 
feature, e.g. docker support or cryptsetup support.

This requires a mapping between user oriented "features" and the kernel 
internal configuration options. This mapping exists already at the Gentoo wiki 
[e.g. 1, 2, 3].
Gentoo also provides (via gentoo-sources) a set of patches that adds some meta 
configuration options to enable some of exactly that user specific features 
(Systemd, OpenRC and Portage support).

Do you think that it is useful and feasible to combine these two mechanisms?
A possible way could be to automatically extract the kernel config flags from 
the wiki pages and map them to Kconfig options.

Best regards,
Gerion

[1] https://wiki.gentoo.org/wiki/Docker#Kernel
[2] https://wiki.gentoo.org/wiki/Dm-crypt#Kernel_Configuration
[3] https://wiki.gentoo.org/wiki/AMDGPU#Kernel




signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Begging notice: please mark your packages as ALLARCHES

2021-03-11 Thread Sam James
Hi,

Please mark your package as ALLARCHES if at all possible.

The  metadata.xml tag indicates to arch teams
that the package is architecture independent and therefore testing on one
architecture is sufficient.

You can read more in the devmanual:
https://devmanual.gentoo.org/keywording/#simultaneous-stabilization-on-all-architectures.

We should do this even if your package is pure ~arch to simplify
matters if it becomes a dependency or included in a stable request in future.

It only takes a few minutes to check if your package is compiling anything
or installing e.g. ELF files but can save arch teams a lot of time.

Proactively doing this is a huge help and I’d be really grateful if maintainers
could take the time to do this.

Generally, unless the package seems somehow special, I wouldn’t
restrict yourself to marking only your own packages ALLARCHES either.

Tips:
1) If you don’t know, ask somebody! Email me or ask in e.g. #gentoo-dev on IRC.

2) Python packages are generally ALLARCHES, see the wiki:
https://wiki.gentoo.org/wiki/Project:Python#ALLARCHES

3) Perl packages don’t count. Technically, some COULD, but due to
prominent usage of e.g. unpack() throughout the ecosystem, it’s best
not to risk it for now. We may find a better way to check for problematic
functions in future.

4) graaff has advised that Ruby is in a similar situation. Far too often
both Perl and Ruby end up exposing system internals.

Thanks!
Sam



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Urgent reminder to port your packages to Python 3.8 and Python 3.9

2021-03-11 Thread Sam James


> On 3 Mar 2021, at 22:55, Sam James  wrote:
> 
> Hi,
> 
> We still have ~31 packages still not declaring support for newer Python 3 
> targets than Python 3.7,
> we have ~1085 packages still not declaring support for newer Python 3 targets 
> than Python 3.8 (i.e.
> Python 3.9).

Thanks to everyone who ported in response!

> Please review this list to see if your packages are stuck on Python 3.7:
> http://qa-reports.gentoo.org/output/gpyutils/37-to-38.txt

We’re now on ~27.

> 
> Please review this list to see if your packages are stuck on Python 3.8:
> http://qa-reports.gentoo.org/output/gpyutils/38-to-39.txt

We’re now on ~1012.

> 
> This list contains maintainer names, so it’s easy to tell if you need to act.
> 
> The default Python target in profiles was switched from Python 3.7 to Python 
> 3.8
> at the beginning of December. A news item still needs to be created [0].
> 
> Your package not supporting the latest targets makes it harder for other 
> packages
> to do so. In particular, packages not supporting even the default target (now 
> Python 3.8)
> means that users have a difficult time installing it.
> 
> Previous warnings have been sent about this including in November [1]. mgorny 
> sent
> this [2] RFC regarding an impeding switch of the default to Python 3.9 too.
> 
> TL;DR:
> * Please port your packages to Python 3.8 (already default) and Python 3.9 
> ASAP.
> * Packages supporting Python 3 but not newer versions may be last-rited.
> 
> [0] https://bugs.gentoo.org/771165
> [1] 
> https://archives.gentoo.org/gentoo-dev/message/f1e452d0a54d5347d9f867478b2604c4
> [2] 
> https://archives.gentoo.org/gentoo-dev/message/ba2fc4854ed6bb49813819ae6f5e9552



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: dev-ruby/astrolabe

2021-03-11 Thread Hans de Graaff
# Hans de Graaff  (2021-03-11)
# Last upstream release in 2018, uses outdated dependencies.  No
# longer works with dev-ruby/parser, bug 775206. No reverse
# dependencies.
# Masked for removal in 30 days.
dev-ruby/astrolabe


signature.asc
Description: This is a digitally signed message part