x11-plugins/purple-hangouts - Hangouts Plugin for libpurple Doesn't need much work, but I don't use it anymore.
Hello Michal, On Sun, Jan 03, 2021 at 09:47:31PM +0100, Michał Górny wrote: > Hello, > (...) > To switch before the aforementioned date, remove 'libressl' from your > USE flags and CURL_SSL targets. Afterwards, it is recommended to > prefetch all the necessary distfiles before proceeding with the system > upgrade, in case wget(1) becomes broken in the process: > > emerge --fetchonly dev-libs/openssl net-misc/wget > emerge --fetchonly --changed-use @world > > A --changed-use @world upgrade should automatically cause LibreSSL > to be replaced by OpenSSL, and all affected packages to be rebuilt: > > emerge --changed-use @world > Doesn't work for me. Emerge prints: ``` [blocks B ] dev-libs/openssl:0 ("dev-libs/openssl:0" is blocking dev-libs/libressl-3.3.1) Total: 37 packages (1 new, 36 reinstalls), Size of downloads: 0 KiB Conflict: 1 block (1 unsatisfied) (...) ``` I think you have to remove libressl first, like `emerge -C libressl`, then install openssl like `emerge -1 openssl`, then rebuild dependencies. As described here but in opposite way: https://wiki.gentoo.org/wiki/Project:LibreSSL
Hi, On 28/12/2020 11:56, Michał Górny wrote: > Hello, developers and Gentoo LibreSSL team. > > TL;DR: is there really a point in continuing the never-ending always- > regressing struggle towards supporting LibreSSL in Gentoo? > I don't agree. I have asked ~20 users who made any contributions (like bug reports or patches) recently, and almost all of them think that having a choice between OpenSSL and LibreSSL adds value to Gentoo. Some still trust LibreSSL more than OpenSSL because of its sins of the past. Although I can see that OpenSSL made a good progress in the latest several years. Anyway LibreSSL serves well to some number of users, and switching back to OpenSSL can be troublesome (think if you had dozens of servers running LibreSSL). LibreSSL support in Gentoo is not critical for me. But it doesn't take too much effort. I think the cost-benefit ratio is good enough for keeping it. Last but not least, the LibreSSL itself is well, alive and actively developed. People might want to use it. I see no good reasons not to support it, other than lack of time, will and effort. I really think that ability to choose (even between things that do not have great advantage over each other) - is a value in itself. > > The vast majority of software is not tested against LibreSSL. While > patches are usually trivial and we have people that submit them, > I find many of them short-sighted. Just look at . Sure, it fixes > the build today but it disabled the feature for all foreseeable future. > How likely is it that somebody will submit another patch reenabling it > with a future LibreSSL version? The likelihood is greater than zero: https://github.com/lighttpd/lighttpd1.4/commit/57f450f1992fc4e28cf85969eeebccb240df4303 https://github.com/gentoo-mirror/gentoo/commit/c7792db235647a6441b315528997b40ba2beeaaa https://github.com/Yubico/yubico-piv-tool/commit/3bcd36bbdbbdc86d06cc53df7e3b7c30d12cd33e etc... That was why I disagree. But I'll acquiesce in the decision to remove LibreSSL, because the number of developers that actually work on LibreSSL support is about 1.5. And unfortunately I don't have much time and effort for Gentoo currently, because of the main job and other life (I hope it will change soon though). I would be happier if some other developers were able and willing to participate actively in the LibreSSL project. But if not, not. Just make the transition as painless as possible.
Hi, I don't use dev-cpp/asio or any of its reverse dependencies any longer. CC to mysql-bugs, because sys-cluster/galera depends on dev-cpp/asio.
Upd. The port to Python 3 is not finished in the upstream. Particularly it is still using pygtk, it seems no work in porting to gtk+3 has been done yet. I don't think I'm going to do it. If anybody will, many people will be grateful. I personally suggest to look at net-wireless/iwd (it has its own client iwctl, no other network managers like connman are necessary). On 05/02/2020 16:16, Stefan Strogin wrote: > Hi, > > On 05/02/2020 09:11, Joonas Niilola wrote: >> >> # Stagnant upstream with latest release from 2016, python2-only, no >> maintainer >> # in Gentoo, no notable ebuild action in years, multiple bugs open. Blocks >> # pygtk removal. >> # Switch to alternatives such as, >> # net-misc/connman, net-misc/dhcpcd, net-misc/netifrc, >> net-misc/NetworkManager >> # and so on. Removal in ~90 days. # >> >> 90-day removal window due it possibly being used in low-maintenance servers. >> >> Updated openrc ebuilds to not suggest installing wicd anymore but >> connman instead, >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1a177f32dc3c792f5fc69f144b1728a705e1fba >> > > The upstream git is alive, it seems it is ported to Python 3, > but not released yet: https://git.launchpad.net/wicd/log/ > Its git version is uploaded to Debian experimental: > https://salsa.debian.org/debian/wicd/tree/python3 > https://packages.debian.org/experimental/wicd > > So I am going to test if wicd-gtk from git works without pygtk and, if it > does, > resurrect the ebuild. >
Hi, On 05/02/2020 09:11, Joonas Niilola wrote: > > # Stagnant upstream with latest release from 2016, python2-only, no > maintainer > # in Gentoo, no notable ebuild action in years, multiple bugs open. Blocks > # pygtk removal. > # Switch to alternatives such as, > # net-misc/connman, net-misc/dhcpcd, net-misc/netifrc, > net-misc/NetworkManager > # and so on. Removal in ~90 days. # > > 90-day removal window due it possibly being used in low-maintenance servers. > > Updated openrc ebuilds to not suggest installing wicd anymore but > connman instead, > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1a177f32dc3c792f5fc69f144b1728a705e1fba > The upstream git is alive, it seems it is ported to Python 3, but not released yet: https://git.launchpad.net/wicd/log/ Its git version is uploaded to Debian experimental: https://salsa.debian.org/debian/wicd/tree/python3 https://packages.debian.org/experimental/wicd So I am going to test if wicd-gtk from git works without pygtk and, if it does, resurrect the ebuild.
# Stefan Strogin (2019-08-29) # Obsolete. No reverse dependencies (games-rpg/eternal-lands no longer # depends on them). # Removal in 30 days. Bug #549890. games-rpg/eternal-lands-bloodsucker games-rpg/eternal-lands-data
# Stefan Strogin (21 May 2019) # Unmaintained. Last release in 2005. Does not build with # >=dev-libs/bglibs-2.04. Bug #686438. net-mail/qmail-qfilter -- Stefan