Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
Hi, > Compare with the shitstorm at: > https://github.com/pkgxdev/pantry/issues/5358 Thank you for this, it made my day. Though I'm just a proxy maintainer for now, I also support this initiative, there should be some guard rails set up around LLM usage. > 1. Copyright concerns. At this point, the copyright situation around > generated content is still unclear. What's pretty clear is that pretty > much all LLMs are trained on huge corpora of copyrighted material, and > all fancy "AI" companies don't give shit about copyright violations. > In particular, there's a good risk that these tools would yield stuff we > can't legally use. IANAL, but IMHO if we stop respecting copyright law, even if indirectly via LLMs, why should we expect others to respect our licenses? It could be prudent to wait and see where will this land. > 2. Quality concerns. LLMs are really great at generating plausibly > looking bullshit. I suppose they can provide good assistance if you are > careful enough, but we can't really rely on all our contributors being > aware of the risks. From my personal experience of using Github Copilot fine tuned on a large private code base, it functions mostly okay as a more smart auto complete on a single line of code, but when it comes to multiple lines of code, even when it comes to filling out boiler plate code, it's at best a 'meh'. The problem is that while the output looks okay-ish, often it will have subtle mistakes or will hallucinate some random additional stuff not relevant to the source file in question, so one ends up having to read and analyze the entire output of the LLM to fix problems with the code. I found that the mental and time overhead rarely makes it worth it, especially when a template can do a better job (e.g. this would be the case for ebuilds). Since during reviews we are supposed to be reading the entire contribution, not sure how much difference this makes, but I can see a developer trusting LLM too much might end up outsourcing the checking of the code to the reviewers, which means we need to be extra vigilant and could lead to reduced trust of contributions. > 3. Ethical concerns. As pointed out above, the "AI" corporations don't > give shit about copyright, and don't give shit about people. The AI > bubble is causing huge energy waste. It is giving a great excuse for > layoffs and increasing exploitation of IT workers. It is driving > enshittification of the Internet, it is empowering all kinds of spam > and scam. I agree. I'm already tired of AI generated blog spam and so forth, such a waste of time and quite annoying. I'd rather not have that on our wiki pages too. The purpose of documenting things is to explain an area to someone new to it or writing down unique quirks of a setup or a system. Since LLMs cannot write new original things, just rehash information it has seen I'm not sure how could it be helpful for this at all to be honest. Overall my time is too valuable to shift through AI generated BS when I'm trying to solve a problem, I'd prefer we keep a well curated high quality documentation where possible. Zoltan signature.asc Description: PGP signature
Re: [gentoo-dev] More packages up for grabs due to developer inactivity
Hi, > sys-apps/ripgrep I'll take this as I use the program regularly anyway. Zoltan signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
On Fri, Oct 27, 2023 at 12:24:32PM +0100, Marek Szuba wrote: > 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 upstream still > used CMake! Telling the truth I wasn't exactly interested either, it's just > that it happened to be an optional dependency of media-gfx/darktable. > > > Thank you for maintaining it till now. > > You're very welcome! > > > Could you address the exact problems to upstream, so they are aware and > > can improve it? > > I think not only Gentoo, but also other distributions suffer if it does > > not build smooth. > > I used to do that. It seemed to have little to no effect so in the end I > just gave up. > > > Looks to me as if the package is not broken now, but there is a lack of > > manpower to update it. 30 days is the minimum for a removal. > > There are two outstanding QA issues (ignored LDFLAGS and pre-stripped > binaries) in 3.3.1 pertaining to USE=gimp and USE=qt5. Prior to adding that > version I tried to leverage qmake-utils.eclass in the Qt parts of the > package, which hopefully would have got rid of these issues - but resulted > in a wall of actual errors. This has been the last straw as far as me > maintaining G'MIC is concerned. > > > I suggest to keep it for a few more months. > > Fine by me if someone actually maintains it. I've just dropped > media-gfx/gmic back to m-n to make it clear that I do not intend to block it > from being reactivated. > > -- > Marecki > This is quite a loss. Ever since the dropping the gimp-resynthesizer plugin (due to Python2 deprecation) gmic was the last package to provide "heal selection" functionality in GIMP. Losing gmic will put GIMP behind other image editing software by a significant margin. I'm wondering if we could collaborate with other distro developers on building and improving the state of this package. E.g. Debian seems to be packaging gmic by itself and also for gimp and krita. I wonder if it's possible to build the gimp plugin portion only and not deal with gmic QT frontend? Zoltan signature.asc Description: PGP signature
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
On Tue, Jul 04, 2023 at 01:13:30AM -0600, Tim Harder wrote: > On 2023-07-03 Mon 04:17, Florian Schmaus wrote: > >On 30/06/2023 13.33, Eray Aslan wrote: > >>On Fri, Jun 30, 2023 at 03:38:11AM -0600, Tim Harder wrote: > >>>Why do we have to keep exporting the related variables that generally > >>>cause these size issues to the environment? > >> > >>I really do not want to make a +1 response but this is an excellent > >>question that we need to answer before implementing EGO_SUM. > > > >Could you please discuss why you make the reintroduction of EGO_SUM > >dependent on this question? > > Just to be clear, I don't particularly care about EGO_SUM enough to gate > its reintroduction (and don't have any leverage to do so anyway). I'm > just tired of the circular discussions around env issues that all seem > to avoid actual fixes, catering instead to functionality used by a > vanishingly small subset of ebuilds in the main repo that compels a > certain design mostly due to how portage functioned before EAPI 0. > > Other than that, supporting EGO_SUM (or any other language ecosystem > trending towards distro-unfriendly releases) is fine as long as devs are > cognizant how the related global-scope eclass design affects everyone > running or working on the raw repo. I hope devs continue leveraging the > relatively recent benchmark tooling (and perhaps more future support) to > improve their work. Along those lines, it could be nice to see sample > benchmark data in commit messages for large, global-scope eclass work > just to reinforce that it was taken into account. > > Tim > I've been following the EGO_SUM thread for quite some time now. One other thing I did not see mentioned in favour of EGO_SUM so far: reproducibility. The problem with external tarballs is that they are gone once the ebuild is dropped from the tree. Should a user ever want to roll back to a previous version of an application, either by checking out on older version of the portage tree or copying said ebuild into their local overlay, they still cannot simply run an emerge on the it as they have to somehow recreate the tarball itself too. While upstream may not host everything forever, it's pretty much guaranteed to be available for much longer than Gentoo's custom tarball bundles of dependencies. Regarding space we are also likely making trade-off. By deprecating EGO_SUM we are saving space in the portage tree but in exchange inflating distfiles as it will start accumulating the same dependencies potentially multiple times since now the content is hidden in tarballs containing a combination of dependencies. This is essentially the source file version of "statically linking". Finally a personal opinion: I find dependency tarballs opaque. With EGO_SUM the ebuild defines all the upstream sources it needs to build the package as well as how to build it, but with the dependency tarball the sources are all hidden and makes verification all that much harder. Zoltan
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
Hi, I'll take the following as proxy-maintainer (for now): acct-user/at acct-group/at sys-process/at sys-fs/encfs Related PRs: https://github.com/gentoo/gentoo/pull/29325 https://github.com/gentoo/gentoo/pull/29326 Cheers, Zoltan
Re: [gentoo-dev] Last rites: multiple packages lacking Python 3.10 support
Hi, Interesting, how come dev-util/kdevelop-python does not support higher versions of Python? I'll take a look! Zoltan On Fri, Nov 18, 2022 at 08:36:21PM +0100, Michał Górny wrote: > # Michał Górny (2022-11-18) > # These packages still lack support for Python 3.10. In general, they > # did not see any activity recently and either have no maintainer > # or their respective maintainers did not reply to the bug. Many > # of them do not have tests enabled or have unresolved test failures. > # Removal on 2022-12-18. Tracker bug #823185. > app-admin/ansible-cmdb > app-arch/bloscpack > app-backup/borgweb > app-i18n/fcitx-sunpinyin > app-i18n/ibus-kkc > app-i18n/ibus-sunpinyin > app-i18n/libkkc > app-i18n/libkkc-data > app-i18n/sunpinyin > app-i18n/sunpinyin-data > app-i18n/xsunpinyin > app-portage/distpatch > app-text/q-text-as-data > app-vim/pydiction > app-vim/vimoutliner > dev-libs/aws-sdk-cpp > dev-python/Rx > dev-python/bert > dev-python/flask-assets > dev-python/libpy_simdjson > dev-python/parallax > dev-python/pytest-salt > dev-python/requests_pkcs12 > dev-python/slackclient > dev-python/tvdb_api > dev-python/webassets > dev-python/ws4py > dev-util/comparator > dev-util/kdevelop-python > dev-util/rosinstall_generator > games-util/pyfa > mate-extra/caja-hide > media-gfx/netpaint > media-plugins/mythplugins > media-sound/marrie > media-tv/tvnamer > net-analyzer/carl > net-im/skype-dbus-mock > sci-libs/bmrblib > sci-mathematics/relational > sys-cluster/crmsh > > -- > Best regards, > Michał Górny > >
Re: [gentoo-dev] Last rites: multiple maintainer-needed packages
Hi, As per Intel's site sys-apps/intel-performance-counter-monitor has been forked by them and now runs under https://github.com/intel/pcm. I'll take a stab at updating the ebuild to this new version as it seems to be an interesting tool. I'm also willing to maintain it going forward. Zoltan > # Michał Górny (2022-11-19) > # Packages with no maintainer and major bugs reported. They are either > # inactive upstream, or have not been bumped for a long time. > # > # app-emulation/aqemu: bug #806421, last bumped in 2016 > # app-forensics/ovaldi: revdep of dev-libs/xalan-c, last bumped in 2017 > # app-misc/glimpse: bug #684096, last bumped in 2013 > # dev-db/cpp-driver: bug #685936, last bumped in 2019 > # dev-erlang/riakc: bug #722688, last bumped in 2016 > # dev-libs/xalan-c: bug #734190, last bumped in 2011 > # dev-util/stubgen: bug #839927, last bumped in 2011 > # media-gfx/xzgv: bug #831252, last bumped in 2009 > # net-dns/dnssec-check: bug #571350, last bumped in 2016 > # net-mail/cmd5checkpw: bug #833292, last bumped in 2005 > # net-ftp/gproftpd: bug #550524, last bumped in 2007 > # sys-apps/intel-performance-counter-monitor: bug #728564, > # last bumped in 2016 > # > # Removal on 2022-12-19. > acct-group/cmd5checkpw > acct-user/cmd5checkpw > app-emulation/aqemu > app-forensics/ovaldi > app-misc/glimpse > dev-db/cpp-driver > dev-erlang/riakc > dev-libs/xalan-c > dev-util/stubgen > media-gfx/xzgv > net-dns/dnssec-check > net-mail/cmd5checkpw > net-ftp/gproftpd > sys-apps/intel-performance-counter-monitor >
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
Hi, When the size of the repo is considered too big maybe we can revisit the option of having the portage tree distributed as a compressed sqashfs image. $ du -hs /var/db/repos/gentoo 536M. $ gensquashfs -k -q -b 1M -D /var/db/repos/gentoo -c zstd -X level=22 /tmp/gentoo-current.zstd.sqfs $ du -h /tmp/gentoo-current.zstd.sqfs 47M /tmp/gentoo-current.zstd.sqfs Though that would probably open another can of worms around incremental updates to the portage tree, or more precisely the lack of it (i.e. increased bandwidth requirements). Regardless, as a proxied maintainer I agree with Flow's point of view here (I think I have expressed these in detail too in the past here) and would prefer undeprecating EGO_SUM. Zoltan On Fri, Sep 30, 2022 at 05:10:10PM +0200, Jaco Kroon wrote: > Hi, > > On 2022/09/30 16:53, Florian Schmaus wrote: > > jkroon@plastiekpoot ~ $ du -sh /var/db/repos/gentoo/ > >> 644M /var/db/repos/gentoo/ > >> > >> I'm not against exploding this by another 200 or even 300 MB personally, > >> but I do agree that pointless bloat is bad, and ideally we want to > >> shrink the size requirements of the portage tree rather than enlarge. > > > > What is the problem if it is 400 MB more? ? What if we double the > > size? Would something break for you? Does that mean we should not add > > more packages to ::gentoo? Where do you draw the line? Would you > > rather have interested persons contribute to Gentoo or drive them away > > due the struggle that the EGO_SUM deprecation causes? > How long is a piece of string? > > I agree with you entirely. But if the tree gets to 10GB? > > At some point it may be worthwhile to split the tree similar to what > Debian does (or did, haven't checked in a while) where there is a core, > non-core repo etc ... except I suspect it may be better to split into > classes of packages, eg, x11 (aka desktop) style packages etc, and keep > ::gentoo primarily to system stuff (which is also getting harder and > harder to define). And this also makes it harder for maintainers. And > this is really already what separate overlays does except the don't (as > far as I know) have the rigorous QA that ::gentoo has. > > But again - at what point do you do this - and this also adds extra > burden on maintainers and developers alike. > > And of course I could set a filter to not even --sync say /x11-* at > all. For example. Or /dev-go or /dev-php etc ... > > So perhaps you're right, this is a moot discussion. Perhaps we should > just say let's solve the problem when (if?) people complain the tree is > too big. No, I'm not being sarcastic, just blunt (; > > The majority of Gentoo users (in my experience) are probably of the > developer oriented mindset either way, or have very specific itches that > need scratching that's hard to scratch with other distributions. Let's > face it, Gentoo to begin with should probably not be considered an > "easy" distribution. But it is a highly flexible, pro-choice, extremely > customizable, rolling release distribution. Which scratches my itch. > > Incidentally, the only categories currently to individually exceed 10MB > are these: > > 11M media-libs > 11M net-misc > 12M dev-util > 13M dev-ruby > 16M dev-libs > 30M dev-perl > 31M dev-python > > And by far the biggest consumer of space: > > 124M metadata > > Kind Regards, > Jaco >
[gentoo-dev] rg(1) supports ebuild as a file type filter
Hey, Admittedly shameless plug and only a minor thing, but since I've seen mgorny's great addition to file(1) mentioned on the list, I've also wanted to share that sometime in early 2020 I've got a PR merged into RipGrep which adds a filter for searching ebuild files only. E.g. you can do: rg -t ebuild Maybe some maintainers will find it useful when searching for examples in ebuilds. Cheers, Zoltan
Re: [gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
Hey, > > How would you suggest we track who has commit access, etc? The same > way we do with developers, via a developer bug? I believe proxy maintainers already have a bug assigned to them (at least I have one), so maybe just a comment or a special tag would be suffient on these bugs to signify commit access. > > I ask because I've noticed a lot of inactive proxied maintainers—one > of which had been listed in metadata.xml for 6 years but had never > committed to ::gentoo. > Should these packages not be dropped to maintainer needed? Just like regular developers, wouldn't it be reasonable to expect a minimal level of activiy from proxied maintainers (even if not as strict) or otherwise be dropped from a package? Zoltan
Re: [gentoo-dev] Up for grabs: app-misc/remind, net-mail/getmail
I use both of these, I'll add myself as the maintainer. Zoltan On Sun, Jul 24, 2022 at 05:48:53PM +0100, Sam James wrote: > The following packages are up for grabs b/c of retirement of proxied > maintainer: > app-misc/remind > net-mail/getmail signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
Hey, > > Rephrasing this just to ensure I'm understanding it correctly: you're > suggesting to move _everything_ that uses Go into its own overlay. Let's > call it gentoo-go for the sake of the example. > > If the above is accurate, then I hard disagree. Yes, that was the suggestion, you understood it correctly. > > The biggest package that I have that uses Go is docker (and accompanying > tools). Personal distaste of docker aside, it's a very popular piece of > software, and I don't think it's fair to require all the people who want > to use it to first enable and sync gentoo-go before they can install it. It could be enabled by default for everyone, and people would have the choice to disable it or mask everything except what they are using in that case, so the extra user toil could be avoided by a creaful rollout. I'm not saying it would be an elegant solution though. > > And what about transitive dependencies? Suppose app-misc/cool-package is > written in some language that isn't Go, but it has a dependency on > sys-apps/cool-util which has a dependency on something written in Go. > Should a user wanting to install cool-package have to enable the > gentoo-go overlay now too? Even though app-misc/cool-package would look > like it doesn't need the overlay unless you dig into the deps. This is however a valid point, something I did not consider. Any reverse dependencies (i.e. packages in main portage tree depending on gentoo-go) would be anithetical to the overlay philosopy (the other direction of dependencies is okay though). This invalidates my separate overlay suggestion, consider it withdrawn. However I think that my other points still stand, until someone convinces me otherwise. > > Not a dev, just a user who really likes Gentoo :) Thanks for your perspective, it was a valueable observation. :) > > - Oskari > Cheers, Zoltan signature.asc Description: PGP signature
[gentoo-dev] Last-rites: sci-libs/oce
# Zoltan Puskas (2022-02-07) # Fork of sci-libs/opencascade. Upstream unmaintained due to opencascade # becoming community friendly and making this fork obsolete. Recommends moving # to opencascade. See: https://github.com/tpaviot/oce/issues/745 # Blocks deprecation of sci-libs/vtk-8.2.0. # Removal on 2022-03-01. Bug #832625. sci-libs/oce signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: media-sound/clementine
On Tue, Dec 07, 2021 at 07:11:23AM +0100, Lars Wendler wrote: > On Mon, 6 Dec 2021 23:56:10 + Alexey Sokolov wrote: > > >24.11.2021 11:33, Lars Wendler пишет: > >> No real development since Q1 2020. Last release from 2016. > >> Users should switch over to media-sound/strawberry which is an > >> actively developed fork. > >> Masked for removal in 30 days. > >> > >> > > > >I've tried strawberry, but it's unusable [1]. At least until bugs are > >fixed, can it be unmasked? I can take maintainership if needed. > > > >[1] https://github.com/strawberrymusicplayer/strawberry/issues/849 > > > > Saying that it's "unusable" is quite a misleading claim when in fact > only keyboard shortcuts do not work... > > -- > Lars Wendler > Gentoo package maintainer > GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Not to fan the flames (ok, maybe a little bit), but web radio support is also rather limited in Strawberry if we are being completely honest (i.e. awful user experience). I'm saying this as a person who has transitioned away from clementine quite some time ago. Cheers, Zoltan signature.asc Description: PGP signature
Re: [gentoo-dev] systems-246 changes tmpfs default size from 50% to 10% of RAM
On Tue, Jul 28, 2020 at 03:19:26PM -0400, Mike Gilbert wrote: > On Tue, Jul 28, 2020 at 3:13 PM Mike Gilbert wrote: > > > > On Tue, Jul 28, 2020 at 2:50 PM Zoltan Puskas wrote: > > > > > > Hi, > > > > > > I've upgraded to and running systemd-246_rc2 on one of my systems and > > > noticed that tmpfs mounted directories are significantly smaller. > > > > > > This is because with commit > > > https://github.com/systemd/systemd/commit/7d85383edbab73274dc81cc888d884bb01070bc2 > > > they have changed them to be 10% of the physical memory instead of the > > > default of 50%. > > > > > > This is a potentially breaking, or at least an unexpected behaviour > > > change, especially for people using tmpfs on /tmp for compiling. > > > > > > Maybe we should make a news item to let people know that they either > > > need to add an fstab entry with size option set, or better, create a > > > systemd local override with relevant content. > > > > Don't use /tmp for PORTAGE_TMPDIR. /tmp is meant for small temporary > > storage. If you want to compile in a tmpfs, set up a separate mount > > point for it. > > > > I don't intend to create a news item for this, but I would not object > > to someone else doing it. > > Also, the limit for /tmp is likely to change again before the 246 final > release. > > https://github.com/systemd/systemd/pull/16576 > I volunteer to write the news item. It seems other distros also have met the overly restricted /tmp size issue, due to yet another legitimate use case (see the RedHat bug referenced in the PR: https://bugzilla.redhat.com/show_bug.cgi?id=1856514). It's worth noting that above PR only resets only /tmp size, but will keep /dev/shm, /run, etc. at the lower limit. While we have to wait and see what the final form will be for systemd-246, I think it'd be useful to notify users. Systemd changing the age old convention of non configured tmpfs mount sizes (from a user's perspective non configured) it means openrc and systemd boxes will end up with different behaviours (e.g. /dev/shm will now be sized differently). Cheers, Zoltan
Re: [gentoo-dev] systems-246 changes tmpfs default size from 50% to 10% of RAM
Hi, > > Don't use /tmp for PORTAGE_TMPDIR. /tmp is meant for small temporary > storage. If you want to compile in a tmpfs, set up a separate mount > point for it. > I'm not sure I can agree with this. If we are being pedantic then we should look at FHS3.0, and it does not specify that it's intended only for small files, only that the contents are essentially ephemeral, see: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#tmpTemporaryFiles Even if user does not use it for portage, there are other legitimate uses to have a large /tmp where user might want to store large amounts of data for faster processing and also to save a non trivial amount of SSD write cycles. Some real life example are: - Firefox stores temporary downloads there like PDF or archive files, that were selected to be opened with and application instead of permanently saving it, which can pile up if Firefox is not restarted for a longer period of time. - I pointed Hugin (panorama stitcher) to /tmp, which during work produces large amount of temporary data in the form of intermediate files. Probably similar to other multimedia related work flows. - Browsing an archive in mc (MidnightCommander) will result in large amount of data being unpacked into /tmp. - During proxy maintenance when patching a source tree, I will actually untar 2 copies into /tmp and do the patching, test compiling and diffing there. /tmp in convenient (and IMHO intended) for this kind of use, and users probably rely on it without even knowing they do. They should not be required to setup a new tmpfs mount for every use case, especially since many things implicitly assume /tmp is to be used for temporary storage. I don't see why portage cannot fit into this formula, especially since it does not use that much space relative to other potential use cases (well except for compiling LibreOffice, Firefox and friends). In today's world machines with 32-64GB of RAM are readily available, and users probably want to utilize them as much as they can (at least personally I do). Restricting /tmp to small files only does not make sense on desktop and laptop environments for at least a decade now if not more, and is probably even acceptable on home or low traffic servers too. Cheers, Zoltan
[gentoo-dev] systems-246 changes tmpfs default size from 50% to 10% of RAM
Hi, I've upgraded to and running systemd-246_rc2 on one of my systems and noticed that tmpfs mounted directories are significantly smaller. This is because with commit https://github.com/systemd/systemd/commit/7d85383edbab73274dc81cc888d884bb01070bc2 they have changed them to be 10% of the physical memory instead of the default of 50%. This is a potentially breaking, or at least an unexpected behaviour change, especially for people using tmpfs on /tmp for compiling. Maybe we should make a news item to let people know that they either need to add an fstab entry with size option set, or better, create a systemd local override with relevant content. Cheers, Zoltan
[gentoo-dev] Packages up for grabs
Hi, I'm stopping proxy maintenance of net-misc/youtube-viewer, as I stopped using it due to YouTube's new requirement of having a private developer's key for it to function. Shared developer key is not a possibility (i.e. setting up a Gentoo key for such packages) as YouTube rate limits the number of requests per developer product key, and also considers them ToS violation, which potentially leads to disabling them pretty fast. See more details on: https://github.com/trizen/youtube-viewer/issues/308 I'm putting up a PR and dropping it to maintainer needed. If no one wants to pick up the package maybe we should also consider last riting it after some months, since YouTube API moves fast and old versions tend to not function after some time. Cheers, Zoltan
Re: [gentoo-dev] Packages up for grabs
Hey, > I have transitioned to "away" state as I have to reclaim my time for other > uses. Here I am trying to reduce the scope of my Gentoo responsibilities to > make potential return to activity less dreadful and overwhelming. > > ... > > Call for co-maintainers or successors > = > > For these I have some minor use. You can expect me to have some interest > revived. > Still, taking responsibility for them in my absence is highly appreciated. > > * dev-python/ruamel-std-pathlib > * dev-python/ruamel-yaml-clib > * dev-python/ruamel-yaml I'm happy to take dev-python/ruamel-yaml and dev-python/ruamel-yaml-clib either as a solo or as a comaintainer. I'll put up a PR later adding myself to the metadata as a proxy maintainer. Feel free to keep or remove yourself after that. Cheers, Zoltan signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: www-client/weboob
Hi, app-office/kmymoney has dependency on weboob to import online banking transactions. Also per linked bug there is 2.0 that is Python 3 compatible and there are ebuilds offered. Can we please reconsider this and instead push for getting 2.0 into the tree? Cheers, Zoltan On Fri, Mar 27, 2020 at 05:50:17PM +0100, Michał Górny wrote: > # Michał Górny (2020-03-27) > # No Python 3 support. Last touched by maintainer in 2014. > # Removal in 30 days. Bug #674734. > www-client/weboob > > -- > Best regards, > Michał Górny > signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-misc/rq, net-news/newsboat
On Mon, Dec 02, 2019 at 11:10:52AM -0800, Georgy Yakovlev wrote: > On Sunday, December 1, 2019 1:27:34 PM PST Michał Górny wrote: > > # Michał Górny (2019-12-01) > > # Unmaintained Rust packages with incorrect license information. > > # Removal in 30 days. Bug #694414. > > app-misc/rq > > net-news/newsboat > > I recently took over newsboat, just did not have enough time to push updated > ebuild, will commit and unmask later today. Let me know if you need some help maintaining newsboat, I'm willing to proxy maintain it, with you being the primary owner of the ebuild. > > also I use rq from time to time, I'll see if I can take it over and remove > mask if I decide to take it. Zoltan signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-misc/rq, net-news/newsboat
Hi, I'd like to maintain net-news/newsboat as I actively use the software. I'll go to bugzilla, check outstanding bugs, as well as fix license and bump revision if needed. Zoltan On Sun, Dec 01, 2019 at 10:27:34PM +0100, Michał Górny wrote: > # Michał Górny (2019-12-01) > # Unmaintained Rust packages with incorrect license information. > # Removal in 30 days. Bug #694414. > app-misc/rq > net-news/newsboat > > -- > Best regards, > Michał Górny > signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: net-misc/casync
Hey, I'm willing to maintain this. Fix, ownership add, and mask removal in: https://github.com/gentoo/gentoo/pull/11490 Cheers, Z. On Sat, Mar 23, 2019 at 08:18:52PM +0100, Michał Górny wrote: > # Michał Górny (23 Mar 2019) > # Unmaintained. Fails to build. Probably needs a fresh snapshot. > # Removal in 30 days. Bug #669592. > net-misc/casync > > -- > Best regards, > Michał Górny > signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs: x11-misc/x11vnc, net-libs/libvncserver, x11-misc/calise, app-misc/trash-cli, app-arch/zopfli
Hi there, I'd like to claim app-misc/trash-cli as a proxied maintainer. Cheers, Zoltan > Dear all, > > The following packages are up for grabs > after retirement of the proxied maintainer > https://bugs.gentoo.org/632924 > > app-arch/zopfli > https://packages.gentoo.org/packages/app-arch/zopfli > > app-misc/trash-cli > https://packages.gentoo.org/packages/app-misc/trash-cli > 1 Bug with a fix in the bugtracker. > > > x11-misc/calise > https://packages.gentoo.org/packages/x11-misc/calise > open bump req. https://bugs.gentoo.org/590986 > > > x11-misc/x11vnc > https://packages.gentoo.org/packages/x11-misc/x11vnc > > !!! > Very wide spread package. Should really get a new Maintainer. > Many open tickets. > https://bugs.gentoo.org/buglist.cgi?quicksearch=x11-misc%2Fx11vnc > !!! > > > net-libs/libvncserver > https://packages.gentoo.org/packages/net-libs/libvncserver > 3 open tickets. > > > -- > Best, > Jonas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > signature.asc Description: PGP signature
