Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4

[Joonas Niilola]

On 10/27/18 2:16 PM, Michal Prívozník wrote:


That is the case on every mailing list. Every -dev list has number of
subscribes far bigger than number of people with commit access.

But I respect your decision guys. I am going to stop posting patches
until there's an agreement on how to do that.

Michal



Why can't you use Github like _everyone_ else? It's really simple and fast.

Also, as I see, tamiko has been applying all of your (recent) patches, 
so maybe you can ask him to become your personal committer (/ proxied 
maintainer), and send patches via PM so everyone stays happy? :)

[gentoo-dev] Last rites: enlightenment.eclass

[Joonas Niilola]

# @DEAD
# Joonas Niilola  (18 Aug 2018)
# Outdated, unmaintained, not being used by any package in the tree,
# has unattended bugs open.
# Bug: #666460. Removal in ~30 days.

[gentoo-dev] [RFC] skel.ebuild: update for EAPI-7

[Joonas Niilola]

# https://bugs.gentoo.org/679408

# https://github.com/gentoo/gentoo/pull/11253


Started with these PRs, but been left without attention for a long time now:

https://github.com/gentoo/gentoo/pull/10333 &&

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


§ $ diff
--- /usr/portage/skel.ebuild    2019-01-02 12:16:14.469856171 +0200
+++ ./skel.ebuild    2019-03-04 16:56:39.353281559 +0200
@@ -10,7 +10,9 @@
 # It is suggested that you use the latest EAPI approved by the Council.
 # The PMS contains specifications for all EAPIs. Eclasses will test 
for this
 # variable if they need to use features that are not universal in all 
EAPIs.

-EAPI=6
+# If an eclass doesn't support latest EAPI, use the previous EAPI instead.
+EAPI=7
+

 # inherit lists eclasses to inherit functions from. For example, an ebuild
 # that needs the eautoreconf function from autotools.eclass won't work
@@ -89,11 +91,15 @@
 # The below is valid if the same run-time depends are required to compile.
 RDEPEND="${DEPEND}"

+# Build-time dependencies that are executed during the emerge process, and
+# only need to be present in the host system, rather than target. Example:
+#BDEPEND="virtual/pkgconfig"
+
 # Source directory; the dir where the sources can be found (automatically
 # unpacked) inside ${WORKDIR}.  The default value for S is ${WORKDIR}/${P}
 # If you don't need to change it, leave the S= line out of the ebuild
 # to keep it tidy.
-#S=${WORKDIR}/${P}
+#S="${WORKDIR}/${P}"


 # The following src_configure function is implemented as default by 
portage, so

@@ -116,7 +122,7 @@
 #    --mandir=/usr/share/man || die
 # Note the use of --infodir and --mandir, above. This is to make
 # this package FHS 2.2-compliant.  For more information, see
-    #   https://www.pathname.com/fhs/
+    #   https://wiki.linuxfoundation.org/lsb/fhs
 #}

 # The following src_compile function is implemented as default by 
portage, so

[gentoo-dev] Re: [RFC] skel.ebuild: update for EAPI-7

[Joonas Niilola]

Per ulm's review in Github, I've updated the BDEPEND description and 
dropped "host" so it won't be mixed with CHOST.



On 3/4/19 5:02 PM, Joonas Niilola wrote:



+# Build-time dependencies that are executed during the emerge 
process, and
+# only need to be present in the host system, rather than target. 
Example:

+#BDEPEND="virtual/pkgconfig"
+



# Build-time dependencies that are executed during the emerge process, and
# only need to be present in the native build system (CBUILD). Example:
#BDEPEND="virtual/pkgconfig"

Re: [gentoo-dev] [PATCH 2/3] savedconfig.eclass: Always quote filename in output

[Joonas Niilola]

On 8/3/19 11:49 PM, Mike Gilbert wrote:
> On Sat, Aug 3, 2019 at 12:21 PM Ulrich Mueller  wrote:
>>> On Sat, 03 Aug 2019, Thomas Deutschmann wrote:
>>> + ewarn "provide a configuration file in 
>>> ${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig/${CATEGORY}/${PN}"
>> Long line.
> How would you shorten it? Splitting it across 2 lines in the middle of
> the string just makes it less readable.
>
I think he was referring to line length limit by devmanual,

https://devmanual.gentoo.org/ebuild-writing/messages/index.html


Anyway:

  ewarn "provide a configuration file in:"
  ewarn "${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig/${CATEGORY}/${PN}"

doesn't IMHO make it less-readable.


-- Joonas 'juippis' Niilola




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Package up for grabs: app-misc/pip3line

[Joonas Niilola]

Hey,

due to retirement of a maintainer one package is up for grabs:
app-misc/pip3line


It has two bugs open, one pretty severe (and subject of a huge QA
violation)

https://bugs.gentoo.org/690784

https://bugs.gentoo.org/691376


If no one takes it, it's probably gonna be last-rited next.


-- juippis

[gentoo-dev] Last-rite: app-misc/pip3line

[Joonas Niilola]

|

#  Joonas  Niilola(2019-08-31)
#  No  maintainer  and  no  one  stepped  in  to  take  it  after  a  mailing  
#  list  announcement.  Has  QA  issues  and  continuous  CI  issues.  Removal  
#  in  30  days.

#  Bugs:  #690784,  #691376,  #693184
app-misc/pip3line

|

[gentoo-dev] x11-misc/enlightenment-extra: last-rites

[Joonas Niilola]

Upstream decided to deprecate this service, and app. Removal in~30 days. 
Bug #695562.



-- Joonas 'juippis' Niilola

Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

[Joonas Niilola]

On 11/4/19 12:55 PM, Michael 'veremitz' Everitt wrote:
> You can also look up what's currently in use at
> https://api.gentoo.org/uid-gid.txt FYI :]


(481 was updated there after the initial mail was sent) other than that,
its a great resource.


-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

[Joonas Niilola]

On 11/4/19 4:20 PM, William Breathitt Gray wrote:
> Thanks, this document is pretty convenient. It looks like 480 is free;
> would that work for Minetest?
>
> William Breathitt Gray
>

Sure, why not. Always try to check if Fedora & Arch Linux have UID/GID
assigned for your user + group, and/or that the number you reserve for a
new one isn't used for something we're going to need free also in
Gentoo. uid-gid.txt is updated and 480 requested until your PR is
reviewed / merged. Thanks!


-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/4] distutils-r1.eclass: Add distutils_enable_tests to ease testing

[Joonas Niilola]

Beautiful work, but is there a way to integrate "esetup.py test" into
this as well?


-- juippis


On 11/4/19 11:00 PM, Michał Górny wrote:
> Add a helpful function to handle adding common stuff for the most common
> test runners.
>
> Signed-off-by: Michał Górny 
> ---
>  eclass/distutils-r1.eclass | 60 ++
>  1 file changed, 60 insertions(+)
>
> Example ebuild use sent in replies.
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index d3eb8f22ead2..2edffdb2d7c5 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -232,6 +232,66 @@ fi
>  # }
>  # @CODE
>  
> +# @FUNCTION: distutils_enable_tests
> +# @USAGE: 
> +# @DESCRIPTION:
> +# Set up IUSE, RESTRICT, BDEPEND and python_test() for running tests
> +# with the specified test runner.  Also copies the current value
> +# of RDEPEND to test?-BDEPEND.  The test-runner argument must be one of:
> +#
> +# - nose: nosetests (dev-python/nose)
> +# - pytest: dev-python/pytest
> +# - unittest: for built-in Python unittest module
> +#
> +# This function is meant as a helper for common use cases, and it only
> +# takes care of basic setup.  You still need to list additional test
> +# dependencies manually.  If you have uncommon use case, you should
> +# not use it and instead enable tests manually.
> +#
> +# This function must be called in global scope, after RDEPEND has been
> +# declared.  Take care not to overwrite the variables set by it.
> +distutils_enable_tests() {
> + debug-print-function ${FUNCNAME} "${@}"
> + [[ ${#} -eq 1 ]] || die "${FUNCNAME} takes exactly one argument: 
> test-runner"
> +
> + [[ ${EAPI} == [56] ]] && local BDEPEND
> +
> + IUSE+=" test"
> + RESTRICT+=" !test? ( test )"
> + BDEPEND+=" test? ("
> +
> + case ${1} in
> + nose)
> + BDEPEND+=" dev-python/nose[${PYTHON_USEDEP}]"
> + python_test() {
> + nosetests -v || die "Tests fail with ${EPYTHON}"
> + }
> + ;;
> + pytest)
> + BDEPEND+=" dev-python/pytest[${PYTHON_USEDEP}]"
> + python_test() {
> + pytest -vv || die "Tests fail with ${EPYTHON}"
> + }
> + ;;
> + unittest)
> + python_test() {
> + "${EPYTHON}" -m unittest discover -v ||
> + die "Tests fail with ${EPYTHON}"
> + }
> + ;;
> + *)
> + die "${FUNCNAME}: unsupported argument: ${1}"
> + esac
> +
> + BDEPEND+=" ${RDEPEND} )"
> +
> + [[ ${EAPI} == [56] ]] && DEPEND+=" ${BDEPEND}"
> +
> + # we need to ensure successful return in case we're called last,
> + # otherwise Portage may wrongly assume sourcing failed
> + return 0
> +}
> +
>  # @FUNCTION: esetup.py
>  # @USAGE: [...]
>  # @DESCRIPTION:



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

[Joonas Niilola]

On 11/4/19 1:37 AM, William Breathitt Gray wrote:
> Hello,
>
> `games-action/minetest` creates a "minetest" user and group with random
> respective IDs, used for running the Minetest server daemon. The latest
> version bump PR (https://github.com/gentoo/gentoo/pull/13272) follows
> GLEP 81 by creating acct-{group,user}/minetest with 481 assigned as
> their respective IDs.
>
> Is this assignment all right?
>
> Thank you,
>
> William Breathitt Gray
>

Hey,


481 was already requested for mongodb.

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


-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org

[Joonas Niilola]

On 12/4/19 5:21 PM, Kent Fredric wrote:
> On Wed, 04 Dec 2019 13:36:07 +0100
> Michał Górny  wrote:
>
>> My point is: gentoo.org as a HOMEPAGE sucks.  Please use something more
>> specific instead.  Even link to gitweb would be more helpful because it
>> would at least be relevant to the package in question.
> I agree so much I would support the addition of a QA check for this.
>
I take it you haven't checked the CI results lately? Reaction to that
probably spawned this ML thread.

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




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Usefulness of HOMEPAGE=https://www.gentoo.org

[Joonas Niilola]

On 12/4/19 7:26 PM, Michał Górny wrote:
> On Wed, 2019-12-04 at 17:24 +0200, Joonas Niilola wrote:
>> On 12/4/19 5:21 PM, Kent Fredric wrote:
>>> On Wed, 04 Dec 2019 13:36:07 +0100
>>> Michał Górny  wrote:
>>>
>>>> My point is: gentoo.org as a HOMEPAGE sucks.  Please use something more
>>>> specific instead.  Even link to gitweb would be more helpful because it
>>>> would at least be relevant to the package in question.
>>> I agree so much I would support the addition of a QA check for this.
>>>
>> I take it you haven't checked the CI results lately? Reaction to that
>> probably spawned this ML thread.
>>
>> https://qa-reports.gentoo.org/output/gentoo-ci/output.html
> Actually, I've requested that check.  However, I didn't expect that many
> packages to be affected.
>
> Given that it's open season on me lately, and apparently people feel
> offended when bugs are reported for their packages, I've decided to
> start by trying to make people realize the problem globally first.

That's a nice initiatitve. Overall I feel like (global) future CI checks
should be discussed first, because they affect everyone who's
committing, and it feels weird starting to suddenly receive mails about
things you've pushed a hundred times before. As seen by the evergrowing
list of new warnings, people just start to ignore these new checks or
"fix it on next version bump", because knowledge wasn't there on a
previous one.

-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

[Joonas Niilola]

>>> repoman would be more useful for this
>> I wouldn't stop pkgcheck from supporting this, but repoman should as
>> well.
>>
>>
>>
> of course, that's what i meant ;)



Looks like it does now,

https://bugs.gentoo.org/702100

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7bb5d7b074164ceae5f03ddfb40881a7cc6f12dd

(didn't see a reply in this thread about this update)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC acct-{user,group} for unbound

[Joonas Niilola]

Hey,

On 11/26/19 8:33 PM, Thomas Deutschmann wrote:
> I am requesting uid and gid 59, both named "unbound", for
> net-dns/unbound.
>
>
59 was already requested for 'tss' few weeks before this mail was sent.

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

Since 'unbound' acct packages haven't been merged yet, I added 59 for
'tss' to the tree. Fedora uses 59 for 'tss' as well, so I find it fits
better.


-- juippis



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

[Joonas Niilola]

On 12/10/19 1:47 PM, Rich Freeman wrote:
>
> Having UIDs chosen completely at random seems fairly non-optimal.
> Suppose you're building containers/etc and then bind-mounting in
> persistent storage (/var/lib/mysql and so on).  Wouldn't it be nice if
> the default were that mysql would get the same UID on every build?  I
> guess you could provide an initial /etc/passwd on every fresh build
> but it just seems like an extra step.

I was more thinking along sys admins being able to modify their acct-
ebuilds with static numbers. If you're bind-mounting already, why not
bind your portage (or local overlay) to children as well. 2 minute more
work for those who need it, but a lot easier to everyone else who don't
care :)


-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

[Joonas Niilola]

On 12/10/19 3:34 PM, Michał Górny wrote:
>> The problem: There is still no any official documentation about using
>> acct-, and reviewing it was/is pretty much left on the shoulders of one
>> man. It's easy to say on hindsight it was implemented too quickly.
> There is official documentation in devmanual [1].

The _detailed_ one was pushed 2 hours before I made my post, if that's
what you're referencing now.

https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=9613e9e69ae16e6981f90135f92811ded641b52c

How could I have missed it? But yes, it's exactly and finally what was
needed for a long time.


>
> Hence my idea that if we stop requiring mailing list RFC, we can replace
> that with obligatory update to uid-gid.txt.  It should work good enough
> for synchronization.

Mmm, yeah sure, I guess it works better for everyone. I can still
imagine someone pushing acct- ebuilds with colliding UIDs, but at least
the CI checks for duplicates right? So committer should receive a mail
to change their numbers ASAP right? While at least with mailing list RFC
there's a small chance it can be prevented (like was done twice last
week), but the process is indeed more annoying and more manual.


-- juippis





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel

[Joonas Niilola]

Hey,


On 11/27/19 6:52 PM, Anthony G. Basile wrote:
> 3) uid/gid = 485/485 for net-misc/stunnel
>
> Both avahi and tor follow fedora.  The values for stunnel were the
> highest available values below 500.
>
485 has been requested for bedrock though.

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


-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel

[Joonas Niilola]

On 11/27/19 8:21 PM, Anthony G. Basile wrote:
>
>
> 3) For net-misc/stunnel
>
> stunnel uid = 478
> stunnel gid = 478
>
>
I just noticed Tomáš Mózes (hydrapolic) had requested 478 UID+GID for
graylog in 21 Nov. I've just merged it.

Come on people, ctrl+fing your ID in your mail client for the gentoo-dev
ML shows pretty fast if it's been requested or not. Ideally we'd update
uid-gid.txt for every request, but not everyone has commit access /
interest for that...


-- juippis



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Joonas Niilola]

Hey,


On 11/25/19 7:38 PM, Michał Górny wrote:
> Hi,
>
> TL;DR: should we depend on setuptools by default?  Alternatively, should
> we add distutils_enable_setuptools API to provide at least partial
> validity checks.
>
>
> The problem
> ===
> The vast majority of Python packages nowadays uses setuptools as their
> build system.  According to a cheap grep, 1633 out of 2415 packages
> using distutils-r1 depends on it -- and I suspect the vast majority of
> those that do not are simply missing the dependency.

Truthfully I thought distutils already (B)DEPENDed on setuptools, so at
least I've left it out "on purpose". I was recently made aware it
doesn't. No bug reports are made about it, so I think it's safe to
assume setuptools is already present in every system?


>
> Are there valid cases for not using setuptools?  Notably, packages
> needed to bootstrap setuptools aren't using it.  Plus some simple
> packages that really don't need its features.
>
> There are also packages that use setuptools but have distutils fallback.
> We don't like them because switching between build systems involves file
> <-> directory replacement that isn't handled cleanly by our package
> managers.  Therefore, we want to always force one build system in them.
>
> The setuptools dependency is so common it's easy to miss.  Notably, it's
> a prerequisite of specifying package dependencies, so it's normally not
> listed in dependencies.
>
> Finally, while most of the time setuptools is just BDEPEND, there are
> cases when it's RDEPEND as well.  The most common is the use
> of entry_points -- and again, upstreams don't mention it explicitly.
>
> All that considered, I think we should work on providing a better API
> for depending on setuptools, to reduce the number of missing
> dependencies and make it possible to automatically test for them
> (reminder: PMS doesn't permit inspecting *DEPEND).
>
>
> Variant 1: automatic dependency on setuptools
> =
> Basically, we add a new trinary pre-inherit variable:
>
> DISTUTILS_USE_SETUPTOOLS=no
>   -> no deps
> DISTUTILS_USE_SETUPTOOLS=bdepend
>   -> add to BDEPEND (the default)
> DISTUTILS_USE_SETUPTOOLS=rdepend
>   -> add to BDEPEND+RDEPEND
>
> This is roughly 'erring on the safe side'.  The default will work for
> the majority of packages.  We will have to disable it for setuptools
> bootstrap deps, and devs will be able to adjust it to correct values
> as they update ebuilds.  For the time being, existing *DEPEND
> on setuptools will avoid breaking stuff.
>
> This will also enable me to add extra QA checks to esetup.py.  It should
> be able to reasonably detect incorrect value and report it.  This will
> imply some 'false positives' for packages that use the old method of
> specifying setuptools in RDEPEND but that's a minor hassle.
>
> Pros:
> - works out of the box for the majority of packages
> - enables full-range QA checking
>
> Cons:
> - pre-inherit variable
> - some (harmless) false positives on existing packages

I'm a fan of this solution, unless it causes a lot of new CI noise. I
think people are getting fed up with recent changes already, starting to
ignore whatever CI bot says, unless it's fatal.

No harm in double-defining setuptools in BDEPEND right...? (via eclass
and ebuild)


>
>
> Variant 2: distutils_enable_setuptools
> ==
> The alternative method is to add another function
> to the distutils_enable* series:
>
> distutils_enable_setuptools [-r]
>
> The basic form adds it to BDEPEND, -r B+RDEPEND.  Of course, no dep is
> present by default.  The main difference from setting deps explicitly is
> that it permits us to do a minimal QA check between pure BDEPEND
> and B+RDEPEND for now.
>
> When all ebuilds are migrated from explicit dependencies to this method,
> we can also start detecting missing deps completely.  However, that
> presumes we require using this function rather than explicit deps.
>
> Pros:
> - no pre-inherit variables
>
> Cons:
> - only partial QA check possible for the time being
> - requires migrating all ebuilds long-term

I don't like this at this point. This would just bring unwanted noise
and lots of editing in ebuilds. V1 and V3 are better IMHO. This could be
implemented in distutils-r2.eclass, though.


>
>
> Variant 3: leave as-is, add minimal install-qa-check.d
> ==
> We can just continue adding deps manually, and add a minimal install-qa-
> check.d that greps installed scripts for entry_points usage.  This will
> let us detect missing RDEPEND on setuptools but not BDEPEND.
>
> Pros:
> - no changes to ebuilds
>
> Cons:
> - only partial QA check possible

The old way, is also good.


>
>
> WDYT?
> =
> Both options have their pros and cons.  I think V1 is the best since it
> avoids a common mistake, and gives full range QA check.  It also doesn't
> interfere with existing deps.  V2 neatly fits into the 

Re: [gentoo-dev] UID/GID assignment for kibana

[Joonas Niilola]

Hey,


On 9/20/19 7:12 PM, Tomas Mozes wrote:

Hi there,
while trying to implement glep 81 for kibana I found out that Arch 
Linux uses uid 183 for it, but it's taken by qmail.eclass. Should a 
new uid/gid be taken or it's safe to assume no one will mix kibana 
with qmail?



I can't find this info anywhere. There's a pull request currently open 
for acct-*/qmail stuff, that seems to reserve 200+ for it (like shown in 
uid-gid.txt). Nothing seems to reserve 183 as far as I can tell?


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

 - 
https://github.com/gentoo/gentoo/pull/12898/files#diff-bb8c77449e92c212844f37fc9a56e12aL105



-- juippis

Re: [gentoo-dev] Re: RFC: GID/UID assignment for epmd service (334)

[Joonas Niilola]

On 10/5/19 11:18 PM, Petr Vaněk wrote:
>
> Oh, I see.
>
> I would like to reserve 335 for epmd than :) I'll change the PR
> https://github.com/gentoo/gentoo/pull/13141 appropriately. Should I do
> the PR to api-gentoo-org as well?
>
> Petr
>

Hey,

I'd say make a pull request IF after merging, the dev who committed
forgets to update that list. I think so far nothing has been left out,
but lately there have been a lot of these UID/GID updates so it may happen.


-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

[Joonas Niilola]

Hey,

On 12/9/19 10:17 AM, Michał Górny wrote:
> Hello,
>
> I think the policies proposed in GLEP 81 [1] were overenthusiastic
> and they don't stand collision with sad Gentoo developer reality. 
> Instead of improving the quality of resulting packages, they rather
> hamper their adoption and cause growing frustration.
>
> The problems I see today are:
>
>
> 2. Mailing list reviews don't serve their original purpose.
>
> The original purpose of mailing list reviews was to verify that
> the developers use new packages correctly.  For example, Michael
> Orlitzky has found a lot of unnecessary home directories specified.
> Of course, that works only if people submit *ebuilds* for review.
>
> However, at some points developers arbitrarily decided to send only
> numbers for review.  This defeats the purpose of the review in the first
> place.

The problem: There is still no any official documentation about using
acct-, and reviewing it was/is pretty much left on the shoulders of one
man. It's easy to say on hindsight it was implemented too quickly.


>
>
> 4. Assignment mechanism is not collision-prone.
>
> The secondary goal of mailing list reviews is to prevent UID/GID
> collisions.  Sadly, it doesn't work there either.  Sometimes two people
> request the same UID/GID, and only sometimes somebody else notices.
> In the end, people have hard time figuring out which number is the 'next
> free', sometimes they discover the number's been taken when somebody
> else commits it first.

If I remember correctly, at one point it was agreed not to paste ebuilds
because they all just looked similar, but just ask for IDs?


>
>
> All that considered, I'd like to open discussion how we could improve
> things.
>
> My proposal would be to:
>
> a. split the UID/GID range into 'high' (app) and 'low' (system)
> assignments, 'high' being >=100 and 'low' <100 (matching Apache suEXEC
> defaults),
>
> b. UIDs/GIDs in the 'high' range can be taken arbitrarily (recommending
> taking highest free), while in the 'low' range must be approved by QA,
>
> c. no review requirement for the 'high' range, just choose your UID/GID
> straight of uid-gid.txt and commit it,
>
> d. strong recommendation to use matching UID/GID for the same user/group
> name.
>
> WDYT?
>
>
> [1] https://www.gentoo.org/glep/glep-0081.html


I think none of the above really prevent collisions for unmotivated
people. They also still require manual update of uid-gid.txt, and it
can't be expected everyone does it. Now this is not of a big interest to
devs, but I believe committing non-dev acct's will get hard here,
because there might be some "lag" with their contributions vrt. the
current situation.


Honestly I'd say just put -1 on all acct- packages then let sys admins
modify them locally to whatever they need. I feel like this whole GLEP
just serves the minority while making many other contributors uneasy.

-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v2 2/2] metadata/qa-policy.conf: Include deprecated eclasses

[Joonas Niilola]

On 2/26/20 3:19 PM, Michał Górny wrote:
> Signed-off-by: Michał Górny 
> ---
>  metadata/qa-policy.conf | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/metadata/qa-policy.conf b/metadata/qa-policy.conf
> index b6ad90337103..f8d4fb34af08 100644
> --- a/metadata/qa-policy.conf
> +++ b/metadata/qa-policy.conf
> @@ -59,3 +59,16 @@ PG0704 = warning
>  PG0803 = warning
>  # User and group account policy
>  PG0901 = warning
> +
> +
> +# The deprecated-eclass section lists deprecated eclasses along with
> +# their suggested replacements (if any).  Most of the values are
> +# replacement eclass names, though free-form text is permitted.
> +[deprecated-eclass]
> +base = (none)
> +epatch = (eapply since EAPI 6)
> +games = (none)
> +ltprune = (inline find ... -delete)
> +mono = mono-env
> +user = (GLEP 81 acct-* packages)
> +versionator = eapi7-ver (built-in since EAPI 7)


autotools-multilib -> multilib-minimal and autotools-utils -> ?


-- juippis




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Package up for grab: app-crypt/scute

[Joonas Niilola]

app-crypt/scute up for grabs due to retirement of a proxy-maintainer.
One bug open requesting a version bump.


-- juippis



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last-rites: net-misc/wicd

[Joonas Niilola]

# Stagnant upstream with latest release from 2016, python2-only, no
maintainer
# in Gentoo, no notable ebuild action in years, multiple bugs open. Blocks
# pygtk removal.
# Switch to alternatives such as,
# net-misc/connman, net-misc/dhcpcd, net-misc/netifrc,
net-misc/NetworkManager
# and so on. Removal in ~90 days. #

90-day removal window due it possibly being used in low-maintenance servers.

Updated openrc ebuilds to not suggest installing wicd anymore but
connman instead,
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1a177f32dc3c792f5fc69f144b1728a705e1fba



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[Joonas Niilola]

On 2/11/20 12:32 PM, Francesco Riosa wrote:
>
>
> Il giorno lun 10 feb 2020 alle ore 08:20 Michał Górny
> mailto:mgo...@gentoo.org>> ha scritto:
>
> On Sun, 2020-02-09 at 22:51 -0800, Zac Medico wrote:
> > In that case, I suppose we'll have to apply consistency
> manually? Can we
> > all agree on a global order of preference for the relevant packages?
>
> That would be my idea, yes.  I'd suggest going for the 'lightest'
> package first.  Would you be able to figure out some kind of measure
> on how heavy each of those packages is?  I suppose we need to account
> for build time and dependencies.
>
> All of these packages are pretty old and not receiving commits in
> years, may I suggest that the order should be from the less prone to
> break to the most prone to break?

How do you determine this?


> I'll leave to maintainers decide on how to assign a vote on resilience,

Ah. So no.


Whats wrong with simply sorting by alphabetic order? Elinks seems a fine
default for those who don't care enough to change it.


-- juippis



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC v2] News item: OpenSSH 8.2_p1 running sshd breakage

[Joonas Niilola]

On 2/19/20 11:32 PM, Patrick McLean wrote:
> Title: OpenSSH 8.2_p1 running sshd breakage
> Author: Patrick McLean 
> Posted: 2020-02-21
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: 
> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
>
> Before restarting sshd, it is *strongly* recommended that you test your
> configuraton with the following command (as root):
> sshd -t
>
> If your system is booted with openrc, use this command  (as root) 

double space (inconsistent with similar sentence below)


> to restart sshd:
> rc-service sshd --nodeps restart
>
> If your system is booted with systemd, use this command (as root)
> to restart sshd:
> systemctl restart sshd
>
> If you are using systemd socket activation for sshd, then no action is
> required.
>
> WARNING: On systemd booted machines with PAM disabled, this command
>  will terminate all currently open ssh connections. It is *strongly*
>  recommended that you validate your configuration before restarting
>  sshd.
>
This is pretty much just nitpicking, but

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

"The text body should be wrapped at 72 characters. No fancy formatting
or tab characters should be used — the news item may be being displayed
directly to a terminal. Paragraphs should be separated by a blank line."

The 72 char limit breaks 4 times.


LGTM.


-- juippis




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rite: net-im/silc-toolkit

[Joonas Niilola]

# Leftover from silc* removal (#522916), unmaintained, no upstream
# releases since 2014, EAPI-4. #705462
# Removal in ~14 days.

-- juippis


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rite: net-im/silc-toolkit

[Joonas Niilola]

On 1/16/20 5:58 AM, Joonas Niilola wrote:
> # Leftover from silc* removal (#522916), unmaintained, no upstream
> # releases since 2014, EAPI-4. #705462
> # Removal in ~14 days.
>
> -- juippis

Reverted since pidgin still uses it, and it seems to work.

-- juippis



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: net-im/silc-toolkit

[Joonas Niilola]

On 1/19/20 5:44 AM, David Seifert wrote:
> On Sat, 2020-01-18 at 23:48 +, Michael 'veremitz' Everitt wrote:
>> On 18/01/20 22:12, David Seifert wrote:
>>> # David Seifert  (2020-01-18)
>>> # Leftover from silc* removal (#522916), unmaintained, no
>>> # upstream releases since 2014, no revdeps, EAPI-4.
>>> # Bug #705462. Removal in 14 days.
>>> net-im/silc-toolkit
>>>
>>>

After

>> Looks like you missed:
>> https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62


I asked the maintainer if he was ok with

> Looks like you missed:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dfe1c280e312416b3856057ccd6c9f88bcaa1c88

And he acked. I just didn't have time to make the PR so soap stepped in.
So all is good. Thanks.


-- juippis





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] moving uid-gid.txt to metadata

[Joonas Niilola]

On 1/20/20 6:57 PM, William Hubbs wrote:
> All,
>
> as I recall I was one of the folks who suggested that uid-gid.txt should
> go in the api repository, but after thinking about it more and seeing it
> in practice, I see the error of my ways on this. ;-)

What's wrong with it?


>
> Imo a better fit is the metadata directory in the ebuild repository.
> That way you can add users/groups along with the acct-* packages that
> install them.
>
> Thoughts?
>
> William

I think it'd be too easy to 'queue' up work, then ignore conflicts with
UID+GID but push your accts anyway. That's the only downside I came up
with, I don't really mind either way where it is.


-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] net-print/cndrvcups* up for grabs

[Joonas Niilola]

On 10/20/19 1:22 PM, Pacho Ramos wrote:
> Hello
>
> I almost lost access to the unique printer that was relying on this driver.
> Also, even if the current latest version was still working there, it will 
> need a
> major update to newer cnRdrvcups driver sooner or later
> https://aur.archlinux.org/packages/cnrdrvcups-lb/
> https://www.canon-europe.com/support/products/imagerunner/imagerunner-1730i.html?type=drivers=en=linux
>
> Hence, the following packages are up for grabs now
> net-print/cndrvcups-common-lb
> net-print/cndrvcups-lb
>
> Thanks

Hey,

Here's my attempt at updating it. I'd appreciate any kind of testing if
you can before I (possibly) push it to the tree. It's based on current
cndrvcups-lb ebuild, your work I guess? I posted my ebuild and some
additional comments in a bug:

https://bugs.gentoo.org/695896#c2

I could use some help decoding that QA notice too, mentioned in the bug...


-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New acct-* package policy

[Joonas Niilola]

On 1/6/20 2:36 AM, Martin Dummer wrote:
> Am 21.12.19 um 18:32 schrieb Michał Górny:
>> Please commit and push uid-gid.txt [3] change to data/api.git *before*
>> your packages.  This makes sure that any potential collisions are caught
>> as merge conflicts before they hit users.  The CI also catches UID/GID
>> collisions.
>
>
> pull requests.
>
> So for proxy-maintained packages which need acct-user/acct-group ebuilds
> this must be
>
> - either done like before - announcement on the gentoo-dev ML, then
> committed by ???
>
> - or done by a member of the proxy-maintainers group.

- your package will be assigned the next free ID by whoever commits.
(your 2nd option)

From the end-user point it doesn't matter much whether it's 321 or 320
as long as it stays the same after being merged. Although I'm still of
the opinion we should try to **pick** same IDs that other distros use,
but it's already looking desperate for that matter.

But if you have time, please do make a pull request to URL mentioned by
Ralph and Aaron.


>
> Maybe you find the time to refine that exception in the documentation.

I think having some guidance on proxy-maint project wiki page about this
whole acct- thing wouldn't hurt, but it may come a bit too late already.


-- juippis




signature.asc
Description: OpenPGP digital signature

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

[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

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

[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] Packages up for grabs

[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] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader

[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] Last-rite: mask www-misc/zoneminder

[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

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

[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] [RFC] Mask gnome-extra/cinnamon and deps for removal

[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

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

[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] Fwd: New eclass suggestion: docs.eclass

[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: bzr.eclass

[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] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[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

[gentoo-dev] Packages up for grabs: LXDE

[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] Packages up for grabs: LXDE

[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

[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] RFC: Gentoo Identity Provider

[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] State of Cinnamon & Mate projects

[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] rfc: backward-incompatible changes in eclasses

[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

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

[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

[gentoo-dev] Packages up for grabs

[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] optfeature.eclass: New eclass with definition from eutils

[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] How to stabilize packages with frequent release cycles?

[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

[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] New customization options available on packages.g.o

[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] [REVIEW] News Item - 2020-10-17-display-manager-init

[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] [RFC] Refactor display manager openrc init scripts to independent package

[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] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

[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] [PATCH 1/2] java-pkg-simple.eclass and java-utils-2.eclass: features and enhancements

[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

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

[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] RFC: New "Accept Github contributions" metadata flag

[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

[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

[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

Re: [gentoo-dev] Packages up for grabs

[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

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

[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] [virtualization project] Help needed with libvirt virtualization stack

[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] Last rites: app-leechcraft/*, virtual/leechcraft-*

[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] newsitem: k8s split packages returning

[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

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

[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] News item: Multiple root kernel command-line arguments

[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] Package up for grabs: x11-libs/libfm

[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

[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] dev-python/numb-0.40.1.ebuild

[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] RFC: packages.gentoo.org Developer Mode

[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] dev-python/numb-0.40.1.ebuild

[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

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

[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/rstcheck-3.3.1: Add rstcheck python package (#16399)

[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

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

[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] */*: Mask Py2 only packages

[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

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

[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] Re: Add commit to pull request

[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

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

[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

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

[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] Graphics Project disbanded [pkgs up for grabs]

[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-rites: dev-util/cutter

[Joonas Niilola]

# Unmaintained in Gentoo, broken, multiple bugs open.
# Removal in ~30 days. #733324


signature.asc
Description: OpenPGP digital signature

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

[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

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

[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] Non-maintainer commits and CI

[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

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

[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] Last-rites: more broken LiveOnlyPackages

[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

[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

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

[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] Re: Last-rites: sys-block/rts_pstor

[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

[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

[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] Packages & projects up for grabs due to jer's retirement

[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

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

[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