[gentoo-dev] Package up for grabs: x11-plugins/purple-hangouts

2021-06-26 Thread Stefan Strogin
x11-plugins/purple-hangouts - Hangouts Plugin for libpurple
Doesn't need much work, but I don't use it anymore.



Re: [gentoo-dev] [News review] LibreSSL support discontinued

2021-01-04 Thread Stefan Strogin
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



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Stefan Strogin
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 [1].  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.



[gentoo-dev] Package up for grabs: dev-cpp/asio

2020-06-01 Thread Stefan Strogin
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.



Re: [gentoo-dev] Last-rites: net-misc/wicd

2020-02-09 Thread Stefan Strogin
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.
> 




Re: [gentoo-dev] Last-rites: net-misc/wicd

2020-02-05 Thread Stefan Strogin
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.



[gentoo-dev] Last rites: games-rpg/eternal-lands-{bloodsucker,data}

2019-08-28 Thread Stefan Strogin
# 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



[gentoo-dev] Last rites: net-mail/qmail-qfilter

2019-05-20 Thread Stefan Strogin
# 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