Re: [gentoo-dev] www-client/chromium needs a new maintainer
That does sound painful. > - Across the 3 channels, you are looking at roughly 12 releases per month. > That's a lot of churn. * Why build unstable stuff, why not build only stable releases and fix the problems once? * Looking at chromium-browser-official and the GitHub mirror, it's unclear to me which release is stable. How is that sorted out? > - Upstream likes to use modern C++ features, and they write C++ code that > tends to break or is unsupported on stable releases of GCC and LLVM. * How common of a problem is the C++ issue? * I don't know C++, is that a major obstacle? > - Upstream bundles many libraries. The Gentoo ebuild has some logic to > unbundle a number of these, but maintaining it is a pain. * What tends to go wrong? > - Using the bundled libraries sometimes is problematic, especially on > non-x86-64 targets which upstream doesn't support well. * What tends to break here? * Is the upstream likely to take patches or are we stuck maintaining a patch set for pretty much all non-x86-64 targets? * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make their way upstream? ~Jeff On Wed, Jun 7, 2023 at 2:38 PM Maciej Barć wrote: > I think Google does all this intentionally to piss off people trying to > use the "free-er" version of Chrome... let's face it, "their" aim is to > create a one-fits-all spyware named Google Chrome. > > Google does not want you to touch their mess. > Google does not want you to even think about going a extra mile to not > have telemetry in software you use every day. > > Having said all this, it really is a miracle to me that the Gentoo > Chromium team had put up with this for so insanely long and I have the > most respect for you guys! > > W dniu 7.06.2023 o 19:45, Mike Gilbert pisze: > > On Wed, Jun 7, 2023 at 9:09 AM Jeff Gazso wrote: > >> > >> I'm in the process of getting Gentoo dev status. I'm willing to consider > >> maintaining www-client/chromium. I have a high core count rack server > that > >> should be able to handle the build process quite well. Can you give me > a list > >> of common pain points? If that is a long conversation feel free to > email me > >> directly. > > > > I'll start by giving a brief overview of the Chromium release process > upstream: > > > > - 3 release channels: stable, beta, dev/unstable > > - Major development occurs on the master branch. > > - Once a month, a new major version is forked from master, and this > > becomes the "dev channel" release series. > > - Over the next several weeks in the dev channel the major version is > > tested and fixed, with releases roughly once per week. > > - Eventually, the branch is promoted to the "beta channel". > > - A similar process occurs in the beta channel, with weekly releases > > until the major version is finally promoted to the "stable channel". > > - The stable channel sees around 1 to 2 releases per month, usually > > with security fixes included. > > > > Downstream, we have historically tried to keep up with all 3 channels. > > Keeping the dev channel working is the biggest challenge. The other > > channels usually just involve build testing and the occasional > > backport of fixes. > > > > Common problems: > > > > - Across the 3 channels, you are looking at roughly 12 releases per > > month. That's a lot of churn. > > - The dev channel never compiles the first time you try it. There are > > always problems to fix. > > - Upstream only really supports using their bundled toolchain (an LLVM > > git snapshot on Ubuntu). On Gentoo, we try to make it work with the > > stable release of GCC and LLVM/clang. > > - Upstream likes to use modern C++ features, and they write C++ code > > that tends to break or is unsupported on stable releases of GCC and > > LLVM. > > - Upstream bundles many libraries. The Gentoo ebuild has some logic to > > unbundle a number of these, but maintaining it is a pain. > > - Using the bundled libraries sometimes is problematic, especially on > > non-x86-64 targets which upstream doesn't support well. > > - Upstream cross-compiles their ARM binaries, whereas we compile > > natively on Gentoo. This sometimes causes conflicts. > > > > I'm probably missing some things, but I think that should give you > > some idea of what you're in for. :-) > > > > -- > Have a great day! > > ~ Maciej XGQT Barć > > x...@gentoo.org > Gentoo Linux developer > (dotnet, emacs, math, ml, nim, scheme, sci) > https://wiki.gentoo.org/wiki/User:Xgqt > 9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C >
Re: [gentoo-dev] www-client/chromium needs a new maintainer
I'm in the process of getting Gentoo dev status. I'm willing to consider maintaining www-client/chromium. I have a high core count rack server that should be able to handle the build process quite well. Can you give me a list of common pain points? If that is a long conversation feel free to email me directly. ~Jeff On Wed, Jun 7, 2023 at 7:06 AM Sam James wrote: > > Alexe Stefan writes: > > > My finger slipped in my last mail. > > How do you see how many people are using a package? > > Bug reports, mentions on forums, mentions on the mailing list, mentions > on IRC, etc. > > Or, to put it another way: when you break it, enough people > shout. Gentoo doesn't have telemetry so we have to go off things like > this. >
Re: [gentoo-dev] Last rites: net-p2p/litecoind
Sam, I've looked into it and, yes, the net-p2p/litecoind ebuild should absolutely get LR. The upstream litecoind project on which it depends seems to have been a fork of the official Litecoin project. Unlike the official Litecoin project which is doing just fine, the litcoind project no longer exists on GitHub. Even better, the official Litecoin project builds litecoind among several other binaries. I'll add Litecoin to my to-do list of ebuilds to write. This functionality will make its way back to Gentoo eventually. ~Jeff On Tue, Apr 18, 2023 at 9:36 AM Jeff Gazso wrote: > Sam, > > I know my ebuild maintainer status is still pending, but let me see what I > can do with this. I'll update you before 05-18. > > ~Jeff > > On Tue, Apr 18, 2023 at 7:02 AM Sam James wrote: > >> # Sam James (2023-04-18) >> # Fails to compile with GCC 13, out of date, QA issues, and various open >> bugs. >> # Removal on 2023-05-18. >> # Bug #899218, bug #899218, bug #796599, bug #672326, bug #788844. >> net-p2p/litecoind >> >
Re: [gentoo-dev] Last rites: net-p2p/litecoind
Sam, I know my ebuild maintainer status is still pending, but let me see what I can do with this. I'll update you before 05-18. ~Jeff On Tue, Apr 18, 2023 at 7:02 AM Sam James wrote: > # Sam James (2023-04-18) > # Fails to compile with GCC 13, out of date, QA issues, and various open > bugs. > # Removal on 2023-05-18. > # Bug #899218, bug #899218, bug #796599, bug #672326, bug #788844. > net-p2p/litecoind >
[gentoo-dev] Fintech Packages
It looks like cryptocurrency related packages are ending up in one of two places: net-misc or net-p2p. The latter seems to be by virtue of the fact that, as an implementation detail, most cryptocurrency networks are peer-to-peer in nature. A (very) cursory look at the Gentoo ebuild repository shows: net-misc/bfgminer net-misc/electron-cash net-misc/electrum net-misc/electrum-ltc net-p2p/bitcoin-cli net-p2p/bitcoind net-p2p/bitcoin-qt net-p2p/litecoind There are probably more, but this is what I could find quickly and easily. Wouldn't it make more sense to silo these ebuilds (and similar) under something like fintech instead? ~Jeff
Re: [gentoo-dev] Last rites: net-misc/electrum-ltc
Sorry for the delay, I have submitted my PR request to save net-misc/electrum-ltc from last rites. I have tagged you and Sam. https://github.com/gentoo/gentoo/pull/27731 Please let me know if there is anything more I need to do. ~Jeff On Tue, Sep 27, 2022 at 3:14 AM Arthur Zamarin wrote: > On 27/09/2022 00.49, Jeff Gazso wrote: > > After some trial and error, I managed to modernize the old > > net-misc/electrum-ltc ebuild based upon the net-misc/electrum ebuild > code. > > I still need to tweak a few things, but it's basically done. > > Thank you for the work on it. > > > I am not (yet) a Gentoo dev, how do I move forward with the revised > > ebuild? > > > > Open a Pull Request in GitHub, and one of our devs will review it. I > recommend to read [1] if this is your first time. Please ping me > (@arthurzam) so we don't miss it :) > > [1] https://wiki.gentoo.org/wiki/GitHub_Pull_Requests > > -- > Arthur Zamarin > arthur...@gentoo.org > Gentoo Linux developer (Python, Arch Teams, pkgcore stack) > >
Re: [gentoo-dev] Last rites: net-misc/electrum-ltc
After some trial and error, I managed to modernize the old net-misc/electrum-ltc ebuild based upon the net-misc/electrum ebuild code. I still need to tweak a few things, but it's basically done. I am not (yet) a Gentoo dev, how do I move forward with the revised ebuild? On Sat, Sep 10, 2022 at 12:22 PM Arthur Zamarin wrote: > On 10/09/2022 18.49, Jeff Gazso wrote: > > This one caught me by surprise. > > > > So, it looks like the versions of net-misc/electrum (the Bitcoin client) > > in Gentoo's repository are in pretty good shape. The version of > > net-misc/electrum-ltc (the Litecoin client) in the Gentoo repository > > looks like it's two years old. (For those who are unfamiliar the > > Litecoin client is downstream of the Bitcoin client, both projects share > > a lot of the same code.) I checked upstream and the current version of > > electrum-ltc appears to have been bumped to Python 3.8 and it looks like > > the old aiorpcX (#792219) issue that was causing such a headache has > > also been fixed as of a PR this past February. See my note in #792219. > > Looks like you are correct, but note that we currently have 3.10 as > stable version, so electrum-ltc should be at least that version. > > > Pardon my ignorance, but couldn't this package be salvaged by > > repurposing the net-misc/electrum ebuild code to bring the > > net-misc/electrum-ltc package current? Is the situation more complicated > > than that? > > If any user manages to fix the issues mentioned in last rite message > (mainly bump to at least 3.10 python target), I would gladly cancel the > last-rite and mask. > If you do it, please ping me in the PR, and I would gladly review it. > > Those last-rites I did today are mainly for those packages that were > stuck in only 3.8, had a bug open for 7-10 month already. If any > maintainer can fix those ebuilds, I would happily revert the last-rite. > > > ~Jeff > > -- > Arthur Zamarin > arthur...@gentoo.org > Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU) > >
Re: [gentoo-dev] Last rites: net-misc/electrum-ltc
This one caught me by surprise. So, it looks like the versions of net-misc/electrum (the Bitcoin client) in Gentoo's repository are in pretty good shape. The version of net-misc/electrum-ltc (the Litecoin client) in the Gentoo repository looks like it's two years old. (For those who are unfamiliar the Litecoin client is downstream of the Bitcoin client, both projects share a lot of the same code.) I checked upstream and the current version of electrum-ltc appears to have been bumped to Python 3.8 and it looks like the old aiorpcX (#792219) issue that was causing such a headache has also been fixed as of a PR this past February. See my note in #792219. Pardon my ignorance, but couldn't this package be salvaged by repurposing the net-misc/electrum ebuild code to bring the net-misc/electrum-ltc package current? Is the situation more complicated than that? ~Jeff On Sat, Sep 10, 2022 at 9:21 AM Arthur Zamarin wrote: > # Arthur Zamarin (2022-09-10) > # Python 3.8 only package, with capped old dependencies, and open > # bugs and issues. > # Removal: 2022-10-10. Bugs #869506, #695090, #792219, #809272. > net-misc/electrum-ltc >
Re: [gentoo-dev] Add systemd/merged-usr profiles
Just out of curiosity, how much pain is this likely to cause existing installations that will need to migrate from a split-usr setup to a merged-usr setup? On Tue, Aug 30, 2022 at 2:28 PM Mike Gilbert wrote: > This patch series adds a "merged-usr" feature profile, and subprofiles > for each systemd profile. > > As background: systemd upstream is preparing to drop support for > split-usr systems soon. All systemd users on Gentoo will eventually > need to migrate to a merged-usr system. > > >
[gentoo-dev] Can app-office/sc be replaced by app-office/sc-im from GURU?
It seems app-office/sc (spreadsheet calculator) was last updated upstream about 20 years ago. At this point it's safe to say the project is no longer in development. There is a currently maintained fork called sc-im (spreadsheet calculator - improved) which has been in continuous development for about 6 years at this point. It does not exist in the main Gentoo repository but app-office/sc-im is present in GURU. The app-office/sc-im ebuild appears to be maintained by someone named Dex Conner. I'm new at this, but it looks to me like the ebuild is in good shape. The only thing that jumps out at me is the fact that the package manifest needs some TLC. My thought is unless some serious deficiency is present in app-office/sc-im it should be moved to Gentoo's main ebuild repository and the last rites process should be started for app-office/sc. Does anyone else have thoughts or comments on this? Jeff Gazso
[gentoo-dev] [TRACKER] Raku support question
Hello, Should these two bugs be linked to by https://bugs.gentoo.org/604346 [TRACKER] Raku support? * https://bugs.gentoo.org/827802 * https://bugs.gentoo.org/834943 ~Jeff
[gentoo-dev] dev-lang/rakudo eclass
Hello everyone, I've been testing dev-lang/raku support on Gentoo and submitting various bugs for a while. I submitted https://bugs.gentoo.org/827802 "dev-lang/rakudo lacks an ebuild for the zef module installer" in an effort to improve Gentoo's support for Raku by getting a proper Raku module installer in place. This would be an obvious stepping stone towards a dev-lang/rakudo-star meta-package. After some back-and-forth a fellow Gentoo user and Raku enthusiast (crocket) attached a draft eclass which supports the zef module installer, Prove6 for unit testing, and Inline-Perl5 for Perl integration to the bug. This caught Sam James' attention and he suggested the eclass be submitted to this list in git-am patch format. The person who submitted the eclass seemed a bit reluctant to email the list. I was going to do it for him, but then I realized that I don't know what git-am patch format is. Can someone on this list look at the eclass attached to https://bugs.gentoo.org/827802 and provide direction? ~Jeff
