Re: [gentoo-dev] Last rites: app-misc/subsurface

2016-09-12 Thread Marek Szuba
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

[gentoo-dev] Last rites: app-misc/subsurface

2016-09-09 Thread Marek Szuba
# 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

Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS

2016-09-28 Thread Marek Szuba
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

[gentoo-dev] Re: Packages up for grabs

2017-03-27 Thread Marek Szuba
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

2017-04-19 Thread Marek Szuba
-- MS Title: app-backup/burp: default config file for bedup Author: Marek Szuba <mare...@gentoo.org> 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

Re: [gentoo-dev] News item: changed default bedup configuration file in >=app-backup/burp-2.0.0

2017-04-20 Thread Marek Szuba
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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-28 Thread Marek Szuba
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.

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

2017-08-16 Thread Marek Szuba
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

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

2017-08-16 Thread Marek Szuba
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

Re: [gentoo-dev] Re: taking a break from arches stabilization

2017-07-12 Thread Marek Szuba
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

Re: [gentoo-dev] Packages up for grabs

2017-04-27 Thread Marek Szuba
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] Last rites: net-misc/asterisk-g729, sci-libs/coinhsl, some games-*/* (BLAKE2B)

2018-05-21 Thread Marek Szuba
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

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

2018-10-10 Thread Marek Szuba
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] [PATCH] user.eclass: die if hard coded UID or GID is already in use

2019-05-29 Thread Marek Szuba
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

[gentoo-dev] [PATCH v2] profiles: add more language codes to desc/l10n.desc

2019-06-13 Thread Marek Szuba
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

Re: [gentoo-dev] [PATCH v2] profiles: add more language codes to desc/l10n.desc

2019-06-13 Thread Marek Szuba
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

[gentoo-dev] [PATCH] profiles: add more language codes to desc/l10n.desc

2019-06-12 Thread Marek Szuba
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

Re: [gentoo-dev] [PATCH] profiles: add more language codes to desc/l10n.desc

2019-06-12 Thread Marek Szuba
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

[gentoo-dev] [PATCH v3] profiles: add more language tags to desc/l10n.desc

2019-06-14 Thread Marek Szuba
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

[gentoo-dev] [PATCH 2/6] acct-group/rtkit: Add 'rtkit' group (GID 133)

2019-06-26 Thread Marek Szuba
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

[gentoo-dev] [PATCH 3/6] acct-group/syncthing: Add 'syncthing' group (GID 502)

2019-06-26 Thread Marek Szuba
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

[gentoo-dev] [PATCH 4/6] acct-user/burp: Add 'burp' user (UID 501)

2019-06-26 Thread Marek Szuba
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

[gentoo-dev] [PATCH 0/6] User/group assignment: burp, rtkit, syncthing

2019-06-26 Thread Marek Szuba
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

[gentoo-dev] [PATCH 1/6] acct-group/burp: Add 'burp' group (GID 501)

2019-06-26 Thread Marek Szuba
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

[gentoo-dev] [PATCH 6/6] acct-user/syncthing: Add 'syncthing' user (UID 502)

2019-06-26 Thread Marek Szuba
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

[gentoo-dev] [PATCH 5/6] acct-user/rtkit: Add 'rtkit' user (UID 133)

2019-06-26 Thread Marek Szuba
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

Re: [gentoo-dev] Re: Why aren't GSoC projects affecting ::gentoo discussed on regular mls?

2019-06-27 Thread Marek Szuba
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

[gentoo-dev] [PATCH 1/4] acct-group/stdiscosrv: Add 'stdiscosrv' group (GID 497)

2019-07-01 Thread Marek Szuba
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

[gentoo-dev] [PATCH 0/4] User/group assignment: stdiscosrv, strelaysrv

2019-07-01 Thread Marek Szuba
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

[gentoo-dev] [PATCH 4/4] acct-user/strelaysrv: Add 'strelaysrv' user (UID 496)

2019-07-01 Thread Marek Szuba
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

[gentoo-dev] [PATCH 3/4] acct-user/stdiscosrv: Add 'stdiscosrv' user (UID 497)

2019-07-01 Thread Marek Szuba
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

[gentoo-dev] [PATCH 2/4] acct-group/strelaysrv: Add 'strelaysrv' group (GID 496)

2019-07-01 Thread Marek Szuba
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

[gentoo-dev] News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0

2019-07-15 Thread Marek Szuba
-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

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-24 Thread Marek Szuba
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

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-25 Thread Marek Szuba
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

Re: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

2019-04-25 Thread Marek Szuba
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

Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Marek Szuba
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.

Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Marek Szuba
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

[gentoo-dev] [PATCH v2 0/6] User/group assignment: burp, rtkit, syncthing

2019-06-27 Thread Marek Szuba
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

[gentoo-dev] [PATCH 2/6] acct-group/rtkit: Add 'rtkit' group (GID 133)

2019-06-27 Thread Marek Szuba
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

[gentoo-dev] [PATCH 1/6] acct-group/burp: Add 'burp' group (GID 498)

2019-06-27 Thread Marek Szuba
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

[gentoo-dev] [PATCH 5/6] acct-user/rtkit: Add 'rtkit' user (UID 133)

2019-06-27 Thread Marek Szuba
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

[gentoo-dev] [PATCH 4/6] acct-user/burp: Add 'burp' user (UID 498)

2019-06-27 Thread Marek Szuba
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

[gentoo-dev] [PATCH 3/6] acct-group/syncthing: Add 'syncthing' group (GID 499)

2019-06-27 Thread Marek Szuba
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

[gentoo-dev] [PATCH 6/6] acct-user/syncthing: Add 'syncthing' user (UID 499)

2019-06-27 Thread Marek Szuba
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

[gentoo-dev] Re: News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0

2019-07-18 Thread Marek Szuba
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

[gentoo-dev] Package up for grabs: dev-libs/amdgpu-pro-opencl

2019-09-30 Thread Marek Szuba
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

[gentoo-dev] RFC: UID/GID assignment for net-analyzer/suricata

2019-12-06 Thread Marek Szuba
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

Re: [gentoo-dev] [PATCH 2/2] acct-user/suricata: new user for UID 477

2019-12-12 Thread Marek Szuba
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

[gentoo-dev] [PATCH 2/2] acct-user/suricata: new user for UID 477

2019-12-11 Thread Marek Szuba
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

[gentoo-dev] [PATCH 1/2] acct-group/suricata: new group for GID 477

2019-12-11 Thread Marek Szuba
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

[gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl

2019-12-16 Thread Marek Szuba
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

Re: [gentoo-dev] Change Bugzilla status to IN_PROGRESS when pull request is linked

2019-10-25 Thread Marek Szuba
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

Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl

2019-12-20 Thread Marek Szuba
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

[gentoo-dev] [PATCH 1/2] acct-group/xrootd: new group for GID 469

2019-12-20 Thread Marek Szuba
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

[gentoo-dev] [PATCH 2/2] acct-user/xrootd: new user for UID 469

2019-12-20 Thread Marek Szuba
man-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-u

[gentoo-dev] Last rites: dev-libs/beignet

2020-02-24 Thread Marek Szuba
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

[gentoo-dev] Last rites: dev-go/ed25519

2020-03-04 Thread Marek Szuba
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

2020-03-04 Thread Marek Szuba
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

[gentoo-dev] RFC: Removing ABI_X86_32 support from virtual/opencl

2020-02-28 Thread Marek Szuba
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

Re: [gentoo-dev] crypto@ packages up for grabs

2020-01-10 Thread Marek Szuba
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] [PATCH 2/3] media-libs/mesa: do not force use of specific ICD loader

2020-04-08 Thread Marek Szuba
Pending maintainer approval, and letting the stable ebuild be. Signed-off-by: Marek Szuba --- media-libs/mesa/mesa-20.0.4.ebuild | 2 +- media-libs/mesa/mesa-.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/media-libs/mesa/mesa-20.0.4.ebuild b/media-libs

[gentoo-dev] [PATCH] Migrate (non-Nvidia) OpenCL providers to virtual/opencl-3

2020-04-08 Thread Marek Szuba
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

[gentoo-dev] [PATCH 3/3] dev-util/intel-ocl-sdk: require an ICD loader instead of running standalone

2020-04-08 Thread Marek Szuba
At least version 4.4.0.117 works fine with a loader, and in any case using an OpenCL implementation which exclusively targets CPUs is of limited use. Pending maintainer approval, and letting the stable ebuild be. Signed-off-by: Marek Szuba --- dev-util/intel-ocl-sdk/intel-ocl-sdk-4.4.0.117-r1

[gentoo-dev] [PATCH 1/3] dev-libs/rocm-opencl-runtime: do not force use of specific ICD loader

2020-04-08 Thread Marek Szuba
Pending maintainer's approval. Signed-off-by: Marek Szuba --- dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild | 2 +- dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild | 2 +- dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild | 2 +- 3 files changed, 3

Re: [gentoo-dev] [PATCH 3/3] dev-util/intel-ocl-sdk: require an ICD loader instead of running standalone

2020-04-08 Thread Marek Szuba
On 2020-04-08 16:28, Marek Szuba wrote: > using an OpenCL implementation which exclusively targets CPUs is of > limited use. Clarification on the above: I meant using an implementation of this sort *in standalone mode* i.e. set as THE OpenCL implementation by eselect-opencl. It has never b

[gentoo-dev] OpenCL refactoring: status report, 2020-04-11

2020-04-11 Thread Marek Szuba
Dear everyone, I am happy to say that we are now almost ready for switching to eselect-opencl-free handling of OpenCL in Gentoo. Both ocl-icd and opencl-icd-loader have now got (masked) versions in the tree which install directly into /usr, the switching between the two works seamlessly, and I

[gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

2020-04-11 Thread Marek Szuba
Does this look okay to you, guys? The date is preliminary and dependent on how quickly we can get nvidia-drivers migrated to the new approach, hopefully we can get this to happen sooner. * * * Title: Manual steps required during upgrade to an eselect-free OpenCL set-up Author: Marek Szuba

[gentoo-dev] [PATCH] virtual/opencl: new version

2020-04-06 Thread Marek Szuba
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

[gentoo-dev] [PATCH v2] Refactor virtual/opencl to provide the API, not an implementation

2020-04-06 Thread Marek Szuba
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] meson.eclass: update the example to use modern helper functions

2020-04-13 Thread Marek Szuba
We have now got meson_use and meson_feature yet the example still used usex. Signed-off-by: Marek Szuba --- eclass/meson.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/meson.eclass b/eclass/meson.eclass index 0932a7ed427..2bd1dc01760 100644 --- a/eclass

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

2020-04-11 Thread Marek Szuba
On 2020-04-11 14:54, Brian Evans wrote: > I would mention that FEATURES='-collision-protect protect-owned' is > the default so most people won't have any action to take at all. I've been wondering what the default is these days. Good point, in fact I'll swap the case around so that the flow of

[gentoo-dev] News item v2: potential file collisions during OpenCL upgrade

2020-04-11 Thread Marek Szuba
that something's changing in how we handle OpenCL will IMHO not hurt even if they in the end do not have to change anything by hand. * * * Title: Potential file collisions during OpenCL upgrade Author: Marek Szuba Posted: 2020-05-01 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-eselect/eselect

Re: [gentoo-dev] Stabilizations and src_test

2020-04-12 Thread Marek Szuba
On 2020-04-12 09:43, Agostino Sarubbo wrote: > If you work on the stabilization workflow you may have noticed that: > > - There are people that rant if you don't run src_test against their packages; > - There are people that rant if you open a test failure bug against their > packages and you

[gentoo-dev] [PATCH] x11-drivers/nvidia-drivers: migrate to >=virtual-opencl-3

2020-04-19 Thread Marek Szuba
due to lack of IUSE=uvm [2] check for kernel_linux because virtual/opencl is not, and now likely never will be, keyworded for FreeBSD Closes: https://bugs.gentoo.org/717042 Signed-off-by: Marek Szuba --- .../nvidia-drivers-340.108-r1.ebuild | 497 +++ .../nvidia-drivers-390.132

[gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader

2020-04-19 Thread Marek Szuba
As previously mentioned, x11-drivers/nvidia-drivers is the last OpenCL runtime we have got in the tree to be migrated to the "must use an ICD loader" approach to virtual/opencl. Unfortunately I have so far failed to reach the maintainer of this package (jer) by either e-mail, Bugzilla, or IRC - so

Re: [gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader

2020-04-20 Thread Marek Szuba
On 2020-04-20 06:13, Joonas Niilola wrote: > He has been on devaway for a while. > > I would've much rather seen the differences between -r0 -r1 ebuilds to > focus on what is actually done there. Not that I have any say what will > be done in the end, but it's easier for the eyes... Indeed,

[gentoo-dev] [PATCH] Refactor virtual/opencl to provide the API, not an implementation

2020-04-04 Thread Marek Szuba
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.

[gentoo-dev] [PATCH] virtual/opencl: new version

2020-04-04 Thread Marek Szuba
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

Re: [gentoo-dev] [PATCH] virtual/opencl: new version

2020-04-05 Thread Marek Szuba
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. >>

Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl

2020-04-05 Thread Marek Szuba
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

Re: [gentoo-dev] Packages up for grabs: app-office/magicpoint, sys-apps/flashrom

2020-03-26 Thread Marek Szuba
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

2020-04-02 Thread Marek Szuba
(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

Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl

2020-04-06 Thread Marek Szuba
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

[gentoo-dev] [PATCH] lua.eclass: initial implementation

2020-09-03 Thread Marek Szuba
Ladies and gentlemen, Here is my first attempt on creating an eclass which would handle installation of Lua modules for multiple implementations. As some of you are aware of, the lack of such an eclass has been a major issue for our efforts on slotting dev-lang/lua. With many, many thanks to

[gentoo-dev] [PATCH 1/2] eclass: Add first version of lua.eclass

2020-09-03 Thread Marek Szuba
doesn't work yet: - support for dev-lang/luajit (not in the least because the versions currently in the tree share module directories with dev-lang/lua) - proper support for building against a single Lua target Signed-off-by: Marek Szuba --- eclass/lua.eclass | 710

[gentoo-dev] [PATCH 2/2] profiles/desc: describe LUA_TARGETS

2020-09-03 Thread Marek Szuba
Already includes lua-5.4. Signed-off-by: Marek Szuba --- profiles/desc/lua_targets.desc | 9 + 1 file changed, 9 insertions(+) create mode 100644 profiles/desc/lua_targets.desc diff --git a/profiles/desc/lua_targets.desc b/profiles/desc/lua_targets.desc new file mode 100644 index

Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation

2020-09-08 Thread Marek Szuba
Merged, thank you everyone who has weighed in with their comments both on IRC and here. -- MS signature.asc Description: OpenPGP digital signature

[gentoo-dev] Stabilisation of app-admin/ansible-2.10.0

2020-09-15 Thread Marek Szuba
Dear Matthew, I notice that you have recently stabilised app-admin/ansible-2.10.0 in Gentoo. Ansible upstream has introduced in that version major changes to their project structure [1] which given the current state of Ansible packaging in Gentoo can be considered severely breaking for our users.

Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-09-13 Thread Marek Szuba
On 2020-09-13 13:21, Andrew Savchenko wrote: > So it will be reasonable to add USE="systemd" to acct-* eclasses > to control the changes proposed above. Having thought about this some more, another benefit of this approach would be - unless I am wrong of course - that all currently installed

Re: [gentoo-dev] [PATCH 1/2] eclass: Add first version of lua.eclass

2020-09-04 Thread Marek Szuba
On 2020-09-03 15:37, Marek Szuba wrote: For the record, some mostly-cosmetic issues that have already been identified. Will include them in the next revision: > +if [[ ! ${_LUA_R0} ]]; then > + > +inherit multibuild toolchain-funcs > + > +BDEPEND="virtual/pkgconfig" T

[gentoo-dev] Last rites: dev-go/siphash

2020-09-01 Thread Marek Szuba
# Marek Szuba (2020-09-01) # Uses golang-* eclasses, only a library, all former reverse # dependencies have long since switched to vendoring. # Removal in 30 days. Bug #732130. dev-go/siphash -- Marecki signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-08-31 Thread Marek Szuba
On 2020-08-29 21:53, Michał Górny wrote: > + newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <( > + printf "u\t%q\t%q\t%q\t%q\t%q\n" \ > + "${ACCT_USER_NAME}" \ > + "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \ > +

Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation

2020-09-07 Thread Marek Szuba
On 2020-09-06 17:46, David Seifert wrote: > Unfortunately we won't get around a single-r1-style eclass too. What > about all those programs embedding a specific lua version as plugin > architecture? This is still very much on my to-do list, I simply figured it would make it easier for everyone

[gentoo-dev] dev-lua/luacrypto: last rites

2020-10-13 Thread Marek Szuba
# Marek Szuba (2020-10-13) # Not compatible with >=dev-libs/openssl-1.1.0, no maintainer in Gentoo, # no new commits to the upstream Git repository since September 2013. # No reverse dependencies. Removal in 30 days (Bug #736190). dev-lua/luacrypto --

Re: [gentoo-dev] [PATCH 0/3] lua-utils.eclass: expose header and library locations

2020-10-15 Thread Marek Szuba
On 2020-10-12 16:05, Marek Szuba wrote: Having had a gander at some of the revdeps of dev-lang/lua{,jit} currently present in the tree, it is fairly common to force the use of the right Lua version by pointing src_configure() to the right include directory and library files. Unfortunately doing

[gentoo-dev] [PATCH 2/3] profiles/embedded/make.defaults: add Lua-target variables to USE_EXPAND

2020-10-15 Thread Marek Szuba
Signed-off-by: Marek Szuba --- profiles/embedded/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/profiles/embedded/make.defaults b/profiles/embedded/make.defaults index 97be65cd4cb..d5337bc35a2 100644 --- a/profiles/embedded/make.defaults +++ b/profiles/embedded

[gentoo-dev] [PATCH 1/3] profiles/base/make.defaults: add Lua-target variables to USE_EXPAND

2020-10-15 Thread Marek Szuba
Signed-off-by: Marek Szuba --- profiles/base/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults index f2b15dd9a7e..f0432935720 100644 --- a/profiles/base/make.defaults +++ b/profiles/base/make.defaults

[gentoo-dev] [PATCH 3/3] profiles/base/make.defaults: set default Lua targets

2020-10-15 Thread Marek Szuba
These are currently both set to lua5-1 only because that is the version we have got in slot 0 of dev-lang/lua. Signed-off-by: Marek Szuba --- profiles/base/make.defaults | 5 + 1 file changed, 5 insertions(+) diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults index

[gentoo-dev] [PATCH 0/3] Set default LUA_TARGETS and LUA_SINGLE_TARGET

2020-10-15 Thread Marek Szuba
Should be harmless to do this already, these flags have only got an effect on ebuilds inheriting lua{,-single}.eclass i.e. will not do anything to legacy ones.

  1   2   >