[gentoo-dev] Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

2022-06-05 Thread Joonas Niilola
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

2022-06-03 Thread Joonas Niilola
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

2022-04-23 Thread Joonas Niilola
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

2022-04-23 Thread Joonas Niilola
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

2022-04-18 Thread Joonas Niilola
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

2022-04-17 Thread Joonas Niilola
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

2022-03-21 Thread Joonas Niilola
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

2022-03-16 Thread Joonas Niilola
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

2022-03-09 Thread Joonas Niilola
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)

2022-03-04 Thread Joonas Niilola
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!

2022-02-11 Thread Joonas Niilola
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

2022-02-06 Thread Joonas Niilola
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

2022-02-02 Thread Joonas Niilola
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

2022-01-24 Thread Joonas Niilola
See topic. No bugs open.

-- juippis


OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Unmask >=net-p2p/bitcoin*-0.21.1

2022-01-24 Thread Joonas Niilola
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

2022-01-22 Thread Joonas Niilola
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

2022-01-20 Thread Joonas Niilola
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

2022-01-17 Thread Joonas Niilola
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)

2022-01-17 Thread Joonas Niilola
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

2021-12-18 Thread Joonas Niilola
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

2021-12-15 Thread Joonas Niilola
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

2021-12-15 Thread Joonas Niilola
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

2021-12-14 Thread Joonas Niilola
# 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

2021-11-26 Thread Joonas Niilola
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

2021-11-25 Thread Joonas Niilola
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

2021-11-25 Thread Joonas Niilola
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

2021-11-21 Thread Joonas Niilola
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

2021-11-20 Thread Joonas Niilola
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

2021-11-11 Thread Joonas Niilola
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

2021-10-27 Thread Joonas Niilola
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

2021-10-26 Thread Joonas Niilola
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

2021-10-16 Thread Joonas Niilola
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

2021-10-15 Thread Joonas Niilola
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

2021-10-11 Thread Joonas Niilola
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

2021-10-10 Thread Joonas Niilola
# 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

2021-10-10 Thread Joonas Niilola
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

2021-10-10 Thread Joonas Niilola
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

2021-10-03 Thread Joonas Niilola
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

2021-10-02 Thread Joonas Niilola
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

2021-10-02 Thread Joonas Niilola
# 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

2021-09-26 Thread Joonas Niilola
# 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

2021-09-15 Thread Joonas Niilola
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

2021-09-03 Thread Joonas Niilola
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

2021-08-16 Thread Joonas Niilola
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

2021-08-16 Thread Joonas Niilola
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


[gentoo-dev] Package up for grabs: games-util/xboxdrv

2021-08-12 Thread Joonas Niilola
Hey, the following package is up for grabs:
games-util/xboxdrv

Haven't used this in years. Last upstream release was in 2015. Even
upstream recommends to use the kernel built-in XPAD module. This package
has one scons-related bug open, and it was recently broken by a scons
update. Upstream started porting it to cmake, but never finished it.
Seems abandoned and unnecessary. Please take it if you need it, I'll
look into last-riting it before christmas otherwise.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rite some broken misc packages (plan, caliper, emilpro)

2021-08-11 Thread Joonas Niilola
# app-office/plan
Broken with gcc >=10, even the latest upstream release fails with
gcc-11. Unmaintained. Removal in ~30 days. #739904

# dev-libs/caliper
A library without revdeps, broken for a long time. No maintainer reply.
Package not updated in Gentoo since 2016 even though upstream is still
active. Removal in ~30 days. #774147

# dev-util/emilpro
Broken since 2016. Latest upstream release 2014, no ebuild activity from
maintainer since 2016, EAPI-5 and the rest. HOMEPAGE leads to some
scammy site. Removal in ~30 days. #584668

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Package up for grabs: www-apps/gitea

2021-08-10 Thread Joonas Niilola
www-apps/gitea is up for grabs. It could use an active dedicated
maintainer since its upstream makes minor releases frequently.

It has two bugs open currently.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs per ikelos's retirement

2021-08-09 Thread Joonas Niilola
Hey,

the following packages are now up for grabs:
app-crypt/ophcrack
app-crypt/ophcrack-tables
app-crypt/ssdeep
app-crypt/xca
app-forensics/foremost
dev-libs/libnfc
dev-python/mypy_extensions
net-analyzer/nipper
net-libs/libnipper


pkgcheck reports:
app-crypt/ophcrack-tables
  DeprecatedEapi: version 1.0-r2: uses deprecated EAPI 5

net-analyzer/nipper
  DeprecatedEapi: version 0.12.0: uses deprecated EAPI 6
  DeprecatedEclass: version 0.12.0: uses deprecated eclass: cmake-utils
(migrate to cmake.eclass)

net-libs/libnipper
  DeprecatedEapi: version 0.12.6-r1: uses deprecated EAPI 6
  DeprecatedEclass: version 0.12.6-r1: uses deprecated eclass:
cmake-utils (migrate to cmake.eclass)

app-crypt/xca
  StableRequest: version 2.3.0-r1: slot(0) no change in 53 days for
unstable keywords: [ ~amd64, ~ppc, ~x86 ]


ophcrack and xca have bugs open.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last rites: net-p2p/go-ipfs-bin

2021-07-16 Thread Joonas Niilola
# To be replaced by net-p2p/go-ipfs, no migration needed.
# Simply deselect the masked package and install the replacement.
# Masked for removal in 30 days. Bug #802381



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow

2021-07-12 Thread Joonas Niilola
On 11.7.2021 23.54, Michał Górny wrote:
> Hi, everyone.
> 
> 
> 
> The point of contention was a proposed change to the EAPI depreciation
> workflow.  The current workflow consists of roughly three steps:
> 
> 1. The Council decides to deprecate an EAPI.  It is added to eapis-
> deprecated in layout.conf and pkgcheck/repoman start emitting warnings
> when they're used in ebuilds.  This is a 'weak' request for developers
> to stop using the old EAPI.
> 
> 2. The Council decides to ban an EAPI.  This is a pure policy decision
> with no technical implementation.  It is a 'strong' request not to use
> the old EAPI, and developers have to have a very good reason (e.g.
> blocked secbump, revbump due to dep changes by a third party and so on)
> to touch an ebuild and leave it at old EAPI.
> 
> 3. When all ebuilds are removed, the EAPI is added to eapis-banned
> and the tools now explicitly forbid adding ebuilds with that EAPI.
> 
> 
> The change proposed in [1] eliminates step 2.  The EAPI remains
> in 'deprecated' policy-state until all ebuilds using it are removed. 
> There is no distinction between 'weak' deprecation ("please don't use
> it") and 'strong' ban ("you mustn't use it unless you have a very good
> reason to").
> 

So it's about removing a bureaucratic step that never resulted in
anything before? Sounds good. The 2nd step should be considered being
added back IF people kept deliberately adding deprecated EAPI ebuilds.
But as you said, guess it's not a problem with active maintainers and
current available QA tools.

-- juippis




OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Package up for grabs: net-print/cnrdrvcups-lb

2021-07-11 Thread Joonas Niilola
Hey,

net-print/cnrdrvcups-lb is up for grabs. It's a driver package for
Canon's MFC series printers.

Gotta say I've been happy how well it has worked, but since all my laser
carts are empty and I can't find a retailer nearby who can supply new
ones, maybe it's time to look for alternatives. Next one, something that
works in Linux without external drivers...

It has 2 bugs open, should be easy to fix. I might still do the next
version bump for this package, but calling out any takers now.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

2021-07-08 Thread Joonas Niilola
On 9.7.2021 5.49, William Hubbs wrote:

>> +Display-If-Installed: virtual/tmpfiles
> 
> This should be:
> 
> Display-If-Installed: sys-apps/opentmpfiles
> 

Disagree. Some people seem to be waking up into "oh no, what have I
installed?".

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode?

2021-06-16 Thread Joonas Niilola
On 16.6.2021 12.13, Michał Górny wrote:
> Hi, everyone.
> 
> We've moved our official support channels from Freenode to Libera.chat.
> All that's happened afterwards pretty much proves that this was
> the right decision.  Maybe even to the point of saying that staying
> on Freenode would be dangerous to our users (e.g. because of the late
> NickServ impersonations, ops with bad reputation etc.).
> 
> However, there are still IRC clients in Gentoo that default to Freenode.
> I think the next questions we need to answer are:

Examples? Is the list huge?
https://packages.gentoo.org/categories/net-irc

> 
> 1. Should we be proactively changing the default network in IRC clients
> (provided they have one) from Freenode to Libera.chat?

Yes.

> 
> 1a. If yes, then should we also make a change if clients default to
> network other than Freenode?

IMO yes.

> 
> 2. Should we be proactively *removing* Freenode from the network list
> in IRC clients (provided they have one)?

Classic or Future Freenode? ;)
(yes, there is no Freenode anymore)

> 
> 2a. Should we be adding Libera.chat to the list even if we do not remove
> Freenode?

Yes.

Ideally all these would be taken care by upstream. Which might provoke
some version updates to dear old IRC clients...

Anyhow I can also imagine leaving these up to package maintainers, and
this mail to work as an encouragement.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: media-gfx/povtree

2021-06-14 Thread Joonas Niilola
# DeprecatedDep jre-1.3, upstream dead,removal in 30 days
# see bug: https://bugs.gentoo.org/787410


-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: media-libs/gmtk

2021-06-11 Thread Joonas Niilola
# A library without consumers, old dep of tree-cleaned gnome-mplayer,
# EAPI-5. Removal in ~30 days. #776898

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Re: Project dotnet is left without members!

2021-05-12 Thread Joonas Niilola
On 23.4.2021 16.32, Joonas Niilola wrote:
> Hey,
> 
> due to the retirement of project dotnet's last member, it is now
> effectively left without any members. If you have any use for packages
> maintained by,
>   https://packages.gentoo.org/maintainer/dot...@gentoo.org
> now's a perfect time to show some care for those.
> 
> I'll be assigning them to m-n in 2-4 weeks time from now otherwise, and
> I fear this will be the death of mono ecosystem in Gentoo.
> 
> -- juippis
> 

And so, the following packages have been put in maintainer-needed status:

dev-dotnet/dbus-sharp
dev-dotnet/dbus-sharp-glib
dev-dotnet/gkeyfile-sharp (m)
dev-dotnet/gtk-sharp (m)
dev-dotnet/libgdiplus (v)
dev-dotnet/monocalendar
dev-dotnet/ndesk-dbus
dev-dotnet/ndesk-dbus-glib
dev-dotnet/notify-sharp (m)
dev-lang/mono (b,v)
dev-util/treecc (b)
www-servers/xsp

b = bugs open,
m = masked for removal,
v = version bump available.

Overall these packages seem to be in a pretty good shape, and most bugs
are open for dev-lang/mono itself.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] sci-libs/cbflib & sci-chemistry/rasmol: last-rites

2021-05-06 Thread Joonas Niilola
sci-libs/cbflib: Doesn't compile with GCC-10 or GCC-11. Was never ported
to work with GCC-10+. sci-chemistry/rasmol depends on cbflib.

Both packages have updates ignored in Gentoo, and their ebuilds pretty
much untouched during git-era. Both had their latest upstream version
release in 2018.

Both EAPI-5 etc.

Removal in ~30 days. Bug: https://bugs.gentoo.org/788508

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item

2021-04-30 Thread Joonas Niilola


On 30.4.2021 3.50, Sam James wrote:
>> On 29 Apr 2021, at 22:01, Michał Górny  wrote:
>>
>> +
>> +
>> +You can also switch to Python 3.9 earlier by setting:
>> +
>> +*/* PYTHON_TARGETS: -* python3_9
>> +*/* PYTHON_SINGLE_TARGET: -* python3_9
>> +
>> +If you choose to follow this or the previous approach, you may want to
>> +remove the package.use overrides after the switch or just leave them
>> +in place to protect your system from the next automatic upgrade
>> +of Python.
>> +
> “It is especially important you do not forget IF you choose to add this,
> because it interferes with the natural rolling-with-the-defaults."
>

No offense, but your suggestion isn't an improvement here :P maybe the
2nd part (after ,) makes sense and should be added, but the first part
of that sentence is a bit hard to read.

-- juippis




OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Project dotnet is left without members!

2021-04-23 Thread Joonas Niilola
Hey,

due to the retirement of project dotnet's last member, it is now
effectively left without any members. If you have any use for packages
maintained by,
  https://packages.gentoo.org/maintainer/dot...@gentoo.org
now's a perfect time to show some care for those.

I'll be assigning them to m-n in 2-4 weeks time from now otherwise, and
I fear this will be the death of mono ecosystem in Gentoo.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Last-rites: readme.gentoo.eclass

2021-04-17 Thread Joonas Niilola


On 4/16/21 11:24 PM, Andreas Sturmlechner wrote:
> readme.gentoo.eclass: Mark as DEAD
>
> - All remaining consumers PMASKED Gentoo ebuild repository
> - Removal on 2021-05-16
And to anyone else who felt shocked after reading this, use
readme.gentoo-r1.eclass...

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Last-rites: app-eselect/eselect-infinality, app-eselect/eselect-lcdfilter, media-fonts/infinality-ultimate-meta, media-libs/fontconfig-ultimate, media-libs/fontconfig-infinality

2021-03-29 Thread Joonas Niilola


On 3/29/21 2:50 PM, Joonas Niilola wrote:
> This has been an useful package regardless of infinality patch set. It
> doesn't depend on it in any way either.
>
> I do have it forked already in my local overlay with few more font
> packages added to the list. Would there be interest in keeping this one
> alive, or replace it with some other new font-meta package?
>
> -- juippis
>
I've made fonts-meta package to replace this, please see
  https://github.com/gentoo/gentoo/pull/20177
for any comments. (+ more maintainers welcome!)

a pkgmove + separate commit to update the ebuild with suggested changes
will probably be smarter than adding a new package.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Last-rites: app-eselect/eselect-infinality, app-eselect/eselect-lcdfilter, media-fonts/infinality-ultimate-meta, media-libs/fontconfig-ultimate, media-libs/fontconfig-infinality

2021-03-29 Thread Joonas Niilola


On 3/29/21 2:27 PM, Andreas Sturmlechner wrote:
> # Removal on 2021-04-26.
>
> media-fonts/infinality-ultimate-meta
>
This has been an useful package regardless of infinality patch set. It
doesn't depend on it in any way either.

I do have it forked already in my local overlay with few more font
packages added to the list. Would there be interest in keeping this one
alive, or replace it with some other new font-meta package?

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Package up for grabs: x11-misc/menumaker

2021-03-20 Thread Joonas Niilola
Hey,

the following package is up for grabs:
  x11-misc/menumaker

1 bug open, and in addition:
  PythonCompatUpdate: version 0.99.12: PYTHON_COMPAT update available:
python3_9

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: dev-libs/OpenSRF

2021-03-18 Thread Joonas Niilola
Has been masked since 2019, depends on apache-2.2 which hasn't been
available in Gentoo for a while, and apparently doesn't build (bug
open). #655502
Removal in 14 days.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs: siege, xmldiff, pgspecial & openresolv

2021-03-18 Thread Joonas Niilola
Due to a retirement of a proxied maintainer, following packages are up
for grabs:

b = bugs open, v = version bump available.
app-benchmarks/siege
app-text/xmldiff
dev-python/pgspecial
net-dns/openresolv (b, v)

In addition:
dev-python/pgspecial
  StableRequest: version 1.12.1: slot(0) no change in 33 days for
unstable keywords: [ ~amd64, ~x86 ]

app-text/xmldiff
  PythonCompatUpdate: version 2.3: PYTHON_COMPAT update available: python3_9

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: dev-libs/zookeeper-c

2021-03-16 Thread Joonas Niilola
# A library without consumers, unbuildable for years, ebuilds not
# touched in years either. Bugs #664776, #747592. Removal in ~30 days.
dev-libs/zookeeper-c




OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs: dev-db/sqlitestudio

2021-02-28 Thread Joonas Niilola
Hey,

per maintainer's request, dev-db/sqlitestudio is now available. It has a
"compile fails" type of bug open, and new version is available upstream.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] glep-0067: Add proxied="" attribute to distinguish proxied maints

2021-02-28 Thread Joonas Niilola


On 2/28/21 1:35 PM, Michał Górny wrote:
> Introduce an additional proxied="" attribute to make it possible
> to explicitly distinguish proxied maintainers from regular maintainers.
> This is supposed to resolve false positives in the QA check responsible
> for detecting leftover proxy-maint project usage.  Currently it wrongly
> assumes that all Gentoo devs (as in people with @gentoo.org) have direct
> push access and therefore don't need a proxy.
>
>
LGTM and I like the idea. One question: Does the metadata.xml file need
to be updated for every currently proxied maintainer?

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Re: Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

2021-02-23 Thread Joonas Niilola


On 2/21/21 3:54 PM, Joonas Niilola wrote:
> Hey,
>
> here are some packages up-for-grabs due to retirement of their maintainers.
> b = bugs open, v = version bump available.
>
> app-arch/innoextract
> net-irc/emech (b)
> net-misc/tigervnc (b)
> x11-misc/urxvtconfig (b)
>
In addition,

app-text/diction
www-client/surfraw (stabilization bug open)

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Re: Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

2021-02-21 Thread Joonas Niilola


On 2/21/21 3:54 PM, Joonas Niilola wrote:
> Hey,
>
> here are some packages up-for-grabs due to retirement of their maintainers.
> b = bugs open, v = version bump available.
>
> app-arch/innoextract
> net-irc/emech (b)
> net-misc/tigervnc (b)
> x11-misc/urxvtconfig (b)
>
In addition, media-video/webcamoid is also up for grabs. It has 3 bugs
open, and a version bump available.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

2021-02-21 Thread Joonas Niilola
Hey,

here are some packages up-for-grabs due to retirement of their maintainers.
b = bugs open, v = version bump available.

app-arch/innoextract
net-irc/emech (b)
net-misc/tigervnc (b)
x11-misc/urxvtconfig (b)



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] A script to pick next free UID/GID for your acct-* packages

2021-02-09 Thread Joonas Niilola
Hey all,

Summary:
There's a script by jkroon in data/api.git
(https://gitweb.gentoo.org/data/api.git/) that prints the next available
UID/GID pair for new acct-* packages. You can use it by:
  cd ~/git/gentoo/data/api
  git pull
  sh bin/used_free_uidgids.sh
 
  The outcome looks like this for those curious:
  https://dev.gentoo.org/~juippis/pics/free_uid_gid_by_jkroon.png
 
Check the Author e-mail from the script to report bugs, and please open
pull requests here:
  https://github.com/gentoo/api-gentoo-org

Story:
As someone who's pushed a few new UID/GID packages lately it was
becoming more and more tedious trying to find the next free number. And
I was personally becoming worried when we're going to run out of
available IDs.

Now a while back I asked half-jokingly someone to write a script that
finds the next free UID, GID and UID/GID, and also prints the current
number of free IDs <500 in #gentoo-dev IRC channel. Lucky for us all,
jkroon was up to the task.

I wanted the implementation to be "open for inspection" and available in
every system syncing data/api.git. So in my eyes the viable options were
using bash or python, and the current script is written in bash. We've
heard enough about using bash for this so please leave such comments out
from this thread. It is well documented and should be maintainable for
the time being, but if someone is up to re-writing it using some other
viable language (python), please go ahead! In its current state the
script works and is very useful!

Script's output looks like this:
  #ID   UID   GID
...
  317..320 FREE  FREE
  321  USED  USED
  322..326 FREE  FREE
  327..330 USED  USED
  331..332 USED  FREE
  333..372 USED  USED
  373  USED  FREE
...

  Recommended GID only: 460
  Recommended UID only: 458
  Recommended UID+GID both: 326
  Free UIDs: 200
  Free GIDs: 177

(note that FREE/USED are colourcoded for your convenience, check the
screenshot above!)

It is not forbidden to mix and mash UID/GID between different packages,
but I'd still suggest to find a new "pair" even if you push just an UID
or GID. Since we don't seem to be in danger of running out any time soon.

Please report bugs to Author (e-mail in the script), and for any fixes
open pull requests at https://github.com/gentoo/api-gentoo-org/

Not to any proxied maintainers (reading this far), a free UID/GID pair
will be given to you when your acct-* packages are merged, so you don't
have to reserve an ID beforehand. But it'd be great if you picked one
that is free when making your new acct-* packages so at least during
merge the next free one will be close to your chosen one.

Enjoy everyone, and huge thanks to jkroon!

-- juippis




OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread Joonas Niilola


On 2/8/21 7:53 PM, Brian Evans wrote:
>
> AFAICT, it is just used to pull GPG sigs in gemato via
> dev-python/requests.
>
And it that's true, isn't this only relevant when syncing the tree using
rsync? So using git would still be viable?

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread Joonas Niilola


On 2/8/21 2:27 PM, Michael Orlitzky wrote:
> Not only that, but you will be dropping support for at least two of my
> machines that are literally incapable of building the 10+ GiB bundled
> rust package due to the amount of disk space and RAM required.
>
Pardon my intervention, but there is rust-bin available at least for
amd64, x86, arm, arm64 and ppc64. Just a PSA to anyone not aware.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs: app-cdr/iat, dev-util/flawfinder

2021-02-07 Thread Joonas Niilola
Packages up for grabs due to retirement of a proxied maintainer:
app-cdr/iat
dev-util/flawfinder (outdated)


-- juippis




OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Would you join to a new project "Themes"?

2021-02-06 Thread Joonas Niilola

On 1/30/21 1:22 AM, Jonas Stein wrote:
> Hi,
>
> x11-themes/* are very similar.
> It could make sense to have a project who maintains all x11-themes.
>
> I never used themes so I am out, but please reply, if you would like
> to create/join such a project.
>
Hey,

since this surfaced again.
I personally wouldn't. I maintain 2 theme packages, but I'm very loyal
to my themes and rarely change them once I find good ones. I know there
are people who change themes, or general UI outlook, based on their mood
multiple times a day. And it'd make sense those people joined the
project to maintain different theme packages.

They should be relatively easy to maintain too as you said.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Joonas Niilola


On 1/8/21 5:42 PM, Thomas Deutschmann wrote:
> Hi,
>
> I wonder how you composed this list. If you just checked if there is
> any revdep, the check was probably useless:
>
> For example,
>
>> dev-libs/cyberjack
>
> is up-to-date, has an active dev as maintainer and is required for any
> ReinerSCT chipcard reader.
>
>
Hey,

I admit the motivation didn't come clear from the first post. I believe
majority of listed packages to be leftovers from previous removals, thus
being "useless" to us now. I also admit to checking git logs for only a
handful of packages, and left few active+useful ones out from the list
already. This is a genuine inquiry to find out if these libs are somehow
useful for someone, not a "last-rites call for action" post ;)

Although I probably will continue to look for the really outdated,
EAPI-5 etc ones after a certain period of time.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Joonas Niilola
# With the help of jkroon I went through all dev-libs/* and media-libs/*
packages and located each one without reverse deps,
# List of dev-libs/* and media-libs/* without any revdeps:
dev-libs/atcore
dev-libs/bcm2835
dev-libs/bemenu
dev-libs/bitset
dev-libs/boost-mpl-cartesian_product
dev-libs/caliper
dev-libs/c-capnproto
dev-libs/cgilib
dev-libs/clhpp
dev-libs/cloog
dev-libs/cyberjack
dev-libs/distorm64
dev-libs/editline
dev-libs/faxpp
dev-libs/go-usb
dev-libs/granite
dev-libs/gtx
dev-libs/igraph
dev-libs/ilbc-rfc3951
dev-libs/injeqt
dev-libs/jthread
dev-libs/keystone
dev-libs/kqoauth
dev-libs/libdivecomputer
dev-libs/libdivsufsort
dev-libs/libdnsres
dev-libs/libdynd
dev-libs/libezV24
dev-libs/libgcrypt-compat
dev-libs/libgpiod
dev-libs/liblzw
dev-libs/libmelf
dev-libs/libpcre-debian
dev-libs/libtomfloat
dev-libs/libtompoly
dev-libs/libtreadstone
dev-libs/libusbhp
dev-libs/light
dev-libs/log4sh
dev-libs/nss-pem
dev-libs/OpenSRF
dev-libs/pigpio
dev-libs/processor-trace
dev-libs/qrosscore
dev-libs/rapidxml
dev-libs/redland-bindings
dev-libs/replicant
dev-libs/rinutils
dev-libs/rocm-hostcall
dev-libs/smack
dev-libs/squareball
dev-libs/stp
dev-libs/tvision
dev-libs/ucommon
dev-libs/ustr
dev-libs/vc-intrinsics
dev-libs/weston
dev-libs/xbyak
dev-libs/zlog
dev-libs/zookeeper-c
media-libs/cimg
media-libs/elles_icc_profiles
media-libs/esdl
media-libs/fluidsynth-dssi
media-libs/freeverb3
media-libs/gmtk
media-libs/gnonlin
media-libs/guilib
media-libs/icclib
media-libs/intel-mediasdk
media-libs/jbig2enc
media-libs/kodi-platform
media-libs/libbsb
media-libs/libggigcp
media-libs/libggimisc
media-libs/libgroove
media-libs/libicns
media-libs/liblingoteach
media-libs/libmpeg3
media-libs/libmpris2client
media-libs/libsixel
media-libs/libyami
media-libs/memphis
media-libs/noise-suppression-for-voice
media-libs/phat
media-libs/raul
media-libs/sdl-terminal
media-libs/taglib-extras
media-libs/tse3
media-libs/volpack

# Following packages did not compile:
dev-libs/caliper https://bugs.gentoo.org/737106 (dev-libs/papi, a
build-dep is broken)
dev-libs/zookeeper-c https://bugs.gentoo.org/747592
media-libs/intel-mediasdk https://bugs.gentoo.org/740070

# Already package.masked:
dev-libs/ilbc-rfc3951
dev-libs/OpenSRF
dev-libs/ustr

# Following packages appear in optfeature or elog otherwise:
(none)

# These packages install binaries, emerged with USE="tools":
dev-libs/bemenu
dev-libs/c-capnproto
dev-libs/cgilib
dev-libs/cloog
dev-libs/cyberjack
dev-libs/granite
dev-libs/keystone
dev-libs/libdivecomputer
dev-libs/libdynd
dev-libs/libgpiod
dev-libs/liblzw
dev-libs/libmelf
dev-libs/libusbhp (/usr/bin/hptest)
dev-libs/light
dev-libs/qrosscore
dev-libs/replicant
dev-libs/stp
dev-libs/tvision
dev-libs/ucommon
dev-libs/weston
dev-libs/zlog
media-libs/icclib
media-libs/jbig2enc
media-libs/libbsb
media-libs/libicns
media-libs/libmpeg3
media-libs/libmpris2client
media-libs/libsixel
media-libs/phat
media-libs/taglib-extras
media-libs/tse3

# So the final list of "useless" libs is:
dev-libs/atcore
dev-libs/bcm2835
dev-libs/bitset
dev-libs/boost-mpl-cartesian_product
dev-libs/caliper
dev-libs/clhpp
dev-libs/distorm64
dev-libs/editline
dev-libs/faxpp
dev-libs/go-usb
dev-libs/gtx
dev-libs/igraph
dev-libs/ilbc-rfc3951
dev-libs/injeqt
dev-libs/jthread
dev-libs/kqoauth
dev-libs/libdivsufsort
dev-libs/libdnsres
dev-libs/libezV24
dev-libs/libgcrypt-compat
dev-libs/libpcre-debian
dev-libs/libtomfloat
dev-libs/libtompoly
dev-libs/libtreadstone
dev-libs/log4sh
dev-libs/nss-pem
dev-libs/OpenSRF
dev-libs/pigpio
dev-libs/processor-trace
dev-libs/rapidxml
dev-libs/redland-bindings
dev-libs/rinutils
dev-libs/rocm-hostcall
dev-libs/smack
dev-libs/squareball
dev-libs/ustr
dev-libs/vc-intrinsics
dev-libs/xbyak
dev-libs/zookeeper-c
media-libs/cimg
media-libs/elles_icc_profiles
media-libs/esdl
media-libs/fluidsynth-dssi
media-libs/freeverb3
media-libs/gmtk
media-libs/gnonlin
media-libs/guilib
media-libs/intel-mediasdk
media-libs/kodi-platform
media-libs/libggigcp
media-libs/libggimisc
media-libs/libgroove
media-libs/liblingoteach
media-libs/libyami
media-libs/memphis
media-libs/noise-suppression-for-voice
media-libs/raul
media-libs/sdl-terminal
media-libs/volpack

# Now my question is, does anyone find any of these packages useful?
Should we go ahead and last-rite them, since it doesn't seem useful to
carry these in Gentoo? The ones broken are heading towards last-riting
nevertheless.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: x11-term/{eterm,pangoterm}

2021-01-07 Thread Joonas Niilola
pangoterm:
# Doesn't compile, no maintainer, EAPI-5. Last version bump 3 years
# ago. Use any of the available alternatives,
# https://packages.gentoo.org/categories/x11-terms
# Removal in ~30 days. Bug: #764353

eterm:
# Eterm's development stopped 2014 and upstream brought to life
# its successor, terminology. Eterm is unmaintained in Gentoo with
# multiple bugs open for a long time. Switch to any available
# alternative, https://packages.gentoo.org/categories/x11-terms
# For Esetroot replacement, use feh from media-gfx/feh or wmsetbg
# from x11-wm/windowmaker.
# Removal in ~30 days. Bug: #764359



Re: [gentoo-dev] Non-maintainer commits and CI

2021-01-07 Thread Joonas Niilola



On 1/7/21 4:28 PM, Agostino Sarubbo wrote:
> Hello,
>
> it happens frequently that CI discovers failure(s) in non-maintainer commits.
>
> The most striking examples are maintainer-needed, proxy-maint and general 
> pull 
> request where who made the change has no visibility on the new bug.
>
> Do you think that is a good idea to CC everyone involved in the commit?
>
>
> Agostino
>
>
>
Overall yes, I think this is a good idea. One should be held responsible
to one's commits even for m-n packages.

But then again I wouldn't wish to be reminded about
CFLAGS/LDFLAGS/cc/ar/etc after fixing some bug unrelated to these. If
there's a CFLAGS/LDFLAGS/etc bug open for 1.2.3 do you usually report a
new one for 1.2.3-r1 or 1.2.4?

-- juippis



Re: [gentoo-dev] [RFC] New go.gentoo.org url shortener

2021-01-03 Thread Joonas Niilola


On 12/8/20 3:55 PM, Max Magorsch wrote:
> Hi all,
>
> the tl;dr is that I've set up a new url shortener which is available
> on https://go.gentoo.org/ currently. It can generate short links like
> 'go.gentoo.org/XXX' or you can create custom persistent links like
> 'go.gentoo.org/arzano/tyrian' or 'go.gentoo.org/infra/hashicorp'.
> Basically, I'm looking for some quick feedback whether you consider
> this as useful or don't think you would use it much, to decide whether
> it's worth offering this service.
>
> As mentioned the url-shortener is deployed on https://go.gentoo.org
> currently. The source code is available at [0]. It's only accessible
> by Gentoo developers using Gentoo SSO for the authentication. You can
> log in using your nickname and your ldap password. Basically two use
> cases are supported:
>
> 1) Just paste a link and get an automatically shortened url like
> 'go.gentoo.org/XXX'. This is pretty much the normal url shortener
> functionality.
>
> 2) You can paste a link and create a custom persistent link using a
> prefix like 'go.gentoo.org/$prefix/$custom'. Allowed prefixes are the
> nickname of the developer that is logged in or a project the developer
> is part of. Thus I for one could create links like
> 'go.gentoo.org/arzano/tyrian' or 'go.gentoo.org/infra/hashicorp'.
> However, I would e.g. not be able to create
> 'go.gentoo.org/qa/policy-guide' as I am not part of the qa project.
> Only members of the QA team could create that link. That's also the
> reason I've been coming up with this, as this way every developer /
> every project would be able to create custom persistent, nice / short
> links.
>
> However, please note that this is just a first beta version yet and
> it's not meant to be production-ready yet. Please feel free to test it
> though. In general, I'm looking for some feedback on whether you would
> be interested in the two functionalities to get a feeling whether it's
> worth spending time on this / offering this service at all.
> Also I would be especially interested whether you consider the second
> functionality as useful. Because if we just want the first
> functionality, we can simplify this and just use any of the
> url-shorteners that are already out there, instead of using the
> solution I have built.
>
> /M
>
> [0] https://gitweb.gentoo.org/sites/go-gentoo.git/
>
Hi,

well my first impressions are that there are few major issues why I
wouldn't use this:
 - for an URL shortener the final URL isn't really that short (there are
multiple alternatives),
 - not a CLI tool to handle this (yet at least),
 - login would be REQUIRED so people won't spread malicious links with
"gentoo.org" in it, or at least the accounts can be disabled.

Although I do like the idea of team-specific links, in the end I fear
there'd be many dead links and no one to clean/check those. So in the
documents we're better at referring to the original source.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [TINDERBOX] A round with dev-lang/python-exec[-native-symlinks]

2020-12-29 Thread Joonas Niilola


On 12/29/20 1:51 PM, Agostino Sarubbo wrote:
> Hello,
>
> as requested by mgorny, the tinderbox is doing a round with dev-lang/python-
> exec[-native-symlinks].
>
> Please expect related bugs.
>
> The tracker is at: https://bugs.gentoo.org/762406
>
> --
> Agostino
>
>
>
Could we have some sort of summary in here what this means, and an
example to fix issues? Please?

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] I'm looking for a Mentor

2020-12-18 Thread Joonas Niilola


On 12/18/20 7:19 PM, Alec Warner wrote:
> TL;DR, I think infra needs more people who can commit to ::gentoo and
> thus, I am looking for an ebuild dev mentor. I myself had commit
> access in the before times (probably 2010 - 2012) but have been mostly
> ignoring ebuild development since then to focus on infra and the
> Foundation. However infra is using more and more software that is
> maintainer-needed and so we probably need to change our focus to
> giving back more to the main tree.
>
> -A
>
You can start your training by filing Github PRs, as contributions to
maintainer-needed packages are mostly dealt with in there. ;)

-- juippis



[gentoo-dev] Last-rites: more broken LiveOnlyPackages

2020-12-06 Thread Joonas Niilola
# Not keyworded, unmaintained, unbuildable for a long time, EAPI-5.
# Removal in ~30 days. List sorted by their bug numbers.
# Bugs: #752432, #752435, #752438, #752441, #752444, #752453.
media-plugins/kodi-screensaver-crystalmorph
media-plugins/kodi-visualization-nastyfft
media-plugins/kodi-screensaver-rsxs
net-wireless/qradiolink
net-libs/liba53
app-emulation/qt-virt-manager



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: sys-kernel/{aufs,ck,xbox}-sources

2020-12-01 Thread Joonas Niilola
|

# Not maintained in Gentoo, multiple versions behind, unsafe, EAPI-5,
# Use other kernel source / binary packages instead,
# https://packages.gentoo.org/categories/sys-kernel
# Bugs: #716490 (aufs), #739782 (-ck), #757843 (-xbox)
sys-kernel/aufs-sources
sys-kernel/ck-sources
sys-kernel/xbox-sources|




OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: app-accessibility/simon

2020-11-21 Thread Joonas Niilola
# Abandoned upstream, unbuildable, unkeyworded in ::gentoo.
# Removal in 14 days. Bug #752456
app-accessibility/simon



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Re: Last-rites: sys-block/rts_pstor

2020-11-19 Thread Joonas Niilola


On 11/20/20 1:17 AM, Martin Dummer wrote:
> Hello developers,
>
> can someone please insert the lines below into the tree?
> (If I file a github PR, it will probably not able to merge because 
> packages.mask changes too quickly) 
>
>
> # Martin Dummer  (2020-11-20)
> # Does not compile with kernels >=5.5, no upstream development
> # since years, for most hardware the in-kernel module
> # rtsx_pci_sdmmc should be preferred over this driver.
> # Bugs #712484 #717184 and #741909. Removal in 30 days.
> sys-block/rts_pstor
>
>
>
> Thanks,
> Martin
Hi,

please do make a PR, and ping us at #gentoo-proxy-maint IRC channel or
send an e-mail to proxy-maint@g.o with a link to your PR, since it
doesn't get assigned in Github, no one gets notified about it. Then it
can be processed swiftly. Making a PR also runs a CI check prior to
merging which is a huge plus.

In worst case we can just use git commit --author.

I can merge this, but can't author you without your sign-off. Even
though this isn't copyrightable work, *all* commits to ::gentoo repo
require sign-off line from their authors. Let me know how you wish to
continue.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: games-emulation/ppsspp

2020-11-18 Thread Joonas Niilola
# Doesn't compile, no maintainer, our package is multiple versions
# behind from upstream. Removal in ~30 days. Bug: #739212
games-emulation/ppsspp



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-09 Thread Joonas Niilola


On 11/9/20 5:59 PM, Kent Fredric wrote:
> Historical context probably matters here.
>
> That's a very old statement.
>
> Partly from the era when Gentoo was "cool" and when "ricing" was a thing.
>
> At the time, upstream was inundated with absurd requests like "oh noes,
> I disabled CXX Exceptions, and the code broke, upstream is wrong!".
>
> Whatever we did, or upstream did, the absurd complaints have gone away.
>
Yep, I posted the link more as a joke rather than an actual complaint...
but the entry is visible in every machine with urxvt installed while
being outdated already. Not that urxvt has recent releases either, but
it'd be nice if you could update it for the next one.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-08 Thread Joonas Niilola



On 11/9/20 12:17 AM, Kent Fredric wrote:
> On Wed, 4 Nov 2020 17:34:07 +0100
> Marek Szuba  wrote:
>>> x11-terms/rxvt-unicode 
>> Will co-maintain this one with conikost, don't mind being listed as 
>> primary maintainer.
> If you strike an issue that you think should be followed upstream, rope
> me in. (put me on the bottom of the maintainer list if you want)
>
> I'm not interested in maintaining it directly, but I use it, and do
> have workable rapport with upstream :)

http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.man.in?revision=1.130=markup#l176

I find this an issue WITH the upstream...

-- juippis



Re: [gentoo-dev] A feedback about the CI bug reporting system

2020-11-06 Thread Joonas Niilola


On 11/6/20 9:21 AM, Agostino Sarubbo wrote:
> Hello all,
>
> 6 months have been passed after the CI system started to file bug reports.
> ~ 4700 bugs have been submitted
>
> We _know_ that atm is not possible to set a specific summary, instead a 
> generic summary is used in case of compile failures and test failures.
> There are also some documented limitations.
Would it be possible for "someone" to figure it out, if you made your
tinderbox scripts/code public? ;) Hate to say it, but toralf does pretty
good job here, so it could be better.

> Since there are conflicting opinions I would like to know if you find it 
> useful or not.
Yes, I do find your tinderbox work useful most of the time. Thanks!
However the latest, ehh, show with DISTUTILS_USE_SETUPTOOLS has made
people do *hundreds* of commits that now apparently need a fixing
anyway, or reverting back, and that doesn't feel nice. Sure maybe the
eclass could do some fixing too, but maybe this notice wasn't meant to
be full-tree scanned (at least _yet_).

From my point of view your work is, and has been, appreciated, but you
could coordinate better with other people. Hate to say it again, but
toralf does seems to do a better job here too in that regard. Unless
you're fine with comparing tinderboxers.

With toralf's logs it's easy to reproduce the whole environment leading
to a build failure, while with yours it's just build.log, thay may or
may not be enough to find the build-breaking issue.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Joonas Niilola


On 11/5/20 6:03 AM, Alec Warner wrote:
>
>
> The result is that we should remove badly maintained stuff; not create
> more policies.
>
> -A
>
Feel like I'm repeating myself... but such policy would prevent us from
getting into situation like this in the first place, with more CI
coverage available, and better visibility to users.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Joonas Niilola


On 11/4/20 11:12 PM, Matt Turner wrote:
>
> Is there value in making snapshots of app-portage/no-distcc-env?
>
> I don't really think so, and that's why I didn't do it. Should I reconsider?
>
We havy many similar packages keyworded, like all theme packages. Last
upstream commit was made 1 year ago, couldn't you treat it as a release
at that point? Does it make sense to have a live ebuild for stagnated
upstream? 1 year is enough time to get even ~alpha keyworded, although
in this case ALLARCHES would apply.

On a more principal level I do wonder why this is an ebuild at all,
should we all package our /etc/portage configs? But as a distcc user I
could find this useful, and with keywords and 'optfeature' added to
distcc, you could find more users reporting more packages to be added
upstream.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Joonas Niilola


On 11/4/20 11:19 PM, Rich Freeman wrote:
> Did you consider that somebody could read your email and not actually
> agree with you?
Impossible! My suggestion is about keeping the tree clean and to provide
the best user experience. Who'd disagree with that?!

Sure the methods for achieving that can be discussed, but if I find ~50
% of current live-only packages being unbuildable, don't you agree
there's a problem with them? And regardless the outcome of this policy
suggestion, I've filed 14 bugs to maintainers notifying their --only
packages aren't working.

> Does it work?  If so, then there is no harm.  If not, then just remove
> it - you don't need a new policy to treeclean stuff that doesn't work.
One of the selling points to this policy suggestion is that they'd get
CI coverage, which they currently don't. Why keep dead weight around for
years that apparently no one uses, not even the maintainer themself.

> You're saying that live-only packages should be removed because they
> could have snapshots.  I'm saying that if you want to maintain a
> snapshot just add it and co-maintain - you don't have to remove
> packages that don't have them.
I'm saying currently maintainers aren't doing very good job at
maintaining them, and no one else uses/finds these packages.

-- juippis





OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Joonas Niilola


On 11/4/20 10:43 PM, Rich Freeman wrote:
>
> Do you really think that users who just blindly run "emerge
> --autounmask-write" are going to be both masking and unmasking
> packages by hand (per your other email)?
Just by following wiki...

>
> And how are they any better off if they do? They just end up in the
> exact same state, except now we have zero control over their
> experience instead of only a little control.
Exactly, we should try to prevent this situation! Glad we agree.

>
> Then why not do that, instead of removing things?
Did you bother reading my reply? There's work being done towards fixing
packages which seem to have hope. Now for some of these packages there's
been last upstream activity 8 years ago. Is having a - ebuild
justified there? Also for some, upstream is dead, gone, making the
package totally un-emergeable. Now imagine if we had a snapshot tarball
in our mirrors, maybe it wouldn't need to be removed, if it still could
be built.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Joonas Niilola


On 11/4/20 8:52 PM, Rich Freeman wrote:
>
> If you remove them from the tree:
If they have an active upstream and/or tagged releases, and the package
builds, I'd much rather keyword than remove them. There's already work
being done towards this,
  https://bugs.gentoo.org/752429
  https://bugs.gentoo.org/752447
  https://bugs.gentoo.org/752423
  https://bugs.gentoo.org/752456
  https://bugs.gentoo.org/752426
  https://bugs.gentoo.org/752438
  etc.

> 4.  If somebody finds one they probably have to add some random
> overlay to their config, which causes this package to become
> available, probably along with 47 other packages that can potentially
> conflict with other things in the tree, all with zero QA.
(It's common practice to mask the entire overlay then unmask the
package(s) you need from it)

> Certainly it is good to have snapshotted versions that get more QA
> where appropriate, and that should probably be communicated.  When it
> is done with an "or else" attached the result is likely to be that a
> lot of stuff just gets removed, with little benefit...
>
Well my intention is to get up-to-date packages KEYWORDED properly, for
better visibility and support.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Joonas Niilola


On 11/4/20 8:18 PM, Alec Warner wrote:
>
> I disagree. These packages are not installable by default, and must be
> unmasked by users, so this tradeoff is one we expect them to make. Are
> there practical problems that these packages pose to developers? You
> listed a bunch of user problems, but again users are opting into these
> problems, presumably.
I just managed to install Gentoo yesterday, today I want package x and
apparently it's masked? I type emerge --autounmask-write x because the
guide told me so without understanding any of the concerns (that are
also written in devmanual) listed above. I have no idea what I'm doing,
but at least I got the package on stable system... if upstream wasn't so
broken currently.

Now imagine you're a developer and you need a certain library to develop
your software, but the upstream repo has been broken for weeks or
months. You couldn't emerge the package, but if there was a snapshot
available to a latest working commit, it could save a lot of your time.

>
> But again, why are we making this a firm policy; as opposed to letting
> the maintainer make their decision?
Look where maintainer decision got us, majority of these ebuilds being
broken, outdated and totally ignored. There aren't that many packages
available right now, but the state could still be cleaner.

Wouldn't you like the solution offered by mgorny, where there could be a
time-limit for these --only packages?

>  
>
> We can't guarantee any package to build..so I'm not sure how this is a
> practical policy goal.
>
> -A
Sure we can. You test it before you push, then it hits at least two
tinderboxes currently. Before stabilization multiple test runs are made.
I do trust the current state of Gentoo packages being better and better
each day.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-03 Thread Joonas Niilola



On 11/3/20 10:10 AM, Michał Górny wrote:

I'm with you on this though I think it should be relaxed to disallow
only long term presence of pure live packages.  It's fine to add a live
ebuild first for a month or two if you're still working on something
(just like it's fine to add a masked package).  However, it's not fine
to leave things like this for years.

That said, maybe the policy should cover 'long-term masked packages'
in general.  See below.

Initially Arfrever suggested the same, I wasn't a fan of it because I 
believe it's much simpler to make this into a pkgcheck/repoman check 
like this.


However with pkgcheck maybe a similar logic can be used as is used with 
StableRequestCheck. So no objections there I guess.


-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: broken, outdated, unmaintained -9999 packages

2020-11-02 Thread Joonas Niilola

# Dead upstream, or broken for a long time, not maintained in Gentoo.
# Removal in 30 days. Bug #752462
app-emulation/rex-client
app-i18n/kde-l10n-scripts
media-plugins/xbmc-addon-xvdr
net-analyzer/nagios-plugins-flameeyes
net-libs/libosmo-abis
net-libs/libosmo-netif
net-misc/lcr
net-misc/srf-ip-conn-srv
net-wireless/dump978
net-wireless/openbsc
net-wireless/openggsn
net-wireless/osmobts
net-wireless/osmocom-bb




OpenPGP_signature
Description: OpenPGP digital signature


  1   2   >