[gentoo-dev] Re: Packages up for grabs
On 2017-03-26 21:50, aide...@gentoo.org wrote: > app-backup/burp I'll grab this one unless anyone minds. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item: changed default bedup configuration file in >=app-backup/burp-2.0.0
-- MS Title: app-backup/burp: default config file for bedup Author: Marek Szuba Posted: 2017-04-24 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-backup/burp Starting with version 2.0.54, the default configuration file of the burp-aware deduplication tool bedup will change from /etc/burp/burp-server.conf to /etc/burp/burp.conf . The latter is the value used by upstream and with burp2 bedup being a part of the main executable rather than a standalone tool, maintaining old Gentoo behaviour would needlessly complicate the code. If you want to keep using burp-server.conf with bedup, you can specify it on the command line: bedup -c /etc/burp/burp-server.conf signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: changed default bedup configuration file in >=app-backup/burp-2.0.0
On 2017-04-19 17:39, Gokturk Yuksek wrote: >> Display-If-Installed: app-backup/burp > Wouldn't you wanna limit this to <2.0.54 ? Otherwise this will pop > up for the consumers of 2.0.54 as well. Might as well, although at present there is no 2.0.54. >> /etc/burp/burp.conf . > You have an extra '.' at the end. Yes, it's a full stop at the end of the sentence. Come to think of it it looks confusing though, I'll remove it. > I think upstream using the new path is enough justification, do you > really need to justify it any further? It's not like that. Upstream has always used $sysconfdir/burp.conf , by default however that file provides client-mode configuration and bedup refuses to run unless it is pointed to a server-mode config file. Making bedup use $sysconfig/burp-server.conf by default is achieved in burp-1 ebuilds through the means of a Gentoo patch. > Maybe it's better to also provide a one-liner of 'mv' for people who > just want to upgrade to the new path. It is not the matter of the config file having been renamed, burp has always come with both burp.conf and burp-server.conf. > Overall, my impression is that people handle conf file changes in > pkg_postinst() with REPLACING_VERSIONS rather than news items. See above. > How fatal are the consequences of not updating the conf file path? > Would the program abort or misbehave? Abort. Please note however that in a typical production scenario bedup would be run periodically by cron or a similar tool, i.e. without admin intervention, meaning that for everyone who doesn't review their logs carefully backup deduplication would simply quietly stop working. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 2017-04-27 12:58, Dirkjan Ochtman wrote: > The proxy maintainer for syncthing just resigned, anyone want to pick > it up? I'll take it. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: taking a break from arches stabilization
On 2017-07-12 00:26, Kristian Fiskerstrand wrote: >> Question is what's more a problem: Having an outdated stable >> package because nobody cared about stabilizing a new version (in >> most cases this will end with a rushed stabilization once a >> security bug was fixed in the package) or move a package in time >> from ~ARCH to ARCH and deal with the fallout sometimes. > Easy, keep the working package any time Seconded. That said, let me repeat something I mentioned during the last discussion about stabilisation procedures: for me at least the problem with stabilisation has never really been with version upgrades, it's with packages which do not even have a single stable version. For reference, as of right now my "version bump" keyword file lists 8 atoms (half of them referring to GIMP-2.9, which should not be stabilised anyway) - whereas my "not in stable" file lists 61. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On 2017-07-28 12:43, Andreas K. Huettel wrote: >> I continue to feel that maintaining two worlds (stable+unstable) >> carries with it an unneccessary cost. > That's not feasible. It would kill off any semi-professional or > professional Gentoo use, where a minimum of stability is required. This. VERY much this. I do not care about having all the latest stuff on work machines, what I want them is to a) remain up to date security-wise, and b) actually survive updates. In fact, problems with the latter was what led us a couple of years ago to quickly conclude evaluation of a certain other rolling-upgrade operating system. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal
On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote: > I'd like to get this one up by Saturday so that we can proceed with > masking and removing of the hardened-sources after upstream stopped > releasing new patches. > > This is my first time writting a news item so all input will be appreciated. Two tiny bits of formal nitpicking from my side: - it's "grsecurity" (not a typo, they do use a lowercase g except when the name appears at the beginning of a sentence), not "grsec"; - the patches were not *distributed by* grsecurity, they *are* grsecurity. The vendor's name is Open Source Security, Inc. -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing PMS to Portage Manager Specification
On 2017-08-14 23:46, William L. Thomson Jr. wrote: > pkgcore - does not support EAPI 6, only experimental EAPI 5 Side note - according to https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification pkgcore has supported EAPI 6 since version 0.9.3. Considering it says exactly the same for EAPI 5, this is almost certainly a mistake - but I'd rather confirm this here before changing the page. -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: net-misc/asterisk-g729, sci-libs/coinhsl, some games-*/* (BLAKE2B)
On 2018-05-15 22:49, Michał Górny wrote: > # Michał Górny (15 May 2018) > # Remaining fetch-restricted game packages missing BLAKE2B hashes. > # Please provide updated hashes if you have the matching distfiles. > # Bug #642876. Removal in 30 days. I have got access to several of these but it turns out that in most cases one has to do more than merely recompute the digests. I reckon it is up to the maintainers to decide whether to proceed after all or let the packages quietly expire. > games-action/shadowgrounds-bin > games-action/shadowgrounds-survivor-bin I updated these two on Friday. Left them masked for now though, just in case the games project is not interested in maintaining them after all - both use deprecated EAPI version and eclasses. > games-action/trine2 I have only got archives for Trine 2 Complete Edition, i.e. the version with the Goblin Menace expansion included. At a glance it seems the ebuild should work with that one as well but it WOULD be changing the product served by the package. > games-rpg/bastion The archives from HumbleBundle.com seem to be completely different from what the ebuild uses right now. > games-rpg/penumbra-collection The latest version available from HumbleBundle.com depends on media-libs/libsdl2 and friends rather than media-libs/libsdl. Otherwise seems okay. -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-misc/subsurface
# Martin Gysel via g-p-m (09 Sep 2016) # Versions currently in Portage are old and block removal of other # packages. Current versions require building against modified versions # of dev-libs/libdivecomputer and kde-apps/marble which must be fetched # from Git, and which are not versioned (upstream uses branch tags). # Finally, upstream considers distribution-maintained packages deprecated. # Removal in 30 days. app-misc/subsurface signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-misc/subsurface
On 2016-09-11 14:19, Martin Gysel wrote: >> +1. Any package whose upstream says "don't build this yourself" is >> hostile to open source principles. > just to make it clear, upstream never said such thing nor are they in > any way hostile to open source principles (I suppose you wouldn't state > that if you know subsurface's developers). They have, however, used the term "deprecated" to describe distribution-maintained packages. It's right there on the download page. And yes, I know (and so do at least several other devs) that one of the major contributors to Subsurface is one Linus Torvalds. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS
On 2016-09-27 22:51, Raymond Jennings wrote: > Doesn't VIDEO_CARDS factor in on xorg-server's video driver > selection? It does. Which is why with the way things are now, and which Michał's proposal should improve, someone with an amdgpu-compatible card will still have xf86-video-ati lying around - VIDEO_CARDS=radeon will pull it in. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item: migration from sys-cluster/singularity to app-containers/apptainer
Dear everyone, This should be a fairly straightforward thing for the users to do but since manual intervention IS necessary, let us have a news item about it! The date is a placeholder because apptainer upstream has not released 1.0.0 yet, that said I want to have the news item ready for publication as soon as they have (I've already got the ebuild ready). As usual, comments and suggestions are most welcome. -- Marecki
[gentoo-dev] [PATCH] Add 2022-03-01-singularity_to_apptainer
Signed-off-by: Marek Szuba --- ...2022-03-01-singularity_to_apptainer.en.txt | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt diff --git a/2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt b/2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt new file mode 100644 index 000..150c947 --- /dev/null +++ b/2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt @@ -0,0 +1,27 @@ +Title: Transition from sys-cluster/singularity to app-containers/apptainer +Author: Marek Szuba +Posted: 2022-03-01 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-cluster/singularity + +In autumn 2021 the Singularity project joined the Linux Foundation +and changed its name to Apptainer [1]. The change has been reflected +in the renaming of executables/configuration files and environment +variables, as well as a reset of version numbers back to 1.0.0. + +Apptainer packages include compatibility symlinks to old Singularity +executables, continue to honour old environment variables and will upon +the first run import user data from Singularity directories. Therefore, +for most users it will be sufficient to deselect the old package and +install the new one, e.g.: + +emerge --deselect sys-cluster/singularity +emerge app-containers/apptainer + +However, customisations made to system-wide configuration +in /etc/singularity will have to be applied to /etc/apptainer by hand, +and since the bash-completion rule file has been renamed as well any and +all customisations here will have to be updated accordingly as well. + +[1] https://apptainer.org/news/community-announcement-20211130/ -- 2.34.1
Re: [gentoo-dev] proposal: use only one hash function in manifest files
On 2022-04-06 19:34, Rich Freeman wrote: This is one of those low cost, low risk, high reward situations IMO. *puts on Council hat* The above pretty much covers my own opinion on the subject. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] News item: breaking change to app-backup/borgmatic user-configuration handling
A couple of breaking changes have been introduced in borgmatic-1.6.0. Only some borgmatic users will be affected but seeing as it is a backup tool, I feel it does warrant a news item. -- Marecki
[gentoo-dev] [PATCH] 2022-05-20-borgmatic-config-changes: new item
Signed-off-by: Marek Szuba --- .../2022-05-20-borgmatic-config-changes.en.txt | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt diff --git a/2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt b/2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt new file mode 100644 index 000..672a0fe --- /dev/null +++ b/2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt @@ -0,0 +1,14 @@ +Title: Breaking configuration changes in borgmatic-1.6.0 +Author: Marek Szuba +Posted: 2022-05-20 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-backup/borgmatic + +Version 1.6.0 of app-backup/borgmatic has introduced some breaking +changes to the way Borgmatic handles the merging of its configuration +files and executes command hooks. If you use these features, please +review your Borgmatic config files to make sure they continue to work +correctly with >=app-backup/borgmatic-1.6.0. For details, see [1]. + +[1] https://github.com/borgmatic-collective/borgmatic/releases/tag/1.6.0 -- 2.35.1
[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...
On 2022-06-05 09:28, Joonas Niilola wrote: sys-process/incron I'll take this one, with Infra as fallback maintainers. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more
On 2022-06-29 08:15, Joonas Niilola wrote: acct-group/lightdm acct-user/lightdm app-admin/keepassxc mail-mta/msmtp sys-apps/gptfdisk sys-apps/lm-sensors sys-fs/ddrescue x11-misc/lightdm x11-misc/lightdm-gtk-greeter I'll take these. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more
On 2022-06-29 08:35, Sam James wrote: dev-libs/libxmlb dev-libs/libjcat sys-apps/fwupd sys-apps/fwupd-efi sys-libs/libblockdev sys-libs/libsmbios This is the fwupd stack. I'm tempted for these but I only have one machine which uses them. I'll see if anyone else is a better set of hands first. Sorry, I'd assumed libjcat was here as it's AFAIK only useful really for fwupd, but it wasn't in the original list. But may still be relevant if interested in fwupd. Would need to speak to Marecki if you are interested though. A second pair of hands on the whole lot (I have always co-maintained dev-libs/libjcat with poly-c, and had already added myself to sys-apps/fwupd before the for-grabs call went out due to having observed my ticket for it having been dropped to m-n; will add myself to the rest shortly) will definitely be welcome! They have, sadly, been a bit neglected of late. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] gnome-extra/gtkhtml: last rites
A GNOME 2-era library with no consumers left in the tree, marked as deprecated since March 2022. Removal in 30 days (Bug #855299). -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On 2022-07-25 15:35, Peter Stuge wrote: Mikhail Koliada wrote: This idea has been fluctuating in my head for quite a while given that the migration had happened a while ago [0] and some other major distributions have already adopted yescrypt as their default algo by now [1]. Please only do that based on proven merit and nothing else. https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/ , https://www.password-hashing.net/ , the fact we still us the default number of rounds (i.e. 5000) with SHA512 which is *ridiculously* weak for modern hardware, lack of Argon2 support in libxcrypt for the time being due to upstream having decided to wait for an official RFC. You can probably find more yourself if you look. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Add systemd/merged-usr profiles
On 2022-08-31 17:27, Mike Gilbert wrote:
The only pain point I see is for users with /usr on a separate
filesystem and that are not using an appropriate initramfs.
As mentioned on IRC earlier on today, another (although this would be
less of a pain point and more of a sneaky changes to run-time behaviour
of a system) might be ebuilds which rely on PATH precedence of /usr/bin
over /bin to override binaries installed in the latter by other
packages. Some examples:
- app-arch/lbzip2[symlink] - installs /usr/bin/b{,un}zip2 to override
/bin/b{,un}zip2 installed by app-arch/bzip2;
- app-arch/pigz[symlink] - ditto for g{,un}zip and app-arch/gzip;
- app-arch/gzip installs the symlink /bin/uncompress pointing to
gunzip, app-arch/ncompress installs /usr/bin/uncompress pointing to
compress.
There probably are more though, and I feel these will all need a
systemic change - eselect modules? shell aliases? - to how such
overrides are handled. Still, for the time being packages which have
such behaviour controlled by USE flags should me added to
package.use.force of relevant profiles.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] RFC: virtual/dbus
Dear everyone, I wonder if we should create a virtual package to allow our users - or at least those who run systemd anyway - to choose between sys-apps/dbus and sys-apps/dbus-broken as D-Bus implementation for their systems. The usual "Gentoo is about choice" thing aside, there is now at least one, security-related, problem with the former which can be worked around by switching to the latter: https://github.com/systemd/systemd/issues/22737 WDYT? PS. Cc'ing maintainers of both packages to see what they might have got to say about this. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: virtual/dbus
On 2022-09-07 17:29, Mike Gilbert wrote: A virtual seems a bit pointless for the following reasons: [...] > 2. dbus-broker[launcher] utilizes config files installed by dbus, and > actually RDEPENDs on sys-apps/dbus for that reason. Yeah, I failed at reading - even the README of dbus-broker clearly states "You still need the dbus reference implementation installed, since it provides tools used by many applications, as well as the dbus.socket unit file." If you can think of some way to encourage users to install/enable dbus-broker, that seems like a good idea to me. Makes sense, I'll think about it. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: virtual/dbus
On 2022-09-07 17:36, John Helmert III wrote: If you find a security issue, please file a security bug. I'm not really sure what the security impact of this is, though. I'm not sure if this is a security issue per se (which is why I described it as security-related), here - the default configuration IS the more secure one. > I'm not really sure what the security impact of this is, though. The impact is that systemd+dbus-daemon users currently have to disable DynamicUser functionality for units communicating over D-Bus in order for said communication to actually work. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Co-maintainer needed for app-admin/ansible-lint
Dear everyone, I really could use a hand with app-admin/ansible-lint. Not that it is exactly complicated to maintain, quite the opposite - it's just that upstream has adopted a rather rapid release cycle and now it feels that as soon as I have tested and pushed an ebuild for a version, another one pops up. And that's even without creating tarballs of Ansible Galaxy collections used by the test suite, which is something I would very much like to introduce at some point so that we no longer have to skip so many tests. All offers gratefully received! -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-editors/elvis
No releases since 2003 (!), upstream effectively dead, no Unicode support, EAPI 6. Removal in 30 days (#884429) -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-dicts/sword-* app-text/sword-modules
# Upstream keeps the module files unversioned so it is only the use of # mirroring that has prevented us from seeing regular hash mismatches # - and it is not clear for many of the modules whether we are allowed # to mirror them or not. A convoluted and fragile process has been # required to detect new modules and versions, and the request for a # Repology-friendly upstream endpoint appears to have stalled. # Please switch to managing SWORD modules on a per-user basis, using # tools bundled with app-text/sword (see e.g. # https://wiki.crosswire.org/SWORD_Module_Source_Discovery_and_Module_Updating) # or appropriate functionality in GUI front-end software. # Removal in 30 days. Bug #892069. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Breaking changes in dev-libs/msgpack-5.0.0
Dear everyone, Having not been given any love for a long time, we have now got in the tree a version of dev-libs/msgpack newer than 3.3.0 - namely 5.0.0. Yes, we have managed to skip the entire major version 4 (yay?)! Anyway, the version in question introduces at least two breaking changes: - since 4.0.0, the (header-only) C++ library is no longer bundled with the C one. As a consequence, a new(ish) package dev-cpp/msgpack-cxx has been introduced and >=dev-libs/msgpack-5.0.0 no longer provide IUSE="boost cxx"; - since 5.0.0 CMake modules for both the C and the C++ variant of msgpack have different names, which might break cmake-based revdeps which have not been updated accordingly. In light of the above, both dev-cpp/msgpack-cxx and >=dev-libs/msgpack-5.0.0 are currently masked in order to give the maintainers of msgpack devreps ample time to test compatibility with the new versions. They will, however, be unmasked on the 3rd of March unless major problems are encountered with the revdep update. There is a tracker bug "msgpack-5" which can be used to group related issues. On behalf of the Vim project, -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Breaking changes in dev-libs/msgpack-5.0.0
On 2023-02-06 15:57, Michał Górny wrote: Given there's only a handful of revdeps, perhaps you could simply test them? I can and have in fact already begun, starting with packages affected by IUSE changes. Can't hurt to let maintainers know, though! -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: media-gfx/rawtherapee media-libs/libiptcdata
In light of the current (proxied) maintainer having stated they no longer have a Linux desktop and therefore expect difficulties in continuing to maintain their packages, media-gfx/rawtherapee and media-libs/libiptcdata are now up for grabs. Both are up to date in the tree. They have also got one open bug each - the former might need a dependency update, the latter appears to fail a documentation-consistency check when emerged with USE=doc. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [RFC PATCH] Add Ansible package-stabilisation group
This is very much for future reference, seeing as stabilisation groups are still very much work in progress. Anyway, the point here is to make it easier to avoid in the future the fairly regular occurrence of Portage complaining about having to hold back newly stabilised Ansible Core owing to version restrictions set in Ansible ebuilds. -- Marecki
[gentoo-dev] [PATCH] metadata: Add stabilisation group for Ansible
Signed-off-by: Marek Szuba --- metadata/stabilization-groups/ansible | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 metadata/stabilization-groups/ansible diff --git a/metadata/stabilization-groups/ansible b/metadata/stabilization-groups/ansible new file mode 100644 index 000..b259400a0fc --- /dev/null +++ b/metadata/stabilization-groups/ansible @@ -0,0 +1,2 @@ +app-admin/ansible +app-admin/ansible-core -- 2.41.0
[gentoo-dev] Last rites: media-gfx/gmic
Upstream uses a massive home-made Makefile which has since the beginning required massive amounts of patching to make it behave reasonably (as well as to fix the problems which ostensibly led upstream to abandoning CMake, and which they immediately re-introduced in their NIH solution) and which if anything have only got worse since then. One, optional, reverse dependency in the tree. Removal on 2023-11-26. Bug #916289. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: media-gfx/gmic
Currently last-rited but since it seems there is interest in keeping it in the tree, I have just returned it to the state in which it was before I took over its maintenance 3 years ago (i.e. m-n). To anyone willing to put up with the updates of the megapatch, the regularly emerging QA issues and the unresponsive upstream: good luck. You will need it. A request (and, to make it absolutely clear, nothing more than a request): PLEASE don't unmask gmic unless it gets a new maintainer. We've got enough junk packages as it is. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Last rites: media-gfx/gmic
On 2023-10-26 02:29, Jonas Stein wrote: this is a very powerful package with many users. ...but sadly, very few maintainers. It was m-n when I took it over 3 years ago, as apparently no-one found it worth looking after following the disbanding of the Graphics project - and that was back when upstream still used CMake! Telling the truth I wasn't exactly interested either, it's just that it happened to be an optional dependency of media-gfx/darktable. Thank you for maintaining it till now. You're very welcome! Could you address the exact problems to upstream, so they are aware and can improve it? I think not only Gentoo, but also other distributions suffer if it does not build smooth. I used to do that. It seemed to have little to no effect so in the end I just gave up. Looks to me as if the package is not broken now, but there is a lack of manpower to update it. 30 days is the minimum for a removal. There are two outstanding QA issues (ignored LDFLAGS and pre-stripped binaries) in 3.3.1 pertaining to USE=gimp and USE=qt5. Prior to adding that version I tried to leverage qmake-utils.eclass in the Qt parts of the package, which hopefully would have got rid of these issues - but resulted in a wall of actual errors. This has been the last straw as far as me maintaining G'MIC is concerned. I suggest to keep it for a few more months. Fine by me if someone actually maintains it. I've just dropped media-gfx/gmic back to m-n to make it clear that I do not intend to block it from being reactivated. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
On 2023-10-26 04:41, Eli Schwartz wrote: This is of course either untrue or every kind of over-reaction, and users have commented there to the effect of being willing to help sort things out but there has been radio silence. ...which, sadly, has been my _overall_ experience with G'MIC upstream. I think this also offers some compelling arguments against maintainers being willing to deal with the challenges of this software -- this is a pretty steep social cost to investing time and effort into caring about, using, or maintaining such software. Given where this package has come from, I have got a nagging feeling that its maintainers suffer from a problem that is fairly common among computational scientists (and before anyone gets offended, a quick reminder that I myself am in fact a computational scientist... Plus just have a look at what many sci-* ebuilds have to look like) - namely that however brilliant they might be at devising algorithms, they are rather less adept at developing actual software. Consider some of the issues I have come up against while maintaining this package (disclaimer: I haven't checked if any of these have been fixed in Git since the release of 3.3.1: - the reason for the megapatch, i.e. features being enabled automagically depending on the presence/absence of dependencies at build time. Not that big of a problem for end-users but very much distro-unfriendly; - one of the alleged reasons for G'MIC upstream to have switched from CMake to a hand-crafted Makefile (and one which said Makefile still fails to fix), namely building without X11 support. Given all that is needed to address the issue is something along the lines of "if !X11 CFLAGS+=-Dcimg_display=0", I simply do not understand why this remains open; - the use of RPATH="." with shared libraries in spite of it being widely considered a security risk, and apparently without any actual reason (media-gfx/gmic appears to work perfectly well with the relevant linker flag patched out); - the use of backslash-whitespace construct in the hand-crafted Makefile causes build issues on systems with grep 3.8 or newer. For the record, GNU grep-3.8 was released over a year ago and Gentoo is now on 3.11; - downright broken target dependency chains, even with -j1 (that bit falls under "if anything, the handcrafted Makefile has got worse since its introduction"); - a rather quirky way of locating the GIMP plug-in directory, including attempting to write to that directory when it hasn't been located - or even when the GIMP plug-in is not to be built. I rest my case. Marecki -- is there any specific concern that it's likely to rot quickly if it lacks a maintainer? The megapatch has to be updated on a fairly regular basis so at the very least, we would end up without updates. On top of that we have got the usual problems cropping up every time we add a new gcc/clang version, having to support MUSL (let's be honest, even among the more mature projects testing against non-glibc is rare), slibtool... So yes, I consider media-gfx/gmic very likely to rot quickly without continuous maintenance. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On 2024-02-27 14:45, Michał Górny wrote: In my opinion, at this point the only reasonable course of action would be to safely ban "AI"-backed contribution entirely. In other words, explicitly forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to create ebuilds, code, documentation, messages, bug reports and so on for use in Gentoo. I very much support this idea, for all the three reasons quoted. 2. Quality concerns. LLMs are really great at generating plausibly looking bullshit. I suppose they can provide good assistance if you are careful enough, but we can't really rely on all our contributors being aware of the risks. https://arxiv.org/abs/2211.03622 3. Ethical concerns. ...yeah. Seeing as we failed to condemn the Russian invasion of Ukraine in 2022, I would probably avoid quoting this as a reason for banning LLM-generated contributions. Even though I do, as mentioned above, very much agree with this point. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: net-misc/connman-gtk
Dear everyone, After over a decade of standing behind Connman, I have in recent months come to the conclusion that there are now better (or at least better-documented) network-management solutions available for all of my use cases. As a result, I no longer use net-misc/connman-gtk . This is essentially a zero-maintenance package - it has seen very, very few bugs since having been added to the tree, it continues to work fine for the time being, and I have just bumped it to EAPI 8. However, it has currently got no upstream (the relevant GitHub repository got archived in 2021) so if/when changes to its dependencies or to the toolchains eventually render it non-functional, the future maintainer will likely be on their own. Were I still there at that point in time I would probably just last-rite it, then again perhaps there is someone here able and willing to give this tool a fighting chance! -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Retirement
Dear everyone, I hesitated for quite a while before making this decision, mostly due to "if not me, who else?" considerations - but in the end, I feel the time has come for me to hand in my OpenPGP keys and retire from Gentoo development at the end of June. These ~8 years have been a very interesting time for me, not in the least thanks to my involvement in getting Gentoo Linux ready for 64-bit RISC-V and my term on the Council. That said, when Roy mentioned in response to one of the other recent retirements that this is supposed to be fun, I realised that - with all the obscure test failures I was never able to reproduce, the perennial battles for compatibility with alternative toolchains and MUSL, the loss of co-maintainers of several packages, the growing number of bugs specific to arches I haven't got much interest in as far as Gentoo is concerned, and the changes to my personal circumstances which began about 2 years ago and have yet to conclude - that this has been anything *but* fun for me lately. I am planning to spend the next 2.5 weeks tackling at least part of my current bug backlog. Will see how far ahead I can get with this. Thank you for your work, ladies and gentlemen of Gentoo. And good luck. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: app-misc/gramps, dev-libs/granite, media-gfx/sane-frontends, media-gfx/yafaray, net-dialup/freeradius, sys-apps/miller
On 2018-10-09 21:58, Michał Górny wrote: > app-misc/gramps Having actually worked together with the proxied maintainer on introducing version 4 into the tree, I'll take this one. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 2019-04-24 13:41, Rich Freeman wrote: > What is the recommended way to create an on-card key? I haven't got my NitroKey yet but between the specifications (which say NK2 can hold up to 3 private RSA keys) and my prior experience with OpenPGP smartcards (which have always had at most one slot each assigned to authentication, encryption and signing), chances are pretty high you cannot have two separate signing keys in hardware. If so, your best bet is probably to generate the primary key in software (preferably with usage bits stripped down so that it can ONLY be used for signing keys), generate hardware subkeys associated with it, then stash the private primary key away somewhere. -- MS
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 2019-04-24 20:34, Rich Freeman wrote: > The only reason to have a separate primary key is to have an offline > copy, Not quite. First and foremost, you don not want to have an offline copy of the primary private key - you want to have the primary ENTIRELY offline. Secondly, the reason for that is not (just) to have a backup but that the primary private key gives you virtually unlimited control. Create pretty much any number of additional subkeys? Check. Assign additional user IDs? Check. Change expiration dates? Check. And so on... In short, having the primary private key compromised means A LOT of trouble - and not just for the key owner either, the primary is also used to sign other people's public keys so it could mess up other users' trust databases. > So, maintaining this requirement with a Nitrokey means that we in > reality have the primary key online most of the time, Seeing as separating the primary and the signing key has been part of OpenPGP best practices for a long, long time, I have got highly mixed feelings about this statement. On the one hand, it is not reasonable to expect someone with no or minimal prior knowledge of OpenPGP to master it overnight. On the other, we are not just some random people from Teh Intarwebz and we *have* been using OpenPGP signatures on commits for quite a while now. > when if it were the same as the signing key then both would be > offline in the Nitrokey. Using a hardware security device is not the same as making the key offline - especially given that the Gentoo NitroKey workflow as currently posted on the Wiki suggests disabling forcesig, which could effectively leave the signing private key unlocked for extended periods of time. > Also, by generating the key outside the Nitrokey it is exposed to a > far higher risk of compromise. As Kristian has already mentioned, in principle one could keep the primary private key on a separate token. > In any case, I think it is far more likely that somebody generating > keys using software has a rooted box than somebody is going to come > up with a way to extract keys from a Nitrokey. You do not have to extract keys from a smartcard in order to be able to use keys physically present on it. All you have to do observe the smartcard user's PIN - either physically or using said rooted box - then nick the smartcard off them, ehich given that we are talking about keys that are supposed to be used on a regular basis might be very simple. Hell, if said smartcard contains the primary key you might even return it to them once you're done compromising them (e.g. by generating your own set of subkeys) and chances are pretty good that as long as everything keeps on working fine for them, it will take a quite a while before anyone notices. Conversely, even a software-generated primary key stored on a software-encrypted USB stick might be more secure simply because with it being only occasionally required, it can be stored somewhere hard to access. You don't even need a vault (which, incidentally, is something I have found people trying to make fun of crypto nerds mention a lot) either - my personal experience has taught me that giving to a trusted family member or friend who doesn't live with you is not a bad solution either. > Really the only thing we're missing with the Nitrokey is some form of > attestation to ensure the keys are in fact generated on the device. That would indeed be nice to have, unfortunately I do not think the current hardware supports this. I know recent YubiKeys do but only in PIV mode (i.e. for X.509). On the other hand, vulnerabilities such as ROCA show clearly that generating the private key on a smartcard does NOT necessarily make it more secure than generating it in software, importing it into the smartcard and wiping the original. -- MS
Re: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards
On 2019-04-25 12:32, Rich Freeman wrote: > The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that > are being distributed to Gentoo developers, do not support having a > separate primary/signing key for keys that are generated on the cards. > As a result they can only be used in accordance with our current > requirements if the keys are generated in software, which places them > at a higher risk of compromise. > > The intent of the separate primary key is to reduce the risk of it > being compromised by keeping it offline. However, if it were > generated on a smartcard it would be exclusively be maintained > offline, so it is counterproductive to require that it be generated > online and then recommend that it be kept offline after this. > Additionally this key needs to be brought back online anytime the key > expiration is updated, which is at least annually. > > I believe this is creating a false sense of security, and that > developers should be encouraged to generate new keys using their > smartcards, so that these keys are never stored outside the protected > hardware. By default gpg creates revocation certificates at this time > as well. If a key is lost it can still be revoked, and of course the > gpg fingerprint associated with the developer can be changed in any > case and is the de-facto root of our trust system. These failure > modes really are no different from an offline primary key that is > separate from the signing keys. > > The revision adds an exception for keys generated on a smartcard. I very much oppose this change, see my comments in the "Best way to create a GLEP 63 compliant GPG key on Nitrocard?" thread for details. Regarding the very accurate comment that requiring a separate primary key does not guarantee said primary key is handled securely - I know it might be overly optimistic of me but I kind of expect developers of a mainstream Linux distribution to be able to grasp and follow OpenPGP best practices. Incidentally, having been using smartcards of various sort in my workflows for 5+ years now I find their most obvious benefit is not that they store crypto keys securely but that they make the use of keys *more convenient*. Worried about persistence of the private key on your drive, especially on a shared system? Remove the card and the key is inaccessible, and since it was never handled by the system itself there should be no traces of it even in RAM. Fed up with resetting user passwords being a significant part of your sysadmin duties due to some people seemingly being unable to retain "at least 16 characters long and a minimum 3 character classes" in their wetware? Smartcard PINs can be much shorter because smartcards can lock up after a fairly small number of having entered the PIN wrong. In fact, although the official Gentoo rationale for the use of Nitrokeys as stated on the relevant Wiki page is that it makes the signing keys more secure, the recommendation to disable forcesig does hint at the ease-of-use factor as well. -- MS
Re: [gentoo-dev] [PATCH] user.eclass: die if hard coded UID or GID is already in use
On 2019-05-27 16:45, William Hubbs wrote: > If a package hard codes the UID or GID when adding a user or group to > the system and that UID/GID already exists, we should abort rather than > changing the UID/GID. +1. It is of course my personal opinion but years of having been working with various scientific software pipelines have made me rabidly allergic to tools which do a different thing than what they were asked to do unless explicitly allowed to do it this way. And what is the point of specifying a "preferred" xID anyway? We cannot rely on these values anywhere so IMHO all they do is add noise. And no, in my book "it has always been like this" is not by itself a good reason to maintain the status quo. -- MS
[gentoo-dev] [PATCH] profiles: add more language codes to desc/l10n.desc
All of these are supported by recent versions of app-text/tesseract. Checked against ISO-639 using the code tables from https://iso639-3.sil.org/ . Signed-off-by: Marek Szuba --- profiles/desc/l10n.desc | 14 ++ 1 file changed, 14 insertions(+) diff --git a/profiles/desc/l10n.desc b/profiles/desc/l10n.desc index 4d30aa57eb3..e5e21346174 100644 --- a/profiles/desc/l10n.desc +++ b/profiles/desc/l10n.desc @@ -41,8 +41,10 @@ bs - Bosnian ca - Catalan ca-valencia - Catalan (Valencian) cak - Kaqchikel +ceb - Cebuano chr - Cherokee cnr - Montenegrin +co - Corsican cs - Czech cy - Welsh da - Danish @@ -53,6 +55,7 @@ de-DE - German (Germany) dgo - Dogri (individual language) doi - Dogri (macrolanguage) dsb - Lower Sorbian +dv - Dhivehi dz - Dzongkha el - Modern Greek en - English @@ -88,13 +91,16 @@ he - Hebrew hi - Hindi hr - Croatian hsb - Upper Sorbian +ht - Haitian hu - Hungarian hy - Armenian ia - Interlingua id - Indonesian is - Icelandic it - Italian +iu - Inuktitut (macrolanguage) ja - Japanese +jv - Javanese ka - Georgian kab - Kabyle kk - Kazakh @@ -120,6 +126,7 @@ mn - Mongolian mni - Manipuri mr - Marathi ms - Malay (macrolanguage) +mt - Maltese my - Burmese nan - Min Nan Chinese nb - Norwegian Bokmål @@ -134,9 +141,11 @@ om - Oromo or - Oriya (macrolanguage) pa - Punjabi pl - Polish +ps - Pashto (macrolanguage) pt - Portuguese pt-BR - Portuguese (Brazil) pt-PT - Portuguese (Portugal) +qu - Quechua (macrolanguage) rm - Romansh ro - Romanian ru - Russian @@ -156,6 +165,7 @@ sr - Serbian sr-Latn - Serbian (Latin script) ss - Swati st - Southern Sotho +su - Sundanese sv - Swedish sw - Swahili (macrolanguage) sw-TZ - Swahili (Tanzania) @@ -165,9 +175,11 @@ ta-LK - Tamil (Sri Lanka) te - Telugu tg - Tajik th - Thai +ti - Tigrinya tk - Turkmen tl - Tagalog tn - Tswana +to-TO - Tonga (Tonga Islands) tr - Turkish ts - Tsonga tt - Tatar @@ -178,6 +190,8 @@ uz - Uzbek ve - Venda vi - Vietnamese xh - Xhosa +yi - Yiddish (macrolanguage) +yo - Yoruba zh - Chinese zh-CN - Chinese (China) zh-TW - Chinese (Taiwan) -- 2.21.0 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] profiles: add more language codes to desc/l10n.desc
On 2019-06-12 16:12, Michał Górny wrote: >> +dv - Dhivehi > > IANA registry says: > > | Subtag: dv > | Description: Dhivehi > | Description: Divehi > | Description: Maldivian > > So maybe make it 'Dhivehi (Maldivian)'? Originally I had all three names here but then I noticed that for at least some of the existing entries which in the SIL database are described by multiple names, lb for instance, only the first one from the list is used. Personally I have got no opinion either way. >> +to-TO - Tonga (Tonga Islands) > > Why not just 'to'? Good point, "to" does specifically refer to Tonga Islands Tonga after all. I think I've been overly cautious here. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2] profiles: add more language codes to desc/l10n.desc
Many thanks for the feedback, here is the revised patch: * * * All of these are supported by recent versions of app-text/tesseract. Checked against ISO-639 using the code tables from https://iso639-3.sil.org/ . Signed-off-by: Marek Szuba --- profiles/desc/l10n.desc | 14 ++ 1 file changed, 14 insertions(+) diff --git a/profiles/desc/l10n.desc b/profiles/desc/l10n.desc index 4d30aa57eb3..e5e21346174 100644 --- a/profiles/desc/l10n.desc +++ b/profiles/desc/l10n.desc @@ -41,8 +41,10 @@ bs - Bosnian ca - Catalan ca-valencia - Catalan (Valencian) cak - Kaqchikel +ceb - Cebuano chr - Cherokee cnr - Montenegrin +co - Corsican cs - Czech cy - Welsh da - Danish @@ -53,6 +55,7 @@ de-DE - German (Germany) dgo - Dogri (individual language) doi - Dogri (macrolanguage) dsb - Lower Sorbian +dv - Dhivehi dz - Dzongkha el - Modern Greek en - English @@ -88,13 +91,16 @@ he - Hebrew hi - Hindi hr - Croatian hsb - Upper Sorbian +ht - Haitian hu - Hungarian hy - Armenian ia - Interlingua id - Indonesian is - Icelandic it - Italian +iu - Inuktitut ja - Japanese +jv - Javanese ka - Georgian kab - Kabyle kk - Kazakh @@ -120,6 +126,7 @@ mn - Mongolian mni - Manipuri mr - Marathi ms - Malay (macrolanguage) +mt - Maltese my - Burmese nan - Min Nan Chinese nb - Norwegian Bokmål @@ -134,9 +141,11 @@ om - Oromo or - Oriya (macrolanguage) pa - Punjabi pl - Polish +ps - Pushto pt - Portuguese pt-BR - Portuguese (Brazil) pt-PT - Portuguese (Portugal) +qu - Quechua rm - Romansh ro - Romanian ru - Russian @@ -156,6 +165,7 @@ sr - Serbian sr-Latn - Serbian (Latin script) ss - Swati st - Southern Sotho +su - Sundanese sv - Swedish sw - Swahili (macrolanguage) sw-TZ - Swahili (Tanzania) @@ -165,9 +175,11 @@ ta-LK - Tamil (Sri Lanka) te - Telugu tg - Tajik th - Thai +ti - Tigrinya tk - Turkmen tl - Tagalog tn - Tswana +to - Tonga (Tonga Islands) tr - Turkish ts - Tsonga tt - Tatar @@ -178,6 +190,8 @@ uz - Uzbek ve - Venda vi - Vietnamese xh - Xhosa +yi - Yiddish +yo - Yoruba zh - Chinese zh-CN - Chinese (China) zh-TW - Chinese (Taiwan) -- 2.21.0 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2] profiles: add more language codes to desc/l10n.desc
On 2019-06-13 13:46, Jaco Kroon wrote: > Any chance of adding en-NZ? > > asterisk-core-sounds depends on L10N USE_EXPAND and there is an upstream > en-NZ pack. It's the only language pack for which there isn't currently > an option already in the list here. Sure, why not. Looks reasonably enough to me. -- MS
[gentoo-dev] [PATCH v3] profiles: add more language tags to desc/l10n.desc
Changes since v2: added en-NZ, updated the description. * * * All of these are supported by upstream in net-misc/asterisk-core-sounds (en-NZ) and recent versions of app-text/tesseract (the rest). Checked against ISO-639 using the code tables from https://iso639-3.sil.org/ and against the IANA language-subtag registry using the list from https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry Signed-off-by: Marek Szuba --- profiles/desc/l10n.desc | 15 +++ 1 file changed, 15 insertions(+) diff --git a/profiles/desc/l10n.desc b/profiles/desc/l10n.desc index 4d30aa57eb3..5a68f285809 100644 --- a/profiles/desc/l10n.desc +++ b/profiles/desc/l10n.desc @@ -41,8 +41,10 @@ bs - Bosnian ca - Catalan ca-valencia - Catalan (Valencian) cak - Kaqchikel +ceb - Cebuano chr - Cherokee cnr - Montenegrin +co - Corsican cs - Czech cy - Welsh da - Danish @@ -53,12 +55,14 @@ de-DE - German (Germany) dgo - Dogri (individual language) doi - Dogri (macrolanguage) dsb - Lower Sorbian +dv - Dhivehi dz - Dzongkha el - Modern Greek en - English en-AU - English (Australia) en-CA - English (Canada) en-GB - English (United Kingdom) +en-NZ - English (New Zealand) en-US - English (United States) en-ZA - English (South Africa) eo - Esperanto @@ -88,13 +92,16 @@ he - Hebrew hi - Hindi hr - Croatian hsb - Upper Sorbian +ht - Haitian hu - Hungarian hy - Armenian ia - Interlingua id - Indonesian is - Icelandic it - Italian +iu - Inuktitut ja - Japanese +jv - Javanese ka - Georgian kab - Kabyle kk - Kazakh @@ -120,6 +127,7 @@ mn - Mongolian mni - Manipuri mr - Marathi ms - Malay (macrolanguage) +mt - Maltese my - Burmese nan - Min Nan Chinese nb - Norwegian Bokmål @@ -134,9 +142,11 @@ om - Oromo or - Oriya (macrolanguage) pa - Punjabi pl - Polish +ps - Pushto pt - Portuguese pt-BR - Portuguese (Brazil) pt-PT - Portuguese (Portugal) +qu - Quechua rm - Romansh ro - Romanian ru - Russian @@ -156,6 +166,7 @@ sr - Serbian sr-Latn - Serbian (Latin script) ss - Swati st - Southern Sotho +su - Sundanese sv - Swedish sw - Swahili (macrolanguage) sw-TZ - Swahili (Tanzania) @@ -165,9 +176,11 @@ ta-LK - Tamil (Sri Lanka) te - Telugu tg - Tajik th - Thai +ti - Tigrinya tk - Turkmen tl - Tagalog tn - Tswana +to - Tonga (Tonga Islands) tr - Turkish ts - Tsonga tt - Tatar @@ -178,6 +191,8 @@ uz - Uzbek ve - Venda vi - Vietnamese xh - Xhosa +yi - Yiddish +yo - Yoruba zh - Chinese zh-CN - Chinese (China) zh-TW - Chinese (Taiwan) -- 2.21.0 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 0/6] User/group assignment: burp, rtkit, syncthing
Here is the RFC for acct-* packages corresponding to users and groups created by packages I currently maintain. This is also a request to reserve the respective UIDs/GIDs, namely: Groups: - burp - 501 - rtkit - 133 Users: - burp - 501 - rtkit - 133 - syncthing - 502 rtkit user and group have got their IDs reserved in both Arch and Fedora, I have opted for consistency with the former.
[gentoo-dev] [PATCH 4/6] acct-user/burp: Add 'burp' user (UID 501)
Signed-off-by: Marek Szuba --- acct-user/burp/burp-0.ebuild | 12 acct-user/burp/metadata.xml | 8 2 files changed, 20 insertions(+) create mode 100644 acct-user/burp/burp-0.ebuild create mode 100644 acct-user/burp/metadata.xml diff --git a/acct-user/burp/burp-0.ebuild b/acct-user/burp/burp-0.ebuild new file mode 100644 index 000..660c98f57b9 --- /dev/null +++ b/acct-user/burp/burp-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the app-backup/burp server" +ACCT_USER_ID=501 +ACCT_USER_GROUPS=( burp ) + +acct-user_add_deps diff --git a/acct-user/burp/metadata.xml b/acct-user/burp/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/burp/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + -- 2.21.0
[gentoo-dev] [PATCH 2/6] acct-group/rtkit: Add 'rtkit' group (GID 133)
Same GID as in Arch Linux. Signed-off-by: Marek Szuba --- acct-group/rtkit/metadata.xml | 8 acct-group/rtkit/rtkit-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/rtkit/metadata.xml create mode 100644 acct-group/rtkit/rtkit-0.ebuild diff --git a/acct-group/rtkit/metadata.xml b/acct-group/rtkit/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/rtkit/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/rtkit/rtkit-0.ebuild b/acct-group/rtkit/rtkit-0.ebuild new file mode 100644 index 000..9361f86968b --- /dev/null +++ b/acct-group/rtkit/rtkit-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the Realtime Policy and Watchdog Daemon" +ACCT_GROUP_ID=133 -- 2.21.0
[gentoo-dev] [PATCH 3/6] acct-group/syncthing: Add 'syncthing' group (GID 502)
Signed-off-by: Marek Szuba --- acct-group/syncthing/metadata.xml | 8 acct-group/syncthing/syncthing-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/syncthing/metadata.xml create mode 100644 acct-group/syncthing/syncthing-0.ebuild diff --git a/acct-group/syncthing/metadata.xml b/acct-group/syncthing/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/syncthing/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/syncthing/syncthing-0.ebuild b/acct-group/syncthing/syncthing-0.ebuild new file mode 100644 index 000..a015336764f --- /dev/null +++ b/acct-group/syncthing/syncthing-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the system-wide net-p2p/syncthing server" +ACCT_GROUP_ID=502 -- 2.21.0
[gentoo-dev] [PATCH 1/6] acct-group/burp: Add 'burp' group (GID 501)
Signed-off-by: Marek Szuba --- acct-group/burp/burp-0.ebuild | 9 + acct-group/burp/metadata.xml | 8 2 files changed, 17 insertions(+) create mode 100644 acct-group/burp/burp-0.ebuild create mode 100644 acct-group/burp/metadata.xml diff --git a/acct-group/burp/burp-0.ebuild b/acct-group/burp/burp-0.ebuild new file mode 100644 index 000..ff29d3a2cd7 --- /dev/null +++ b/acct-group/burp/burp-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the app-backup/burp server" +ACCT_GROUP_ID=501 diff --git a/acct-group/burp/metadata.xml b/acct-group/burp/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/burp/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + -- 2.21.0
[gentoo-dev] [PATCH 6/6] acct-user/syncthing: Add 'syncthing' user (UID 502)
Signed-off-by: Marek Szuba --- acct-user/syncthing/metadata.xml | 8 acct-user/syncthing/syncthing-0.ebuild | 14 ++ 2 files changed, 22 insertions(+) create mode 100644 acct-user/syncthing/metadata.xml create mode 100644 acct-user/syncthing/syncthing-0.ebuild diff --git a/acct-user/syncthing/metadata.xml b/acct-user/syncthing/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/syncthing/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/syncthing/syncthing-0.ebuild b/acct-user/syncthing/syncthing-0.ebuild new file mode 100644 index 000..e9a04702f3d --- /dev/null +++ b/acct-user/syncthing/syncthing-0.ebuild @@ -0,0 +1,14 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the system-wide net-p2p/syncthing server" +ACCT_USER_ID=502 +ACCT_USER_HOME=/var/lib/syncthing +ACCT_USER_HOME_PERMS=0770 +ACCT_USER_GROUPS=( syncthing ) + +acct-user_add_deps -- 2.21.0
[gentoo-dev] [PATCH 5/6] acct-user/rtkit: Add 'rtkit' user (UID 133)
Same UID as in Arch Linux. Signed-off-by: Marek Szuba --- acct-user/rtkit/metadata.xml | 8 acct-user/rtkit/rtkit-0.ebuild | 12 2 files changed, 20 insertions(+) create mode 100644 acct-user/rtkit/metadata.xml create mode 100644 acct-user/rtkit/rtkit-0.ebuild diff --git a/acct-user/rtkit/metadata.xml b/acct-user/rtkit/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/rtkit/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/rtkit/rtkit-0.ebuild b/acct-user/rtkit/rtkit-0.ebuild new file mode 100644 index 000..0e63e6514a1 --- /dev/null +++ b/acct-user/rtkit/rtkit-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the Realtime Policy and Watchdog Daemon" +ACCT_USER_ID=133 +ACCT_USER_GROUPS=( rtkit ) + +acct-user_add_deps -- 2.21.0
[gentoo-dev] [PATCH v2 0/6] User/group assignment: burp, rtkit, syncthing
Thank you for your feedback, here is the second version of the patch set. Changes: - shifted the IDs for burp and syncthing into the appropriate LSB range; the Wiki page has been updated accordingly. * * * Here is the RFC for acct-* packages corresponding to users and groups created by packages I currently maintain. This is also a request to reserve the respective UIDs/GIDs, namely: Groups: - burp - 498 - rtkit - 133 - syncthing - 499 Users: - burp - 498 - rtkit - 133 - syncthing - 499
[gentoo-dev] [PATCH 1/6] acct-group/burp: Add 'burp' group (GID 498)
Signed-off-by: Marek Szuba --- acct-group/burp/burp-0.ebuild | 9 + acct-group/burp/metadata.xml | 8 2 files changed, 17 insertions(+) create mode 100644 acct-group/burp/burp-0.ebuild create mode 100644 acct-group/burp/metadata.xml diff --git a/acct-group/burp/burp-0.ebuild b/acct-group/burp/burp-0.ebuild new file mode 100644 index 000..f9d68d05dab --- /dev/null +++ b/acct-group/burp/burp-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the app-backup/burp server" +ACCT_GROUP_ID=498 diff --git a/acct-group/burp/metadata.xml b/acct-group/burp/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/burp/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + -- 2.21.0
[gentoo-dev] [PATCH 2/6] acct-group/rtkit: Add 'rtkit' group (GID 133)
Same GID as in Arch Linux. Signed-off-by: Marek Szuba --- acct-group/rtkit/metadata.xml | 8 acct-group/rtkit/rtkit-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/rtkit/metadata.xml create mode 100644 acct-group/rtkit/rtkit-0.ebuild diff --git a/acct-group/rtkit/metadata.xml b/acct-group/rtkit/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/rtkit/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/rtkit/rtkit-0.ebuild b/acct-group/rtkit/rtkit-0.ebuild new file mode 100644 index 000..9361f86968b --- /dev/null +++ b/acct-group/rtkit/rtkit-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the Realtime Policy and Watchdog Daemon" +ACCT_GROUP_ID=133 -- 2.21.0
[gentoo-dev] [PATCH 4/6] acct-user/burp: Add 'burp' user (UID 498)
Signed-off-by: Marek Szuba --- acct-user/burp/burp-0.ebuild | 12 acct-user/burp/metadata.xml | 8 2 files changed, 20 insertions(+) create mode 100644 acct-user/burp/burp-0.ebuild create mode 100644 acct-user/burp/metadata.xml diff --git a/acct-user/burp/burp-0.ebuild b/acct-user/burp/burp-0.ebuild new file mode 100644 index 000..f6c78b24856 --- /dev/null +++ b/acct-user/burp/burp-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the app-backup/burp server" +ACCT_USER_ID=498 +ACCT_USER_GROUPS=( burp ) + +acct-user_add_deps diff --git a/acct-user/burp/metadata.xml b/acct-user/burp/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/burp/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + -- 2.21.0
[gentoo-dev] [PATCH 3/6] acct-group/syncthing: Add 'syncthing' group (GID 499)
Signed-off-by: Marek Szuba --- acct-group/syncthing/metadata.xml | 8 acct-group/syncthing/syncthing-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/syncthing/metadata.xml create mode 100644 acct-group/syncthing/syncthing-0.ebuild diff --git a/acct-group/syncthing/metadata.xml b/acct-group/syncthing/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/syncthing/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/syncthing/syncthing-0.ebuild b/acct-group/syncthing/syncthing-0.ebuild new file mode 100644 index 000..4e7ab771bb4 --- /dev/null +++ b/acct-group/syncthing/syncthing-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the system-wide net-p2p/syncthing server" +ACCT_GROUP_ID=499 -- 2.21.0
[gentoo-dev] [PATCH 6/6] acct-user/syncthing: Add 'syncthing' user (UID 499)
Signed-off-by: Marek Szuba --- acct-user/syncthing/metadata.xml | 8 acct-user/syncthing/syncthing-0.ebuild | 14 ++ 2 files changed, 22 insertions(+) create mode 100644 acct-user/syncthing/metadata.xml create mode 100644 acct-user/syncthing/syncthing-0.ebuild diff --git a/acct-user/syncthing/metadata.xml b/acct-user/syncthing/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/syncthing/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/syncthing/syncthing-0.ebuild b/acct-user/syncthing/syncthing-0.ebuild new file mode 100644 index 000..136d34e4cdb --- /dev/null +++ b/acct-user/syncthing/syncthing-0.ebuild @@ -0,0 +1,14 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the system-wide net-p2p/syncthing server" +ACCT_USER_ID=499 +ACCT_USER_HOME=/var/lib/syncthing +ACCT_USER_HOME_PERMS=0770 +ACCT_USER_GROUPS=( syncthing ) + +acct-user_add_deps -- 2.21.0
[gentoo-dev] [PATCH 5/6] acct-user/rtkit: Add 'rtkit' user (UID 133)
Same UID as in Arch Linux. Signed-off-by: Marek Szuba --- acct-user/rtkit/metadata.xml | 8 acct-user/rtkit/rtkit-0.ebuild | 12 2 files changed, 20 insertions(+) create mode 100644 acct-user/rtkit/metadata.xml create mode 100644 acct-user/rtkit/rtkit-0.ebuild diff --git a/acct-user/rtkit/metadata.xml b/acct-user/rtkit/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/rtkit/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/rtkit/rtkit-0.ebuild b/acct-user/rtkit/rtkit-0.ebuild new file mode 100644 index 000..0e63e6514a1 --- /dev/null +++ b/acct-user/rtkit/rtkit-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the Realtime Policy and Watchdog Daemon" +ACCT_USER_ID=133 +ACCT_USER_GROUPS=( rtkit ) + +acct-user_add_deps -- 2.21.0
Re: [gentoo-dev] Re: Why aren't GSoC projects affecting ::gentoo discussed on regular mls?
On 2019-06-27 04:16, Benda Xu wrote: > Michał, you were overreacting to the word "GSoC" since our original RFC > at gentoo-dev. Please, just ignore GSoC when you are executing your > experise of QA. Gentoo should be developed independently, regardless of > whether any development effort is supported by 3rd party. [...] > Personally I don't regard the GSoC selection and decision process > interesting to all the Gentoo devs. In my opinion Michał has got a very good point regarding potential PR consequences of us rejecting GSoC work. Of course it can be done, I've seen my share of student projects of various sort getting binned immediately after implementation - but more often than not it shows a lack of of foresight, at best, on behalf of institutions which requested manpower for such projects. Yes, it is good for you to have eventually brought this to -dev - but IMHO it really is too late. In the future, I would STRONGLY advise having a general discussion before having even a single line of code written. -- MS
[gentoo-dev] [PATCH 0/4] User/group assignment: stdiscosrv, strelaysrv
Further to my RFC from last week, net-p2p/syncthing optionally installs two auxiliary components - the discovery server and the relay server - which run as their own users. The following patch set creates appropriate acct-* packages for them. This is also a request to reserve the respective UIDs/GIDs, namely: Groups: - stdiscosrv - 497 - strelaysrv - 496 Users: - stdiscosrv - 497 - strelaysrv - 496 The relevant Wiki page has already been updated accordingly.
[gentoo-dev] [PATCH 1/4] acct-group/stdiscosrv: Add 'stdiscosrv' group (GID 497)
Signed-off-by: Marek Szuba --- acct-group/stdiscosrv/metadata.xml| 8 acct-group/stdiscosrv/stdiscosrv-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/stdiscosrv/metadata.xml create mode 100644 acct-group/stdiscosrv/stdiscosrv-0.ebuild diff --git a/acct-group/stdiscosrv/metadata.xml b/acct-group/stdiscosrv/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/stdiscosrv/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/stdiscosrv/stdiscosrv-0.ebuild b/acct-group/stdiscosrv/stdiscosrv-0.ebuild new file mode 100644 index 000..478159a9351 --- /dev/null +++ b/acct-group/stdiscosrv/stdiscosrv-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the Syncthing discovery server" +ACCT_GROUP_ID=497 -- 2.21.0
[gentoo-dev] [PATCH 3/4] acct-user/stdiscosrv: Add 'stdiscosrv' user (UID 497)
Signed-off-by: Marek Szuba --- acct-user/stdiscosrv/metadata.xml| 8 acct-user/stdiscosrv/stdiscosrv-0.ebuild | 14 ++ 2 files changed, 22 insertions(+) create mode 100644 acct-user/stdiscosrv/metadata.xml create mode 100644 acct-user/stdiscosrv/stdiscosrv-0.ebuild diff --git a/acct-user/stdiscosrv/metadata.xml b/acct-user/stdiscosrv/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/stdiscosrv/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/stdiscosrv/stdiscosrv-0.ebuild b/acct-user/stdiscosrv/stdiscosrv-0.ebuild new file mode 100644 index 000..06485edd765 --- /dev/null +++ b/acct-user/stdiscosrv/stdiscosrv-0.ebuild @@ -0,0 +1,14 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the Syncthing discovery server" +ACCT_USER_ID=497 +ACCT_USER_HOME=/var/lib/stdiscosrv +ACCT_USER_HOME_PERMS=0770 +ACCT_USER_GROUPS=( stdiscosrv ) + +acct-user_add_deps -- 2.21.0
[gentoo-dev] [PATCH 2/4] acct-group/strelaysrv: Add 'strelaysrv' group (GID 496)
Signed-off-by: Marek Szuba --- acct-group/strelaysrv/metadata.xml| 8 acct-group/strelaysrv/strelaysrv-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/strelaysrv/metadata.xml create mode 100644 acct-group/strelaysrv/strelaysrv-0.ebuild diff --git a/acct-group/strelaysrv/metadata.xml b/acct-group/strelaysrv/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/strelaysrv/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/strelaysrv/strelaysrv-0.ebuild b/acct-group/strelaysrv/strelaysrv-0.ebuild new file mode 100644 index 000..ddb60b5ea64 --- /dev/null +++ b/acct-group/strelaysrv/strelaysrv-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the Syncthing relay server" +ACCT_GROUP_ID=496 -- 2.21.0
[gentoo-dev] [PATCH 4/4] acct-user/strelaysrv: Add 'strelaysrv' user (UID 496)
Signed-off-by: Marek Szuba --- acct-user/strelaysrv/metadata.xml| 8 acct-user/strelaysrv/strelaysrv-0.ebuild | 14 ++ 2 files changed, 22 insertions(+) create mode 100644 acct-user/strelaysrv/metadata.xml create mode 100644 acct-user/strelaysrv/strelaysrv-0.ebuild diff --git a/acct-user/strelaysrv/metadata.xml b/acct-user/strelaysrv/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/strelaysrv/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/strelaysrv/strelaysrv-0.ebuild b/acct-user/strelaysrv/strelaysrv-0.ebuild new file mode 100644 index 000..4208dc590e0 --- /dev/null +++ b/acct-user/strelaysrv/strelaysrv-0.ebuild @@ -0,0 +1,14 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for the Syncthing relay server" +ACCT_USER_ID=496 +ACCT_USER_HOME=/var/lib/strelaysrv +ACCT_USER_HOME_PERMS=0770 +ACCT_USER_GROUPS=( strelaysrv ) + +acct-user_add_deps -- 2.21.0
[gentoo-dev] News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0
Hello, Please find attached a news item warning the users of net-p2p/syncthing that version 1.2.0 and newer do not interoperate with version 0.14.45 and older. I have included the same warning in the 1.2.0 ebuild, that said I believe this deserves a news item because a) it could affect mission-critical file-replication set-ups, and b) old versions panic and shut down when fed incompatible data. Thank you in advance for any and all feedback! -- MS Title: Syncthing 1.2.0 and newer do not interoperate with 0.14.45 and older Author: Marek Szuba Posted: 2019-07-18 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: net-p2p/syncthing Starting with version 1.2.0, Syncthing always uses large, variable-sized, blocks to index and transfer files larger than 256 MiB [1]. Syncthing version 0.14.45 and older will initially appear to accept files scanned with large blocks, but will later panic during some internal file operations. Do NOT enable large blocks in clusters with devices still on v0.14.45 or older, e.g. Debian Stretch servers using official packages. [1] https://docs.syncthing.net/advanced/folder-uselargeblocks.html signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript
On 2019-07-15 12:38, Jaco Kroon wrote: > I'm personally using a separate /usr (On numerous systems) and other > than one problem I've encountered this isn't actually currently an issue > for me, and the reason this specific case was an issue was due to one > single tool (which unfortunately I can't remember now) having been > installed into /usr where I'd personally expect it to go into /. The issue is not with *split* /usr, it's with the scenario currently being adopted by many Linux distros (e.g. Fedora or Debian) in which /bin, /sbin, /lib and /lib64 are symlinks to respective subdirectories of /usr. The purpose of the changes at hand is, as described by floppym in his initial post, to pave the way towards making merged /usr workable on Gentoo for the average user. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript
On 2019-07-15 14:59, Jaco Kroon wrote: > I've seen arguments that it's a historic split, and to an extent this is > true, however, having critical system recovery (and basic boot) stuff in > /, on as small as possible a partition, with the bulk of the system on > /usr makes a lot of sense for me. That's one of the reasons, yes. For a more in-depth discussion, see https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ as well as the Fedora feature the above mentions. -- MS
[gentoo-dev] Re: News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0
On 2019-07-18 11:12, Kristian Fiskerstrand wrote: > Should we be more specific as to how not to enable it here? is it a > USE-flag? does it require a package mask for newer versions if it is > always used for the newer ones? Good point, this should explicitly say "do not emerge new versions". My own thoughts on the matter have been that since we are now in the process of stabilising syncthing-1.1.4 (i.e. the latest version which does not force the use of large blocks) and that I do not intend to push the 1.2.0 ebuild until stabilisation has been concluded, it would be up to individual users to mask newer versions should they insist on using ~arch ebuilds. > Also cluster immediately made me think of server<>client relationship > and this only affecting server side, which probably doesn't fit well > with syncthing, but admittedly I don't use it so not familiar with the > nomenclature. I guess it is a bit subjective and/or based on one's experience, in my case "cluster" brings to mind a cluster of peers. Anyway, this is the wording from the official upstream statement so I would rather not change it unless there is a good reason for it - like the Gentoo-specific clarification you have suggested above. PS. For the record, I have already published this news item (a couple of hours ahead of schedule I am afraid, I didn't remember the exact time I submitted the RFC) so I'll include your comments in the second revision. -- MS
[gentoo-dev] Package up for grabs: dev-libs/amdgpu-pro-opencl
For those of you not familiar with it, dev-libs/amdgpu-pro-opencl packages the OpenCL bits of the proprietary, binary-only AMDGPU-Pro software stack into a form compatible with the Open Source amdgpu environment in general and Gentoo in particular. It has been working surprisingly well for an ugly hack it is but now that we have Radeon Open Compute-based OpenCL support for amdgpu (which will eventually be fully Open Source and at the moment only requires proprietary libraries for one last feature, image support) in the tree I feel it is time for it to go - especially given that it only support AMD GPUs older than Vega 10. Unfortunately it would be awkward to simply last-rite because the ROC-based implementation does not support ABI_X86_32 (dev-libs/rocm-opencl-runtime and its dependencies may or may not work in 32-bit mode but have neither multilib support nor x86 keywords at present, whereas the closed-source components are only available for native amd64). No open tickets on Bugzilla, binaries for both versions currently in the tree are still available, and beyond the obvious shortcoming of not supporting more recent GPUs in spite of upstream providing appropriate libraries (I haven't tried packaging them because my AMD GPU is too old to test them on), no real problems at the moment. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Change Bugzilla status to IN_PROGRESS when pull request is linked
On 2019-10-25 17:00, Ralph Seichter wrote: > For convenience, would it be possible to automatically change the status > of bugs from (UN)CONFIRMED to IN_PROGRESS when Larry The Cow attaches a > pull request? I tend to forget to change the status myself, and perhaps > I am not alone in feeling my age in that fashion. ;-) I am against this, for the same reason as Michał and Kent - to me "in progress" means "the maintainer is working on it", not "someone has just made a PR on GitHub which the maintainer may or may not accept". -- MS
[gentoo-dev] RFC: UID/GID assignment for net-analyzer/suricata
Hello, I hereby order... no, wait. Let me start over. Seeing as I am now in the process of reviving net-analyzer/suricata in the tree (5.0.0 builds and tests fine for me, there are however a few installation-time QA issues I'd like to take care of before pushing this), I would like to request UID/GID 477 for the Suricata user/group. There is no such user in either Arch or Fedora. Let me know if you have any questions or comments. -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 2/2] acct-user/suricata: new user for UID 477
Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Marek Szuba --- acct-user/suricata/metadata.xml | 8 acct-user/suricata/suricata-0.ebuild | 14 ++ 2 files changed, 22 insertions(+) create mode 100644 acct-user/suricata/metadata.xml create mode 100644 acct-user/suricata/suricata-0.ebuild diff --git a/acct-user/suricata/metadata.xml b/acct-user/suricata/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-user/suricata/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-user/suricata/suricata-0.ebuild b/acct-user/suricata/suricata-0.ebuild new file mode 100644 index 000..015bea8d022 --- /dev/null +++ b/acct-user/suricata/suricata-0.ebuild @@ -0,0 +1,14 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="User for Suricata IDS" +ACCT_USER_ID=477 +ACCT_USER_HOME=/var/lib/suricata +ACCT_USER_HOME_PERMS=0750 +ACCT_USER_GROUPS=( suricata ) + +acct-user_add_deps -- 2.23.0
[gentoo-dev] [PATCH 1/2] acct-group/suricata: new group for GID 477
Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Marek Szuba --- acct-group/suricata/metadata.xml | 8 acct-group/suricata/suricata-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/suricata/metadata.xml create mode 100644 acct-group/suricata/suricata-0.ebuild diff --git a/acct-group/suricata/metadata.xml b/acct-group/suricata/metadata.xml new file mode 100644 index 000..3e5026ee375 --- /dev/null +++ b/acct-group/suricata/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + mare...@gentoo.org + Marek Szuba + + diff --git a/acct-group/suricata/suricata-0.ebuild b/acct-group/suricata/suricata-0.ebuild new file mode 100644 index 000..11ead7b3086 --- /dev/null +++ b/acct-group/suricata/suricata-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for Suricata IDS" +ACCT_GROUP_ID=477 -- 2.23.0
Re: [gentoo-dev] [PATCH 2/2] acct-user/suricata: new user for UID 477
On 2019-12-11 13:54, Michael Orlitzky wrote: >> +ACCT_USER_HOME=/var/lib/suricata >> +ACCT_USER_HOME_PERMS=0750 > > Please don't set these unless it's absolutely necessary. The rationale > for this has finally been committed to the devmanual, but has yet to be > pushed to the website. In the meantime it's here: > >> http://michael.orlitzky.com/articles/gentoo_glep81_user_package_guidelines.xhtml Thank you for this detailed explanation! As far as I can tell there is indeed no need for this user to have a home directory other than that's the way it was done in old Suricata ebuilds - so I'll just drop these two lines (and also use $PN as the name of the primary group) from the final commit. -- MS
[gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
Penny for your thoughts, guys: I am thinking about splitting the video_cards_i965 condition in virtual/opencl so that NEO is pulled in by video_cards_iris instead, and I wonder if there is anything I haven't thought about. The reason why I would like to do this is that there is clear correspondence between compatibility matrices of the Iris OpenGL driver and the NEO OpenCL driver - both only work on Broadwell and newer. There are differences of course, most notably that the old OpenCL driver (Beignet) is already considered deprecated for systems supported by NEO whereas the old OpenGL driver in Mesa (i965) is still the official one even for newer systems. Nb. to the best of my knowledge it is safe to set VIDEO_CARDS=iris even globally because if both i965 and iris are available, Mesa for now still prefers the former unless the environment variable MESA_LOADER_DRIVER_OVERRIDE has been set to 'iris'. There would of course have to be a news item advising the users of virtual/opencl + dev-libs/intel-neo to adjust their USE flags. What do you think, guys? -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
On 2019-12-17 21:21, Matt Turner wrote: >> What do you think, guys? > > I don't love it. > > I don't like the mess that has become VIDEO_CARDS=... either. radeon > vs radeonsi vs amdgpu. [...] I hear you and very much agree, especially regarding the Radeon mess. That said, it seems what we are complaining about is the whole VIDEO_CARDS system rather than the introduction of 'iris' into virtual/opencl. The current situation with OpenCL providers for Intel GPUs ugly even disregarding the above. Basically, it is: 1. Set VIDEO_CARDS: i965 2a. If you do not set ABI_X86: 32 for virtual/opencl, it will pull in dev-libs/intel-neo 2a.1. NEO may or may not work but with the former more likely than the latter (it's been a few years since Broadwell architecture came out); 2b. If, however, you DO enable 32-bit x86 ABI it will pull dev-libs/beignet instead 2b.1. Beignet at least for the time being is likely to work even on modern systems but nowhere nearly as well as NEO would and without official upstream support. In contrast, reassigning NEO to video_cards_iris would make the Intel-GPU provider tree much more straightforward: 1. For i965, you would get dev-libs/beignet regardless of whether you want 32-bit x86 ABI or not; 2. For iris, you would get dev-libs/intel-neo for native 64 bits and nothing (okay, technically it would fall back to media-libs/mesa - but the fact Mesa is considered a fallback OpenCL provider for all GPUs is a completely different can of worms) for 32-bit x86 ABI. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 1/2] acct-group/xrootd: new group for GID 469
Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Marek Szuba --- acct-group/xrootd/metadata.xml| 8 acct-group/xrootd/xrootd-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/xrootd/metadata.xml create mode 100644 acct-group/xrootd/xrootd-0.ebuild diff --git a/acct-group/xrootd/metadata.xml b/acct-group/xrootd/metadata.xml new file mode 100644 index 000..46a304a17de --- /dev/null +++ b/acct-group/xrootd/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + sci-phys...@gentoo.org + Gentoo Physics Project + + diff --git a/acct-group/xrootd/xrootd-0.ebuild b/acct-group/xrootd/xrootd-0.ebuild new file mode 100644 index 000..7a62ea791cd --- /dev/null +++ b/acct-group/xrootd/xrootd-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the XRootD server" +ACCT_GROUP_ID=469 -- 2.24.1
[gentoo-dev] [PATCH 2/2] acct-user/xrootd: new user for UID 469
enewuser in net-libs/xrootd ebuilds has set the home directory to
"${EPREFIX}"/var/spool/xrootd but as far as I can recall from my
personal experience or see in the documentation, it isn't really
necessary for that user to have a home directory.
Package-Manager: Portage-2.3.79, Repoman-2.3.16
Signed-off-by: Marek Szuba
---
acct-user/xrootd/metadata.xml| 8
acct-user/xrootd/xrootd-0.ebuild | 12
2 files changed, 20 insertions(+)
create mode 100644 acct-user/xrootd/metadata.xml
create mode 100644 acct-user/xrootd/xrootd-0.ebuild
diff --git a/acct-user/xrootd/metadata.xml b/acct-user/xrootd/metadata.xml
new file mode 100644
index 000..46a304a17de
--- /dev/null
+++ b/acct-user/xrootd/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd";>
+
+
+ sci-phys...@gentoo.org
+ Gentoo Physics Project
+
+
diff --git a/acct-user/xrootd/xrootd-0.ebuild b/acct-user/xrootd/xrootd-0.ebuild
new file mode 100644
index 000..7b0eaaf9584
--- /dev/null
+++ b/acct-user/xrootd/xrootd-0.ebuild
@@ -0,0 +1,12 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="User for the XRootD server"
+ACCT_USER_ID=469
+ACCT_USER_GROUPS=( "${PN}" )
+
+acct-user_add_deps
--
2.24.1
Re: [gentoo-dev] crypto@ packages up for grabs
On 2020-01-08 21:16, Mikle Kolyada wrote: > app-crypt/chntpw > app-crypt/rainbowcrack I'll take these two. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-libs/beignet
Deprecated upstream in Q1'2018 in favour of dev-libs/intel-neo and while it officially remains the recommended solution for "legacy HW platforms" not supported by NEO (i.e. Sandy Bridge, Ivy Bridge and Haswell GPUs), there has been no repository activity since August 2018. Only really suitable for code development due to poor performance, some OpenCL-aware software (e.g. media-gfx/darktable) explicitly blacklists Beignet devices. Upstream does not support LLVM versions newer than 7, third-party patches exist for 8 and 9 but Beignet built against those versions fails some unit tests. Removal in 30 days. Bug #710640. -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: Removing ABI_X86_32 support from virtual/opencl
Hello, I think the time has come to follow the example of CUDA and stop supporting ABI_X86_32, both natively and in multilib configurations, in virtual/opencl. Let us have a quick look at OpenCL providers currently listed in virtual/opencl-2: 1. No 32-bit support: - dev-libs/intel-neo (Intel GPUs from Broadwell onwards) - upstream has confirmed NEO requires a 64-bit system and stated they have no plans to add 32-bit support; - dev-libs/rocm-opencl-runtime (AMD GPUs supported by the amdgpu driver) - ROC ebuilds support neither multilib nor native x86, no 32-bit binary packages produced by upstream; - dev-util/intel-ocl-sdk (Intel CPUs) - closed-source, and while there *are* 32-bit builds for Windows Intel only supports 64-bit Linux; 2. Partial 32-bit support: - x11-drivers/nvidia-drivers (Nvidia GPUs) - all versions currently available in the tree support amd64 multilib but only one of them (390.132-r1, which according to the Nvidia Web site only supports legacy GPUs) supports both KEYWORDS=x86 and USE=uvm. 3. Do support ABI_X86_32: - dev-libs/beignet (Intel Sandy Bridge, Ivy Bridge and Haswell GPUs) - last-rited due to having been effectively orphaned by upstream and lack of official support for LLVM versions newer than 7; - dev-libs/amdgpu-pro-opencl (AMD Polaris) - proprietary, hacky (it basically pulls OpenCL-related parts of the AMDGPU Pro stack in hope they will work with the open AMDGPU stack, which is not something AMD supports), no longer maintained in Gentoo; - media-libs/mesa[opencl] (old Radeon and Nvidia GPUs) - the only provider without a huge list of caveats, if you both have an old-enough GPU and do not mind only being able to use OpenCL 1.1. it actually seems to work fine. In other words, nearly every other provider either is or should be (ROCm) wrapped in the "abi_x86_64? ( ! abi_x86_32 ( ... ) )" guard. This makes virtual/opencl multilib support minimal at best and native-x86 support is even more limited. Do we even want to still bother? Especially the multilib bit, seeing as unless there is some super-special proprietary 32-bit OpenCL-aware software out there, OpenCL support in Wine seems to be the only thing that actually needs it - and I have my doubts regarding the usefulness of running OpenCL-aware Windows software under Linux. What do you think, guys? Moreover, assuming we do decide to make OpenCL support 64-bit only, what do you reckon should be done? Things I have thought of: 1. News item; 2. Mask USE=abi_x86_32 in virtual/opencl for all profiles and USE=opencl globally for x86 profiles; 3. At some point later, remove the x86 keyword from virtual/opencl. -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-go/ed25519
Most of upstream code has got merged into x-crypto (dev-go/go-crypto), and since go-1.13 subsequently into the Go standard library. Original code is no longer maintained and contains known bugs. Removal in 30 days. Bug #711520. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item: Removing ABI_X86_32 support from virtual/opencl
This will be shown as relevant to everyone who has installed virtual/opencl, i.e. also to people on amd64 who have NOT enabled abi_x86_32 for this package - but there is no way to filter news items by use flags, is there? Anyway, comments are welcome! * * * Title: Removing ABI_X86_32 support from virtual/opencl Author: Marek Szuba Posted: 2020-03-09 Revision: 2 News-Item-Format: 2.0 Display-If-Installed: virtual/opencl From April 2020 onwards virtual/opencl will no longer provide support for the 32-bit ABI on either multilib amd64 or native x86 systems. The reason for this is that most modern OpenCL providers currently available from Gentoo only support the 64-bit ABI anyway. Therefore, we intend to initially mask: - virtual/opencl in x86 profiles, - USE=abi_x86_32 for virtual/opencl in all profiles, and - USE=opencl in x86 profiles. and follow up with removal of multilib support and x86 keywords from virtual/opencl. Note that this change will only affect the virtual package, i.e. OpenCL providers which do support ABI_X86_32 will continue to advertise this capability. Users of such providers who wish to retain 32-bit OpenCL support are advised to add virtual/opencl to package.provided; see portage(5) for details. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: app-office/magicpoint, sys-apps/flashrom
On 2020-03-23 20:33, Jonas Stein wrote: > sys-apps/flashrom I'll take this one, I still use it from time to time. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
(with many thanks to everyone who mulled on this problem in #gentoo-dev yesterday, mattst88 in particular) So, yesterday's attempt to begin phasing support for 32-bit OpenCL out of Gentoo (which, to remind everyone who may not have followed the earlier discussion, would essentially acknowledge the status quo of most OpenCL providers only supporting native amd64 ABI) has failed miserably: the masking of abi_x86_32 in virtual/opencl on amd64 and of virtual/opencl as a whole on x86 resulted in breakages in the dependency graph. On the one hand, there are several packages keyworded x86 which unconditionally depend on virtual/opencl: - dev-libs/clhpp - dev-python/pyopencl - net-wireless/cpyrit-opencl - sci-libs/clblas - sci-libs/clblast This is the easier part of the problem - seeing as most OpenCL providers we now have in the tree (the exceptions being proprietary AMD and NVidia drivers for legacy GPUs) do not support x86 anyway, it should be safe to simply drop the keyword. On the other, there is the much hairier issue of multilib-capable packages: - dev-libs/cl - app-emulation/crossover-bin - app-emulation/wine-staging - app-emulation/wine-vanilla - app-text/tesseract - media-libs/opencv - media-libs/x264 - media-video/ffmpeg for which the consensus of yesterday's discussion seems to be that assuming the dropping of multilib or opencl support altogether is not an option, we would have to have separate src_configure (at the very least) stages for different ABIs. It seems therefore that the easiest way of phasing out 32-bit OpenCL would be for virtual/opencl to list a dummy provider that is both keyworded x86 and multilib-capable, and provides both header files and libraries reverse dependencies need to build successfully regardless of what OpenCL devices, if any, are actually available. Fortunately there already are packages in the tree which do just that - OpenCL ICD loaders, i.e. dev-libs/ocl-icd (has stable keywords for both amd64 and x86) and, since yesterday evening, dev-libs/opencl-icd-loader (the official Khronos Group ICD loader, the first tagged version of which got released in mid-March). Then, between mattst88 and myself we have come to the conclusion that it might in fact make sense to have virtual/opencl provide *only* an ICD loader and merely inform the users what hardware-specific runtimes are available. Advantages of this approach: - both ocl-icd and opencl-icd-loader are keyworded x86 (actually, I realised this morning that I have made a mistake with the latter because it is no longer up to developers to keyword things for x86 themselves - but I *have* tested this in a 32-bit chroot) and multilib-capable so they will keep the dependency tree consistent even if there are no actual OpenCL runtimes capable of supporting abi_x86_32; - intel-neo, rocm-opencl-runtime, amdgpu-pro-opencl and mesa[opencl] all actually *require* an IDC loader to work, intel-ocl-sdk (or at least version 4 of it) works fine through a loader, and given nvidia-drivers[uvm] ebuilds install an ICD file, I presume they are fine with the loader as well; - not having to switch between OpenCL runtimes would allow us to phase out eselect-opencl (similarly to how the introduction of an OpenGL loader has allowed us to get rid of eselect-opengl), or at the very least limit it to the management of OpenCL header files; - it would make it easier for users to enable out-of-tree runtimes, e.g. manually installed whole AMDGPU-Pro stack or Beignet from an overlay; - the current VIDEO_CARDS-based way of selecting runtimes is quite often misleading, namely: * intel-neo only supports Intel GPUs from Broadwell onwards rather than everything served by the i965 driver; * amdgpu-pro-opencl is not compatible Vega 10 and newer GPUs, and to make it worse it causes segfaults rather than simply ignore such GPUs; * nvidia-drivers[uvm] is actually several sets of drivers, with different versions appropriate for different GPUs; * mesa[opencl] only supports some (old) Nvidia GPUs; * intel-ocl-sdk does not support non-Intel amd64 CPUs. Having the options presented to users in human-readable fashion will IMHO work better. Therefore, mattst88 and I (or to clarify: the write-up is mine but Matt has contributed several important points to it) would like to propose the following steps to take: 1. Introduce a new version of virtual/opencl with RDEPEND consisting *only* of app-eselect/eselect-opencl and dev-libs/ocl-icd[khronos-headers], with the list of actual runtimes moved to a postinst message and expanded to explain what works where; 2. Have all ebuilds of OpenCL runtimes depend on virtual/opencl (replacing the dependency on dev-libs/ocl-icd wherever it is present) but do NOT call "eselect opencl" if they currently do; 3. Test if downstream applications are happy with the new unified OpenCL headers required by the Khronos Group ICD loader and if they are, add dev-libs/opencl-icd-loader to virtual/opencl as a
[gentoo-dev] [PATCH] virtual/opencl: new version
Instead of pulling in various OpenCL runtimes, only depend on
eselect-opencl and an OpenCL ICD loader (dev-libs/ocl-icd) in order
to provide hardware-independent header files and libraries for
OpenCL-aware software to build against. Actual runtimes are now simply
suggested to the user via a postinst message.
Signed-off-by: Marek Szuba
---
virtual/opencl/opencl-3.ebuild | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 virtual/opencl/opencl-3.ebuild
diff --git a/virtual/opencl/opencl-3.ebuild b/virtual/opencl/opencl-3.ebuild
new file mode 100644
index 000..9851d1ccbeb
--- /dev/null
+++ b/virtual/opencl/opencl-3.ebuild
@@ -0,0 +1,31 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=6
+
+inherit multilib-build
+
+DESCRIPTION="Virtual for OpenCL API"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+
+RDEPEND="app-eselect/eselect-opencl
+ dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]"
+
+pkg_postinst() {
+ elog
+ elog "In order to take advantage of OpenCL you will need a runtime for
your hardware."
+ elog "Currently included in Gentoo are:"
+ elog
+ elog "dev-libs/intel-neo - integrated Intel GPUs from Broadwell
onwards. Open. 64-bit only"
+ elog "dev-libs/rocm-opencl-runtime - AMD GPUs supported by the
amdgpu kernel driver. Mostly open [1]. 64-bit only"
+ elog "media-libs/mesa[opencl] - some older AMD GPUs; see [2]. Open.
32-bit support"
+ elog "dev-libs/amdgpu-pro-opencl - AMD Polaris GPUs. Proprietary,
provided as-is. 32-bit support"
+ elog "dev-util/intel-ocl-sdk - Intel CPUs. Proprietary. 64-bit only"
+ elog "x11-drivers/nvidia-drivers[uvm] - Nvidia GPUs; specific
package versions required for older ones [3]. Proprietary. 32-bit support"
+ elog
+ elog " [1] Proprietary library from dev-libs/hsa-ext-rocr required for
image support"
+ elog " [2] https://dri.freedesktop.org/wiki/GalliumCompute/";
+ elog " [3] https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/";
+ elog
+}
--
2.24.1
[gentoo-dev] [PATCH] Refactor virtual/opencl to provide the API, not an implementation
As proposed in my e-mail to the list from two days ago. Advantage: OpenCL-aware ebuilds will have something to compile and link against regardless of whether the runtime invoked by the ICD loader supports abi_x86_32 or not, or indeed even if there is no suitable runtime in the Gentoo tree.
Re: [gentoo-dev] [PATCH] virtual/opencl: new version
On 2020-04-05 06:44, Michał Górny wrote:
>> +EAPI=6
> Is there really a good reason to use an old EAPI here?
None other than me having assumed that there must have been an important
reason why such a simple ebuild had not been bumped to EAPI 7 yet. Will
change this in the next iteration.
>> +RDEPEND="app-eselect/eselect-opencl
>> +dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]"
>
> Wouldn't it make sense to remove the virtual and just have stuff depend
> on that instead?
It would if there only were only one ICD loader in the tree - but there
are two, this one and dev-libs/opencl-icd-loader. Overall it seems the
latter might be preferable in the long run (official Khronos Group
loader, much smaller output library, supports the new unified headers,
the last ocl-icd release came out in November 2017 and there has been
minimal repo activity since then) but with it having only been
officially released in mid-March and with me having only just added it
to Gentoo, I feel I'd rather test it for a while before listing it as an
alternative in the virtual.
Moreover, for the time being we still need eselect-opencl here even if
we are no longer to use to switch between implementations because
somewhat surprisingly (to me anyway), the package in questions installs
OpenCL header files too.
> This looks like README.gentoo material.
Will do.
--
MS
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
On 2020-04-02 15:31, Marek Szuba wrote: > 3. Test if downstream applications are happy with the new unified OpenCL > headers required by the Khronos Group ICD loader and if they are, add > dev-libs/opencl-icd-loader to virtual/opencl as an alternative to ocl-icd; Quick update on this: today I have attempted to rebuild and test various OpenCL-dependent packages using the unified headers and dev-libs/opencl-icd-loader. The good news is, they have all been perfectly happy with them. The bad news is, I actually had to manually symlink all contents /usr/lib/OpenCL/vendors/opencl-icd-loader/include/CL/ into /usr/include/CL/ for this to work because eselect-opencl contains a hard-coded list of expected vendor header files. In other words, it will be necessary to either teach eselect-opencl how to handle the unified headers or make it possible for it to let the contents of /usr/include/CL be. Personally I am leaning towards the latter - it doesn't even handle legacy headers that well (it installs several versions into /usr/lib/OpenCL/global but in the end offers no way of switching between them), and in any case even its description suggests its job is to switch between implementations rather than handle global headers. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
On 2020-04-06 06:27, Michał Górny wrote: > While at it, is there any chance to rewrite eselect-opencl so that it > stops writing into /usr and uses environment approach like eselect- > opengl does? I think I'd rather just nuke eselect-opencl altogether and force the use of an ICD loader for all implementations. Looks like it will be easier than Matt and I thought too, touch wood: - as previously mentioned, most of the runtimes currently in the tree actually REQUIRE using an ICD loader. Of the remaining two, I know for a fact at least the latest version of intel-ocl-sdk works fine via a loader so the only one that remains to be verified is x11-drivers/nvidia-drivers[uvm]; - likewise, I have confirmed that with the possible exception of x11-drivers/nvidia-drivers[uvm], none of the presently available runtimes install their own header files that would have to be symlinked into place by eselect-opencl. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2] Refactor virtual/opencl to provide the API, not an implementation
Changes since v1: * bump EAPI to 7 * use readme.gentoo for the postinst message * do not depend on app-eselect/eselect-opencl * make note in the comments about dev-libs/opencl-icd-loader to explain why we need a virtual in the first place
[gentoo-dev] [PATCH] virtual/opencl: new version
One, instead of pulling in various OpenCL runtimes, only depend on
an OpenCL ICD loader (dev-libs/ocl-icd, with dev-libs/opencl-icd-loader
to be added later) in order to provide hardware-independent header
files and libraries for OpenCL-aware software to build against.
Actual runtimes are now simply suggested to the user via a postinst
message / README.gentoo file.
Two, do not depend on eselect-opencl either - both ICD loaders pull in
their own OpenCL headers so there is no need to depend on the legacy
headers provided by this package, and for being able to switch to a
specific loader it is enough for loaders themselves to depend on this.
Signed-off-by: Marek Szuba
---
virtual/opencl/files/README.gentoo | 18 ++
virtual/opencl/opencl-3.ebuild | 25 +
2 files changed, 43 insertions(+)
create mode 100644 virtual/opencl/files/README.gentoo
create mode 100644 virtual/opencl/opencl-3.ebuild
diff --git a/virtual/opencl/files/README.gentoo
b/virtual/opencl/files/README.gentoo
new file mode 100644
index 000..aa2dc0ef519
--- /dev/null
+++ b/virtual/opencl/files/README.gentoo
@@ -0,0 +1,18 @@
+In order to take advantage of OpenCL you will need a runtime for your hardware.
+Currently included in Gentoo are:
+
+ * open:
+- dev-libs/intel-neo - integrated Intel GPUs from Broadwell onwards.
64-bit only;
+- dev-libs/rocm-opencl-runtime - AMD GPUs supported by the amdgpu kernel
driver.
+ Image support still requires a proprietary extension [1]. 64-bit only;
+- media-libs/mesa[opencl] - some older AMD GPUs; see [2]. 32-bit support;
+
+ * proprietary:
+- dev-libs/amdgpu-pro-opencl - AMD Polaris GPUs. 32-bit support;
+- dev-util/intel-ocl-sdk - Intel CPUs (*not* GPUs). 64-bit only;
+- x11-drivers/nvidia-drivers[uvm] - Nvidia GPUs; specific package versions
+ required for older devices [3]. 32-bit support.
+
+ [1] dev-libs/hsa-ext-rocr
+ [2] https://dri.freedesktop.org/wiki/GalliumCompute/
+ [3] https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/
diff --git a/virtual/opencl/opencl-3.ebuild b/virtual/opencl/opencl-3.ebuild
new file mode 100644
index 000..6268723a166
--- /dev/null
+++ b/virtual/opencl/opencl-3.ebuild
@@ -0,0 +1,25 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit multilib-build readme.gentoo-r1
+
+DESCRIPTION="Virtual for OpenCL API"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+
+# Will add dev-libs/opencl-icd-loader here as an alternative once all potential
+# file collisions with eselect-opencl have been resolved
+RDEPEND="dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]"
+
+# so that src_install() doesn't fail on missing directory
+S="${WORKDIR}"
+
+src_install() {
+ readme.gentoo_create_doc
+}
+
+pkg_postinst() {
+ readme.gentoo_print_elog
+}
--
2.24.1
[gentoo-dev] [PATCH] Migrate (non-Nvidia) OpenCL providers to virtual/opencl-3
Now that we have got two OpenCL ICD loaders in the tree, that starting with version 3, virtual/opencl will only pull an ICD loader rather than any specific implementation, and that we are in the process of following the footsteps of OpenGL in migrating away from using eselect to switch between OpenCL implementations in favour of always going through a loader, update implementations accordingly. Specifically: depend on >=virtual/opencl-3 rather than on any specific ICD loader, and make sure even implementations which previously ran standalone use one. Note that while the same should be done for x11-drivers/nvidia-drivers, all the ebuilds there are marked stable so they will have to be handled with more care. Maintainers whose sign-off is needed: candrews for ROCm, zerochaos for intel-ocl-sdk, the X11 project for Mesa.
