[gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

[Michael 'veremitz7; Everitt]

Hello,

I've noticed a lot of stabilisation commit messages (and a few keywording
ones too) simply state the package atom and not the relevant
release/version. I find this a little meaningless, as unless this is the
first time the package has ever been either stabilised or keyworded, it is
reasonable to expect that there is/was some transition point for a package
from when it first entered the Gentoo Repository.

Therefore, it would be much /more/ useful to have the package-version
tagged in the commit message, so that you could easily grep logs for when a
given version of a package was stabilised, and/or keyworded. Granted, this
is more of-use in a historical context compared to a present (future?!)
one, but I would argue that it conveys more meaning -with- the version than
without.

Thoughts from outside peanut gallery?

Michael / veremitz.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: RFC: Require full $P not just $PN on stable/keyword commit messages

[Michael 'veremitz7; Everitt]

On 01/11/19 19:59, Michael 'veremitz' Everitt wrote:
> Hello,
>
> I've noticed a lot of stabilisation commit messages (and a few keywording
> ones too) simply state the package atom and not the relevant
> release/version. I find this a little meaningless, as unless this is the
> first time the package has ever been either stabilised or keyworded, it is
> reasonable to expect that there is/was some transition point for a package
> from when it first entered the Gentoo Repository.
>
> Therefore, it would be much /more/ useful to have the package-version
> tagged in the commit message, so that you could easily grep logs for when a
> given version of a package was stabilised, and/or keyworded. Granted, this
> is more of-use in a historical context compared to a present (future?!)
> one, but I would argue that it conveys more meaning -with- the version than
> without.
>
> Thoughts from outside peanut gallery?
>
> Michael / veremitz.
>
Also, it's particularly helpful if you have an atom feed of a given
package, to see when versions are stabilised (present and future contexts
covered... ;D)



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

[Michael 'veremitz7; Everitt]

On 01/11/19 21:11, Rich Freeman wrote:
> On Fri, Nov 1, 2019 at 4:36 PM Matt Turner  wrote:
>> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt
>>  wrote:
>>>
>>> Therefore, it would be much /more/ useful to have the package-version
>>> tagged in the commit message, so that you could easily grep logs for when a
>>> given version of a package was stabilised, and/or keyworded.
> git log --format=oneline glibc-2.29-r2.ebuild | grep stable
> 9c04d06d06d51d9c76b3fe5ceb573213769f45ae sys-libs/glibc-2.29-r2: sparc
> stable, bug 685818
> b61ab167e82261ed2078c068ba0c2fc3a7b58aa3 sys-libs/glibc: stable
> 2.29-r2 for hppa, bug #685818
> fad52f75c759ca326ce0f8c37e227827f01cd2f1 sys-libs/glibc: m68k stable
> wrt bug #685818
> 0fe91535a7ba382f10084def5482e61359f201cb sys-libs/glibc: sh stable wrt
> bug #685818
> 7b7ec9a6b3355d6111e1a449ca13e24cb6ef0295 sys-libs/glibc: s390 stable
> wrt bug #685818
> bcddad6780ead2b44528a4aa1d51107b4a225524 sys-libs/glibc-2.29-r2: alpha stable
> 2ca6a4b9d647f567d2300e7b90829993d7575b41 sys-libs/glibc: ia64 stable
> wrt bug #685818
> e56c3c1f1c0a256c228a59be94869751d7fd31d7 sys-libs/glibc: ppc64 stable
> wrt bug #685818
> 52355459ec00b9ca9921bd5f788bad9b95346910 sys-libs/glibc: ppc stable
> wrt bug #685818
> 745b07e84b5035576737d3e1a719121d02e53feb sys-libs/glibc: arm stable
> wrt bug #685818
> 332fc91e3e72a6dd1b183ce4a19d08b45daa8e00 sys-libs/glibc: x86 stable
> (bug #685818)
> 9e06c1242e104b66a532e7d5d919c1b3b1f8343d sys-libs/glibc: arm64 stable
> (bug #685818)
> b3ad265998a04a40820d078d25c06b7cb51173ef sys-libs/glibc: amd64 stable
> wrt bug #685818
>
> Seems to work fine for me.
>
>
How well does git handle that when the ebuild is deleted from the tree?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

[Michael 'veremitz7; Everitt]

On 01/11/19 21:45, Mike Gilbert wrote:
> On Fri, Nov 1, 2019 at 5:34 PM Michael 'veremitz' Everitt
>  wrote:
>> On 01/11/19 21:11, Rich Freeman wrote:
>>> On Fri, Nov 1, 2019 at 4:36 PM Matt Turner  wrote:
>>>> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt
>>>>  wrote:
>>>>> Therefore, it would be much /more/ useful to have the package-version
>>>>> tagged in the commit message, so that you could easily grep logs for when 
>>>>> a
>>>>> given version of a package was stabilised, and/or keyworded.
>>> git log --format=oneline glibc-2.29-r2.ebuild | grep stable
>>> 9c04d06d06d51d9c76b3fe5ceb573213769f45ae sys-libs/glibc-2.29-r2: sparc
>>> stable, bug 685818
>>> b61ab167e82261ed2078c068ba0c2fc3a7b58aa3 sys-libs/glibc: stable
>>> 2.29-r2 for hppa, bug #685818
>>> fad52f75c759ca326ce0f8c37e227827f01cd2f1 sys-libs/glibc: m68k stable
>>> wrt bug #685818
>>> 0fe91535a7ba382f10084def5482e61359f201cb sys-libs/glibc: sh stable wrt
>>> bug #685818
>>> 7b7ec9a6b3355d6111e1a449ca13e24cb6ef0295 sys-libs/glibc: s390 stable
>>> wrt bug #685818
>>> bcddad6780ead2b44528a4aa1d51107b4a225524 sys-libs/glibc-2.29-r2: alpha 
>>> stable
>>> 2ca6a4b9d647f567d2300e7b90829993d7575b41 sys-libs/glibc: ia64 stable
>>> wrt bug #685818
>>> e56c3c1f1c0a256c228a59be94869751d7fd31d7 sys-libs/glibc: ppc64 stable
>>> wrt bug #685818
>>> 52355459ec00b9ca9921bd5f788bad9b95346910 sys-libs/glibc: ppc stable
>>> wrt bug #685818
>>> 745b07e84b5035576737d3e1a719121d02e53feb sys-libs/glibc: arm stable
>>> wrt bug #685818
>>> 332fc91e3e72a6dd1b183ce4a19d08b45daa8e00 sys-libs/glibc: x86 stable
>>> (bug #685818)
>>> 9e06c1242e104b66a532e7d5d919c1b3b1f8343d sys-libs/glibc: arm64 stable
>>> (bug #685818)
>>> b3ad265998a04a40820d078d25c06b7cb51173ef sys-libs/glibc: amd64 stable
>>> wrt bug #685818
>>>
>>> Seems to work fine for me.
>>>
>>>
>> How well does git handle that when the ebuild is deleted from the tree?
> It handles it just fine, though you need to add "--" to disambiguate
> it from a ref. For example:
>
> git log --format=oneline --grep=stable -- foo-123.ebuild
>
Consider me somewhat enlightened .. (!) :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

[Michael 'veremitz7; Everitt]

On 02/11/19 08:54, Kent Fredric wrote:
> On Fri, 1 Nov 2019 19:59:35 +
> Michael 'veremitz' Everitt  wrote:
>
>> Thoughts from outside peanut gallery?
>>
>> Michael / veremitz.
> I have an alternative that might be more pleasant:
>
> 1. Change repoman so that when its clear that:
>- There is at least one ebuild being changed
>- There is only one ebuild being changed
>   Then the templated summary line is full ${P}
>
> 2. Otherwise, retain the current semantics of using a simpler
>${P} in other cases.
>
> 3. Make no *requirements* that ${P} be used instead of ${PN},
>and that way people who think they have a good reason to use ${PN}
>instead of ${P} can do just that (if for instance, they need to lop
>off context so they can have a longer commit message )
>
> This IMO improves things by default, given that the majority of changes
> get run through repoman, and a majority of changes have very terse
> requirements for extra data.
>
> It also means that by default, when people just make the commit message
> something silly like "bump", or "version bump", despite the fact they
> didn't put in much effort, the log defaults to being useful, and the
> commit messages relayed to #gentoo-commits improves in usefulness.
>
> Partly, because for me, one of my prime vectors where I become aware
> changes are occuring is in #gentoo commits, particularly because
> something in there highlights me.
>
> I don't want to *have* to:
> - Resync my git repo 
> - Dig into git wizardry 
>
> *just* to ascertain what version was involved, and to then ascertain if
> I need to investigate further.
>
> ( Because once I've already synced and started using git wizardry, I'm
> already starting to pay investigation taxes )
>
>
This sounds like a good compromise, and one I'm content to work on. Anyone
else able/willing to pitch in?



signature.asc
Description: OpenPGP digital signature

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

[Michael 'veremitz7; Everitt]

On 04/11/19 07:57, Tomas Mozes wrote:
>
> On Mon, Nov 4, 2019 at 4:50 AM Joonas Niilola  > wrote:
>
>
> 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
>
>
> Sorry, I haven't seen this UID/GID in the ML so I used it, haven't
> checked the PRs on github. Next time, please send a mail to the ML along
> with the PR creation.
>
> Thanks,
> Tomas 
You can also look up what's currently in use at
https://api.gentoo.org/uid-gid.txt FYI :]


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

[Michael 'veremitz7; Everitt]

On 04/11/19 23:17, Michael Orlitzky wrote:
> On 11/4/19 2:40 PM, William Hubbs wrote:
>>
>> This is a whole other thread I've been talking about for years, but if
>> we want to be concerned about dumping "garbage" on people's limited root
>> file systems, there are other things we need to re-consider, like our
>> notion that we have to install small files everywhere even though they
>> aren't always used.
>>
>> So, if you want to talk about that, please start a whole new thread.
>>
>
> 1. The idea that we should fix all existing problems before we can
>    prevent people from creating new ones is ridiculous.
>
> 2. Those other files don't get installed to the root filesystem on the
>    systems that we're talking about.
>
> 3. Those other files generally aren't completely useless.
>
> 4. "small files" aren't big.
>
>
Straw man anyone? I know Guy Fawkes night is coming up here in the UK ... ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode

[Michael 'veremitz7; Everitt]

On 16/11/19 16:59, Matt Turner wrote:
> On Sat, Nov 16, 2019 at 1:06 AM Jaco Kroon  wrote:
>> Hi,
>>
>> On 2019/11/15 21:35, Matt Turner wrote:
>>> On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller  wrote:
 The package is somewhat redundant, because sys-kernel/linux-firmware
 installs the same files. (Same for all other sys-firmware/iwl*-ucode
 packages.)
>>> Should last-rite all of them, IMO.
>>>
>> I both agree and disagree with this.  It's the simpler solution and
>> therefore I agree.
>>
>> I disagree because in some cases I really only want specific firmware
>> for specific sets of hardware (especially where space constraints are an
>> issue, read: embedded type systems).
>>
>> The current linux-firmware package is getting quite big in terms of install.
> USE=savedconfig allows you to choose exactly which files to install :)
>
I've never found a good way (yet...) to figure out how to write a fresh new
'savedconfig' if you haven't ever previously emerged the package in
question. Does anyone have a good method for this, that doesn't require
unpacking the whole nine yards (Megs, Gigs...) first?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: app-misc/toilet

[Michael 'veremitz7; Everitt]

On 17/11/19 02:07, Aaron Bauman wrote:
> On Sat, Nov 16, 2019 at 08:29:58PM -0500, Aaron Bauman wrote:
>> # Aaron Bauman  (2019-11-16)
>> # EAPI=4. --filter=gay Really?!
>> # Removal in 15 days
>> app-misc/toilet
>>
>> -- 
>> Cheers,
>> Aaron
> Add the following as it is an rdep
>
> net-irc/rbot
>
OOps, there goes willikins ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Addressing split usage of USE=gles[123]

[Michael 'veremitz7; Everitt]

On 21/11/19 21:53, Dennis Schridde wrote:
> On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote:
>> See also this related old thread:
>> https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09
>> 211
> I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good
> idea.  Generally, all these probably have to distinguish between "support for
> XYZ" and "use only XYZ", the latter hopefully being the exception, so that the
> former can take the shorter use-flag.  That's what I don't like about the
> proposal from 2018: Globally enabling USE=gles will have different effects on
> different packages.  That's also what I like about the recent proposal: The
> flags are more explicit.
>
> --Dennis
I don't think the problem is so much in the principle of making a change,
or even the specifics of any particular permutation of change, it's who
gets to manage and implement the change in a maintainable fashion, and who
has to deal with the fallout of any changes occurring where a particular
scenario 'slips through the net'

If you can convince the latter people that there is no problem arising from
making said changes, and you ensure that there genuinely *is* minimal
impact (by whatever means) then you stand a much better chance of this
change actually being implemented ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Perspectives on improving (dis-hacking) python-single-r1

[Michael 'veremitz7; Everitt]

On 24/11/19 16:06, Francesco Riosa wrote:
> Since we are here ...
> I'd still like to see some way to adopt latest python version if user
> wants to.
> One way it could work is that we add a "LATEST" to PYTHON_TARGETS that
> would always build against best version of python.
> To avoid complications if a new version of python is emerged together
> with other packages it must always include also a numeric version like 3_8
>
> Regarding your proposal getting rid of PYTHON_SINGLE_TARGET would be nice
> but being able to have multiple version of python installed is nicer and
> differentiate gentoo from most other distro
>
> Alternative 2 is also nice, the only thing that make me dubious is that
> it looks like it will be a gigantic work, but you have a better sense of
> the situation and will be one of those doing the actual work, so go for it!
Most distros have (or haD) .. python2 and python3 (not necessarily each
with their suffix) in their repo's .. but being able to have multiple
branches of either is certainly a feature IMHO.

I'm certainly for re-working the PYTHON_[SINGLE_]TARGETS dependencies, as
they can often get 'screwed up' when upgrading between versions, and
updating packages in between, and all quickly gets out of sync, and
requires a lot of hacking to fix up properly.



signature.asc
Description: OpenPGP digital signature

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

[Michael 'veremitz7; Everitt]

On 02/12/19 06:23, Joonas Niilola wrote:
>
>
> 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
>
surely if you have commit access to gentoo.git you can update uid-gid.txt ?
how hard can it be?! 


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: dev-python/* leaf packages

[Michael 'veremitz7; Everitt]

On 05/12/19 00:15, Aaron Bauman wrote:
> Fellow devs,

> dev-python/sqlitecachec
> dev-python/supervisor-quick
> dev-python/python-cdb
> dev-python/fabric
^ https://github.com/mathiasertl/fabric/ is a fork of fabric for py3.4+
FYI. Also on PyPi at https://pypi.org/project/Fabric3/.
> dev-python/foolscap
> net-fs/tahoe-lafs
> dev-python/pyvtk


HTH,
veremitz/Michael.



signature.asc
Description: OpenPGP digital signature

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

[Michael 'veremitz7; Everitt]

On 06/12/19 15:41, Matt Turner wrote:
> On Fri, Dec 6, 2019 at 5:51 AM Alexis Ballier  wrote:
>> On Fri, 6 Dec 2019 04:33:36 -0500
>> Tim Harder  wrote:
>>
>>> On 2019-12-06 Fri 04:03, Alexis Ballier wrote:
 it's not just like repoman and cvs since repoman commit did push ;)
 it will never be perfect but i really like repoman commit to refuse
 to even commit if there's something obviously wrong
>>> I'm more of the opinion (and am working towards that practicality in
>>> terms of runtime speed) that a subset of QA checks should be run as a
>>> git hook which would cause push failures on certain classes of bad
>>> commits.
>>
>> There should be both. Amending the 23rd commit message because one
>> mistyped a semicolon is kind of a PITA.
> It is?
>
> git rebase -i HEAD~23
>
> Is that what you think is a pain in the ass, or do you not know about
> interactive rebase? :)
>
I hope you're not suggesting a rebase of any sort in gentoo.git, Matt  ;)



signature.asc
Description: OpenPGP digital signature

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

[Michael 'veremitz7; Everitt]

On 06/12/19 16:28, Mike Gilbert wrote:
> On Fri, Dec 6, 2019 at 10:46 AM Michael 'veremitz' Everitt
>  wrote:
>> I hope you're not suggesting a rebase of any sort in gentoo.git, Matt  ;)
> He's talking about rebasing local commits that haven't yet been
> pushed. That's perfectly normal.
>
Fair .. it was a very tongue-in-cheek remark .. fwiw.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Michael 'veremitz7; Everitt]

On 06/12/19 20:10, Andreas Sturmlechner wrote:
> On Friday, 6 December 2019 20:47:31 CET Thomas Deutschmann wrote:
>> On 2019-12-06 17:44, Mike Gilbert wrote:
>>> 1. Keep the old version installed.
>>> 2. Emit a confusing error message to the user since the use-dependency
>>> on dev-python/example[python_targets_python2_7] cannot be resolved
>>> with the latest visible version.
>> I don't fully understand #2 to be honest but yes, you will be cut off
>> from latest version at some point. Same in PHP.
> Considering that above statement, I would expect a bit more humility than the 
> following:
>
>> Maybe someday one of those responsible will admit that this step was not
>> a thoughtful and good decision and promise not to do it that way again
>> and I'll get over it. Who knows. :)
> Just so we're on the same page, a recent example of what some people 
> suggesting to keep py27 ad nauseam are asking users to deal with:
>
>
>
> # emerge -uDpv @world
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
> Total: 0 packages, Size of downloads: 0 KiB
>
> WARNING: One or more updates/rebuilds have been skipped due to a dependency 
> conflict:
>
> dev-python/sphinx:0
>
>   (dev-python/sphinx-2.0.1:0/0::gentoo, ebuild scheduled for merge) conflicts 
> with
> >=dev-python/
> sphinx-1.5.3[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/sphinxcontrib-websupport-1.1.0:0/0::gentoo, installed)
>   
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/cython-0.29.4:0/0::gentoo, installed)
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/flask-babelex-0.9.3:0/0::gentoo, installed)
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/testtools-2.3.0:0/0::gentoo, installed)
>   
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/pytest-runner-4.2:0/0::gentoo, installed)
>   
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/flask-babel-0.11.2-r2:0/0::gentoo, installed)
>   
>   
>   
> 

Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds

[Michael 'veremitz7; Everitt]

On 14/12/19 12:03, Kent Fredric wrote:
> On Sat, 14 Dec 2019 08:16:03 +0100
> Ulrich Mueller  wrote:
>
>> These prevent NOCOLOR in make.conf or emerge --color=n from working
>> correctly, and I guess they are also problematic from an accessibility
>> point of view.
>>
>> Are there any objections against removing these sequences from strings?
>> AFAICS, they are used by less than ten packages, and one eclass.
> Maybe we can have some future EAPI feature, or special eclass, that
> allows people to add escape codes while also respecting the
> configuration.
>
> Sort of like what git has in its formatting codes, where they're turned
> off when colours are turned off.
>
>   hl 1 "${@}"  # because 'hl' inherently behaves like echo when not captures 
>   einfo "Fetching $(hl "${r}" ) ..."
>
> Or something along those lines?
>
> I'd wager that a large body of things "not using it" is not because
> it wouldn't be useful, but due to people knowing this problem exists?
>
> -- Further Bikeshed --
>
> Maybe it could even be thematic?
>
>"Fetching $(hl url https://path.to/whatever )"
>
> Nah.
>
> But < hl   > as a general concept works.
>
Something that could be included in gentoo-functions script(s)?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs due to slis' retirement

[Michael 'veremitz7; Everitt]

On 18/12/19 22:33, Michał Górny wrote:
> Hi,
>
> Due to slis retiring, the following packages are now in need of a new
> maintainer:
>
> [ v] app-arch/wimlib
> [ v] dev-embedded/lpc21isp
> [b?] dev-libs/libflatarray
> [  ] dev-libs/libpfm
> [bv] dev-libs/papi
> [ v] dev-python/aldryn-
> boilerplates
> [ v] dev-python/aldryn-common
> [ v] dev-python/click-plugins
> [
> v] dev-python/cligj
> [ v] dev-python/django-durationfield
> [ v] dev-
> python/django_polymorphic
> [ v] dev-python/django-sortedm2m
> [bv] dev-
> python/django-spurl
> [ v] dev-python/easy-thumbnails
> [ v] dev-
> python/ipdbplugin
> [bv] dev-python/Kivy
> [  ] dev-python/kivy-garden
> [  ]
> dev-python/munch
> [ v] dev-python/scoop
> [  ] dev-python/URLObject
> [ v] dev-
> python/YURL
> [b ] media-gfx/librecad
> [b ] media-gfx/pycam
> [b ] media-
> libs/assimp
> [S ] net-analyzer/ntopng
> [  ] net-libs/nDPI
> [ v] sci-libs/deap
> [
> v] sci-libs/Fiona
> [b?] sci-libs/libgeodecomp
> [ v] sci-libs/pyshp
> [ v] sci-
> libs/Rtree
> [  ] sci-libs/Shapely
> [bv] sci-misc/repsnapper
> [bv] sci-
> visualization/visit
> [bv] sys-cluster/hpx
>
> Legend:
> b - package has (regular) bugs
> S - package has vulnerabilities reported
> v - package needs version bump
>
There is some very strange wrapping/formatting in this message, was that
intentional?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michael 'veremitz7; Everitt]

On 21/12/19 11:52, Ulrich Mueller wrote:
>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
>> And for the record, commenting on standards in response to a series of
>> commits that display low standards is not a personal attack.
> *shrug* As a matter of fact, I've run that series of commits past the
> QA lead, who has approved them.
>
FWIW, the QA lead doesn't always reflect the opinion of the whole QA team ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

[Michael 'veremitz7; Everitt]

On 28/12/19 11:05, Kent Fredric wrote:
> On Sat, 28 Dec 2019 10:35:09 +0100
> Fabian Groffen  wrote:
>
>> Hmmm, interested to hear what kind of things you're thinking about here.
> A lot of the "Work" of filing a keyword request is modelling all the
> consequential keywordings that have to take place.
>
> If there was say, a web based UI, that:
>
> - Automatically determined which packages are ready for stabilization
>   due to all their dependencies already being stable (and maybe with
>   automatic cooldown-from-testing detection )
>
> - Automatically determined which packages can be keyworded without
>   additional work due to all their dependencies being keyworded


I know I'm gonna be shot down in flames, because $heresy, but here is where
a package 'database' would actually work quite well, because you can
trivially create a query that pulls this data out, and sorts it by package
category or maintainer or whatever you like ..

Ok, let the flamewars begin ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

[Michael 'veremitz7; Everitt]

On 28/12/19 11:32, Kent Fredric wrote:
> On Sat, 28 Dec 2019 11:14:15 +
> Michael 'veremitz' Everitt  wrote:
>
>> I know I'm gonna be shot down in flames, because $heresy, but here is where
>> a package 'database' would actually work quite well, because you can
>> trivially create a query that pulls this data out, and sorts it by package
>> category or maintainer or whatever you like .
> Oh, and once upon a time, there was actually a trick you could do to
> make portage keep its metadata caches in an SQLite database, which had
> its benefits, and I even had a rough tool I wrote in ruby and shared on
> the old (defunct) wiki that helped do quick database queries.
>
> But the trick actually makes portage slower in multiple ways, and it
> never really got widespread love.
>
> ( Though I would argue how the data was stored was also inadequate for
> a lot of other tasks one might want to do with a database, like,
> keeping DEPEND stored in its string format )
Note:  we're nnot acttually talking about replacing portage here, just
creating a tool thiink php script web tthingy)) that will do some of
the pre-screeninng wok that AT hate (eg what kensiington did  with
stable-bbot)

* with apologies for keyboard/remote-access la creating typo hell.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Handle recursive submodules in EGIT_SUBMODULES

[Michael 'veremitz7; Everitt]

On 30/12/19 13:30, Michał Górny wrote:
> Match recursive submodules using their full paths rather than path
> relatively to the parent submodule.
>
> Closes: https://bugs.gentoo.org/694494
> Signed-off-by: Michał Górny 
> ---
>  eclass/git-r3.eclass | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
> index 144236c6ac38..663fd939b295 100644
> --- a/eclass/git-r3.eclass
> +++ b/eclass/git-r3.eclass
> @@ -401,16 +401,22 @@ _git-r3_set_gitdir() {
>  }
>  
>  # @FUNCTION: _git-r3_set_submodules
> -# @USAGE: 
> +# @USAGE:  
>  # @INTERNAL
>  # @DESCRIPTION:


How is this backward compatible?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Handle recursive submodules in EGIT_SUBMODULES

[Michael 'veremitz7; Everitt]

On 30/12/19 14:11, Michał Górny wrote:
> On Mon, 2019-12-30 at 14:03 +0000, Michael 'veremitz' Everitt wrote:
>> On 30/12/19 13:30, Michał Górny wrote:
>>> Match recursive submodules using their full paths rather than path
>>> relatively to the parent submodule.
>>>
>>> Closes: https://bugs.gentoo.org/694494
>>> Signed-off-by: Michał Górny 
>>> ---
>>>  eclass/git-r3.eclass | 27 +++
>>>  1 file changed, 19 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
>>> index 144236c6ac38..663fd939b295 100644
>>> --- a/eclass/git-r3.eclass
>>> +++ b/eclass/git-r3.eclass
>>> @@ -401,16 +401,22 @@ _git-r3_set_gitdir() {
>>>  }
>>>  
>>>  # @FUNCTION: _git-r3_set_submodules
>>> -# @USAGE: 
>>> +# @USAGE:  
>>>  # @INTERNAL
>>>  # @DESCRIPTION:
>> 
>>
>> How is this backward compatible?
>>
> This is an internal function.
>
Ah thanks. id10t check passed! :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies

[Michael 'veremitz7; Everitt]

On 02/01/20 21:08, Michał Górny wrote:
> On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote:
>>> On Thu, 02 Jan 2020, Michał Górny wrote:
>>> --- a/eclass/ruby-ng.eclass
>>> +++ b/eclass/ruby-ng.eclass
>>> @@ -137,7 +137,7 @@ ruby_samelib() {
>>> local res=
>>> for _ruby_implementation in $(_ruby_get_all_impls); do
>>> has -${_ruby_implementation} $@ || \
>>> -   res="${res}ruby_targets_${_ruby_implementation}?,"
>>> +   res="${res}ruby_targets_${_ruby_implementation}(-)?,"
>>> done
>>>  
>>> echo "[${res%,}]"
>> Hadn't we established that ruby_samelib() is dead code, no longer used
>> since 2010?
>>
> You did.  However, it isn't marked as private API and I'm not the eclass
> maintainer to take care of removing public API.  I have no clue if Ruby
> project doesn't have some secret overlays using it.
>
 You can't use QA super-powerz ?! BDFL + sub-BDFL ?! *

* Thought the tags probably worth making explicit



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

[Michael 'veremitz7; Everitt]

On 02/01/20 23:35, Rolf Eike Beer wrote:
> Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
>> On Thursday, January 2, 2020 3:32:12 PM EST Rolf Eike Beer wrote:
 - Allowed a simple "Add keyword(s)  for package " interface,

   that intelligently created an issue and a target list, and then once
   the list was built, constantly ensured the list to be valid, or
   determined automatically when sub-work was completed and reducing the
   published list automatically, and then responded to potential issues
   based on changes in git, ( as opposed to being only triggered when
   the bug was touched )
>>> As someone who does both keywordings and stabilizations regularly on hppa
>>> and sparc I think I must share a bit of my experiences:
>> 
>>
>> hppa is making us keep old kernels around [1].  Should the kernel team be
>> doing more to get your attention then CC'ing hppa on all of the kernel
>> STABLEREQ bugs [2]?
> I only run vanilla-sources since there are still lot of cache corruption 
> problems in hppa kernels, or whatever makes them flaky.
>
> Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64 
> PA8800 (Mako) 9000/785/C8000 GNU/Linux
> Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600 (PCX-
> W+) 9000/785/C3600 GNU/Linux
>
> So _I_ personally would say just drop old kernels, but that is in no way 
> authorative.
>
> Eike
Is it viable at all to test gentoo-sources or would it be better simply to
unkeyword?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Vanilla sources

[Michael 'veremitz7; Everitt]

On 03/01/20 14:48, Toralf Förster wrote:
> On 1/3/20 3:46 PM, Rich Freeman wrote:
>> If OpenRC contains a vulnerability wouldn't it make more sense to set
>> this as part of OpenRC,
> Indeed.
>
> Furthermore there's a nifty page 
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
> which yields for me to this /etc/sysctl.d/local.conf :
>
>
> #   Restrict potential illegal access via links
> # 
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1 
>
> #
> # https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#CONFIGs
> #
>
> # Try to keep kernel address exposures out of various /proc files (kallsyms, 
> modules, etc).
> kernel.kptr_restrict = 1
>
> # Avoid kernel memory address exposures via dmesg.
> kernel.dmesg_restrict = 1
>
> # Block non-uid-0 profiling (needs distro patch, otherwise this is the same 
> as "= 2")
> kernel.perf_event_paranoid = 3
>
> # Turn off kexec, even if it's built in.
> kernel.kexec_load_disabled = 1
>
> # Avoid non-ancestor ptrace access to running processes and their credentials.
> kernel.yama.ptrace_scope = 1
>
> # Disable User Namespaces, as it opens up a large attack surface to 
> unprivileged users.
> user.max_user_namespaces = 0
>
> # Turn off unprivileged eBPF access.
> kernel.unprivileged_bpf_disabled = 1
>
> # Turn on BPF JIT hardening, if the JIT is enabled.
> net.core.bpf_jit_harden = 2
>
>
FWIW, there is a move to add further hardening options to the
Gentoo-sources kernel - bug 689154, based on the kernsec recommendations.
Further details of proposals, and inspiration, are in the bug.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies

[Michael 'veremitz7; Everitt]

On 03/01/20 10:36, David Seifert wrote:
> On Thu, 2020-01-02 at 21:54 +0000, Michael 'veremitz' Everitt wrote:
>> On 02/01/20 21:08, Michał Górny wrote:
>>> On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote:
>>>>>>>>> On Thu, 02 Jan 2020, Michał Górny wrote:
>>>>> --- a/eclass/ruby-ng.eclass
>>>>> +++ b/eclass/ruby-ng.eclass
>>>>> @@ -137,7 +137,7 @@ ruby_samelib() {
>>>>>   local res=
>>>>>   for _ruby_implementation in $(_ruby_get_all_impls); do
>>>>>   has -${_ruby_implementation} $@ || \
>>>>> - res="${res}ruby_targets_${_ruby_impleme
>>>>> ntation}?,"
>>>>> + res="${res}ruby_targets_${_ruby_impleme
>>>>> ntation}(-)?,"
>>>>>   done
>>>>>  
>>>>>   echo "[${res%,}]"
>>>> Hadn't we established that ruby_samelib() is dead code, no longer
>>>> used
>>>> since 2010?
>>>>
>>> You did.  However, it isn't marked as private API and I'm not the
>>> eclass
>>> maintainer to take care of removing public API.  I have no clue if
>>> Ruby
>>> project doesn't have some secret overlays using it.
>>>
>>  You can't use QA super-powerz ?! BDFL + sub-BDFL ?!
>> *
>>
>> * Thought the tags probably worth making explicit
>>
> Can you please stop polluting the -dev mailing list with this senseless
> chatter?
>
>
Perhaps I should remind you that this is a public mailing list (or hasn't
successfully been censored Yet) and not a private communication channel for
developers (see -core for this). But I don't need to tell you this



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

[Michael 'veremitz7; Everitt]

On 04/01/20 11:09, Rolf Eike Beer wrote:
> Am Freitag, 3. Januar 2020, 11:00:14 CET schrieb Rolf Eike Beer:
>> Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman:
>>> On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer  wrote:
 Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
> hppa is making us keep old kernels around [1].  Should the kernel team
> be
> doing more to get your attention then CC'ing hppa on all of the kernel
> STABLEREQ bugs [2]?
 I only run vanilla-sources since there are still lot of cache
 corruption
 problems in hppa kernels, or whatever makes them flaky.

 Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64
 PA8800 (Mako) 9000/785/C8000 GNU/Linux
 Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600
 (PCX-W+) 9000/785/C3600 GNU/Linux

 So _I_ personally would say just drop old kernels, but that is in no
 way
 authorative.
>>> Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel
>>> sources of each stable and LTS version.
>> If it's just that I could test them, but this still be no LTS version that I
>> would look at.
> So, do you want me to stable a random gentoo-sources (usually the most recent 
> one) every few weeks when I just happen to upgrade my machine?
>
> Eike
I don't think that works very well with kernel/security-team stabilisation
policies, sadly.

Is there any possibility you would be able to do a stabilisation run, and
do a reboot cycle on one LTS branch (of choice, eg. most recent) and then
revert to your preferred kernel afterwards?

I appreciate this is a rather onerous process on older hardware, but just
trying to think of some form of semi-compromise that prevents potential
de-keywording, without also suggesting that something that genuinely has
issues is either (1) working or (2) supported, if so.

I believe Whissi is leading kernel stabilisation requests, on behalf of
security- and kernel- teams, so maybe a chat with him may be fruitful.
Cheers,
veremitz/Michael.



signature.asc
Description: OpenPGP digital signature

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

[Michael 'veremitz7; Everitt]

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
>
>
Looks like you missed:
https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62

Yw.



signature.asc
Description: OpenPGP digital signature

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

[Michael 'veremitz7; Everitt]

On 19/01/20 06:23, Joonas Niilola wrote:
> 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
>
>
>
WFM cheers.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Ebuild Generators

[Michael 'veremitz7; Everitt]

On 03/02/20 12:19, Benda Xu wrote:
> Hi Gerion,
>
> Gerion Entrup  writes:
>
>>> Yes, that makes a lot of sense.  The R overlay follows this model.  Most
>>> of the ebuilds are automated.  When an ebuild generation fails, we add
>>> the ebuild manually, understand it and then update the generator to
>>> cover it in the future.
>> Is this possible in all cases? I think of adding custom patches,
>> appropriate mapping of dependencies, check for things like desktop
>> icon cache...
> That's too complex to handle automatically.  Luckily, in R overlay, such
> packages are less than 5%.  An ebuild generator is based on the
> observation that many language-specific packages are trivial to fetch,
> compile and install.
>
 I'm only "maintaining" an overlay so maybe I'm  missing experience
 but I often have wished a tool that automatically parses the language 
 specific
 packaging files and is able to generate a primitive ebuild out of that.
 Maybe it even can do this in an interactive way:
 "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have 
 found
 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
>>> Yes, that's the way R overlay is working.  And I have a similar plan and
>>> proof-of-concept solution for the Java Maven overlay.
>> Nice to hear. I think, it is meaningful to solve all generation with one
>> tool. Maybe it can even "recognize" the used build system and package
>> database. Is this your plan, too?
> No, I don't think it possible as far as I can see...  That would be a
> strong AI.
>
> Yours,
> Benda
There was some interest in doing this for PyPI packages for Liguros linux.
See https://gitlab.com/liguros/bugs/issues/75 .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode

[Michael 'veremitz7; Everitt]

On 07/02/20 19:50, Matt Turner wrote:
> On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller  wrote:
>>> On Fri, 07 Feb 2020, Matt Turner wrote:
>>> On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano  wrote:
 # Mike Pagano  (2020-02-07)
 # The standalone ebuild for this driver is made
 # unnecessary as it is included in the package:
 # sys-kernel/linux-firmware
 sys-firmware/iwl6050-ucode
>>> How about all the others as well?
>>> sys-firmware/iwl1000-ucode
>>> sys-firmware/iwl3160-7260-bt-ucode
>>> sys-firmware/iwl3160-ucode
>>> sys-firmware/iwl6005-ucode
>>> sys-firmware/iwl6030-ucode
>>> sys-firmware/iwl7260-ucode
>>> sys-firmware/iwl8000-ucode
>> I had asked the same question back in November, but an argument against
>> it was that sys-kernel/linux-firmware is quite a monster. In the default
>> configuration, its installation footprint is 515 MiB.
> Oh yeah. The thread where the person arguing for keeping them didn't
> know about USE=savedconfig :)
>
You still have to install the full 515MiB before you can apply savedconfig,
unless you already know the list of firmwares included, and create the file
in advance. For some systems (esp. storage constrained) that's not a very
good option ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode

[Michael 'veremitz7; Everitt]

On 07/02/20 20:39, Matt Turner wrote:
> On Fri, Feb 7, 2020 at 12:03 PM Michael 'veremitz' Everitt
>  wrote:
>> On 07/02/20 19:50, Matt Turner wrote:
>>> On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller  wrote:
>>>>>>>>> On Fri, 07 Feb 2020, Matt Turner wrote:
>>>>> On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano  wrote:
>>>>>> # Mike Pagano  (2020-02-07)
>>>>>> # The standalone ebuild for this driver is made
>>>>>> # unnecessary as it is included in the package:
>>>>>> # sys-kernel/linux-firmware
>>>>>> sys-firmware/iwl6050-ucode
>>>>> How about all the others as well?
>>>>> sys-firmware/iwl1000-ucode
>>>>> sys-firmware/iwl3160-7260-bt-ucode
>>>>> sys-firmware/iwl3160-ucode
>>>>> sys-firmware/iwl6005-ucode
>>>>> sys-firmware/iwl6030-ucode
>>>>> sys-firmware/iwl7260-ucode
>>>>> sys-firmware/iwl8000-ucode
>>>> I had asked the same question back in November, but an argument against
>>>> it was that sys-kernel/linux-firmware is quite a monster. In the default
>>>> configuration, its installation footprint is 515 MiB.
>>> Oh yeah. The thread where the person arguing for keeping them didn't
>>> know about USE=savedconfig :)
>>>
>> You still have to install the full 515MiB before you can apply savedconfig,
>> unless you already know the list of firmwares included, and create the file
>> in advance. For some systems (esp. storage constrained) that's not a very
>> good option ...
> Even that's not true. Just look at the git repo.
>
In that case, and in truth this is what I do in practice, I just simply
download the relevant firmware files Direct from git, and side-step all
this package nonsense :)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

[Michael 'veremitz7; Everitt]

On 09/02/20 20:31, Robin H. Johnson wrote:
> Signed-off-by: Robin H. Johnson 
> ---
>  app-admin/kube-bench/Manifest | 232 ++
>  .../kube-bench/kube-bench-0.2.3-r1.ebuild | 120 +
>  2 files changed, 352 insertions(+)
>  create mode 100644 app-admin/kube-bench/kube-bench-0.2.3-r1.ebuild
>
> diff --git app-admin/kube-bench/Manifest app-admin/kube-bench/Manifest
> index 0321873230e4..700b432ae04e 100644
> --- app-admin/kube-bench/Manifest
> +++ app-admin/kube-bench/Manifest
> @@ -1,3 +1,171 @@
> +DIST cloud.google.com%2Fgo%2F@v%2Fv0.37.4.info 51 BLAKE2B 
> 0b87b5b8f8ea4ccdd26272750a7fe8d9228d451c46b166f4478c89c0c7918bb6eb2d611c416795ea9e09c121754eed102933e996b6f4a731ad0a50cb97a01875
>  SHA512 
> ad485c9d6b16cbc36ec0e3b85ba9d80f7d46f68f8fb36bcfe721774a6e46d04a23705b166d8f606ca44d21fd412c97fc0d68f2e0d9a33011cc89aa9e9a856229
> +DIST cloud.google.com%2Fgo%2F@v%2Fv0.37.4.mod 1006 BLAKE2B 
> ed912b9fe91ee4e16f58b599232ea85bc1f994a290e8f514f6d053bad6312422c18e868b9d419079c63cd547781dcf82994b53af6ef10bb23fea05b66f55747f
>  SHA512 
> 8e12292cb0c83d0ea8d4227c27fdabaed182de6f42bc6a29bd53848c41c87754994dd50df282ff30ab78411d54a6667a371d84b620d1b02f3f953429e3c2e97b
> +DIST cloud.google.com%2Fgo%2F@v%2Fv0.37.4.zip 2717957 BLAKE2B 
> d5de25820cbee7f89ca2fce9c721b59839c1d1c38023e5d0ae153423b3ffc6b5e344d978d5a5cd18f99f732b56946a779adf82b1074eb78a2feccbdbd9962739
>  SHA512 
> 7bb51ac0b816eb709386e0116fdd2e7cd9f3e6dc55db7b0d2ea5e221b45647b05452da36839ef840c701d74fa0aabd71b92459944761b686aa91379f935ca5dc
> +DIST github.com%2F!burnt!sushi%2Ftoml%2F@v%2Fv0.3.1.info 50 BLAKE2B 
> 142643662a79ba5e13604668b5e5983c53c794ad5f6185e25bf4906c6a5a57f04fe30ff33be7da434799dea50e8562a68717a889f046eeb1776479ca781afb49
>  SHA512 
> 1e953b8c664b2c25982d7458129e61a41e9b91a75eea46ce2d0932fd14ea6a425810d1fb4dfe32988a41fa4bb975bdcd04a03439b7474b3d288a4b2d46067bd6
> +DIST github.com%2F!burnt!sushi%2Ftoml%2F@v%2Fv0.3.1.mod 34 BLAKE2B 
> ce54a247aef91043830bdf0603c8452ba38eceb1495af6e7a74c9119234a0dc5cd080cb25258c28f5e270acf91189a5ed33e361cbf17de2be5e37dadbda1d90d
>  SHA512 
> 320941bc3b7fb8bc595e6135cbc513a7583d129f0cd92508055291e141191066303cf75148e25198c21f6c6c539a790ea3210f3ecf5de6a2a03b70c753091146
> +DIST github.com%2F!burnt!sushi%2Ftoml%2F@v%2Fv0.3.1.zip 56132 BLAKE2B 
> 5edcfe991d7fc40094d637bae8d8d6f1f897ab3d3786ade2bb80287738103264520681ced8d30d2037253206c32d3f867f4d024a571cb9aad030ebc451e198eb
>  SHA512 
> 43ed64ae515738487e9b75a2290d0b2bc25e83c021a9f29b21487c37adbf34e74e1e7d3d5ec0dfe678c8396356f95c3993a5f5610d1791ff62056cd182a4272f
> +DIST github.com%2F!puerkito!bio%2Fpurell%2F@v%2Fv1.1.1.info 87 BLAKE2B 
> 5ba3587337f8cd5c67c84a707a6af2511996a78fdba29e7cc5a3a2d1ae9a0a56169b663f00831687d615786f89eb57b606d6e6106bae58e91290f4360e048152
>  SHA512 
> 37aba7f1fe097944d8f9600f02a578786015e955c67ade275329ca932e827765a279ac7af9795a2f607df4ae8663602ff1aa942c85674e8bbbef5b2d01a84d7e
> +DIST github.com%2F!puerkito!bio%2Fpurell%2F@v%2Fv1.1.1.mod 37 BLAKE2B 
> 9aad8d876b88c7c8976667747135ea2496c21542d029e879d80490e9d979923ac3060f65ddc443044db8eff2f92e2eed6b18682822f6b5706c5605d8de92ecbb
>  SHA512 
> 8382734877c9dc6a9c8a59b12d9735b6f971ea72ddeeb9985ea0cd0573820991a4b936baa1a643d38b694f1df7395d7b0d119f4f52be8d947f00adba96773989
> +DIST github.com%2F!puerkito!bio%2Fpurell%2F@v%2Fv1.1.1.zip 15402 BLAKE2B 
> efbf0c8a3f7e771b5a90ff620bfd513d476e21a672e3f7446202861121dcea08fa95d33b0438b6f1882273630e3cfe756c5934a14a1ab6b2676b117273616097
>  SHA512 
> 4c39d0907455b1c60e539e8497477e676bf7656c3b30996d55104d6129ebaa02079e5d7d27856352446ec2570c54f0d945be83e2a3445a025c85d12834120ea6
> +DIST 
> github.com%2F!puerkito!bio%2Furlesc%2F@v%2Fv0.0.0-20170810143723-de5bf2ad4578.info
>  78 BLAKE2B 
> 624792caee6d10a9767136e6206baa0f6874a126ceeba764c40dcf697850bc723299dd028c5c254262fc25a5b5b84878b0b874f71a267c9199a003f94150ddcb
>  SHA512 
> 5fa248cefba87b4376c9ebf40b8d271fba646106c68b903c90262344d054def1e7da472d059d09ae98b9c1f4ed2570e116eddf84cf544f839a49f312ed5b0e89
> +DIST 
> github.com%2F!puerkito!bio%2Furlesc%2F@v%2Fv0.0.0-20170810143723-de5bf2ad4578.mod
>  37 BLAKE2B 
> 28c9393f5171487d23b732afcbb1d3d835d13d1a63b7e852fd3205925742fcf5a686c39b0600359e9052770360e9396f6bfe52aecb51e3ed0a23611a2853
>  SHA512 
> a2b3211e3520fdef3d5c1991b5ad4b3745f4bb1b49be3afc5b1936c82b2a3058231b6cc17c63c85402cae0b80f037a70051d42738e89a708865e43dabf7b7b8a
> +DIST 
> github.com%2F!puerkito!bio%2Furlesc%2F@v%2Fv0.0.0-20170810143723-de5bf2ad4578.zip
>  8169 BLAKE2B 
> 61db06641c2c1db4102b72c097f63fae0bff296481556fa16e66ddd1808478aded29256befdc3d767b72f3abc91e376ae61656f8da2cfbfbb5ffbfe3fde20361
>  SHA512 
> 9746be89f7fc5d50acd6376f77d43754e4a40d9da173a0b3226b78b1b1fab9afd859f15332ae5a429ce1e0e85227ceef05d94f2237c4969a8e6fc5e8454937e6
> +DIST github.com%2Fdavecgh%2Fgo-spew%2F@v%2Fv1.1.1.info 50 BLAKE2B 
> 6189d1d85ef1da6c5f08a41697fc1690d6bf3cbef094affefdf78aa5c4e2342facdb1799d17c2bb1095184b0088f91e3ed54278857e82b5c1b5ed18af3923434
>  SHA512 
> 483c62e4

Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

[Michael 'veremitz7; Everitt]

On 09/02/20 20:47, Robin H. Johnson wrote:
> On Sun, Feb 09, 2020 at 08:38:23PM +0000, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:31, Robin H. Johnson wrote:
> ...
>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>> Manifest?!
> No, but I wanted to show scale of Manifest that is going to be present
> in covering all the dependencies for static-build languages like Golang.
>
> Every entry in EGO_SUM is 2-3 files that need to be fetched (two tiny
> files, one a bit larger [zip of source]).
>
> app-admin/kube-bench has _77_ dependencies, each with 3 distfiles.
>
Yoikes, gotcha ! :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

[Michael 'veremitz7; Everitt]

On 09/02/20 20:55, Michał Górny wrote:
> On Sun, 2020-02-09 at 20:38 +0000, Michael 'veremitz' Everitt wrote:
>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>> Manifest?!
> Pardon mine but do 'we' really need to read your useless comments
> everywhere, all the time and just get irritated for no benefit to
> Gentoo?
>
There's a really simple method to deal with that .. would you like me to
explain, or would that be 'useless' too?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

[Michael 'veremitz7; Everitt]

On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:55, Michał Górny wrote:
>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
>>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>>> Manifest?!
>> Pardon mine but do 'we' really need to read your useless comments
>> everywhere, all the time and just get irritated for no benefit to
>> Gentoo?
>>
> There's a really simple method to deal with that .. would you like me to
> explain, or would that be 'useless' too?
>
For the benefit of other readers, it's clear Michal is incapable of
implementing the measures I am thinking of .. or simply isn't aware of what
they might be?
which is quite unusual for a developer of his supposed capability ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

[Michael 'veremitz7; Everitt]

On 09/02/20 20:59, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:55, Michał Górny wrote:
>>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
>>>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>>>> Manifest?!
>>> Pardon mine but do 'we' really need to read your useless comments
>>> everywhere, all the time and just get irritated for no benefit to
>>> Gentoo?
>>>
>> There's a really simple method to deal with that .. would you like me to
>> explain, or would that be 'useless' too?
>>
> For the benefit of other readers, it's clear Michal is incapable of
> implementing the measures I am thinking of .. or simply isn't aware of what
> they might be?
> which is quite unusual for a developer of his supposed capability ...
>
For the avoidance of doubt, whilst my ban from this list is enacted, here
is the list of "Unacceptable behaviour" from the Gentoo Code of Conduct[1].

"Deciding to suspend or ban someone isn't a decision to be taken lightly,
but sometimes it has to happen. Below is a list of things that could result
in disciplinary action. * Flaming and trolling. What is trolling? You are
deemed to be trolling if you make comments intended to provoke an angry
response from others. What is flaming? Flaming is the act of sending or
posting messages that are deliberately hostile and insulting.
* Posting/participating only to incite drama or negativity rather than to
tactfully share information.
* Being judgmental, mean-spirited or insulting. It is possible to
respectfully challenge someone in a way that empowers without being
judgemental.
* Constantly purveying misinformation despite repeated warnings."

It is left as an exercise for the reader, who is transgressing here...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

[Michael 'veremitz7; Everitt]

On 09/02/20 21:16, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:59, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
>>> On 09/02/20 20:55, Michał Górny wrote:
>>>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
>>>>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>>>>> Manifest?!
>>>> Pardon mine but do 'we' really need to read your useless comments
>>>> everywhere, all the time and just get irritated for no benefit to
>>>> Gentoo?
>>>>
>>> There's a really simple method to deal with that .. would you like me to
>>> explain, or would that be 'useless' too?
>>>
>> For the benefit of other readers, it's clear Michal is incapable of
>> implementing the measures I am thinking of .. or simply isn't aware of what
>> they might be?
>> which is quite unusual for a developer of his supposed capability ...
>>
> For the avoidance of doubt, whilst my ban from this list is enacted, here
> is the list of "Unacceptable behaviour" from the Gentoo Code of Conduct[1].
>
> "Deciding to suspend or ban someone isn't a decision to be taken lightly,
> but sometimes it has to happen. Below is a list of things that could result
> in disciplinary action. * Flaming and trolling. What is trolling? You are
> deemed to be trolling if you make comments intended to provoke an angry
> response from others. What is flaming? Flaming is the act of sending or
> posting messages that are deliberately hostile and insulting.
> * Posting/participating only to incite drama or negativity rather than to
> tactfully share information.
> * Being judgmental, mean-spirited or insulting. It is possible to
> respectfully challenge someone in a way that empowers without being
> judgemental.
> * Constantly purveying misinformation despite repeated warnings."
>
> It is left as an exercise for the reader, who is transgressing here...
>
My final posting to this list (for posting this I am insuring my permanent
banning) here is the correspondence from the "ComRel" or Community
Relations bug (currently private) in the subject of 'policing' the mailing
lists:
--
 David Seifert gentoo-dev 2020-02-10 15:18:53 GMT

M. J. Everitt (veremitz on IRC) has used the dev ML to post general chatter
which contributes zero to the discussion at hand and just lowers the
signal-to-noise ratio. Previously, when the ML had a whitelist instead of a
blacklist, I requested his removal already (bug 664688), and I'd like
comrel to vote on blacklisting him posting to the gentoo-dev ML.

Examples:
https://archives.gentoo.org/gentoo-dev/message/786a4475d72b67937716c9624354ba17
https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg87819.html (ml
was down at the time)

Reproducible: Always

David Seifert 2020-02-10 15:19:19 GMT
Group: Community Relations
[tag] [reply] [\u2212] Comment 1 David Seifert gentoo-dev 2020-02-10
15:20:35 GMT

I vote yes (for a permanent ban).

[tag] [reply] [\u2212] Comment 2 Luca Barbato gentoo-dev 2020-02-10
20:05:37 GMT

I warned him again. Once he steps again out of boundary I'd link both
warnings and have him permabanned.-


Farewell folks.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Changes made by acct-* ebuilds

[Michael 'veremitz7; Everitt]

On 13/02/20 16:17, Mike Gilbert wrote:
> On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann  wrote:
>> In short: It was a very bad decision that acct-* stuff is *changing*
>> existing stuff. This must be turned of *by default*. Maybe provide a
>> setting a user can put into make.conf to opt into current, still new,
>> behavior but by default, a package should never ever make changes to
>> *existing* user (unless it knows for sure it was the only source
>> creating that user and nothing was changed since creation which isn't
>> easy to track).
> I think it would make sense to add some eclass variables that would
> turn user.eclass functions into no-ops.
>
> I don't agree that this should be happen by default. I suspect the
> majority of users do not wish to manage system users/groups
> themselves.
>
I would suggest anyone competent enough to build a kernel from scratch
(genkernel users, I'm ignoring you) should be equally at-home managing
system users and groups and associated permissions? Or am I perhaps
overestimating the average Genbuntu users here ... >,<




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michael 'veremitz7; Everitt]

On 14/02/20 19:48, Vadim A. Misbakh-Soloviov wrote:
>> And now you're changing the subject.  You've just claimed that *your*
>> user's group ownership will be overwritten and when challenged you
>> present the case of *system* user's group ownership being overwritten.
> Actually, he showed the rewrite of **system** user (that was modified 
> locally).
>
> And, as it already mentioned above, this behaviour violates Gentoo Philosophy 
> of not pretending to be smarter than user and don't dictate them a way to go.
>
> So, if the problem is only in the existance of the bug, I can create it 
> tomorrow morning.
> But it would be great to know that it wont be closed in a minute after with 
> "WONTFIX, works as expected".
>
> Also, as already stated, changing the stuff that was modified by user is 
> **prohibited**.
>
> P.S. I don't care about your  relations with whissi, but let's back to the 
> topic:
>
> [big red letters]
> We should **NEVER** ever rewrite any system configuration made by local 
> system 
> administrator (call it "user" or whatever). Dixi.
> [/big red letters]
>
> Modification of system users and groups are also covered by that user.
>
> So, we, actually don't need any changes to disable acct-* things at all and 
> make users to manage all the things by themselves.
> We need a change that will prevent any changes over **already existing** user.
>
> I think we should make it in a manner like:
> 1) when we install acct-pkg for a first time - CONFIG_PROTECT changes, and 
> let 
> user to review.
> 2) when we **reinstall** same package - do **nothing**. Although, I'm not 
> sure 
> here:
> on the one hand, why should we bother users by merging changes they already 
> did before,
> on the other hand, it can be useful way to reset to defaults in case if "all 
> this stuff is screwed up".
> 3) when we upgrade acct-package (assuming there was changes) - only allow 
> "positive" changes (group additions), but not negative (dropiing groups), and 
> anyway CONFIG_PROTECT all the changes.
>
>
> Well, there is also "kludgy way": does not globally reimplement anything, but:
> 1)  force CFGPROTECT
> 2) perform a "light" modification to only perform "positive" modifications 
> (see above) on users/groups, but no "negatives".
> It will anyway fix the both issues Whissi and OP had. 
>
There is a filthy hack which works around all this nonsense .. throw all
acct-* packages in a Package.Provided entry, and mask installation of any
other versions ..

*runs and hides*



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] eclass/acct-user.eclass: disable pkg_* on Prefix.

[Michael 'veremitz7; Everitt]

On 18/02/20 13:02, hero...@gentoo.org wrote:
> From: Benda Xu 
>
>   Gentoo Prefix runs with a normal user and cannot manage any other user.
>   Exit gracefully with a message.
>
> Closes: https://bugs.gentoo.org/709570
> Signed-off-by: Benda Xu 
> ---
>  eclass/acct-user.eclass | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index be6b3dd3e600..e3ec3966035d 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -360,6 +360,11 @@ acct-user_pkg_preinst() {
>  acct-user_pkg_postinst() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
> + return 0
> + fi
> +
>   # NB: eset* functions check current value
>   esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}"
>   esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}"
> @@ -376,6 +381,11 @@ acct-user_pkg_postinst() {
>  acct-user_pkg_prerm() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
> + return 0
> + fi
> +
>   if [[ -z ${REPLACED_BY_VERSION} ]]; then
>   if [[ -z $(egetent passwd "${ACCT_USER_NAME}") ]]; then
>   ewarn "User account not found: ${ACCT_USER_NAME}"
Peanut gallery says 'ACK' +1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [Policy change] Package masking of live ebuilds

[Michael 'veremitz7; Everitt]

On 18/02/20 19:52, Ulrich Mueller wrote:
> The devmanual says about live ebuilds:
>
> | CVS ebuilds must be either with empty KEYWORDS or package.masked
> | (but not both). Empty KEYWORDS are strongly preferred. This applies
> | to "live" ebuilds (-) and to ebuilds that extract a static
> | revision but still use CVS for fetching.
>
> As of today, I count 2123 live ebuilds in the Gentoo repository with
> empty KEYWORDS and 1 (one) ebuild with non-empty KEYWORDS but
> package.masked.
>
> So, can we finally make empty KEYWORDS mandatory and drop the part
> about package.masking?
>
> Ulrich
>
> [1] 
> https://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html
> (Yes, there really should be a chapter about Git sources ...)
This sounds like an ideal opportunity for repoman/pkgcheck warnings .. no?



signature.asc
Description: OpenPGP digital signature