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
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
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  https://wiki.gentoo.org/wiki/Docker#Kernel  https://wiki.gentoo.org/wiki/Dm-crypt#Kernel_Configuration  https://wiki.gentoo.org/wiki/AMDGPU#Kernel signature.asc Description: This is a digitally signed message part.
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
> 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 . > > 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 . mgorny > sent > this  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. > >  https://bugs.gentoo.org/771165 >  > https://archives.gentoo.org/gentoo-dev/message/f1e452d0a54d5347d9f867478b2604c4 >  > https://archives.gentoo.org/gentoo-dev/message/ba2fc4854ed6bb49813819ae6f5e9552 signature.asc Description: Message signed with OpenPGP
# 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