| View previous topic :: View next topic |
| Author |
Message |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1541
Location: South America
|
 Posted: Tue Sep 19, 2023 1:42 pm Post subject: |
 |
|
| stefan11111 wrote: | | See what happened with libressl and the amount of duplicate work needed to support it. |
I've read Orbeas' e-mails in the "hellthread", and still fail to see what the "duplicate work" consists of.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
 |
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Tue Sep 19, 2023 2:01 pm Post subject: |
|
|
| GDH-gentoo wrote: | | stefan11111 wrote: | | See what happened with libressl and the amount of duplicate work needed to support it. |
I've read Orbeas' e-mails in the "hellthread", and still fail to see what the "duplicate work" consists of. |
The latest one in libressl is the nvidia drivers.
Right now, nvidia-drivers depends on openssl:0/3, but the libressl provides a fake openssl:0/54 package to satisfy dependencies and cause rebuilds when needed.
To fix this, we either have to hope that the openssl:0/3 dependency will be relaxed after openssl 1.1 is gone, or there will have to be another ebuild added to the overlay, with the only change being the relaxed dependency.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1541
Location: South America
|
| Posted: Tue Sep 19, 2023 2:30 pm Post subject: |
|
|
| stefan11111 wrote: | | Right now, nvidia-drivers depends on openssl:0/3, but the libressl provides a fake openssl:0/54 package to satisfy dependencies and cause rebuilds when needed. |
And this fake openssl couldn't follow the same slot and subslot convention of Gentoo's repository because...?
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Tue Sep 19, 2023 2:48 pm Post subject: |
|
|
| GDH-gentoo wrote: | | stefan11111 wrote: | | Right now, nvidia-drivers depends on openssl:0/3, but the libressl provides a fake openssl:0/54 package to satisfy dependencies and cause rebuilds when needed. |
And this fake openssl couldn't follow the same slot and subslot convention of Gentoo's repository because...? |
Did you read the issue I linked?
| Orbea wrote: | | Actually now that I slept on it my idea is flawed, we will need to change the slot on the fake openssl package everytime the libressl API changes requiring other packages to be rebuilt which makes it impossible to match the package in ::gentoo... |
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1541
Location: South America
|
| Posted: Tue Sep 19, 2023 3:46 pm Post subject: |
|
|
| Orbea wrote: | | [...] which makes it impossible to match the package in ::gentoo... |
And whose fault is that? I suppose that you know what dev-libs/openssl's subslot is for.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 437
|
| Posted: Wed Sep 20, 2023 4:44 pm Post subject: |
|
|
| NeddySeagoon wrote: | The Gentoo is about choice mantra has never been true. Gentoo is about what the contributors are interested in. It really is that simple.
There are no conspiracies - Gentoo does not even have the organisation for that. |
Respectfully Neddy, those two are not exclusive.
Gentoo for me has always been about it's ability to allow me to build a system as close to what I want as possible, hence, my choice. I have never been confused about an open source project being about someone else doing uncompensated work for my edification.
When others are doing the hard work of creating what I would like to use, I gratefully benefit from their contributions.
I also think the current implementation of overlays looks far better than it was, say 10 years ago. I used to keep a mythtv backend and several frontends running at the house. There were periods when people contributed ebuilds for most of the components, and others when you had to roll your own and use overlays. It is easier to build what I want now than before. My choice has become even more empowered.
Anyhow, thanks to those that spend their time contributing. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54266
Location: 56N 3W
|
| Posted: Wed Sep 20, 2023 4:55 pm Post subject: |
|
|
flysideways,
I agree totally. The 'choice' aspect of Gentoo comes about by accident. Its not intentional.
Gentoo makes it easy to have competing projects doing the same thing in the ::gentoo repo.
It happens because devs are interested that the competing projects, not because Gentoo is about choice.
Thus we have OpenRC and systemd (and other) init systems in ::gentoo.
Anything that suffered bitrot and was unmaintained will be tree cleaned, even systemd. There are no sacred cows.
My point is that choice is accidental.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Wed Sep 20, 2023 7:29 pm Post subject: |
|
|
| NeddySeagoon wrote: |
Anything that suffered bitrot and was unmaintained will be tree cleaned, even systemd. There are no sacred cows.
|
What is something like if(!strcmp(os, "gentoo"){ panic(); } gets sprinkled throughout the systemd codebase?
Would gentoo not carry a huge patchset to be able to keep using systemd?
I didn't expect this one though. But I have a hard time believing gnome will ever go away from gentoo:
| Code: | [gentoo-dev] GNOME needs a new maintainer in Gentoo Inbox
Add star Matt Turner<mattst88@gentoo.org> Wed, Sep 20, 2023 at 5:31 PM
Reply-To: gentoo-dev@lists.gentoo.org
To: gentoo development <gentoo-dev@lists.gentoo.org>
Cc: gnome@gnome.org, Guillermo Joandet <gjoandet@gmail.com>
Reply | Reply to all | Forward | Print | Delete | Show original
Hello,
Happy GNOME 45.0 release day!
I've been maintaining the GNOME packages in Gentoo, essentially alone,
since GNOME 3.38 (Sept 2020).
After adding seven major versions of GNOME to Gentoo, I've decided to
stop. So, the GNOME project needs a new maintainer. Preferably
multiple.
A quick accounting shows that I've done 1350 bumps of GNOME packages
in the last 3 years (and reviewed and merged another 530 from
Guillermo who has been contributing for only 1 year now). In upstream
GNOME projects I've landed about 100 merge requests.
IMO, the state of the project is really good. We've been adding
alpha/beta/rc versions in order to catch and report problems to
upstream and to give us time to sort out important issues beforehand.
Most of GNOME 45 is already in ::gentoo under package.mask.
When I forced myself into the GNOME team, there were a lot of bits of
knowledge that were only accessible by being yelled at by the lead.
I've tried to remedy that and to document important things to know. To
that end, I've maintained a few pages on the Wiki:
Somewhat of a guide for bumping GNOME packages:
https://wiki.gentoo.org/wiki/Project:GNOME/GNOME_Bumping_Guide
Notes about why packages listed on packages.gentoo.org's Outdated page
haven't been handled:
https://wiki.gentoo.org/wiki/Project:GNOME/GNOME_bumping_notes
A table of unit testing results (from src_test) for GNOME packages:
https://wiki.gentoo.org/wiki/Project:GNOME/GNOME_Unit_Test_Status
libsoup:3.0 transition status (mostly behiind us at this point)
https://wiki.gentoo.org/wiki/Project:GNOME/libsoup:3_transition
I'll still be around, and I'm happy to help ramp up a developer that
wants to take over. Guillermo has been doing great and has been an
incredible help. I hope he'll become a Gentoo developer, but the
project really needs more than a single person maintaining things.
Matt |
This brings me to the question. Is temporarily restricting choice enough is some cases?
Would history be the same if gnome worked without systemd when debian became a systemd distro?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54266
Location: 56N 3W
|
| Posted: Wed Sep 20, 2023 7:36 pm Post subject: |
|
|
stefan11111,
Lets stick to a fact based technical discussion.
Speculation like this is not useful.
KDE was without gentoo maintainers an one time. I'll leave it for you to research the mailing list.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21642
|
| Posted: Wed Sep 20, 2023 9:34 pm Post subject: |
|
|
| stefan11111 wrote: | | NeddySeagoon wrote: |
Anything that suffered bitrot and was unmaintained will be tree cleaned, even systemd. There are no sacred cows.
|
What is something like if(!strcmp(os, "gentoo"){ panic(); } gets sprinkled throughout the systemd codebase? |
The Gentoo maintainer(s) for systemd would either patch it out, or decide they had better things to do with their time than fight systemd upstream, and then quit maintaining systemd in Gentoo. At that point, Neddy's point comes into play: if systemd is not being maintained in Gentoo, it is eligible to be tree cleaned. In the case of systemd, it's critical to enough people that someone would probably step up to keep it working, for their own sake, and hopefully would share their work so that other less technical users who had systemd-based systems and wanted not to change could benefit. It all depends on exactly how obnoxious upstream gets. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Wed Sep 20, 2023 9:57 pm Post subject: |
|
|
| stefan11111 wrote: | | See what happened with libressl and the amount of duplicate work needed to support it. |
It isn't at all clear to me what you mean by "duplicate work" In the case of libressl, it isn't supported by Gentoo, so any duplicate work appears to be the fault of those performing unnecessary work, whatever that may be.
| stefan11111 wrote: | | I get that gentoo is run by volunteers, but this model doesn't work for all packages. |
The volunteer model doesn't work? Or that the Gentoo developers get to choose what they want to work on? Or something else?
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Wed Sep 20, 2023 10:29 pm Post subject: |
|
|
| pjp wrote: | | stefan11111 wrote: | | See what happened with libressl and the amount of duplicate work needed to support it. |
It isn't at all clear to me what you mean by "duplicate work" In the case of libressl, it isn't supported by Gentoo, so any duplicate work appears to be the fault of those performing unnecessary work, whatever that may be.
|
I gave nvidia-drivers as an example.
The ebuild already exists and is maintained.
All that is needed to make it work with libressl is to relax the openssl dependency.
The duplicate work is the entire ebuild, except that one line with the openssl dependency.
This happens because there is no way to patch ebuilds like we have for packages.
| pjp wrote: |
| stefan11111 wrote: | | I get that gentoo is run by volunteers, but this model doesn't work for all packages. |
The volunteer model doesn't work? Or that the Gentoo developers get to choose what they want to work on? Or something else? |
The volunteer model fails for large packages that have a high maintenance burden, few maintainers, and a lot of users unlikely to contribute in any way.
See packages like chromium and gnome.
I wouldn't mind not having these packages, but i think others would.
This is not the case with eudev and opentmpfiles.
Eudev does not have much of a maintenance burden and it's got 2 volunteers.
Opentmpfiles can live without a maintainer and a few commits once in a while.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21642
|
| Posted: Wed Sep 20, 2023 11:12 pm Post subject: |
|
|
Given your general attitude about bloat, I find it odd you want to run the proprietary nVidia drivers. 
As I understand that case, the dependency is correct as-is, and reflects what nVidia actually requires when using real OpenSSL. If an out-of-tree project chooses to ship a fake openssl ebuild that nvidia-drivers does not accept due to slot constraints, that is not the fault of nvidia-drivers. Gentoo has generally taken the position that ebuilds in ::gentoo are not obligated to carry special logic to accommodate ebuilds that are not in ::gentoo.
We have explained repeatedly that the only way Gentoo could consider carrying opentmpfiles is if someone steps up to patch it to resolve the published CVE for it. Yes, we are well aware you are not concerned about that CVE for your system. The Gentoo project is concerned about shipping a package with a known CVE and no expectation that it will be fixed in the immediate future. We have also gone over that the people who have examined this have decided that fixing the CVE is a huge amount of work, such that using systemd-tmpfiles, even if some compatibility patches are required on it, is less effort.
As regards eudev, it could be carried, but unless its volunteers get it to be ABI-compatible with the latest systemd-udevd, its utility will be limited and may decline as more projects choose to add a hard dependency on systemd-udevd features that eudev has not backported. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Wed Sep 20, 2023 11:24 pm Post subject: |
|
|
| stefan11111 wrote: | I gave nvidia-drivers as an example.
The ebuild already exists and is maintained.
All that is needed to make it work with libressl is to relax the openssl dependency.
The duplicate work is the entire ebuild, except that one line with the openssl dependency.
This happens because there is no way to patch ebuilds like we have for packages. |
Thank you! Now I understand. I think that also clarifies an earlier comment: | stefan11111 wrote: | | Does the tool serve the user when it forces you to track and needlessly duplicate work done by gentoo devs? |
That the tool allows you to make changes to what Gentoo provides by default seems very much to "serve the user." Could they be improved? Sure. Does anything exist that cannot be improved?
I would expect Gentoo developers to modify ebuilds, not patch them. That might be one reason why that capability doesn't exist, and also why there isn't a lot of incentive for them to create it.
| stefan11111 wrote: | The volunteer model fails for large packages that have a high maintenance burden, few maintainers, and a lot of users unlikely to contribute in any way.
See packages like chromium and gnome. |
I don't use either, so I'm not familiar with any issues they have. Gnome does seem to be lagging behind by a few years. I'm not sure how that differs from versions before 40. Chromium only appears to be one major release behind.
I'm only guessing, but I wonder if that has been some of the motivation to support some of the -bin versions of packages.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Thu Sep 21, 2023 4:14 am Post subject: |
|
|
| Hu wrote: | Given your general attitude about bloat, I find it odd you want to run the proprietary nVidia drivers.
|
It's either that on no hw accel.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21642
|
| Posted: Thu Sep 21, 2023 3:12 pm Post subject: |
|
|
| I seem to get adequate hardware acceleration using amdgpu and an AMD-based graphics card. This has the additional benefit of being full FOSS, a stated goal in the linked thread. |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 437
|
| Posted: Thu Sep 21, 2023 4:31 pm Post subject: |
|
|
| Hu wrote: | | I seem to get adequate hardware acceleration using amdgpu and an AMD-based graphics card. This has the additional benefit of being full FOSS, a stated goal in the linked thread. |
But, that's a hardware choice. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1541
Location: South America
|
| Posted: Thu Sep 21, 2023 6:07 pm Post subject: |
|
|
| flysideways wrote: | | But, that's a hardware choice. |
That affects the software choices you have for running on that hardware. Just like software packages' upstream (in)actions, you see
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
| Posted: Sat Sep 23, 2023 7:50 pm Post subject: |
|
|
| pietinger wrote: | | I do not understand this thread. |
...
It is a miss understood about perspectives. We on Gentoo, have a multi Setting configuration of turing machines. And it will be fine til some single package your are using for on of your systems will be deprecated. That's why most of us are in the Software-Hell, really. And you have to support that small peace of software in that one Version 10 years before for that one Computer in a secure manner and its hard... like if its left Openssl lower than 3.0. But you have to maintain.
And then you will update some needed software packages to that one ebuild and it will need more and more dependencies to be hold. On some Day it will be less work to just code that Software to rust as to code/update old code to today security issues. Or to just fit your Gentoo installation to that Package.
We will all meed this situation in our lives in the near or far future... i think. |
|
| Back to top |
|
|
De-Javu
n00b
Joined: 30 Mar 2009
Posts: 24
Location: USA
|
| Posted: Sat Sep 23, 2023 10:06 pm Post subject: |
|
|
| ChrisJumper wrote: | | pietinger wrote: | | I do not understand this thread. |
...
It is a miss understood about perspectives. We on Gentoo, have a multi Setting configuration of turing machines. And it will be fine til some single package your are using for on of your systems will be deprecated. That's why most of us are in the Software-Hell, really. And you have to support that small peace of software in that one Version 10 years before for that one Computer in a secure manner and its hard... like if its left Openssl lower than 3.0. But you have to maintain.
And then you will update some needed software packages to that one ebuild and it will need more and more dependencies to be hold. On some Day it will be less work to just code that Software to rust as to code/update old code to today security issues. Or to just fit your Gentoo installation to that Package.
We will all meed this situation in our lives in the near or far future... i think. |
pietinger,
Me neither - but also I did not read much of it. I believe it is a silly question for a distro which goes to such great lengths to accommodate your choice of OpenRC/systemd and compiler.
---
pietinger and ChrisJumper,
It's my personal opinion that this was a major point of stress and worry before the days when containers such as Docker existed. Now, you have the choice: to restrict such a problematic, vintage & unmaintained package to live within a container; or to maintain the package to fit your system. Sometimes, some ancient package which isn't updated in ages "just works", so it doesn't receive attention until it breaks, and maybe then the original developers are no longer around or interested, but it's not worth the effort to re-write code simply to compile with newer libraries.....
This kind of situation is MUCH easier to deal with, if you are willing to use a container system. I can think of several times in the old days where I really spent the time making my own patches so a package would install, where a container would have been much easier.
If a user does not want to use a containerization method on their Gentoo system, that is their choice Personally, I will prefer to put my most headache-inducing packages which require strange specific dependencies within a container. Anyway, I know that is only describing one side of the issue. I don't find that any choices regarding the direction the Gentoo team has brought the project has made my life worse as time goes on. On the contrary, things are only better in Gentoo as it has matured. I have been using Gentoo since 2009 and I think it is better than it ever was. 
For the record, I absolutely don't use flatpak or snap on my Gentoo systems, but I also don't judge anyone who does.
---
Hu, flysideways, and GDH-gentoo,
I chose an AMD GPU for my system because it is easier to use in a FOSS context than nVidia. Theoretically speaking, the user is free to change their hardware if they don't like the software choices available as a result of using it. However, I do respect that there are situations where maybe one can't change their hardware, for example if one's hardware is laptop or proprietary non-customizable hardware. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Sun Sep 24, 2023 6:34 pm Post subject: |
|
|
| ChrisJumper wrote: | | pietinger wrote: | | I do not understand this thread. |
...
It is a miss understood about perspectives. We on Gentoo, have a multi Setting configuration of turing machines. And it will be fine til some single package your are using for on of your systems will be deprecated. That's why most of us are in the Software-Hell, really. And you have to support that small peace of software in that one Version 10 years before for that one Computer in a secure manner and its hard... like if its left Openssl lower than 3.0. But you have to maintain.
And then you will update some needed software packages to that one ebuild and it will need more and more dependencies to be hold. On some Day it will be less work to just code that Software to rust as to code/update old code to today security issues. Or to just fit your Gentoo installation to that Package.
We will all meed this situation in our lives in the near or far future... i think. |
That side of things isn't really new. Both in terms of deprecations (new compilers, incompatible library changes, ...) but also in that we've always removed things that have problems, see e.g. the XMMS removal many years ago which caused a lot of upset. It's just distro life. |
|
| Back to top |
|
|
mrbassie
l33t
Joined: 31 May 2013
Posts: 773
Location: over here
|
| Posted: Thu Sep 28, 2023 7:45 pm Post subject: |
|
|
| sMueggli wrote: | | Thankfully the developers base their choice on technical facts and not on ideological propaganda. |
I don't follow, could you explain the propagana thing?
_________________
Bus conductors learned to code. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3347
Location: Rasi, Finland
|
| Posted: Thu Sep 28, 2023 8:19 pm Post subject: |
|
|
A preemptive comment:
No no no. Let's not derail into the "systemd and RH is taking over" yet again. Thank you.
EDIT: Letter swap to fix typo.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
Last edited by Zucca on Fri Sep 29, 2023 4:31 am; edited 1 time in total |
|
| Back to top |
|
|
mrbassie
l33t
Joined: 31 May 2013
Posts: 773
Location: over here
|
| Posted: Thu Sep 28, 2023 9:03 pm Post subject: |
|
|
The queen?
_________________
Bus conductors learned to code. |
|
| Back to top |
|
|
ultronix
n00b
Joined: 20 Dec 2023
Posts: 1
|
| Posted: Wed Dec 20, 2023 12:07 pm Post subject: |
|
|
| stefan11111 wrote: | | GDH-gentoo wrote: | | stefan11111 wrote: | | See what happened with libressl and the amount of duplicate work needed to support it. |
I've read Orbeas' e-mails in the "hellthread", and still fail to see what the "duplicate work" consists of. |
The latest one in libressl is the nvidia drivers.
Right now, nvidia-drivers depends on openssl:0/3, but the libressl provides a fake openssl:0/54 package to satisfy dependencies and cause rebuilds when needed.
To fix this, we either have to hope that the openssl:0/3 dependency will be relaxed after openssl 1.1 is gone, or there will have to be another ebuild added to the overlay, with the only change being the relaxed dependency. |
I use libressl system-wide, local nvidia-drivers ebuild repo with fixed dependency line dev-libs/openssl:0/3 to dev-libs/openssl, it build normally with faked openssl package from libressl overlay. |
|
| Back to top |
|
|
|
Gentoo Chat
