Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management
Hey, On 11.4.2024 9.14, Jaco Kroon wrote: > > The latter can certainly be done and makes sense (only required if > you're using the fuse mount, so if USE=fuse at least). > > The former doesn't make sense to do blindly in /etc/init.d/netmount > (which belongs to sys-apps/openrc, not glusterfs). > well I was thinking about putting that into glusterfs's init file. -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 6.4.2024 14.57, Eddie Chapman wrote:
>
> --- /usr/portage/net-mail/dovecot/dovecot-2.3.21-r1.ebuild
> +++ /usr/local/portage/net-mail/dovecot/dovecot-2.3.21-r1.ebuild
> @@ -43,7 +43,6 @@
>
> DEPEND="
> app-arch/bzip2
> - app-arch/xz-utils
> dev-libs/icu:=
> dev-libs/openssl:0=
> sys-libs/zlib:=
> @@ -126,7 +125,7 @@
> --disable-rpath \
> --with-bzlib \
> --without-libbsd \
> - --with-lzma \
> + --without-lzma \
> --with-icu \
> --with-ssl \
> --with-zlib \
>
> --- /usr/portage/dev-lang/python/python-3.11.8_p1.ebuild
> +++ /usr/local/portage/dev-lang/python/python-3.11.8_p1.ebuild
> @@ -179,6 +179,7 @@
> # Avoid as many dependencies as possible for the cross build.
> cat >> Makefile <<-EOF || die
> MODULE_NIS_STATE=disabled
> + MODULE__LZMA_STATE=disabled
> MODULE__DBM_STATE=disabled
> MODULE__GDBM_STATE=disabled
> MODULE__DBM_STATE=disabled
> @@ -328,7 +329,7 @@
> fi
>
> # force-disable modules we don't want built
> - local disable_modules=( NIS )
> + local disable_modules=( NIS _LZMA )
> use gdbm || disable_modules+=( _GDBM _DBM )
> use sqlite || disable_modules+=( _SQLITE3 )
> use ssl || disable_modules+=( _HASHLIB _SSL )
>
>
> --- /usr/portage/dev-lang/python/python-3.12.2_p1.ebuild
> +++ /usr/local/portage/dev-lang/python/python-3.12.2_p1.ebuild
> @@ -177,6 +177,7 @@
> cat > Modules/Setup.local <<-EOF || die
> *disabled*
> nis
> + _lzma
> _dbm _gdbm
> _sqlite3
> _hashlib _ssl
> @@ -299,6 +300,7 @@
> cat > Modules/Setup.local <<-EOF || die
> *disabled*
> nis
> + _lzma
> $(usev !gdbm '_gdbm _dbm')
> $(usev !sqlite '_sqlite3')
> $(usev !ssl '_hashlib _ssl')
>
>
> Lastly, I needed to create a custom dev-libs/libxmlb ebuild in order to
> upgrade it from 0.3.14 (latest in Gentoo at time of writing) to 0.3.15.
>
> I also needed to apply a very recent patch from upstream, from this
> commit, which makes LZMA support optional:
> https://github.com/hughsie/libxmlb/commit/bdf845510fbed40b88465b2272ccad9e93656639
>
> and I needed to make some small changes to the ebuild.
>
> So this is what you need to do at the time of writing (6th April 2024):
>
> 1. Copy the in-tree /usr/portage/dev-libs/libxmlb ebuild directory into
> your local ebuilds directory.
>
> 2. Rename the ebuild file from libxmlb-0.3.14.ebuild to
> libxmlb-0.3.15.ebuild
>
> 3. Download the raw patch, you can use this link:
>
> https://github.com/hughsie/libxmlb/commit/bdf845510fbed40b88465b2272ccad9e93656639.patch
> rename it to:
> libxmlb-0.3.15-make_lzma_optional.patch
> and place it in the local "files" directory.
>
> 4. Modify the new ebuild according to the diff below. Then just rebuild it.
>
> --- /usr/portage/dev-libs/libxmlb/libxmlb-0.3.14.ebuild
> +++ /usr/local/portage/dev-libs/libxmlb/libxmlb-0.3.15.ebuild
> @@ -14,15 +14,15 @@
> SLOT="0/2" # libxmlb.so version
>
> KEYWORDS="amd64 ~arm arm64 ~loong ppc ppc64 ~riscv x86"
> -IUSE="doc introspection stemmer test +zstd"
> +IUSE="doc introspection -lzma stemmer test +zstd"
>
> RESTRICT="!test? ( test )"
>
> RDEPEND="
> - app-arch/xz-utils
> dev-libs/glib:2
> sys-apps/util-linux
> stemmer? ( dev-libs/snowball-stemmer:= )
> + lzma? ( app-arch/xz-utils:= )
> zstd? ( app-arch/zstd:= )
> "
>
> @@ -43,6 +43,7 @@
>
> PATCHES=(
> "${FILESDIR}"/${PN}-0.3.12-no_installed_tests.patch
> + "${FILESDIR}"/${PN}-0.3.15-make_lzma_optional.patch
> )
>
> python_check_deps() {
> @@ -60,6 +61,7 @@
> $(meson_use stemmer)
> $(meson_use test tests)
> $(meson_use zstd)
> + $(meson_feature lzma)
> )
> meson_src_configure
> }
Hey,
I'll admit I didn't read everything, but I just want to point out you
may not have to edit ebuilds at all. If xz-utils is package.provided
portage should ignore the dependency without you removing the dep from
an ebuild. Then you can utilize /etc/portage/patches to apply any
patches and finally try using EXTRA_ECONF and MYMESONARGS to override
configure options via package.env.
-- juippis
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management
On 8.4.2024 12.51, Jaco Kroon wrote: > > In order for glusterfs to mount successfully the fuse module needs to be > available when mount.glusterfs is invoked. This can be achieved in one > of two ways: > > 1. Compile the module statically into the kernel. > 2. Arrange for fuse service to be started prior to netmount (using say > /etc/conf.d/netmount rc_need="fuse") > 3. Add "/sbin/modprobe -q fuse" to the init.d file's start_pre() function, ExecStartPre with systemd, and make the ebuild warn about CONFIG_FUSE_FS with linux-info.eclass. -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 1.4.2024 23.07, James Le Cuirot wrote: > > That's not stupid at all, I'd been thinking exactly the same thing. I raised > this whole issue during a discussion at FOSDEM 2019, where I admitted that I > didn't check the code changes for packages I was bumping, knowing that few to > none of the other people in the room did so either. Despite speaking up then, > I still didn't do it because it's a heavy a burden and I'm not paid to do it. > Now I'm thinking I really should, but I could really use some help. I'll raise > this idea at work. You could say that we specialise in these things. :) > > Regards, > Chewi Offtopic but I'll just throw this out there: "pkgdiff-mg -b" from mgorny-dev-scripts does wonders when bumping packages. Not everyone knows about this so posting for awareness. (Maybe slightly related after all since it would've shown the suspicious CmakeLists.txt change at least) -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: app-admin/ananicy
app-admin/ananicy up for grabs. It's currently in good shape. -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: media-gfx/iscan
media-gfx/iscan is up for grabs. Has few bugs open, pending stabilization and nothing critical with pkgcheck. -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last-rites: net-misc/buka
The webpage it was built to scrape isn't online anymore. Removal in ~30 days. Bug #924007 -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] News item: LXD to lose access for its image server
### Notes: Tried to keep this news item as concise as possible, ### more information in #920527. Title: LXD to lose access for its image server Author: Joonas Niilola Posted: 2023-12-28 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-containers/lxd Earlier this year Canonical took their LXD project from community-hosted LinuxContainers under Canonical's own management. While doing so, they removed management access from non-Canonical employees, along with other things. This caused LXD to be forked and so Incus was born. Incus would pull updates from upstream LXD to stay compatible. Recently LXD was re-licensed so Incus can't benefit from its code anymore. Therefore Incus will become a truly independent project. However it is LinuxContainers community that still hosts most LXD images for free, for Incus and LXD. With them unable to benefit or use LXD anymore, LinuxContainers have decided to stop building and hosting LXD images. They will start limiting access immediately in 2024 for non-LTS users which is LXD >=5.18, or "unstable" in Gentoo. LTS LXD, or "stable" (5.0) in Gentoo will be allowed to pull images until May (an estimate), or until Incus LTS will be released. Times are subject to change. What can you do? 1: Switch to Incus. 2: Deploy your own image server. 3: Wait and see what Canonical does. For unstable users the matter is rather urgent, while stable users have the luxury of waiting. Note that a downgrade from unstable to stable is not possible due to database schemas. Please follow or take a look at Gentoo bug #920527 with more information about this situation, and updates e.g. for timetables. OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Last-rite: app-misc/neofetch
On 20.10.2023 10.38, Joonas Niilola wrote: > Upstream is totally abandoned with no updates for 2 years. The situation > has spawned multiple forks and there are different maintained > alternatives available now in Gentoo's repository. To list a few: > fastfetch, hyfetch, screenfetch > > If you're aware of more/better alternatives, please add them to the > package.mask file at your will. Bug #916040 > > -- juippis Hey, so my reason for removal was that the upstream issue number is growing weekly and there's no one fixing them. Apparently a new fork was made where the new authors have been fixing bugs / merging PRs from neofetch and it seemed reasonable to switch to that. But neofetch does do the job of showing Gentoo-logo just fine I guess... but I also want to point out it's literally a single wgettable bash script and I personally don't see much value in keeping it, but people seem to love it too much :) so let's keep it. And I agree, neofetch is the original, it has a legendary status. -- juippis
Re: [gentoo-dev] Last-rite: app-misc/neofetch
On 20.10.2023 15.30, Pascal Jaeger wrote: > > This is only two years without a release. We have packages way way older > than that. > I know fetch scripts have a reputation, but this thing is kind > of a staple in the community and it is still widely used. > > I can jump in as a proxy maintainer if that is the problem. > > Pascal > Hey, I was looking at these metrics: https://github.com/dylanaraps/neofetch/branches/active https://github.com/dylanaraps/neofetch/branches https://github.com/dylanaraps/neofetch/issues https://github.com/dylanaraps/neofetch/pulls and it's not looking good. Do we have the wrong upstream in our current ebuild? https://packages.gentoo.org/packages/app-misc/neofetch -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last-rite: app-misc/neofetch
Upstream is totally abandoned with no updates for 2 years. The situation has spawned multiple forks and there are different maintained alternatives available now in Gentoo's repository. To list a few: fastfetch, hyfetch, screenfetch If you're aware of more/better alternatives, please add them to the package.mask file at your will. Bug #916040 -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: app-portage/gentle, dev-python/insipid-sphinx-theme, net-libs/libomemo-c
Hey, due to a retirement of a proxied maintainer, the following packages are up for grabs: app-portage/gentle dev-python/insipid-sphinx-theme net-libs/libomemo-c Gentle has 3 bugs open, otherwise all in good shape. -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last-rites: x11-plugins/enigmail
Enigmail's functionality has been built into Thunderbird-68, carrying over all the way to 115. Enigmail hasn't been supported in TB since 91. It's currently only supported on SeaMonkey, but upstream provides a pre-packed extension to download for SM directly. Therefore there's not much reason to package it in Gentoo, given also the current version is years behind upstream releases. Removal in ~30 days. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: net-misc/dahdi (and related pkgs)
DAHDI is not suited for a rolling-release distribution. Upstream releases new versions sporadically and it may take multiple years between them. Old versions are constantly broken with newer kernels, requiring heavy patching downstream. Has no active maintainer in Gentoo. If you use DAHDI and have some ideas how to help, please see bug #914477. Removal on 2024-03-01. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: app-mobilephone/heimdall
Hey, app-mobilephone/heimdall is up for grabs. It's up to date, no bugs open. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: MATE desktop
Hey, MATE desktop project is being disbanded due to no joining. At least now someone will get notified when a Github PR is made (not for bugs though). It seems like packages are bumped to latest major version, but minor version bumps are missing (1.26.0+). ~30 bugs open. Packages up for grabs: app-arch/engrampa app-editors/pluma app-editors/pluma-plugins app-text/atril dev-libs/libmateweather dev-python/python-caja mate-base/caja mate-base/libmatekbd mate-base/mate mate-base/mate-applets mate-base/mate-applets-meta mate-base/mate-common mate-base/mate-control-center mate-base/mate-desktop mate-base/mate-menus mate-base/mate-panel mate-base/mate-session-manager mate-base/mate-settings-daemon mate-extra/caja-actions mate-extra/caja-admin mate-extra/caja-dropbox mate-extra/caja-extensions mate-extra/mate-calc mate-extra/mate-indicator-applet mate-extra/mate-media mate-extra/mate-netbook mate-extra/mate-polkit mate-extra/mate-power-manager mate-extra/mate-screensaver mate-extra/mate-sensors-applet mate-extra/mate-system-monitor mate-extra/mate-user-guide mate-extra/mate-user-share mate-extra/mate-utils media-gfx/eom media-libs/libmatemixer x11-misc/mate-notification-daemon x11-misc/mozo x11-terms/mate-terminal x11-themes/mate-backgrounds x11-themes/mate-icon-theme x11-themes/mate-icon-theme-faenza x11-themes/mate-themes x11-wm/marco -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Massive Github PR Queue
On 11.8.2023 17.07, orbea wrote: > Hi, > > Currently the Gentoo Github PR queue is at 577 open PRs that even > includes one that has been left open in 2018 and neglected since 2021. That's a bit misleading. The PR in question is opened by a Gentoo developer, and labeled as "do-not-merge". So maybe they lost interest, or forgot? Ping in the PR if you want to see it finished. But there are indeed tons of PRs open from 2020. > > While not trying to be rude before contributing to Gentoo I was involved > with Slackbuilds.org for Slackware where everything gets reviewed once > a week with only a handful of maintainers doing the reviewing process. We also have 32,000 PRs closed, while slackbuild is at 3000. And here also only handful of members are putting effort in general PR review. So I'd say we're doing pretty good in that regard. > > Why does Gentoo lets PRs indefinitely sit around and collect dust? Its > extremely discouraging for contributors if their work just gets ignored. > With some extra work I imagine its possible to get the PR queue to a > much more manageable size where work doesn't get lost. > It is discouraging I agree. Even for us. If you want to help, go through the old PRs seeing which are relevant, ping the maintainers if the PR is waiting for action on their side, and let us know (via IRC for example) which PRs are mergeable. Now as to the problems. We've done some cleanups in the past, but in my opinion it's no point in putting too much energy on that if there's are many fresh PRs to look at. We shouldn't lose the momentum. There's also this handy tool, https://github.com/wimmuskee/gengee which I used a lot in the past but haven't been able to recently due to always looking at few week old PRs. Another big issue is as mjo pointed out, not everyone uses GH. But don't be fooled, I don't think you're gaining better record attaching your work to bugzilla either. It really depends on the maintainer whether they prefer contributions via GH or BZ, and we've tossed some ideas in the past trying to show maintainer's preference, but nothing came of those ideas. Then unfortunately some maintainers who'll ignore both exists. There's pretty much only 1 project dealing with Github PRs (proxy-maint) and that project only gets notified with packages under maintainer-needed, or maintained via proxy-maint itself. This project doesn't get notified for _every_ PR opened, which I believe is a common misconception. And it shouldn't either. There's simply too much incoming mail even with few projects. So it's up to projects handling their own PRs, but again, not everyone uses GH / care about PRs. What I suggest for everyone to do: 1: open a bug that gets assigned to maintainer, 2: link your PR to the bug with "Bug:" or "Closes:" tag, 3: if no one reviews it for 2-4 weeks, pop into #gentoo-proxy-maint IRC channel and ask someone to take a look. Open bug is a requirement for other non-project members to merge your work, since it allows maintainer timeout. Note that packages maintained by base-system and toolchain can't be merged by devs outside these projects. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: app-admin/kpcli
Hey, app-admin/kpcli is up for grabs. Finally migrated to pass. It's up to date and has one bug open about copying passwords to clipboard, which I believe is a bug in urxvt because it works for me on other terms. There's a huge release 4.0 in the making and will probably be out soon, but currently everything is handled. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Possible merge of myspell/hunspell dictionaries
On 7.7.2023 12.55, Zurab Kvachadze wrote: > Hello everyone, > > I am new here, so I'm sorry in advance for any stupid thing I may say. I > want to adopt hunspell for various reasons and what I've noticed is a > plethora of app-dicts/myspell-* packages (for each language there's one). > > I suggest merging them into one big myspell-dicts package, which will > certainly reduce maintenance burden (the similar thing is done with > libreoffice-l10n, I think). > > Looking forward to hearing your thoughts about my proposal > > > — Obligatory footer — > > BalkanMadman > > Hey, it would be better than the current situation for sure, but my impression with myspell* packages is that they all have different version releases and different upstream source uris, so just wondering can it be done with a single package? In theory it'd be an improvement though if there is a single upstream holding all language options. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs per grknight's retirement
Hey, these packages are up for grabs: dev-db/mycli dev-libs/judy dev-util/imediff2 lxde-base/lxdm mail-client/s-nail mail-filter/amavisd-milter net-misc/omnisync sys-power/acpilight They're in pretty good state. lxdm has bunch of bugs open, some others were eligible for python-3.12 compatibility bump, but nothing major stood out. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] www-client/chromium needs a new maintainer
On 8.6.2023 13.08, Alexe Stefan wrote: > Can you build firefox/librewolf with gcc? > Afaik, you can only build it with clang/llvm. > Librewolf if the only reason I have clang and llvm on my system. > > joi, 8 iun. 2023, 10:31 Joonas Niilola <mailto:juip...@gentoo.org>> a scris: > > Luckily few years ago > Mozilla invested in a pretty efficient CI system where they now test > commits/releases using multiple different setups; for example, multiple > different llvm releases, gcc etc. > Unfortunately Firefox does link to libclang for the web developer tools, syntax highlight etc so a clang dep is mandatory. You can fully build the source using GCC though. No idea about LibreWolf, but I'd imagine it's similar. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] www-client/chromium needs a new maintainer
On 8.6.2023 1.11, Alexe Stefan wrote: > > Also, with all this discussion, one can't help but wonder, is > firefox/librewolf also in such danger? > > Maintaining Firefox shares many of the bullet points mentioned above. We used to provide alpha/beta builds so issues would be caught early and reported upstream before a release was made. Luckily few years ago Mozilla invested in a pretty efficient CI system where they now test commits/releases using multiple different setups; for example, multiple different llvm releases, gcc etc. That does relieve us from some burden, but obviously Gentoo ships Firefox with multiple configure options and something is bound to be broken every now and then. We've made the choice of only stabilizing the ESR release which takes some pressure off, because ESR is usually pretty stable between minor releases. They also happily welcome patches to fix any issues, although new features may not get in without strong reasoning first. I'd also like to credit previous Firefox's maintainers in Gentoo who've historically been active and done a good job while having close ties with upstream. I'm glad upstream mostly takes us seriously, even with our ability to heavily customize the build outcome. Let's hope this doesn't change. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] EGO_SUM
On 2.6.2023 21.06, William Hubbs wrote: >> >> In theory it's "easy", but in practice how'd you work? This would be >> fine when a single developer is proxying a single maintainer, but when a >> a stack of devs (project) are proxying hundreds of different people, it >> becomes messy and unsustainable rather fast. > > This comment is completely off topic for this thread, so start another > thread for it if you want, but if hundreds of people are being proxied > by proxy-maint, that seems to be a concern unrelated to this. It seems > the fix for that is to advocate for some of these hundreds of people to > become developers so they don't have to be proxied any more. > How is it offtopic when I'm answering concerns you raised? Imagine there are tens of people who do 4 commits a year, roughly, to bump random go packages. What do you believe is the time investment for reviewing, testing and committing their contributions, vs. mentoring them to become devs if they don't involve themselves much outside bumping these packages? Also, will _you_ volunteer to mentor them? It's so easy to push more work for others to do. Sorry if I come out harsh but this is reality, not just theory. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] EGO_SUM
On 1.6.2023 22.55, William Hubbs wrote: >> >> The EGO_SUM alternatives >> - do not have the same level of trust and therefore have a negative >> impact on security (a dubious tarball someone put somewhere, especially >> when proxy-maint) > > For this, I would argue that vetting the tarball falls to the developer > who is proxying. If you don't trust the proxy maintainer you > are pushing for, it is easy to make a dependency tarball yourself and > add it to your dev space. > > >> - require additional effort when developing ebuilds > > This "additional effort" is pretty subjective. Making a dependency tarball > isn't a lot of work, especially with the script that I posted in this thread. > In theory it's "easy", but in practice how'd you work? This would be fine when a single developer is proxying a single maintainer, but when a a stack of devs (project) are proxying hundreds of different people, it becomes messy and unsustainable rather fast. I do want to point out that any proxied maintainer can and should upload the vendor tarballs to their own Github / Gitlab distfile-repos for the time being, but allowing EGO_SUM to be used again would be the easiest solution here in my opinion for everyone involved. I'm aware it's pushed back due to technicalities. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: net-p2p/freenet, net-p2p/fms, net-libs/NativeThread, dev-java/jbitcollider-core
Hey, the following packages are up for grabs: acct-group/freenet acct-user/freenet dev-java/jbitcollider-core net-libs/NativeThread net-p2p/fms net-p2p/freenet They are in pretty good condition. net-p2p/freenet needs a version bump, has few bugs open and some pkgcheck QA issues. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: net-vpn/networkmanager-fortisslvpn
Hey, net-vpn/networkmanager-fortisslvpn is up for grabs due to the previous proxied maintainer not using this package anymore. It currently has one bug open. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: sys-kernel/pf-sources sys-process/uksmd
Hey, the following packages are up for grabs: sys-kernel/pf-sources sys-process/uksmd Both need a version bump. uksmd has no releases so tag the latest commit and package a snapshot version. pf-sources's ebuild should be documented well-enough for anyone to understand how it works. After dealing with tons of amdgpu-related issues in latest kernels, I've realized how chill using LTS kernel version is. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] all openrc messages look very strange after upgrading many packages yesterday
On 14.4.2023 9.50, Andrey Grozin wrote: > Hello *, > > Yesterday I upgraded a large number of packages (but not including > openrc). After that all openrc messages look very strange. Many (null), > colors are weird. Don't know which specific upgrade has led to this > effect. This includes system boot messages and system poweroff messages > (in text mode) as well as messages in the terminal in X, as illustrated > in the screenshot. What has happened? > > Andrey Ncurses, the latest version has been masked and you should get a downgrade on your updates. #904263 https://packages.gentoo.org/packages/sys-libs/ncurses -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: media-gfx/frogr
On 25.2.2023 8.05, Michał Górny wrote: > # Michał Górny (2023-02-25) > # Unmaintained. The Gentoo version is from 2018 and needs bumping. > # It has a build failure reported. > # Removal on 2023-03-27. Bug #649234. > media-gfx/frogr > This got saved. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: media-libs/libiptcdata
media-libs/libiptcdata is up for grabs. It's a dependency of app-misc/tracker-miners and media-gfx/rawtherapee. Has two bugs open: test failure and python-3.11 compatibility bump. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: net-vpn/networkmanager-l2tp
Package up for grabs: net-vpn/networkmanager-l2tp No bugs open, bumped to latest version today. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] last-rite: net-print/{apsfilter,kyocera-mita-ppds}
On 14.12.2022 22.20, Marco Scardovi wrote: > Hi everyone, > > I'm gonna propose to l-r these packages as both are dead upstream and on > our side > > # Marco Scardovi (2022-12-14) > # We are literally the only distro that still have > # an installation option for that package. > # It still uses EAPI 6 and no real support since > # years. > # Removal on 2023-01-14. Bug #885605 > net-print/kyocera-mita-ppds > > # Marco Scardovi (2022-12-14) > # Dead upstream, dead homepage, dead symlinks, > # no revdeps and no version bump since 2011 > # Removal on 2023-01-14. Bug #884307 > net-print/apsfilter > > Please see https://github.com/gentoo/gentoo/pull/28606 too. > > Best regards, Marco Scardovi (scardracs) > > This mask has been applied. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
On 13.12.2022 0.26, Piotr Karbowski wrote: > On 12/12/2022 23.06, Sam James wrote: >> It's unusual to have discussion about a single package on the mailing >> lists. I tend to keep an eye on PAM >> bugs because I maintained pambase. >> >> Bugs are the primary method of discussing changes to packages. > > You really came strong on this one. I did explain why it went to mailing > list, that very few people would notice bug on undeclared > maintainer-needed package, unlike mailing list, assigning it to zlogene > and hoping for few people to catch it up, yet you still zealously > challenge it. I see value in having both, this mailing list discussion AND a bug. It was indeed a great initiative to open the discussion here, since as you said the main maintainer is AWOL and pam is a critical package so this needs attention, but the fix should now be finished in a bug IMHO. Once you make the changing commit you can reference a bug and it'll show relevant history data for the reason. It's much harder and annoying trying to locate the "why was this ever changed?" from a mailing list, months or years after, when you can just find a commit and a linked bug. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: mozcoreconf-v5.eclass
No more consumers in tree. Removal in ~30 days unless some rdep needs returning - in which case let's not remove it all yet! -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: dev-python/influxdb
dev-python/influxdb is up for grabs. No open bugs, no available version releases, but pkgcheck reports: dev-python/influxdb DeprecatedDep: version 5.3.0-r1: BDEPEND: deprecated dependency: >=dev-python/nose-1.3.7_p2021_p1-r1[python_targets_python3_10(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?] DistutilsNonPEP517Build: version 5.3.0-r1: uses deprecated non-PEP517 build mode, please switch to DISTUTILS_USE_PEP517=... PythonCompatUpdate: version 5.3.0-r1: PYTHON_COMPAT update available: python3_11 RedirectedUrl: version 5.3.0-r1: HOMEPAGE: permanently redirected: https://github.com/influxdb/influxdb-python -> https://github.com/influxdata/influxdb-python RedirectedUrl: version 5.3.0-r1: HOMEPAGE: permanently redirected: https://github.com/influxdb/influxdb-python -> https://github.com/influxdata/influxdb-python -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: Bitrise stack
Hey, these packages are up for grabs: dev-util/bitrise dev-util/stepman dev-util/envman All of them are several versions behind (3+ years worth of updates), use old go eclasses (need to migrate to go-module) and most likely don't have all licenses listed in LICENSE field (since it's go). -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On 8.11.2022 2.23, Rich Freeman wrote: > > Of course if somebody wants to contribute to 100% FOSS tinderbox > efforts that would be even better. Perhaps if our 100% FOSS tinderbox > efforts addressed our needs very well, then nobody would want to > bother with the proprietary reports, or generating them. IMO it would > be better to create the FOSS solution before abandoning the > proprietary one. Doing otherwise is basically burning bridges - it > can be motivating in a sense but not really ideal. I'd love to have a > 100% FOSS solution around all of this, but I appreciate what has been > created and can hardly criticize volunteers for failing to make it > happen, especially since I haven't contributed to that myself. > https://gitweb.gentoo.org/proj/tinderbox-cluster.git/ https://wiki.gentoo.org/wiki/Project:Tinderbox-cluster Hopefully soon. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On 7.11.2022 8.07, Oskari Pirhonen wrote: > On Sun, Nov 06, 2022 at 11:37:24 +0100, Piotr Karbowski wrote: >> I would be in favour of stepping up the social contract and actually >> prohibiting this kind of things, we had that before too, the nattka you >> mgorny wrote is replacement for old bugzilla bot that was ... >> closedsource and perished, though nattka now have way more features than >> the old thing ever had. > > As a user, I think it would be really cool if there was a requirement > that all infra and infra-adjacent stuff was free software. > > I feel like I've read that Debian already has something like this. While > doing some quick searches I didn't find a full-on requirement, but all > their infra bits I did find were powered by free software. The most > relevant ones being buildd [1] and debci [2]. Additionally, the debci > docs has inctructions on reproducing tests yourself [3] which is a nice > extra IMO. > > [1] https://buildd.debian.org > [2] https://ci.debian.net > [3] https://ci.debian.net/doc/file.MAINTAINERS.html > > - Oskari I _believe_ ago's tinderbox isn't being paid by the GF _anymore_ due to this reason, but he keeps it running with his own expenses. I don't mind this as long as the results are desirable and not phony. I still see a lot of value in most of ago's work. It is unfortunate we don't get to see the engine behind and copy it, since I'd be really interested in using his automated bug search / report tool. Even tattoo (https://github.com/arthurzam/tattoo) lacks that at the moment. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: The Gentoo VDR Project is empty
On 6.11.2022 11.49, Martin Dummer wrote: > Hi, > > as I already have taken care about many packages from the vdr project, I > will continue to do so. > > Is there any progress on the discussion about [gentoo-project] RFC: > "Trusted contributor model"? > > Meanwhile I continue to wait for an answer on my email to > recruit...@gentoo.org from november 2019. > > Bye / Martin > > I wasn't part of recruiters back then, so if the e-mail you refer to has been unanswered, please re-send it. But I do see I've given you two replies to a mail which was sent to recruiters in november 2019 with me in cc. I'd say my replies still stands to this day. The status for "Trusted contributor model": I haven't given up, but it seems technically harder than I had anticipated. It's still something I'm pursuing on free time. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] The Gentoo VDR Project is empty
Hey all, with the only member of VDR project gone, the project is currently essentially empty. https://wiki.gentoo.org/wiki/Project:VDR Please join the project to keep it alive. We may have some help through the proxy-maint project, but someone with immediate commit access is always better. If no one joins the project, the packages (and eclass) are bound to be reassigned. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: dev-libs/jemalloc
Hey, dropped Mozilla project as jemalloc's maintainer. No Mozilla product depends on it. Looks like it's used by (web) server software mostly. No bugs open, no pending stabilizations, no version bumps available, so it's in good state right now. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-themes/e-flat-theme
This flat theme has been incorporated to upstream's enlightenment-0.25 release. With e-0.24 removed from the tree, this theme ebuild is useless. Removal in 30 days. Bug #870355 -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: media-fonts/source-pro (package split)
# Upstream split this font into separate packages: media-fonts/ # source-code-pro, source-sans, source-serif. The current non-split # version is broken. Removal in 30 days. #865103 Tree should be handled so there's no inconvenience unless the font is in your @world set. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: www-servers/lighttpd
Hey, www-servers/lighttpd is up for grabs. Looks like a version bump is pending (and offered as PR#20900). No other bugs open. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] A couple of new 'features' available on the Gentoo wiki
On 5.8.2022 6.31, Matthew Marchese wrote: > Hi all, > > Wanted to document a public service announcement for minor wiki > enhancements: > > 1. "Fund me" links are now available on the wiki developer 'profile' > boxes. You can post a free-form URL to your GitHub Sponsor, Patreon, > PayPal or another page. I know that I'm very appreciative of all the > work that people put into making my OS run amazingly, so if you do have > a method to accept donations I encourage you to post it here. :) > > 2. Project pages now include an optional link to assigned-bugs at > bugs.g.o. (closes bug 686264). Of course only works if the project has > an email address assignment on our Bugzilla. > > See the announcement on the wiki here: > > https://wiki.gentoo.org/wiki/Main_Page#20220804 > > I historically haven't written to the mailing lists much, but if this is > well received I'll try better to keep everyone in the loop on wiki > changes (as infrequent as they are!). If you see something that's > terrible, please let me know. > > Thankful for you all! > > maffblaster > > Thanks for your continuous work on wiki! It's a great resource to have. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: gui-libs/wlroots, app-text/scdoc, net-fs/sshfs and more
Hey, these packages are up for grabs: app-text/scdoc dev-libs/light gui-apps/grim gui-apps/kanshi gui-apps/slurp net-fs/sshfs www-apps/jekyll-watch gui-libs/wlroots The usual set. Some outdated, most waiting for stabilizations and cleanups, some have bugs open. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: x11-misc/urxvt-{perls,tabbedex}
Hey, these packages are up for grabs: x11-misc/urxvt-perls x11-misc/urxvt-tabbedex Just realized I don't have urxvt installed anymore anywhere (was a backup terminal for a long time). x11-misc/urxvt-perls: upstream has archived their repo, not sure if a new upstream has emerged somewhere or is it totally dead. Last commit 2020. x11-misc/urxvt-tabbedex: Just bumped to latest version. Stabilization awaits in 14-30 days. Depends on urxvt-perls. No bugs open for either. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: app-eselect/eselect-wine, gui-libs/gtk-layer-shell ...
Hey, these packages are up for grabs: app-crypt/acme-tiny dev-util/patchbin games-strategy/freeorion gui-libs/gtk-layer-shell net-libs/libcapi net-libs/libmicrodns sys-apps/duc x11-misc/primus app-eselect/eselect-wine -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
On 22.7.2022 21.32, Robin H. Johnson wrote: > > BUT, we can't write a simple gitolite ACL that limits the content within > profiles/package.mask or other files in profiles/ (we can write hooks > that might be able to do this, but that still requires the challenge of > validation inside the file). > > I'd EXPECT a contributor to WANT to package.mask a cutting edge version > so it has time to bake and get well-tested, but if they can't do both > parts of the commit themselves, this process is likely problematic. Well as I said I think the best way is to fall back to the current way of a dev merging it, via Github PR or other means. I'd say pushing these experimental packages is rather rare (for proxied people at least), and can also be added without KEYWORDS for example. > > How do we make the mentorship process more lightweight? > (and possibly the quiz process, I haven't seen how the quiz has changed > since I last mentored) > > Let's start with a potential intersection of your two ideas: > (these numbers are arbitrary, but try to reflect what I see some of the > trusted contributors doing) > - 9 good submissions (patches or PRs) over a 3 month period [must be at least > 3/month] > - will get you an invite from recruiters to join > - either without a mentor, or a lightweight mentor > This is a bit complicated topic and I'm not sure if I'm the best one to answer the mentoring part. But I'd like to point out this kind of teaching and/or "lighweight mentoring" happen everyday in #gentoo-dev-help, #gentoo-proxy-maint and in related IRC channels, and in Github PRs... just that it's done by multiple different people in different places. So many people add a little bit to one's growth instead of one/two people adding a lot, making weaker bonds with contributors. Then again I would say the entry bar is very high right now, which in return gives us high quality developers, but maybe less people are even interested in attempting it. With these propositions I guess we can focus less on the quiz, and more on the existing positive contributions and interactions when considering someone. So to help "lightweight mentoring": Grant some person you've been proxying commit access, follow their commits and their bugzilla activity, and after some time if you get good vibes from the person, encourage them to widen their contribution areas. If they manage it after a while, they have most likely accumulated enough experience and knowledge to get recruited. If you tell people to attempt the quiz after seeing 10 commits from them, and after they've been around for a month, it's most likely going to end up being a very long road for everyone involved. Please don't try to rush and force the quiz - if GOOD verbose answers come naturally, the person is most likely ready. As I was trying to present in the original post, this way of recruiting would be for someone who's been around for a long time already (+year) and has been actively contributing and participating in the community, keeping up with Gentoo's development changes. It's not for someone trying to rush their recruitment. So in your example, I _doubt_ we'd take the initiative. But then again, it's really about people who impress us and make us say "why hasn't this person been recruited already?" - there are no metrics we should even try to list here. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
On 22.7.2022 21.18, Matt Turner wrote: > > How would you suggest we track who has commit access, etc? The same > way we do with developers, via a developer bug? > > 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. > We can see them in gitolite's configuration. For example I can already see who has guru commit access (to which branch even) or to infra-hosted personal overlays. But I don't expect this list to grow very large, at least currently. A tracker bug wouldn't hurt either, if we can enforce it as part of the process early on (it can even be visible to infra-only or something) I must admit I haven't looked into actually implementing this in the main tree but I'm pretty sure our gitolite has to be included, which itself would solve this. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] devmanual as pdf ?
On 22.7.2022 16.48, k...@aspodata.se wrote: > Since the ip connection here isn't too good, is there some way I > can download the devmanual, perhaps as a pdf ? > > https://devmanual.gentoo.org/ > > Regards, > /Karl Hammar > > > emerge =app-doc/devmanual- with "+offline" USE flag, then $BROWSER file:///usr/share/doc/devmanual-/html (or clone the devmanual git development repo on your own and run "make" inside the cloned repo to generate .html pages) -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] RFC: "Trusted contributor model"
Cross-posting to gentoo-dev and -project lists due to technical and non-technical nature. Reply-to is set to -project. Once again new council has been elected: congratulations to the chosen members! And once again many nominees expressed their wishes to see more non-developer contributors to become official developers. Yet, only very few people (if any) are interested in mentoring them. I get it, the relationship between a mentor and their mentee is very intimate, and mentoring takes a lot of time. While the Github PRs are helping us increase the user contributions merged, perhaps it's distancing us from creating stronger bonds with the contributors? But more about this topic later. 1st RFC: "Trusted contributor model" I'm proposing us to giving special commit access to our well-reputable contributors (mostly proxied maintainers). They'd have access _only_ to their maintained package in git-tree. To understand what I mean, check git shortlog -s -n net-im/telegram-desktop-bin/ git shortlog -s -n net-im/signal-desktop-bin/ There are few packages like these where I'd already trust the core proxied maintainer to commit at their will. It's as ajak said during the council election; _We_ are the bottleneck currently reviewing and _testing_ contributions, and with these two examples above, 99 % of time everything's in condition and we just need to merge. Obviously if these trusted contributors had to touch another package, or anything in profiles/ (just basically anything outside their dedicated package directory) they'd have to do a PR or .patch file to be merged by official developers. And they'd still need a proxy Gentoo developer/project listed in metadata, at least for now, to take responsibility. On the technical side I'm not sure how to achieve this, but I know it can be done. For example the sync-repos are compiled like this all the time. If this proposal gains support, I'm willing to start figuring it out more in-depth. AFAIK Fedora and Arch have somewhat similar systems in place already. 2nd RFC: Recruiting proven contributors without a mentor I'm aware recruiters don't really need to ask a permission here, but I believe it's great to gauge the general feelings about this beforehand. What would you say if recruiters started more actively approaching potential developers? And currently I'm talking about people who have been active for a very long time (+year or two), who keep up with development-wise changes in Gentoo (eclasses, EAPI, virtuals...), participate in the community, and always provide top-quality contributions, but for some reason never got a mentor? I'd like to point out that this method would only be for the very few ones and recruiting through mentoring would still be the desired method. Recruiting through recruiters would still require the candidate to fill the ebuild/developer quiz, and they'd have to pass it without a mentor. So I'll emphasize: Currently only few special ones would qualify. But seeing the general lack of interest towards mentoring, maybe this is something we _need_ to do in near future. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 16.7.2022 14.24, Florian Schmaus wrote: > > That reads as if you wrote it under the assumption that we can only > either use dependency tarballs or use EGO_SUM. At the same time, I have > not seen an argument why we can not simply do *both*. > > EGO_SUM has numerous advantages over dependency tarballs, but can not be > used if the size of the EGO_SUM value crosses a threshold. So why not > mandate dependency tarballs if a point is crossed and otherwise allow > EGO_SUM? That way, we could have the best of both worlds. > > - Flow > ++ this sounds most sensible. This is also how I've understood your proposal. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] proposal
On 7/6/22 18:04, Fabian Groffen wrote: > - please do not needlessly change style: if you do not "maintain" the > ebuild, respect the style of the maintainer, so only add the changes > you need, keep it minimal, respect the original even though you don't > like it (and don't use QA as an excuse to change style) QA actually states to honor the maintainer's style as much as possible, https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html "Respect developers' coding preferences. Unnecessarily changing the syntax of an ebuild can cause complications for others. Syntax changes should only be done if there is a real benefit, such as faster compilation, improved information for the end user, or compliance with Gentoo policies. " Of course there are some "strict" rules, but very much is left to the maintainer. https://projects.gentoo.org/qa/policy-guide/ebuild-format.html#pg0101 > - when you make a change, make sure you check for bugs in the following > days, so you can cleanup yourself should there be fallout > ago does a good job CCing the commit author too in his bug reports, if the person is not the maintainer. This only applies to tinderbox bugs though. Obviously you should manually CC the author if you see the bug coming from their commit. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more
Packages up for grabs: acct-group/crontab acct-group/gkrellmd acct-group/icecast acct-group/lightdm acct-group/msmtpd acct-group/murmur acct-group/nsd acct-group/pdnsd acct-group/roccat acct-group/uptimed acct-group/vboxguest acct-group/vboxsf acct-group/vboxusers acct-user/gkrellmd acct-user/icecast acct-user/lightdm acct-user/murmur acct-user/nsd acct-user/pdnsd acct-user/uptimed acct-user/vboxguest app-admin/gkrellm app-admin/keepassxc app-admin/whowatch app-arch/pbzip2 app-crypt/gpa app-editors/nano app-editors/notepadqq app-emulation/virtualbox app-emulation/virtualbox-additions app-emulation/virtualbox-extpack-oracle app-emulation/virtualbox-guest-additions app-emulation/virtualbox-modules app-misc/uptimed app-shells/rush app-shells/zsh app-text/convmv app-text/ding dev-libs/apr dev-libs/apr-util dev-libs/libassuan dev-libs/libbytesize dev-libs/libgaminggear dev-libs/libgnt dev-libs/libgpg-error dev-libs/libksba dev-libs/libp11 dev-libs/libxmlb dev-libs/volume_key dev-python/pocketlint dev-util/geany dev-util/kbuild games-emulation/mgba games-engines/devilutionx mail-client/claws-mail mail-client/clawsker mail-mta/msmtp media-libs/libxmp media-libs/sdl_audiolib media-plugins/hdx-realtime-media-engine media-sound/bluez-alsa media-sound/mumble media-sound/murmur media-sound/pamix media-sound/umurmur media-video/simplescreenrecorder net-dns/nsd net-dns/pdnsd net-ftp/lftp net-ftp/pure-ftpd net-im/pidgin net-irc/hexchat net-libs/gsoap net-libs/libetpan net-libs/libpsl net-libs/nghttp2 net-mail/ytnef net-misc/htpdate net-misc/icaclient net-misc/icecast net-misc/putty net-misc/wget2 sys-apps/fwupd sys-apps/fwupd-efi sys-apps/gptfdisk sys-apps/lm-sensors sys-apps/netplug sys-apps/roccat-tools sys-auth/pam_p11 sys-fs/android-file-transfer-linux sys-fs/ddrescue sys-fs/inotify-tools sys-fs/jfsutils sys-libs/libblockdev sys-libs/libsmbios sys-libs/liburing sys-process/cronie sys-process/htop sys-process/schedtool www-apache/mod_gnutls x11-apps/radeon-profile x11-apps/radeon-profile-daemon x11-drivers/xf86-video-vboxvideo x11-misc/lightdm x11-misc/lightdm-gtk-greeter x11-plugins/pidgin-otr x11-themes/claws-mail-themes x11-themes/icewm-extra-themes x11-wm/icewm pkgcheck reports tons of python compat updates (even for 3.10), stable requests, old EAPIs and all kinds of small issues. There's a lot of cleaning up to do in general. Overall nearly 400 bugs has been reassigned. The biggest bug swarms were - virtualbox stack, - mumble/murmur stack, - lightdm stack, - fwupd, - claws-mail, - pidgin. for anyone interested in these packages. In addition some value packages, like media-libs/freetype and media-libs/harfbuzz, could use an update to their maintainer status. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...
Full list: acct-group/collectd acct-group/fritzbox_smarthome_exporter acct-group/mysqld_exporter acct-group/nginx acct-group/sabnzbd acct-user/collectd acct-user/fritzbox_smarthome_exporter acct-user/mysqld_exporter acct-user/nginx acct-user/sabnzbd app-admin/cli53 app-admin/rsyslog app-arch/rar app-backup/tarsnap app-metrics/collectd app-metrics/fritzbox_smarthome_exporter app-metrics/mysqld_exporter app-portage/elicense app-portage/golop app-text/vgrep dev-libs/libee dev-libs/libestr dev-libs/libfastjson dev-libs/liblognorm dev-libs/librdkafka dev-libs/librelp dev-python/PyRSS2Gen dev-python/sabyenc dev-python/ws4py net-irc/znc-clientbuffer net-irc/znc-igloo-push net-irc/znc-playback net-libs/liboping net-libs/zeromq net-misc/httpstat net-nntp/sabnzbd sys-apps/hponcfg sys-block/f3 sys-block/hpacucli sys-block/hpssacli sys-block/storcli sys-fs/ncdu sys-libs/libfaketime sys-process/incron www-apps/nextcloud-notify_push www-apps/nikola www-servers/nginx The usual stuff. Outdated packages, open pull requests, bugs, security bugs. Lots of pkgcheck issues too, so fix those if interested in taking over some of these while at it. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Introduce a pandoc virtual
On 3.6.2022 17.45, Maciej Barć wrote: > Hello! > > I'd like to introduce "pandoc" virtual package depending on pandoc-bin > or pandoc. > > Pandoc is a very helpful tool for converting between document formats, > most commonly used to build a project documentation, but it depends on > many Haskell libraries, and I believe not many users will want to > install full pandoc to build given project's documentation. > > Using the following command: "grep -R 'app-text/pandoc' > --exclude-dir=.git --exclude-dir=metadata --exclude-dir=profiles | cut > -d':' -f 1 | cut -d'/' -f 1-2 | sort | uniq" we can diagnose that > following pkgs could benefit from it: > app-emacs/auto-complete > app-emacs/markdown-mode > app-emulation/xen-tools > app-text/nuspell > dev-haskell/hakyll > dev-haskell/pandoc-citeproc > dev-lang/lfe > dev-libs/pmdk > dev-python/ipython > dev-python/nbconvert > dev-python/pandas > media-sound/bluez-alsa > media-sound/pms > net-misc/mptcpd > sci-mathematics/rkward > sci-mathematics/rstudio > sys-apps/earlyoom > sys-apps/exa > sys-apps/ripgrep-all > www-apps/gitit > www-apps/hugo > x11-wm/xpra > > Attached a initial patch. > > Thoughts? > First time I hear about pandoc-bin. Great idea indeed now that the package exists! But you'll have to match KEYWORDS for both options first. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Announcing the Gentoo/LoongArch project
On 18.4.2022 7.47, WANG Xuerui wrote: > Of course I forgot to mention the devbox situation... The single box I > currently use is placed in my company, so I probably wouldn't be able to > share it. I have ordered another board though, so I'll be able to > provision it as a devbox after receiving it, and reworking of my home > network to provide for enough isolation. I'd post another progress > update when that happens. :) > Out of curiosity, what's the price on these things? Will they ever find their way to hobbyists? TIA. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Security Bug Assignment Change
On 15.4.2022 4.38, John Helmert III wrote: > Hi all! Currently all security bugs are assigned to security@g.o, > always. This can easily lead to some confusion about who needs to do > something about a given bug; right now this is generally tracked by > whiteboard magic strings that probably not many people outside of the > Security Project understand [1] and this has been a source of > confusion around security bugs for a long time. Is there a specific group that has this problem? E.g. inactive developers, proxied maintainers, (dead) projects? Like is this actually a wide-spread problem? > > To make it abundantly clear who needs to take action for a given bug, > I propose we move away from the dogma of security@ always being > assigned to security bugs, and instead assign bugs to whoever needs to > take action for the bug. For example, on security bugs that need a > package bumped or cleaned up, the package maintainer would be > assigned. For bugs needing a GLSA, security@ would be assigned. > > As a nice side effect, this would be a step towards making security > bug state discernable outside of the human-maintained and oft-stale > whiteboard. In the long term, a maintainer's security bugs could be > more easily tracked via things like packages.g.o. p.g.o already has a "security" tab for maintainers, but the bug listing is pretty ineffective already as-is. > > As far as bug handling goes, I see two obvious (though rathor minor) > sticky points: > > - Who do we assign bugs to when a bug is in stabilization > state? The stabilization bug will always be assigned to the > maintainer, but the security bug will be neither actionable by the > maintainer nor security@ until the stabilization is finished. > > - Rarely, we have a security bug that affects multiple packages with > different maintainers (e.g. a package and its -bin variant). Under > this scheme, we would have to always separate bugs by package > maintainer. > > I'm not proposing any change to the Bugzilla product or component, so > security bugs will still be able to be exhaustively enumerated this > way, but any tooling that relies on security bugs always being > assigned to security@ would have to be changed. > > What do you all think? > > [1] > https://www.gentoo.org/support/security/vulnerability-treatment-policy.html > "Severity Level" section I don't mind either way as long as it's really fixing a problem. Just got familiar with the new workflow after most recent change... Anyway hope things have gotten better since sending this e-mail, but I fear (assume) people who had these problems aren't actively reading the mailing list either. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] [committed] edo.eclass: update eclassdoc to clarify purpose
On 18.4.2022 20.59, Sam James wrote:
> Signed-off-by: Sam James
> ---
> eclass/edo.eclass | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/edo.eclass b/eclass/edo.eclass
> index 550d6770cb63..c2e7ed60083f 100644
> --- a/eclass/edo.eclass
> +++ b/eclass/edo.eclass
> @@ -10,9 +10,12 @@
> # @BLURB: Convenience function to run commands verbosely and die on failure
> # @DESCRIPTION:
> # This eclass provides the 'edo' command, and an 'edob' variant for
> ebegin/eend,
> -# which dies (exits) on failure and logs the command used verbosely.
> +# which logs the command used verbosely and dies (exits) on failure.
> #
> -
> +# This eclass should be used only where needed to give a more verbose log,
> e.g.
> +# for invoking non-standard ./configure scripts, or building objects/binaries
> +# directly within ebuilds via compiler invocations. It is NOT to be used
> +# in place of generic 'command || die' where verbosity is unnecessary.
> case ${EAPI} in
> 7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
Thanks for this clarification, had me wondering.
-- juippis
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Projects Alsa & VOIP are without members
Hey, with the retirement of chainsaw, projects ALSA and VoIP are left memberless. It looks like VoIPs' packages are assigned long time ago, so the project will most likely just be disbanded. But ALSA is still maintaining packages in the tree. https://packages.gentoo.org/maintainer/alsa-b...@gentoo.org If you feel like, please join the ALSA project. https://wiki.gentoo.org/wiki/Project:ALSA Otherwise the packages will be re-assigned to maintainer-needed in ~30 days. Also as a sidenote, sound@g.o lost their lead. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
Hey, these packages are ups for grabs after a retirement of a proxied maintainer. app-admin/prelude-manager dev-libs/libprelude dev-libs/libpreludedb net-analyzer/prelude-correlator net-analyzer/prelude-lml net-analyzer/prelude-lml-rules www-apps/prewikka pkgcheck reports: app-admin/prelude-manager StaticSrcUri: version 5.1.0-r1: '5.1.0' in SRC_URI StaticSrcUri: version 5.2.0-r1: '5.2.0' in SRC_URI These *prelude* packages have tons of bugs open, and prewikka one too. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Add debug-print-function calls to Ruby eclasses
On 14.2.2022 19.37, Anna Vyalkova wrote:
> These functions write to ${T}/eclass-debug.log, which is useful for
> testing ebuilds.
>
>
>
Acked by graaff and merged yesterday after some testing. Thanks!
As a sidenote, these ruby eclasses received 5 commits yesterday so if
something breaks now it's not hard to figure what's related. But I
emerged around ~200-300 ruby packages and everything passed.
-- juippis
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecating repoman
On 9.3.2022 23.00, Matt Turner wrote: > I'd like to deprecate and ultimately remove repoman. I believe that > dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts) > are far superior replacements, and it makes sense to have people using > the same tool and seeing the same warnings as in the CI. > > Are there any useful checks or behaviors of repoman that are missing > from pkgcheck and pkgcommit? > > Thanks, > Matt > I still fail to see the "why" in here. Repoman is better than pure 'git commit' that I know some people still like to use, and as long as it's kept maintained. We should be teaching people about the alternatives, and let them choose whatever they like more. https://wiki.gentoo.org/wiki/Package_maintainer%27s_responsibilities#Ebuilds_and_git_workflow Repoman is a very lightweight tool. All that being said, I can't think of a single feature that pkgdev+pkgcheck don't cover when switching from repoman. The quick global CI checks after each commit saves us from a lot of trouble. If you do bad commits, you get immediately noticed about it and you can fix it rather quickly usually. When you "get hit", you also learn about pkgcheck and we've seen that this is the point when people usually integrate it to their workflows. I'd also like to point out whenever doing more complicated pushs, one can trigger the automatic CI check in our Github mirror via a pull request before pushing. My only worry is: are pkgcheck and pkgdev _really_ maintained anymore? More than repoman is? -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
On 4.3.2022 2.35, Ionen Wolkens wrote: > On Tue, Oct 05, 2021 at 02:21:22PM -0700, Alec Warner wrote: >> I'd argue we can add NOTES.md to packages (e.g. allow those files.) >> Then we modify packages.gentoo.org to render the markdown; or users >> can render locally or read unrendered. >> >> WDYT? > > Given this topic came up again on IRC, late reply to say that some > kind NOTES of file in the tree is my preference over metadata.xml > at the moment. > > I don't feel strongly about being rendered somewhere though, a dev > will see the file in the tree if they work on the package (partly > because of that I'd also rather rst over md for bit better plain-text > readability, but can work with either). Seeing the file is main reason > I prefer this over metadata.xml, making it clear there's notes without > needing any tools integration to parse metadata.xml and remind about. > > fwiw given these are entirely for devs they could even be skipped > from sync mirrors so users don't get them and think it's something > they need to read (+less files), but no strong opinion here. > make.conf: FEATURES="bumpnotes" or make.conf: BUMPNOTES=y then .ebuild: BUMPNOTES=1 or has_version sys-apps/portage[gentoo-dev] results in: "QA notice: This package has internal version bump notes. Please see..." and do those notes get saved to metadata.xml? Because I doubt people will get to the habit of checking metadata.xml manually for each bump. But we all test the packages we merge ":^)" and therefore would see this QA notice. Or ewarn. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo LLVM project needs help!
On 11.2.2022 1.36, Michał Górny wrote: > Hi, > > As you may have noticed, I'm practically maintaining LLVM all by myself. > This is a really tedious, time consuming and ungrateful task, and I'm > pretty close to burnout. I'd really appreciate some help. > > The problem with LLVM that it's a really huge, rapidly moving forward > (and breaking things) project. It needs frequent testing as regressions > happen frequently, and we have a good chance of having somebody else fix > it if we report them early. At the same time, testing takes a lot of > time. While ccache is pretty much a must, it doesn't help much long > term as the code is changing frequently and invalidating the cache. > > On top of this, there's almost-overlapping release process and Gentoo > slotting that's working so-so at best. After I've pushed LLVM 13.0.1 > final, I've had to immediately start testing 14.x and barely managed to > get some fixes in before rc1. Now 14.0.0 is expected soon, > simultaneously major changes are happening on the main branch > (i.e. 15.x) that also need testing and adjusting the ebuilds to. Would it help at all to not always support different _rc's and .s? Or would that just bite "us" (as in Gentoo) back with a delay? > > 6. Work on setting up and configuring a buildbot for Gentoo LLVM builds. > This is some effort and I don't have the time to learn how to do that. > You'll probably need to set up a local instance and figure out how to > set our builds before submitting anything upstream; in my experience > they aren't very responsive to buildbot changes, so ideally we need to > flesh out any problems early. GSOC-worthy project? > > Yes, that's a lot of work. I can't do it all myself, I'm already doing > too much and this is having negative impact on my health. I really need > help with this. > I wonder if llvm and toolchain projects should join - not that there's probably anyone in toolchain interested/capable of doing llvm/clang currently. But they'd be the next with knowledge for at least simplest version bumps if you lay back a bit. Remember this is just a hobby - even though your work is very much appreciated, not worth of wearing yourself out over. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: app-dicts/verbiste
Hey, app-dicts/verbiste is available due to retirement of its maintainer. Has currently 3 bugs open. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Unmask >=net-p2p/bitcoin*-0.21.1
On 29.1.2022 19.51, Florian Schmaus wrote: > On 25/01/2022 07.49, Joonas Niilola wrote: >> On 24.1.2022 20.37, Florian Schmaus wrote: > > Hi Joonas, > >>> I think it is time to unmask the currently masked Bitcoin versions. The >>> mask was added in Juli of 2021 [1], with the mask's commit message >>> indicating that unmasking is planned for November 2021. >>> >>> I doubt that the mask was ever needed in the first place, as it was >>> intended to prevent automated updates of Bitcoin in Gentoo. However, >>> Gentoo has no unattended upgrade mechanism. Instead, the user explicitly >>> triggers all updates. >>> >>> As this has already caused a little bit of friction, I'd like to get a >>> feeling of the community's view on that. >>> >>> - Flow >>> >>> 1: >>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d0bbc4dcc33927cbf0ca27a054c430f6866ed72e >>> >>> >>> >> >> Publishing a news item 2-4 weeks prior wouldn't cost much for us, I feel >> like just to make sure it'd be the right thing to do. > > I am skeptical that a news item would be the right thing to do > > First, I doubt that the package mask was needed, as I already wrote. > Hence unmasking the package is nothing that the users need to be > notified about. > > Secondly, we never did a news item for Bitcoin in the past, even on > consensus changes. So I want to prevent creating a precedent that puts > us in a position where people expect us to do one for every Bitcoin > protocol consensus change. > > Finally, the news item would state the obvious: Newer software versions > may include changes that you, as a user, may want to review before > upgrading. > > That said, I wouldn't object if someone published one. Please let me > know if you plan to publish one. Otherwise, I would unmask Bitcoin in > one week since no fundamental objections have been raised so far. > > - Flow > > > > Maybe I'm overthinking it due to all the attention bitcoin has received lately in Gentoo. But yeah, we haven't received any comments or bugs about the mask so I guess it's fine to remove it finally. I still kind of do think a news item wouldn't be the "wrong thing to do" either, but don't wish to prolong this process any further. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: app-admin/cdist, app-admin/integrit & sys-fs/genfstab
See topic. No bugs open. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Unmask >=net-p2p/bitcoin*-0.21.1
On 24.1.2022 20.37, Florian Schmaus wrote: > I think it is time to unmask the currently masked Bitcoin versions. The > mask was added in Juli of 2021 [1], with the mask's commit message > indicating that unmasking is planned for November 2021. > > I doubt that the mask was ever needed in the first place, as it was > intended to prevent automated updates of Bitcoin in Gentoo. However, > Gentoo has no unattended upgrade mechanism. Instead, the user explicitly > triggers all updates. > > As this has already caused a little bit of friction, I'd like to get a > feeling of the community's view on that. > > - Flow > > 1: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d0bbc4dcc33927cbf0ca27a054c430f6866ed72e > > Publishing a news item 2-4 weeks prior wouldn't cost much for us, I feel like just to make sure it'd be the right thing to do. (that only gets printed for people with bitcoin* installed) -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: www-client/seamonkey & net-misc/npapi-sdk
Hey, # Seamonkey Seamonkey is currently being neglected in Gentoo as no one in the mozilla project care or has time for it. The currently packaged versions won't build with newer non-vulnerable rust, and therefore seamonkey is currently blocking a (security) cleanup for rust. It needs a dedicated maintainer for ::gentoo (or someone interested to join the mozilla project), and if no one steps up, it will be cleaned along with rust's security cleanup. Bug #824066 # npapi-sdk This package has served its purpose and none of the available browsers support or depend on it anymore. Its upstream is also long gone. Removal in ~30 days. Bug #831819 -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On 20.1.2022 23.32, Brian Evans wrote: > > GNOME and Mozilla products still pull in spidermonkey but other users > will have a much reduced requirement for rust. > While Firefox and Thunderbird contain a js engine, no mozilla product depends externally on spidermonkey. I was wondering recently why mozilla project maintains it and not Gnome or Freedesktop, but I guess it's because of the similarities shared by the ebuilds between firefox, thunderbird and spidermonkey. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On 18.1.2022 4.58, Ionen Wolkens wrote:
>
> Unsure what I like best, I generally agree should default to sources
> but I do see new users complaining about building rust every few days.
> Not that the step of telling them that rust-bin exists is that bad
> (part of the issue is that they don't know it's an option).
>
Indeed, can see both ways. On my desktop I use rust, and on my
laptop+containers rust-bin. Having to package.mask rust so rust-bin gets
pulled might not be the first thing new users are aware.
To make things more complicated...
IUSE="+binary"
RDEPEND="binary? ( ~dev-lang/rust-bin-${PV} )
!binary? ( ~dev-lang/rust-${PV} )"
or "+pre-compiled" or something ;)
-- juippis
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Mailing list for ebuild patches? (Was: Re: [PATCH] media-libs/freetype: fix GCC usage during configure)
On 8.1.2022 7.12, Sam James wrote: > > FWIW, normally we don't post individual package patches > to this ML, but it's a good question as to.. where they should go > if people want to use git send-email/a ML workflow. > > Right now, sometimes people send them to gentoo-proxy-maint > (the list) which the proxy maintainers team that handles > most user contributions looks at, but I'll be honest and say > our workflow isn't really optimised for it given it's used > pretty infrequently. > > Makes me wonder if we should rename the list > or have a separate one (gentoo-patches?). > > (Or just use that list and make sure people CC > maintainers as you did here?) > > Best, > sam I don't think setting up a new mailing list purely for patches will benefit much. It all comes down to who's gonna merge the contributions, and Github/bugzilla are definitely easier in that regard. I suggest opening a bug like normally, and then sending the .patch to the maintainers directly via e-mail with bug #nr linked either in Subject or git message body. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: media-sound/clementine
On 18.12.2021 12.02, Alexey Sokolov wrote: > > Lars, can you merge https://github.com/gentoo/gentoo/pull/23209 ? > Done, please take of the bugs. Especially the security bug. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 0/3] Version 2
On 13.12.2021 23.12, Jonas Licht wrote: > So nearly ten months have now gone by. > Is there any thing I can do to push this changes to get merged? > > Best regards, > Jonas Unfortunately I don't think anyone other than the current nginx maintainer is brave enough to get involved. For an outsider there's a lot of reading, understanding and _testing_ to do. Haven't checked the related bugs as to an explanation why it hasn't been merged yet, but since I use nginx personally I might be interested in landing this support. The concept at least looks awesome on paper. (Still, realistically I can probably "get to this" in January 2022). Meanwhile, maybe you could update the eclass to support EAPI-8? :) https://github.com/gentoo/gentoo/pull/16053 here's the PR if someone wants to comment, minor enhances etc. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proxy maintainer ritired
On 15.12.2021 15.18, geaaru wrote: > Hi guys, > > i'm sorry but i haven't sufficient time to support and follow the > package net-dialup/freeradius and the others packages maintained by me. > > I hope that someone could take care of them. > > Best Regards, > -- geaaru Thanks for your work! You're of course free to contribute to maintainer-needed packages too without having to become the maintainer. That being said, I've dropped the following packages to maintainer-needed: acct-group/radius acct-user/radius dev-db/cpp-driver net-dialup/freeradius dev-db/cpp-driver and net-dialup/freeradius have tons of bugs open, lagging stable, missing cleanup and python compat updates. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-fs/docker-volume-netshare
# Outdated, we are the only one who still have a package for it. # Docker can mount these NFS, AWS EFS, Ceph & Samba/CIFS volumes # by itself now. Removal in 30 days. Bug #829068 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCHv3] 2021-11-23-mariadb-database-restore-maybe-required: add item
On 25.11.2021 22.54, Thomas Deutschmann wrote: > Bug: https://bugs.gentoo.org/825234 > Signed-off-by: Thomas Deutschmann > --- > ...adb-database-restore-maybe-required.en.txt | 45 +++ > 1 file changed, 45 insertions(+) > create mode 100644 > 2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt > > diff --git > a/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt > > b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt > new file mode 100644 > index 000..c977ae7 > --- /dev/null > +++ > b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt > @@ -0,0 +1,45 @@ > +Title: Full MariaDB database restore maybe required > +Author: Thomas Deutschmann > +Posted: 2021-11-23 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Installed: dev-db/mariadb > +Display-If-Installed: sys-cluster/galera > + > +On 2021-11-21, keywords for dev-db/mariadb:10.6 were removed to > +address a file collision with dev-db/mariadb-connector-c. This > +unintentionally triggered a version downgrade for users who had > +successfully upgraded to dev-db/mariadb:10.6 already. [Link 1]. I'd add: "successfully upgraded to dev-db/mariadb:10.6 already during a short time period. [Link 1]." to make it clearer this doesn't concern absolutely everyone. v3 LGTM regardless of that addition. More comments, more acks to get this merged even possibly tonight (UTC)? Anyone from PR? -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] profiles: mask sys-fs/eudev for removal
On 25.11.2021 16.15, Thomas Deutschmann wrote: > Hi, > > why do you want to drop the package? Since news item, upstream changed. > There will be a new release soon. Was this just on your list to finish > or is there another reason? > > I am currently watching upstream and would wait to see if they really do > the release and keep up with the promise. We can still last-rite next > quarter, not? > > ++ I'd also like to see what comes out with new upstream. Regarding maintainership, AFAIK one person who's involved in the new upstream is also interested in maintaining this in Gentoo. But this is just based on my current assumption. (any non @gentoo.org addresses are still welcome to post in this ML after subscribing - at least for now) -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
On 25.11.2021 15.37, Thomas Deutschmann wrote: > For the records: For the records: This post could've been an attempt to get it merged faster. But no, you chose to prolong it even further. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] 2021 retrospective
On 20.11.2021 0.32, Andreas K. Huettel wrote: > Hey all, > > in the spirit of our "2020 in retrospect & happy new year 2021!" front page > article, > > https://www.gentoo.org/news/2021/01/15/new-year.html > > which was rather well received, I'd already like to start collecting news > from 2021! > > Suggestions, text snippets, illustrations welcome- either as a reply here > on-list, or > directly to me. > > Cheers, > Andreas > Cross-posting to -project. OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Aisha's packages up for grabs
Hey, the following are up for grabs: acct-group/greetd acct-user/greetd app-emulation/virtio-win app-shells/loksh dev-lang/zig dev-libs/aml dev-libs/libucl dev-python/python-evdev gui-apps/gtkgreet gui-apps/lavalauncher gui-apps/tuigreet gui-apps/wayland-logout gui-apps/waypipe gui-apps/wayvnc gui-apps/wcm gui-apps/wf-shell gui-libs/greetd gui-libs/neatvnc gui-libs/wayfire-plugins-extra gui-libs/wf-config gui-wm/hikari gui-wm/wayfire mail-client/mutt-wizard media-fonts/fontawesome media-fonts/iosevka media-fonts/joypixels x11-misc/dunst x11-themes/chameleon-xcursors x11-themes/echo-icon-theme x11-themes/faenza-icon-theme x11-themes/gargantuan-icon-theme x11-themes/nou-icon-theme x11-themes/numix-icon-theme x11-themes/numix-icon-theme-circle x11-themes/nuovo-icon-theme x11-themes/yasis-icon-theme x11-wm/cwm The wayland-related packages have some bugs open, but mostly it's just adding python-3.10 compatibility and doing stable requests. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
On 11.11.2021 13.34, Florian Schmaus wrote: > On 11/11/2021 11.59, Ulrich Mueller wrote: >> We could: >> >> - Open some part of the range between 500 and 1000. For example, >> 500..799, which would leave 200 IDs for dynamic allocation. > > +1, since I am not aware of any significant downsides doing so. > > Could you elaborate why the range 500-799 only leaves us with 200 IDs? > > - Flow > > Read it like this: Only 800-999 gets freed with this suggestion, as 500...999 is currently reserved for dynamic allocation. And >1000 is also reserved. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] 2021-10-27-upgrade-to-net-news_rssguard-4_0: add news item
On 27.10.2021 18.19, John Helmert III wrote: > On Wed, Oct 27, 2021 at 10:53:10AM +0500, Anna Vyalkova wrote: >> Signed-off-by: Anna Vyalkova >> --- >> Related to this version bump and unmask: >> https://archives.gentoo.org/gentoo-proxy-maint/message/d86352b4ebad8c4ddd14fcd8ce37162f >> >> ...27-upgrade-to-net-news_rssguard-4_0.en.txt | 29 +++ >> 1 file changed, 29 insertions(+) >> create mode 100644 >> 2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt >> >> diff --git >> a/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt >> >> b/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt >> new file mode 100644 >> index 000..35971f0 >> --- /dev/null >> +++ >> b/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt >> @@ -0,0 +1,29 @@ >> +Title: net-news/rssguard-4.0 upgrade >> +Author: Anna Vyalkova >> +Posted: 2021-10-27 >> +Revision: 1 >> +News-Item-Format: 2.0 >> +Display-If-Installed: > Why the version restriction? Seems unecessary to me, especially for > anyone who might completely miss the mask who could upgrade straight > to >=rssguard-4.0 due to when they sync. > (can't speak for the original author, but) I on the other hand liked it more this way. Since >=4.0 has been available for quite some time already (package.masked), people might've done the upgrade with the info available in pkg_postinst(). And then again this news item seems useless if you never had <4.0 installed anyway. You should receive a notification about this news item after you sync, before you world-update. I do prefer it like this, seems a bit clearer, but no strong opinions either way... -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] hd_brummy's & nerdboy's packages up for grabs
Hey, due to inactivity these packages have been reassigned: hd_brummy: dev-libs/tntnet www-misc/xxv - EAPI-5 & other ebuild quality standards Note that the Gentoo VDR Project is basically inactive as well. https://packages.gentoo.org/maintainer/v...@gentoo.org nerdboy: app-misc/vit dev-python/pdfrw dev-python/smartypants dev-util/ media-gfx/svg2rlg sci-libs/eccodes sci-libs/libbufr - EAPI-5 and stuff -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] app-misc/physlock: Upstream repo archived
On 15.10.2021 9.33, Oskari Pirhonen wrote: > Hi, > > I sent a pull request to upstream earlier this year to fix a PAM related > issue (see also: Gentoo bug #774729), but the repo has since been > archived [1]. Looking at the commit history, I see that there's only > been a single upstream commit since the beginning of 2020. > > What is the proper procedure, if there is one, to reclaim a package with > a dead upstream? I use physlock on all my machines and have recommended > it to my friends as a solid screen locker and would very much like to > help keep it alive. > > I would be willing to maintain a fork [2] as well as help maintain the > Gentoo package itself. I've already got a little bit of experience in > working with Portage by creating packages into my overlay [3]. > > [1]: https://github.com/muennich/physlock > [2]: https://github.com/xxc3nsoredxx/physlock > [3]: https://github.com/xxc3nsoredxx/unc3nsored > > I've CC'ed the current proxy maintainer for app-misc/physlock as well as > the main upstream developer in case they have any input. > > - Oskari > Hey, so far it seems there's just a single commits difference. I think for now we can just apply the patch you provided into our current ebuild file, https://gitweb.gentoo.org/repo/gentoo.git/tree/app-misc/physlock/physlock-13-r1.ebuild If you'd like we'd prefer a GitHub pull request where you modify the ebuild adding this patch, and revbump the ebuild to -r2. We should only switch upstreams if there's some clear development done in a fork - are you aware of any other forks existing, with active development happening? Since I saw the original upstream had some issues open before the project was archived. You should collaborate all efforts into one fork. Let me know if you need help with these tasks, or pop by in #gentoo-dev-help @ libera.chat IRC network. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
On 14.10.2021 20.10, Michał Górny wrote: > On Thu, 2021-10-14 at 15:40 +0200, Marek Szuba wrote: >> Dear everyone, >> >> Following some private discussions, I feel quite strongly now that it >> would both considerably improve certain processes and make our use of >> limited manpower more efficient were we to further reduce the number of >> stable arches in Gentoo Linux. Specifically, I propose to drop >> - hppa, >> - ppc, >> - sparc, >> - x86 >> to ~arch-only status. >> Yes please. Still confused why people by default push KEYWORDS="~amd64 ~x86", but I guess they're the most compatible with each other. > > On one hand, I fully realize that these platforms are a hassle (hppa > and x86 especially). On the other hand, I wouldn't want to basically go > tell Dakon "sorry, you're doing a good job but we've arbitrarily decided > it's not worth your effort". Isn't this just strengthening the point; there's one guy behind all work ;) > > While we're discussing it, maybe we should start by defining a clear > criteria for platform support tiers? Like: what are the requirements > for a platform to maintain stable keywords? Then the decisions could > look less arbitrary, and people would have a clear way of knowing what > they need to do if they wish the platform to continue having stable > keywords. > ++ -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: johu's packages up for grabs
On 11.10.2021 2.05, Petru Ciobanu wrote: > I'm using net-vpn/openfortivpn almost everyday and I would like to start > contributing to Gentoo. If possible, I would not mind to start looking > after it, alone or to co-maintain it with someone who knows more > about maintaining a package. Also, I would not mind some hits on where > to start, but I'm sure I can find enough information on Gentoo docs. > Hey, thanks for your interest! I see there's a lot to do with openfortivpn. First, there's a version bump available, and a relatively simply-looking bug you could try to fix with the version bump, https://bugs.gentoo.org/766357 Then you can call for a stabilization of a newer version, net-vpn/openfortivpn StableRequest: version 1.16.0: slot(0) no change in 161 days for unstable keyword: [ ~amd64 ] and after stabilization is done, you can attempt to remove the older versions. Please see https://devmanual.gentoo.org/keywording/index.html#moving-from-arch-to-arch for stabilization guide. We prefer getting pull requests through Github, see https://wiki.gentoo.org/wiki/Gentoo_Github for a general guide into that. If you use IRC, you can join #gentoo-dev-help on Libera.chat network to get more guidance. You can contribute to maintainer-needed packages without having to become the maintainer. We do allow regular users to become maintainers of packages they're interested in via the proxy-maint project, https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers but we'd first like to see some successful contributions and consistency from you. As said, you can freely contribute to maintainer-needed packages without having to become the maintainer. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: x11-misc/compton
# Development stopped by upstream. Switch to its actively developed # fork, x11-misc/picom. Bug #817338. Removal in ~30 days. OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-vcs/gti
LiveOnlyPackage with no maintainer. Upstream has multiple releases. Please become the maintainer and make a versioned ebuild for an upstream release. Bug #817320. Removal in ~30 days. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] johu's packages up for grabs
Hey, due to inactivity the following packages are now up for grabs: app-admin/calamares app-admin/profile-cleaner app-crypt/zulucrypt app-doc/zsh-lovers app-misc/screenfetch dev-cpp/websocketpp dev-libs/qtkeychain dev-vcs/gti media-sound/lollypop net-im/discord-bin net-misc/sshpass net-vpn/openfortivpn sys-apps/daemonize sys-fs/fuse-zip x11-apps/luit x11-misc/compton x11-misc/fpm2 x11-misc/obconf x11-misc/sxhkd x11-terms/xterm x11-wm/bspwm There's a lot of stabilization to be done, few EAPI-5, and lots of bugs open in general (especially with discord-bin). -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] thev00d00's packages up for grabs
Hey, Due to retirement these are now up for grabs: acct-group/gerbera acct-user/gerbera dev-lang/duktape dev-libs/libcec dev-libs/libplatform dev-python/rarfile dev-python/tvdb_api media-tv/tvnamer media-video/handbrake net-libs/libupnp net-misc/gerbera sys-apps/sensei-raw-ctl x11-themes/kvantum pkgcheck doesn't report anything radical for these, mostly PythonCompatUpdates, then a couple of DeprecatedEapis, DeprecatedEclasses, VariableScopes and UnusedInherits. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Last-rite: dev-libs/rapidxml
On 2.10.2021 20.22, Anna Vyalkova wrote: > On 2021-10-02 15:57, Joonas Niilola wrote: >> # A library without revdeps. Last upstream release in 2009, huge amount > There's a revdep in ::guru (app-accessibility/rhvoice) > What do I do: use bundled rapidxml or add dev-libs/rapidxml to ::guru? > >> # of open bugs not fixed has led the project being forked already. > Is that the fork you mean? > https://github.com/timniederhausen/rapidxml > Hey, I'd suggest you import this fork at its latest snapshot state to ::guru, see that it's compatible with rhvoice, and add to ::guru's local package.unmask if it works. The unmask can be cleaned, when the package is removed from the ::gentoo repo. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rite: dev-libs/rapidxml
# A library without revdeps. Last upstream release in 2009, huge amount # of open bugs not fixed has led the project being forked already. # Bug #776895. Removal in ~30 days. OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: media-libs/libyami
# A library without revdeps, EAPI-5. #776901 # Removal in ~30 days. OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] News item for eudev deprecation
On 22.8.2021 23.14, Anthony G. Basile wrote: > Hi everyone, > > Yes! It is time to finally deprecate eudev! sys-fs/udev now builds > under musl! My original purpose for maintaining eudev was because > systemd + musl did not play well together when udev was absorbed into > the sytemd repo. Now thanks to patches from openembedded, they do, and > my original reason for maintaining eudev is no longer valid. So its > time to retire eudev. It has served its purpose as a stop-gap. > With its new upstream, and this post serves as a PSA to the uninititated, I guess eudev will be kept? https://github.com/eudev-project/eudev -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New tools: iwdevtools to help spot rdepend issues and others
On 3.9.2021 12.58, Ionen Wolkens wrote: > Some of you may already know about it but, now that it has been tested > a bit more, felt should advertise here. > > It's small'ish scripts available from "app-portage/iwdevtools" > > See github[1]'s README.rst for a lowdown (and --help or man pages for > options), but for a quick overview: > Also some example usage to daily ebuild development in https://wiki.gentoo.org/wiki/Package_testing -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cmake.eclass: support EAPI 8
On 16.8.2021 19.53, Marek Szuba wrote: > On 2021-08-16 17:49, Sam James wrote: > >> See https://bugs.gentoo.org/802786 and >> https://github.com/gentoo/kde/pull/903. There's some work to be done >> first. > > I see. Guess we'll have to stick with EAPI 7 for cmake revdeps in the > foreseeable future, then. > What's the rush with 8 anyway? We still have eclasses that don't even support 7. And since 6 is now, sigh, deprecated, any bump to ebuilds depending on those eclasses will add to the evergrowing CI issue list right? I'd say it's more important to secure EAPI-7 support there first. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Package up for half-grabs: net-libs/nodejs
On 16.8.2021 14.56, Marek Szuba wrote: > Hi all, > > I'm taking a (hopefully temporary) break from maintaining > net-libs/nodejs, as I expected when took it on it is a relatively > high-intensity package and I fear that if I keep it up at this rate I'll > end up burning out as a Gentoo developer. Anyone interested in stepping > in? Node has still got another maintainer in Gentoo who to the best of > my knowledge isn't going anywhere, but I do feel this package needs more > than one pair of hands. > It'd help if you described the caveats that are to be expected. -- juippis OpenPGP_signature Description: OpenPGP digital signature
