[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


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

2020-11-02 Thread Joonas Niilola

Hey,

I'm suggesting a new QA policy to disallow any "live-ebuild-only
packages" being hosted in ::gentoo. Rationale being the same as why
- packages can't have KEYWORDS: They are unpredictable and
potentially insecure. Unpredictability could mean upstream repo being
broken at any given time placing users in an awkward situation, where
they are able to build some packages while not the others. Upstream
repo can also be force-pushed over. I feel like packages offered in
::gentoo shouldn't have these issues, and the need to have at least one
safe release available to users that's guaranteed to build.

With Git-like VCS's becoming popular, it is super easy to create an
unchanged snapshot based on a commit. Even devmanual encourages this
with proper guide how-to:
https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#snapshots-and-live-ebuilds
  (https://devmanual.gentoo.org/keywording/index.html)

We currently have 43 "live-ebuild-only" packages in tree. Out of those
19 are totally unbuildable, that's 44 % of all packages present in the
repo. Overall the maintenance of these live-ebuild-only packages looks
low, there's only a handful of ebuilds that have good quality and no
issues at all. 12 of them, 28 %, are still on EAPI-5. Of all 43, only 2
would require the maintainer to generate a tarball by themself, while
others can utilize upstream's tagged releases, or ability to make a
snapshot from a specific commit. Obviously if this policy passes, I'll
be helping getting these packages keyworded.

And finally here's an example how to introduce new packages to tree
without upstream releases:
https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/rlottie?id=42873c46b7ed07d5b4f8af5fcf08d8549cb6385b
https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=2de52234783be909f6e4aed333533e6a804e8e6b
https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=8305f0c6cd0ce8cb5ac0f2d92569acce36a5cc0a
  etc...
https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=24c48b325dd5a22284d077d6581a1a45e397e511

If the only available version for a package doesn't build - or can't be
guaranteed to build - then it should be last-rited, or not exist in
::gentoo repo at all.

Some history and initiative: bug #713802

-- juippis



Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-18 Thread Joonas Niilola



On 10/18/20 8:48 AM, Michał Górny wrote:

On Sat, 2020-10-17 at 18:05 -0400, Aisha Tammy wrote:

This package provides the 'display-manager' startup script for
handling your chosen display manager, without being dependent on
Xorg server.

being dependent -> depending



Do you really think a rename for the sake of renaming justifies
requiring all users to rewrite their configuration?  While we're
requiring the users to do that, wouldn't it be better to stop using
the awful layout of 'one script to run them all', and switch to separate
scripts for every DM?

This is exactly what I proposed in the previous RFC, systemd already 
works this way and is IMHO a lot clearer to use.


-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-11 Thread Joonas Niilola


On 10/11/20 4:40 PM, Thomas Deutschmann wrote:
>
>
> First of all, calm down. You are reading too much into this. Just
> revert your own logic: You obviously like your idea, worked on this
> and pushed it to repository. Don't you see that anyone could ask the
> same? Who are you? Why do believe that you can force something like
> that down to everyone's system? That feature got enabled in developers
> profiles by default, it will blow up distfiles with useless data (a
> view you can have when you share my concerns and don't see any
> problems with current Manifest system; For example we banned stuff in
> $FILESDIR before and asked developers to move them to d.g.o when >25kb
> in total arguing that large distfile is affecting *any* user... I am
> not comparing this 1:1 but to repeat your question: Who are you that
> you can decide to force something similar down to everyone).
>
>
> Sure, if I am the only having that opinion and most people see a value
> in this and disagree with me...
>
>
I vote for disabling that USE flag in developer profile. There are more
than 1 person using it not yet buying or understanding this "draft". I
also believe such a profile flag change should be discussed first.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package

2020-10-10 Thread Joonas Niilola

On 10/10/20 1:57 PM, Aisha Tammy wrote:
> Hi all,
>   This change is for OpenRC init scripts only.
>   Currently the way our display managers are started, is by using the
> xdm init script present in the xorg-base/xorg-server package, with its
> script
> dependencies spread across four other packages, without any logical
> separation.
> This makes it so that every display manager needs the whole xorg-server
> package even if just for the init scripts.
> There are bugs open about this for a while to refactor the scripts out
> from
> xorg-server and into their own independent package, to make them easier
> to manage and modify
> - https://bugs.gentoo.org/730644
> - https://bugs.gentoo.org/356915
> The change is not just for the sake of closing bugs either.
> Given the recent number of huge additions in wayland, it is now possible
> to have a Xorg-free setup starting from the display manager.
> There are wayland-only display-managers available in gentoo
> - gui-apps/gtkgreet
> - gui-apps/tuigreet
>
> It should now be possible to start these display managers using openrc
> without pulling in Xorg.
>
> The changes are currently being worked on in the PR at
> https://github.com/gentoo/gentoo/pull/16554

+1 to separating xdm from xorg-server.


>
> Changes
>  - xdm init.d is replaced by display-manager init.d script

Why this rename? I can't find a reason for that.


>  - Configuration of display-manager is done similar to xdm by modifying
>     /etc/conf.d/display-manager
>  - Add display-manager to default runlevel and it should start working

My counter-proposal at this point would be to handle DMs similarily to
how it's done with systemd. In other words, every DM would provide their
own init and conf files (or, "service" files) and they'd be controlled
like that. I really see no point in renaming xdm to display-manager. xdm
to gdm, xdm to lightdm etc causes at least the same amount of confusion
and hassle, but would at least match the other init system. Then
swapping between openrc and systemd would be one step less difficult.

I have both openrc and systemd systems installed, and find the systemd
way a lot cleaner in this regard. What would other people think?

-- juippis


>
> Other changes, less relevant to everyday users
>  - boot parameter nox has been replaced by nogui
>  - usage of /etc/.nox has been removed in favor of /run/.nogui as the
> boot
>     parameter is a better controller
>
> Cheers,
> Aisha
>



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New customization options available on packages.g.o

2020-10-07 Thread Joonas Niilola

On 10/6/20 11:55 PM, Max Magorsch wrote:
> For example, it's possible to customize the keywords that are shown or
> the classes of pkgcheck warnings that are displayed. Furthermore it's
> also possible to include all packages, QA reports, pull requests and
> bugs of projects a maintainer is part of on the maintainer page. This
> way, it's for instance possible to view all bugs of packages you are
> maintaining as well as bugs of packages that are maintained by
> projects you are part of.
>
> Further customization options are available on the preferences pages.
> Feel free to let me know if you are missing anything. Apart from that:
> Happy customizing.
>
> /M
>
A link to everyone:

https://packages.gentoo.org/user/preferences/packages

Is this cookie-based? Is there a way to "save" your preferences somehow,
or would you need to introduce a new login account to p.g.o? How's the
"single-login-to-all-gentoo-services" idea moving?

Still this is awesome and thanks for your work on p.g.o. I'm off to test
some settings.

-- juippis




OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: k8s split packages returning

2020-10-04 Thread Joonas Niilola
Could you please plaintext the news item in your mail so it'd be easier 
to quote?


The first paragraph resembles more of a personal blog than a news item. 
You should be able to passivize it. The first sentence also goes beyond 
72 characters.


https://www.gentoo.org/glep/glep-0042.html#news-item-body

-- juippis




Re: [gentoo-dev] New acct-* packages for media-sound/snapcast

2020-09-30 Thread Joonas Niilola

On 9/30/20 1:09 PM, Jakov Smolic wrote:
> Hi all,
> I'd like to reserve 1 GID (462) and 2 UIDs (461 and 463) for new acct-*
> packages needed with media-sound/snapcast.
> I've submitted the packages as part of the following PR:
> https://github.com/gentoo/gentoo/pull/17333
>
> Thanks!

Hi,

this is not necessary anymore. You said in your PR you saw this is
required, where did you see it? It's outdated information. Please refer to

https://projects.gentoo.org/qa/policy-guide/user-group.html

https://wiki.gentoo.org/wiki/Proxied_Maintainer_FAQ#Adding_acct-.7Bgroup.2Cuser.7D.2Fpackages_as_a_proxied_maintainer

Also do note we try to go downwards from 500, so the next available
number seems to be 384, per,

https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.txt

although a next free one will be given to you during merge. 461-463 are
already taken.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: app-leechcraft/*, virtual/leechcraft-*

2020-09-22 Thread Joonas Niilola
I'd also like to point out something regarding "- packages only"; It
may be buildable one day for users, and broken the next. And some of the
deps may be unbuildable, it's really random and up to state of upstream
instead of state of ::gentoo repo. This was the case with leechcraft for
example, check bug #693328. You should always have a keyworded static
version available.

-- juippis

On 9/22/20 2:23 PM, Michał Górny wrote:
> # Michał Górny  (2020-09-22)
> # Poorly maintained suite of NIH packages.  Only live ebuilds left
> # for over a year.  This really belongs in an overlay.  Some of them
> # depend on deprecated dev-qt/qtwebkit (#684672).
> # Removal in 14 days.  Bug #693328.
> app-leechcraft/laretz
> app-leechcraft/lc-advancednotifications
> app-leechcraft/lc-aggregator
> app-leechcraft/lc-anhero
> app-leechcraft/lc-auscrie
> app-leechcraft/lc-azoth
> app-leechcraft/lc-bittorrent
> app-leechcraft/lc-blasq
> app-leechcraft/lc-blogique
> app-leechcraft/lc-certmgr
> app-leechcraft/lc-core
> app-leechcraft/lc-cpuload
> app-leechcraft/lc-cstp
> app-leechcraft/lc-dbusmanager
> app-leechcraft/lc-deadlyrics
> app-leechcraft/lc-devmon
> app-leechcraft/lc-dolozhee
> app-leechcraft/lc-eleeminator
> app-leechcraft/lc-fenet
> app-leechcraft/lc-gacts
> app-leechcraft/lc-glance
> app-leechcraft/lc-gmailnotifier
> app-leechcraft/lc-historyholder
> app-leechcraft/lc-hotsensors
> app-leechcraft/lc-hotstreams
> app-leechcraft/lc-htthare
> app-leechcraft/lc-imgaste
> app-leechcraft/lc-intermutko
> app-leechcraft/lc-kbswitch
> app-leechcraft/lc-kinotify
> app-leechcraft/lc-knowhow
> app-leechcraft/lc-krigstask
> app-leechcraft/lc-lackman
> app-leechcraft/lc-lastfmscrobble
> app-leechcraft/lc-laughty
> app-leechcraft/lc-launchy
> app-leechcraft/lc-lemon
> app-leechcraft/lc-lhtr
> app-leechcraft/lc-liznoo
> app-leechcraft/lc-lmp
> app-leechcraft/lc-mellonetray
> app-leechcraft/lc-monocle
> app-leechcraft/lc-musiczombie
> app-leechcraft/lc-nacheku
> app-leechcraft/lc-netstoremanager
> app-leechcraft/lc-networkmonitor
> app-leechcraft/lc-newlife
> app-leechcraft/lc-ooronee
> app-leechcraft/lc-otlozhu
> app-leechcraft/lcpackgen
> app-leechcraft/lc-pintab
> app-leechcraft/lc-pogooglue
> app-leechcraft/lc-popishu
> app-leechcraft/lc-poshuku
> app-leechcraft/lc-qrosp
> app-leechcraft/lc-rosenthal
> app-leechcraft/lc-sb2
> app-leechcraft/lc-scroblibre
> app-leechcraft/lc-secman
> app-leechcraft/lc-seekthru
> app-leechcraft/lc-summary
> app-leechcraft/lc-sysnotify
> app-leechcraft/lc-tabsessmanager
> app-leechcraft/lc-tabslist
> app-leechcraft/lc-touchstreams
> app-leechcraft/lc-tpi
> app-leechcraft/lc-vrooby
> app-leechcraft/lc-xproxy
> app-leechcraft/lc-xtazy
> app-leechcraft/leechcraft-meta
> app-leechcraft/liblaretz
> virtual/leechcraft-browser
> virtual/leechcraft-downloader-http
> virtual/leechcraft-notifier
> virtual/leechcraft-quark-sideprovider
> virtual/leechcraft-search-show
> virtual/leechcraft-storage-device-manager
> virtual/leechcraft-task-show
> virtual/leechcraft-trayarea
> virtual/leechcraft-wysiwyg-editor
>
> eclass/leechcraft.eclass
>



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [virtualization project] Help needed with libvirt virtualization stack

2020-09-22 Thread Joonas Niilola

On 9/22/20 3:02 PM, Marc Schiffbauer wrote:
> I would like to help out with lxc 
>
> * Matthias Maier schrieb am 21.09.20 um 22:25 Uhr:
>> Dear all,
>>   app-emulation/lxc
>>   app-emulation/lxc-templates
>>
>> If you use these packages and are interested in helping out with version
>> bumps and maintenance, please contact me over e-mail / IRC and add
>> yourself to the virtualization project :-)
> I would like to help out with lxc
>
> -Marc
>
LXC is currently in a good state, but all help is of course welcome. I
have multiple TODOs regarding them, just waiting for the next release.
Let's discuss about those before touching ebuilds first please.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] How to stabilize packages with frequent release cycles?

2020-09-15 Thread Joonas Niilola

On 9/15/20 9:42 AM, Michał Górny wrote:
> Hi,
>
> The regular stabilization workflow works for the majority of packages.
>  However, it makes little sense for packages with frequent release
> cycles.  Examples of these are boto3/botocore (daily release cycle) or
> hypothesis (upstream conflates commits with releases).
>
> When the latest release remains 'latest ~arch' for less than 3 days,
> stabilizing it after 30 days makes little sense.  After all, people with
> frequent upgrade cycle will test it for no more than that, and people
> with infrequent upgrade cycle may miss the version entirely.

Isn't the 30 days just a recommendation, not a strict rule?


>
> In the end, we stabilize an entirely arbitrary version at an arbitrary
> point in time, and even if users were willing to give it better testing,
> they can't guess which version will be the next stable candidate.
>
> Do you have any suggestions how we could improve this?

Just use maintainer's discretion on them. For example, see how
youtube-dl and vivaldi are stabilized, both having frequent releases. In
vivaldi's case the security updates make fast-stabilization a mandatory
step pretty much and for youtube-dl you want to keep it compatible with
"today". Anyway, that's one way.

Not like every stable version in the tree works either.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: dev-python/mini-amf

2020-09-07 Thread Joonas Niilola
# Nothing in the tree uses this lib anymore. Removing as redundant.
# Removal in ~30 days. Bug #740868.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/2] optfeature.eclass: New eclass with definition from eutils

2020-09-06 Thread Joonas Niilola

On 9/6/20 6:47 PM, David Seifert wrote:
> ---
>  eclass/optfeature.eclass | 63 
>  1 file changed, 63 insertions(+)
>  create mode 100644 eclass/optfeature.eclass
>
Can we have the "why" answered? Wasn't this supposed to be part of
future EAPI?

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2020-08-30 Thread Joonas Niilola

On 8/30/20 11:19 AM, Joonas Niilola wrote:
> net-misc/anydesk b,v

My bad, anydesk is still maintained.

app-dicts/myspell-de was missing though, no bugs open etc.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs

2020-08-30 Thread Joonas Niilola
Hey all,

here's a list of few packages dropped to maintainer-needed due to
retirement of inactive    maintainers.

b = bugs open,
v = new version available.

app-arch/lha
app-arch/unarj b

dev-cpp/popl
dev-cpp/aixlog b,v

dev-db/pgcli b,v

dev-libs/keystone b,v

dev-python/google-auth-oauthlib
dev-python/greenstalk
dev-python/pgspecial

dev-vcs/tortoisehg b,v

media-gfx/iscan-data v
media-gfx/iscan-plugin-gt-x770 b
media-gfx/iscan-plugin-gt-x820 b

media-sound/snapcast b,v

net-im/skype-dbus-mock b

net-irc/quasselgrep b

net-misc/anydesk b,v
net-misc/seafile b,v
net-misc/seafile-client v

sys-apps/ucspi-ssl b,v

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/2] java-pkg-simple.eclass and java-utils-2.eclass: features and enhancements

2020-08-25 Thread Joonas Niilola

On 8/25/20 6:46 PM, zongyu wrote:
> Signed-off-by: zongyu 

Hey, these patches can't be applied as-is due to this sign-off. Please
see https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin

This is probably just your "mis"configured git settings.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Joonas Niilola

On 8/18/20 8:52 PM, Miroslav Šulc wrote:
> is there a way or would it be possible to get notified on pull
> requests that are relevant to me? though i get notifications from
> github, i get tens to hundreds daily and most of them are irrelevant
> to me so searching for those few that are related to me is really
> inefficient for me.

You should receive them for any team you're part of? But as you said,
sometimes they're in the hundreds per day. The only way I'm aware to
sort them is by configuring your e-mail client's filtering. If you use
GMail for your devpost, it's pretty easy.


> if a maintainer is mia and does not accept pull requests, there is
> much lower chance to get his/her package fixed/bumped. i personally do
> not hesitate to step up and fix a package though i do not maintain it
> if the bug bothers me and i see no activity from the maintainer. and
> if i can find a pull request for such a package, it could save me some
> time. so what i had on my mind is a situation with maintainer mia +
> no-pull-requests-policy -> worse situation than maintainer mia and
> yes-pull-requests-policy.

If you see a devaway permitting that, sure go ahead. Otherwise it's not
different to how things are now - wait for maintainer timeout, get their
approval in IRC or by e-mail, or ask QA to do it / permission to do it.


>> I believe toggling the flag per-package basis is too much. Sure I can
>> see the situation where this happens, but the point here is to enable
>> communication between contributor and maintainer. If you're not
>> accepting PRs to some packages, you can close the PR informing
>> contributor about it. It'd be better than leave it to rot for months,
>> years, with no answer.
>
> you know much better than me how pull requests are processed and what
> benefits and problems those bring. for me pull requests are generally
> good thing but sometimes when i see the quality of them, basic issues
> not resolved like the missing signed-off-by, contributors not
> responding and disappearing... i'm just not sure this whole effort
> will bring some advancement, but i trust your opinion on that as you
> are the one spending a lot of time on github. anyway, when it comes to
> this feature mentioned above, if it might be of any use, it can work
> as an override for package where it is specified and otherwise be
> undefined. in the end the contributor will be interested in whether
> the package accepts pull requests, not a dev or project.
>
If you see faults in the PR, please let the contributor know. It's their
only way to improve. Yeah not everyone reads all docs, but if you work
with them, the quality gets better.

There is a reason for every PR. Nobody will get flooded by them, since
there shouldn't be a continuous reason to push them right? And if there
is, maybe it implies something about the current state of maintenance...

And the package inherits "acceptance state" of its maintainers which'd
then be visible, per-package.


> can't we have a bug tracker for this webapp? i think it's so useful
> that it would deserve such a space :-)

You're asking for a tracker, just letting everyone know there is a way
to file/list bugs for packages.gentoo.org:

New bug -> Websites -> Packages. Arzano should decide whether we track
this or not. But for sure a bug about this needs to be created, unless
other people shoot the idea down.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Joonas Niilola

On 8/18/20 8:06 PM, Joonas Niilola wrote:
>
> So I think it's just simplest to enable it per-user per-project basis.
> We can all edit Project: pages, toggling the flag. If you're willing to
> look and merge sound@ PRs, you enable it for Sound project. However this
> might cause a problem when a member who enabled the flag leaves the
> project, or gets retired. But that's relatively easy to keep a track of.
>
> As for non-dev maintainers, they **require** @gentoo.org person/project
> to proxy for them. It'd be a start to mirror the project/dev option,
> since they'd be the one committing for non-dev maintainers anyway. Also
> non-dev maintainers can have their own wiki pages to toggle this.
> However I'm not aware if the linking is as simple as with @gentoo.org
> metadata info.
>
Forgot to add, if you have say 1 person and 2 projects assigned as
maintainers, where 1 does look for Github PRs and 2 does not, it'd still
be flagged as "Yes". Or maybe the majority here wins?

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Joonas Niilola

On 8/18/20 7:30 PM, Miroslav Šulc wrote:
> hi,
>
> how would be handled cases where you and me agreed that you will take
> care of pull requests on behalf of sound@ and proaudio@? and what if a
> package is maintained by multiple maintainers or even some maintainers
> and a project, each with a different preference? how that would be
> solved to not bring in some confusion? and how about maintainers that
> are not gentoo devs? and what if there are packages that have a
> maintainer that is mia but has the no-accept policy set and some other
> dev would like to fix a package that has an annoying bug (using a pull
> request by a contributor) as the reported maintainer is mia, or a
> contributor might want to maintain the package? and what if a
> maintainer wants pull requests just for some packages and not for
> others? and what if a pull request is referenced from a bug at
> bugzilla but the maintainer does not accept pull requests?

One idea for implementation would be to enable the flag in your User:
page. Then if any member in a project has it enabled, the project would
have it set positive as well. However it doesn't necessary directly
translate to you you merging personal PRs -> you merging all of your
project PRs. I also thought the project could count Yes's and No's from
their members, printing something like "This project has a 66 %
probability of handling Github PRs". But that'd look silly.

So I think it's just simplest to enable it per-user per-project basis.
We can all edit Project: pages, toggling the flag. If you're willing to
look and merge sound@ PRs, you enable it for Sound project. However this
might cause a problem when a member who enabled the flag leaves the
project, or gets retired. But that's relatively easy to keep a track of.

As for non-dev maintainers, they **require** @gentoo.org person/project
to proxy for them. It'd be a start to mirror the project/dev option,
since they'd be the one committing for non-dev maintainers anyway. Also
non-dev maintainers can have their own wiki pages to toggle this.
However I'm not aware if the linking is as simple as with @gentoo.org
metadata info.

If the current maintainer is MIA, it doesn't change anything from our
current situation. At least it doesn't make it any worse than it is, but
has advantages for those available. I'm sorry I may have not understood
your question correctly here? We can claim maintainer timeout, or ask QA
to deal with these situations. It wouldn't change.

I believe toggling the flag per-package basis is too much. Sure I can
see the situation where this happens, but the point here is to enable
communication between contributor and maintainer. If you're not
accepting PRs to some packages, you can close the PR informing
contributor about it. It'd be better than leave it to rot for months,
years, with no answer.

Your last question wouldn't be any different from a current situation,
however other devs/users can inform the contributor that this maintainer
can't/doesn't use Github, and the PR can be closed. I'm mostly looking
for communication here. I believe being rejected is better than being
ignored. The bug can be dealt separately from Github PR.

There's a tool that tells what PRs reference a closed bug,

(ie contribution was made, but not accepted/noticed, and the bug was
closed regardless of it)

https://github.com/wimmuskee/gengee


>
> sorry for this flood of questions but atm it brings confusion to me
> :-) from my point of view and personal preference, i appreciate pull
> requests from contributors if those are of a decent quality, but for
> me it's hard to easily find out the relevant pull requests. with the
> new packages.gentoo.org it might be easier in the future but i'm not
> sure yet how reliable it is atm as for example the list of outdated
> packages for proaudio@
> (https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated)
> does not seem to be updated or i misunderstood something. the same
> goes for the list of bugs
> (https://packages.gentoo.org/maintainer/proau...@gentoo.org/bugs)
> which seems to be missing some bugs as my list with "Assignee:
> proau...@gentoo.org" has 96 bugs atm compared to 76 bugs at
> packages.gentoo.org.
>
> fordfrog

Please talk to arzano about this. Although I'm pretty sure he will read
this thread ;)

-- juippis



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Joonas Niilola
Hey,

some of you may already have seen the new packages.gentoo.org page,
  https://packages.gentoo.org/

and the new maintainer pages in it,
  https://packages.gentoo.org/maintainers

If you open a maintainer page,
  https://packages.gentoo.org/maintainer/juip...@gentoo.org

you can see a tab called "pull requests" there,
  https://packages.gentoo.org/maintainer/juip...@gentoo.org/pull-requests

with description saying:
"If you also like to help the Gentoo project, you can consider sending a
Pull Request via GitHub.
Before doing so, you might want to take a look at the wiki page."

I'm suggesting of adding a new metadata flag to our Wiki's
User:/Project: page which then prints a message to this page saying
whether the maintainer (be it project or user), "accepts" or "deals
with" Github contributions. The wording can be a bit better, but it'd be
there to **notify** our **contributors** whether their time and effort
will most likely be wasted making a pull request for this particular
maintainer.

This note would then be displayed in every package the maintainer is
assigned to,
  https://packages.gentoo.org/packages/media-libs/rlottie/pull-requests

I'd imagine a simple switch in Wiki could do it. No need to add anything
to ::gentoo repo. The switch can be visible in User:/Project: page, but
it doesn't have to. Unspecified metadata flag would print something like
"This maintainer hasn't specified whether they handle Github pull
requests. If you wish to help using Github, please also open a bug prior
to that and link your pull request commit to that bug (add link to
glep-66 here)". Or just default it to "No."

Note that the bug text could always be displayed nevertheless, since
that is still the main channel to communicate with maintainers.

It's undeniable we get a lot of pull requests and unfortunate that many
are left without any attention to rot.
  https://github.com/gentoo/gentoo/pulls

I think this would serve both parties - devs and contributors, with
little to no cost.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Package up for grabs: x11-libs/libfm

2020-08-12 Thread Joonas Niilola

On 8/13/20 7:25 AM, Jimi Huotari wrote:
> Unless I'm being blind, the LXQt project does not need this one, making it
> 'maintainer-needed':
>
> x11-libs/libfm
>
Seems to be needed by LXDE stuff only. Regarding that, should we
last-rite remaining LXDE stuff? It's pretty clear the development has
shifted to LXQT, and LXDE seems abandoned upstream.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-11 Thread Joonas Niilola

On 8/11/20 11:36 AM, Jaco Kroon wrote:
> And I've already provided you one use case where udev doesn't work well
> but eudev does.  I've also mentioned some historic issues I believe
> should already be fixed but which did bit me in systemd-udev which was
> never a problem in eudev.
>
Your systems seem to diverge a lot from what I'd consider as 'default'.
You must already make many changes to them.

Before this thread I didn't even know/remember I was using eudev. It
works and there doesn't seem to be any global issues related to it.
However after reading this thread I'm a bit considered about the
maintenance state of it.

Switched to udev. Simple as 'emerge -1 sys-fs/udev'. It works, didn't
notice any difference.

If musl is a problem, to my knowledge musl has its own stage images, so
why can't those stages use eudev while other ones defaulting to udev?

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Joonas Niilola

On 8/6/20 10:58 PM, Thomas Deutschmann wrote:
> Well, the purpose of this is to educate and avoid problems for
> headless/server users. But if so many devs seem to care about pushing
> maybe unrelated information and believe that avoiding that has much more
> value than avoid a problem like an unbootable system for just a few
> people (and for headless/servers this is a major problem in case you
> cannot trigger remote reboot)... ¯\_(ツ)_/¯
>
Yeah let's break some setups and make people change distributions instead.

I'd support showing it. Weren't we all taught that too much
communication is better than no communication?

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Bug #733802, USE 'scp' now defaults to off in net-misc/openssh

2020-07-27 Thread Joonas Niilola

On 7/26/20 12:57 PM, Ulrich Mueller wrote:
> Even more appropriate would be to enable the flag with an IUSE default.
> The ebuild could still display an ewarn message pointing out the alleged
> security issue.
>
> Ulrich

This'd be nice. A news-worthy update in my opinion regardless.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: dev-util/cutter

2020-07-24 Thread Joonas Niilola
# Unmaintained in Gentoo, broken, multiple bugs open.
# Removal in ~30 days. #733324


signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs: app-arch/unar, x11-misc/rofi-calc

2020-07-05 Thread Joonas Niilola
Hey all,

due to retirement of a proxied maintainer, app-arch/unar and
x11-misc/rofi-calcare maintainer-needed. No bugs are open for either,
but rofi-calc seems to have a new release available.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/numb-0.40.1.ebuild

2020-07-02 Thread Joonas Niilola

On 7/2/20 4:14 PM, Aisha Tammy wrote:
> On 7/2/20 9:06 AM, Xianwen Chen (陈贤文) wrote:
>> Dear juippis,
>>
>> Thank you. I checked the pull thread out on github.com.
>>
>> Do I get it right that the numba folder is already removed from 
>> https://github.com/gentoo/gentoo/tree/master/dev-python?
>>
> Its not removed yet.
> It should be working now but am awaiting feedback.
>
> Aisha
>
It was just removed today. :\

Next place for numba is science overlay?

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/numb-0.40.1.ebuild

2020-07-01 Thread Joonas Niilola

On 7/1/20 10:37 PM, Xianwen Chen (陈贤文) wrote:
>
> This ebuild enables Python 3 as one of the Python targets. Otherwise
> there is no difference between this ebuild and the latest ebuild in
> Portage, which only had Python 2 as the Python target.
>
>
Then it probably doesn't work. Did you try running tests on python3
implementations?

There's an ongoing process trying to get it fixed for python3, and I
hope the science team will take over now, because this package is ...

https://github.com/gentoo/gentoo/pull/15766

Also we have this site called "Bugzilla" where you would've seen any
bugs/process related to numba being worked on, and you could've reported
the julia issue earlier on:

https://bugs.gentoo.org

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: packages.gentoo.org Developer Mode

2020-06-30 Thread Joonas Niilola

On 6/30/20 1:28 AM, Max Magorsch wrote:
> 1. Would you prefer this information to be displayed in packages.g.o
> using a 'developer mode' or would you prefer a separate application
> similar to the idea of project Grumpy?

I'd prefer not to scatter tools around anymore. 'Developer' mode sounds
better from these two options, but as you already know, I'd prefer
showing relevant CI checks for users as well.


>
> 3. What else would you like to see here? For instance, I could think
> of a configurable dashboard that shows all pkgcheck warnings, new
> versions and open pull requests for packages that a developer
> maintains. Would that be useful? What else could you think of?

I'm happy with what you've come up. Can we change the defaults from
pkgcheck though? I don't think these 'UnstableOnly' or 'PotentialStable'
benefit anyone since they cause a lot of noise, and checking
PotentialStable still requires a lot of maintainer attention.

I'd like to see them be replaced with 'StableRequestCheck' and
'RedundantVersionCheck' which I believe servers majority of maintainers
better.

Then obviously the usual CI checks, AbsoluteSymlink, BannedEapiCommand
etc what is shown here:

https://qa-reports.gentoo.org/output/gentoo-ci/output.html

Showing open pull requests would be a **massive** enhancement to
developer mode in my opinion.  

This is the alpha version, right? Looking good so far! Thanks for your work.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-27 Thread Joonas Niilola

On 6/27/20 2:28 AM, Robin H. Johnson wrote:
>
> TL;DR: Please make it easier to search on the QA reports site for
> issues, and only show things directly relevant to the search.
>
> A long time ago, there was blizzy's site that listed packages that were
> stabilization candidates, and you could filter by developer. It really
> helped making it easier to detect and progress.

$ pkgcheck --color true scan $(git grep -l robb...@gentoo.org
'**/metadata.xml' | cut -d/ -f1-2) -c StableRequestCheck -R
FormatReporter --format 'stabilize {category}/{package}-{version}  # {desc}'

There's also a bug open to integrate some of the pkgchecks to p.g.o,
https://bugs.gentoo.org/725704



>
> At a bare minimum, having an on-site way that already expands the data
> and makes it searchable by developer.

You can filter the output.html per-dev/per-project, but it's not as
verbose as running pkgcheck locally can be.

https://qa-reports.gentoo.org/output/gentoo-ci/output.html;maintainer=robbat2

https://qa-reports.gentoo.org/output/gentoo-ci/output.verbose.html;maintainer=robbat2

It doesn't straight out show python2 like this, but with the
package.deprecated entry for it, it'll flag newly added py2 commits.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

2020-06-26 Thread Joonas Niilola

On 6/26/20 10:29 AM, Michał Górny wrote:
> Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich  
> napisał(a):
>
> Pushed as:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049
> with full text being:
>
> +# Sergei Trofimovich  (2020-06-26)
> +# Deprecated.
> +# - optional python:2.7 dependency should be dropped if no reverse
> +#   dependencies are using it.
> +# - mandatory python:2.7 depepndency will require package porting
> +#   or package removal if no reverse dependencies are using it.
> +dev-lang/python:2.7
> You've just introduced 829 CI warnings, effectively disabling the ability to 
> distinguish *new* problems in these packages.
>
>
> --
> Best regards, 
> Michał Górny
>
Hi,

Overall can we let the python project handle large-scale python-2.7
removal, please? Everyone can help updating their own packages, or m-n
packages.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/rstcheck-3.3.1: Add rstcheck python package (#16399)

2020-06-26 Thread Joonas Niilola

On 6/26/20 1:18 AM, Brian Dolbec wrote:
> On Thu, 25 Jun 2020 23:11:29 +0100
> Samuel Bernardo  wrote:
>
>> Hi,
>>
>> I send this email to ask for your help on selecting the project
>> maintainer for a new ebuild.
>>
>> I created a pull request for the ebuild in subject[1] and the QA
>> reports complaints about missing project maintainer[2]. What should I
>> do?
>>
>> Thanks
>>
>> [1] https://github.com/gentoo/gentoo/pull/16399
>>
>> [2]
>> https://qa-reports.gentoo.org/output/gentoo-ci/2e4d12bbfa/output.html#dev-python/rstcheck
>>
>>
> You add yourself as primary maintainer.  The proxy maintainers will add
> themselves for the merge to the repo after all review is done.  This
> will mean that you will need to maintain the pkg, do the version bumps,
> etc..  The proxy team will help merge the changes to the ebuild tree.

This results in a CI error, and personally I often just skip PRs that
have CI errors. So you can imagine this is not the best suggestion ;)


Currently proxy-maint team isn't merging new packages to ::gentoo tree,
because self-maintained packages already take too much work. We are
currently ~14 days behind on those. Please read more here,
https://archives.gentoo.org/gentoo-proxy-maint/message/44f7712fb49850288cd840c3541f6d7e

So the only choice for now is to use ::guru overlay,
https://wiki.gentoo.org/wiki/Project:GURU


Also can I ask you to stop posting to this mailing list about every
minor obstacle you come ahead? There are multiple more suitable support
channels available (forums, IRC, -user ML), these topics have nothing to
do with Gentoo development.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Add commit to pull request

2020-06-21 Thread Joonas Niilola

On 6/21/20 7:48 PM, Samuel Bernardo wrote:
> Hi,
>
> I need to add a commit to a gentoo pull request that I had opened before.
>
> https://github.com/samuelbernardo/gentoo
>
> Is it possible to add the commit to that pull request or I need to open
> a new pull request?
>
> I already try to get help in gentoo-dev channel but I haven't voice there...
>
> Thanks
>
>
Looking at your fork, you'll want to update your master branch (or
whatever it's called nowadays) and create a new branch for every new
pull request you make.

#gentoo-dev-help IRC channel exists.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: News item: xorg-server dropping default suid

2020-06-21 Thread Joonas Niilola
Hey,

It has some typos. What's the current trend of attaching news items? It
makes hard to point out enhancements.

-- juippis

On 6/21/20 10:22 PM, Piotr Karbowski wrote:
> Hi,
>
> Please find news item attached.
>
> -- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: php-ext-source-r2.eclass

2020-06-07 Thread Joonas Niilola
No ebuilds in the tree use this eclass anymore, since php-ext-source-r3
exists. Removal in ~30 days. Bug #727472.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Joonas Niilola

On 6/7/20 9:14 PM, Jonas Stein wrote:
>
> Glad to read your offer. Yes, please do so.
>
> I think it would hurt the Gentoo project if single developers delete
> projects
>
> - without without informing the project members
> - without prior discussion (on gentoo-dev for example),
> - without vote/consent
> - without an organized shutdown (reassign bugs, archive things...).
>
> However we should continue to find a general solution for the problems
> discussed in this thread and find a general consent.
>
> Thank you.
>
The "voting" and "discussion" happened in #gentoo-dev IRC channel. Every
participant was unhappy with the state of graphics project, and even
after pinging the project, no members responded. This "discussion" has
been ongoing for a while now. While I agree the outcome wasn't clean, in
my eyes attempts to contact project has been made.

Now for the future, I wouldn't mind having a "last rite: XYV Project" or
similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is
taken, so the project members/lead has one final chance to stop it.
Maybe this even encourages us to go through some of the more inactive
projects currently?

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Joonas Niilola

On 6/6/20 10:11 PM, Aisha Tammy wrote:
> On 6/6/20 2:50 PM, Aaron Bauman wrote:
>> All, the graphics project has now been disbanded.
>>
> Is it weird to ask what happened?
>
> It seems like a lot of the packages listed here should be and are
> very popular :O
>
> Aisha
>
Hi,

floppym's response sums it up.

https://archives.gentoo.org/gentoo-dev/message/c0b5e5e1ab4e0ed77725d4366a5232be

jstein started a new thread about this subject,

https://archives.gentoo.org/gentoo-dev/message/f9fae5f9583e73e6d4dbf4fc521dd559

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rite x11-themes/terminology-themes

2020-06-01 Thread Joonas Niilola
# Last snapshot is from 2+ years ago, which doesn't build. Latest 
# upstream commit won't build with in-tree efl versions. Has a bug 
# open and unanswered for 2 years, so this package seems unmaintained
# in Gentoo. Removal in ~30 days. Bug #656098

-- juippis



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-23 Thread Joonas Niilola

On 5/24/20 5:41 AM, Mike Gilbert wrote:
> Also, people are likely to disable this accidentally via USE="-*".

Counts as

> if they want to break their system intentionally.
>



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Gentoo Identity Provider

2020-05-19 Thread Joonas Niilola

On 5/19/20 4:42 AM, Alec Warner wrote:
> TL;DR: What if we launched id.gentoo.org , an
> identity provider that provides authentication for Gentoo properties?
> Basically, 1 username / password for wiki, bugs, email, forums, and
> any other http service[0][1].
>
>
> Is this a thing people are interested in?
>  
>
Sounds good to me.

-- juippis



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs

2020-05-16 Thread Joonas Niilola
Hey all,

here's a small list of packages dropped to maintainer-needed. Some are
from retired proxied maintainers, and some are from me, ie packages I
don't use anymore and see no reason to hoard ownership.

(b) = open bugs,
(v) = new version is available.

app-backup/rsnapshot (b,v)

app-misc/cargo-license

dev-python/sphinxcontrib-documentedlist (b)

gnome-extra/gnome-commander (b,v)

media-libs/imlib2

media-plugins/imlib2_loaders

sys-fs/compsize (b,v)

sys-fs/cryfs (b)

I also welcome co-maintainers to dev-libs/check or media-libs/rlottie,
if anyone's interested.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-12 Thread Joonas Niilola

On 5/12/20 8:36 PM, Samuel Bernardo wrote:
>
> My concern was about the others, for instance go-overlay that I have
> enabled.
>
> Should it be possible to run a QA check to create a bug request to
> remember the update of those ebuilds in the overlays?
>
> This would reduce the bug management task when searching for related bugs.
>
Nothing stops you from doing that, and reporting any issues you find to
overlay maintainers. This is probably doable with a single grep. We
_cannot_ cater all the overlays. There has been enough time to react.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs: LXDE

2020-05-11 Thread Joonas Niilola

On 5/11/20 10:00 AM, Joonas Niilola wrote:
>
> And here are packages that were co-maintained by lxqt project, or by
> individual devs:
>
>
> media-gfx/gpicview
And this by graphics...



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs: LXDE

2020-05-11 Thread Joonas Niilola
Hey all,

since LXDE has no project members, and no one joined for a long time or
picked up the packages, let's properly reassign them. Here are packages
that were dropped to maintainer-needed:

lxde-base/lxde-icon-theme
lxde-base/lxtask
lxde-base/lxappearance-obconf
lxde-base/lxrandr
lxde-base/lxsession
lxde-base/lxappearance
lxde-base/lxpanel
lxde-base/lxterminal
lxde-base/lxde-common
lxde-base/lxde-meta
lxde-base/lxinput
lxde-base/lxlauncher
media-sound/lxmusic
x11-misc/pcmanfm

And here are packages that were co-maintained by lxqt project, or by
individual devs:

x11-libs/libfm-extra
x11-libs/libfm
lxde-base/lxdm
lxde-base/menu-cache
media-gfx/gpicview

I will reassign bugs next.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] CFLAGS=-fno-common related breakage is incoming

2020-05-04 Thread Joonas Niilola

On 5/2/20 2:14 PM, Sergei Trofimovich wrote:
> With Toralf's help we now have rough estimate of broken packages. It's about
> 450 yet unfixed ones:
> https://bugs.gentoo.org/showdependencytree.cgi?id=705764_resolved=1
>
> gcc-10 will be released soon. Maybe in a week.
>
> Please look at the broken list and fix your packages.
>
> Thanks!
>
Thanks for the heads-up!

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Mask gnome-extra/cinnamon and deps for removal

2020-04-28 Thread Joonas Niilola

On 4/28/20 9:18 PM, Matt Turner wrote:
> I'd like to mask the following packages for removal due to lack of an
> active maintainer. I'll wait a couple of days for comments before
> adding the mask to be extra nice.
>
> dev-python/xapp

Note that (at least) this has revdeps outside cinnamon.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: bzr.eclass

2020-04-28 Thread Joonas Niilola
With recent removal of dev-vcs/bzr this eclass became redundant and
broken. Removal in ~30 days. Bug #719892.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Fwd: New eclass suggestion: docs.eclass

2020-04-27 Thread Joonas Niilola

On 4/27/20 7:10 PM, Andrew Ammerlaan wrote:
> Hi all,
>
Hey,

could you please plaintext your whole patch in this thread, so it can be
viewed and commented by replying? See how lanodan did. Or check:

https://archives.gentoo.org/gentoo-dev/message/f2a7abcc8506ae3e56a0ebb0ea0cadc8

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: twisted-r1.eclass

2020-04-27 Thread Joonas Niilola
It has no more consumers in ::gentoo tree. Removal in ~30 days. Bug:
https://bugs.gentoo.org/719794

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader

2020-04-19 Thread Joonas Niilola

On 4/19/20 11:40 PM, Marek Szuba wrote:
> As previously mentioned, x11-drivers/nvidia-drivers is the last OpenCL
> runtime we have got in the tree to be migrated to the "must use an ICD
> loader" approach to virtual/opencl. Unfortunately I have so far failed
> to reach the maintainer of this package (jer) by either e-mail,
> Bugzilla, or IRC - so I'm submitting this for review here.
>
>
>
He has been on devaway for a while.

I would've much rather seen the differences between -r0 -r1 ebuilds to
focus on what is actually done there. Not that I have any say what will
be done in the end, but it's easier for the eyes...


-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs

2020-04-14 Thread Joonas Niilola
Hey,

here's a list of packages recently dropped to maintainer-needed due to
retirement of multiple inactive proxied maintainers.

(b) = open bugs,
(v) = new version is available.

--
app-admin/cdist (v)
app-admin/passwordsafe (b,v)

app-backup/duply (b,v)
app-backup/rear (b,v)

app-crypt/envchain (b,v)

app-emulation/crun (b,v)

app-laptop/i8kutils (b,v)

app-misc/abduco
app-misc/dfshow (b,v)

dev-go/delve (b)

dev-lua/luv (v)

dev-libs/granite (b,v)

dev-tex/biber (b,v)

dev-util/kdstatemachineeditor (b,v)
dev-util/kubebuilder (b,v)
dev-util/packer (b,v)
dev-util/spec-cleaner (b,v)

dev-python/confuse (v)
dev-python/mediafile (v)
dev-python/sphinxcontrib-pretty-searchresults

games-puzzle/nudoku (b,v)

media-fonts/fontawesome (v)
media-fonts/iosevka (b,v)

media-libs/gexiv2 (b)

media-sound/beets (b)

net-dns/dnscap (b,v)
net-dns/dnstop (b)

net-im/skypeforlinux (b)

net-irc/ngircd (b,v)

net-nntp/suck (b,v)

net-p2p/transmission-remote-cli (b)

net-vpn/vpnc (b,v)

sci-calculators/bc-gh (v)

sci-electronics/librepcb (b,v)

www-apps/hugo (b,v)

x11-terms/roxterm (b,v)

x11-wm/notion (b,v)
--

Note to any current proxy-maintainers admiring to take these: Remember
to do version bumps and bug fixes where possible before adding yourself
to metadata.xml.

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Joonas Niilola

On 4/11/20 6:33 PM, Michał Górny wrote:
> Hi,
>
> Now that we have proper components for keywording and stabilization,
> the old keywords are redundant.  Nevertheless, some people still set
> them.  I would like to propose two solutions going forward.  Either:
>
> 1. We kill both keywords, and just rely on components, or
>
> 2. I make NATTkA automatically add KEYWORDREQ or STABLEREQ where
> appropriate.
>
> Which would you prefer?
>
Less noise is better, so I vote for 1.

Wasn't aware KEYWORDREQ and STABLEREQ were useless, thats why I always
set them. Will it break any commonly used search scripts / settings?

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rite: mask www-misc/zoneminder

2020-04-05 Thread Joonas Niilola
# Not maintained in Gentoo, doesn't build for 2 years, has only
# deprecated version present in Gentoo. Has a huge number of open
# bugs. Removal in 30 days. #642952
www-misc/zoneminder


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread Joonas Niilola

On 3/23/20 8:23 PM, William Hubbs wrote:
> but we need to
> find a way to notify them when a breaking change is going into a widely
> used eclass and give them time to adjust their ebuilds.
>
>
> Thoughts?
>
Subscribe to this mailing list.

AFAIK all major changes have been posted here and pushed with some delay.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] State of Cinnamon & Mate projects

2020-03-19 Thread Joonas Niilola
Hanno's previous message about the LXDE project made me think other
desktop projects that are facing a bad state in Gentoo: Cinnamon and
Mate. They are both outdated and last I tried, Cinnamon didn't even
build for me (bug open for a ~year now).

  https://repology.org/maintainer/cinnamon%40gentoo.org
    outdated: 86.7 %

  https://repology.org/maintainer/mate%40gentoo.org
    outdated: 97.4 %

Mate doesn't seem to be that much behind. Gentoo has 1.22 and latest
release is 1.24. 1.22 was released 2019-03-18, and 1.24 last month. Many
of the packages are outdated in a sense that these packages have minor
releases, which haven't been packaged in Gentoo. Ie 1.22.3.
There was a 1.23 release in-between, but looks like not many distros
packaged that either. (Might be some full-development version?)

Cinnamon on the other hand is _horribly_ outdated. Gentoo has 4.0 while
latest release is 4.4. And as noted, I couldn't even build it while
trying. 4.0.3 was released in Nov 2018, while the latest 4.4.8 Jan 2020.
The have been _numerous_ releases in between.

Should some general consensus be agreed on whether to keep them or
remove them? I feel like we are lying to any new users installing
Gentoo; When they setup their system and boot into installed DE, they
immediately have to resort to some overlay to update it. While they
should get it from the overlay in the first place. Saying, IF they even
manage to build it (Cinnamon). This came up and was discussed in the
Gentoo forums.

There could be more issues these non-maintained big projects cause, like
enabling elogind distrowide.

cinna...@gentoo.org has been assigned to 27 open bugs, m...@gentoo.org
to 33.

This message also works as a call-to-arms with these projects. Even if
people decide to rather keep them in ::gentoo, help and some action is
needed.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-admin/needrestart/

2020-03-09 Thread Joonas Niilola

On 3/9/20 2:51 PM, Craig Andrews wrote:
>
> Removal of that version was a mistake. Thank you for pointing it out.
>
> Here's the commit re-adding it:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f3fa1c548
>
> I checked, and repoman doesn't seem to be warning about removing the
> last stable version of a package.
>
> ~Craig


Neither does pkgcheck for what it's worth. Unless the removal causes a
situation where there are unsatisfied revdeps left.

-- juippis




signature.asc
Description: OpenPGP digital signature


  1   2   >