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
--
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
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 '.
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
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 p
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.
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 wi
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
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 tu
# 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 (upstrea
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
>
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
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
publicati
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
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
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
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
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
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 s
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
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
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 th
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-ti
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 leas
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 cle
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 configu
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
No releases since 2003 (!), upstream effectively dead, no Unicode
support, EAPI 6. Removal in 30 days (#884429)
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
# 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 detec
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:
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
Descriptio
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
g
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 versi
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
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
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 an
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
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 upstrea
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, documentati
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
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 in
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
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 e
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 tha
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 acco
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
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
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
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
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 enoug
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
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 hav
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
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
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
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
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
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
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 pack
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
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
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
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
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
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
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 suppo
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/GI
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
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
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
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
-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
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'
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.
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
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
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 a
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/
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
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
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 mean
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
corresponden
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
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
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/a
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
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
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
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
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
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
(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
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
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.
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.
>> +RDE
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
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 i
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
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
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 Open
1 - 100 of 287 matches
Mail list logo
