Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-util/wxglade/files/, dev-util/wxglade/

[M. J. Everitt]

On 18/02/17 20:03, Mart Raudsepp wrote:
> Ühel kenal päeval, L, 18.02.2017 kell 19:47, kirjutas Michał Górny:
>> commit: 7207a292b2591dde5cbd336470bed3c11617a8e1
>> Commit: Michał Górny  gentoo  org>
>> CommitDate: Sat Feb 18 19:47:25 2017 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7207
>> a292
>>
>> dev-util/wxglade: python-single-r1, EAPI=6
> While I appreciate work done to do this conversion finally, what was
> the reason to bypass the maintainers after being explicitly told on IRC
> to not do so?
> Since when have we entered a free-for-all state of maintenance in
> Gentoo?
> I would like to know the state of affairs, so I know for future
> reference what can I expect and what I can do to packages that I do not
> explicitly maintain either.
>
> And yes, I am aware there was a pending bump request for a couple
> years. I'm still dealing with backlog after getting back to tree
> maintenance.
>
>
> Mart Raudsepp,
> thoroughly confused about current maintenance policies
>
I would also argue why wasn't this revbumped at the same time, if the
package was touched -at all-. This is a package I've been interested in
as a user for a couple of years now, but not having the required
knowledge, hadn't touched it to update. 0.6.3 is -ancient- and
unsupported upstream. In fact, I have been instrumental in fixing a few
bugs in the 0.7-series upstream, but could not bring these releases to
Gentoo because of the reasons mentioned.

Equally mystified,
Michael/veremit.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-wireless/gr-air-modes/

[M. J. Everitt]

On 20/02/17 18:09, Robin H. Johnson wrote:
>  * ERROR: net-wireless/gr-air-modes-::gentoo failed (depend phase):
>   *   PYTHON_COMPAT not declared.
>
> On Mon, Feb 20, 2017 at 05:43:10PM +, Michał Górny wrote:
>> commit: 5458c6d9da6bbb3b4009a4ff9d9ab17737d07849
>> Author: Michał Górny  gentoo  org>
>> AuthorDate: Mon Feb 20 16:43:24 2017 +
>> Commit: Michał Górny  gentoo  org>
>> CommitDate: Mon Feb 20 17:43:03 2017 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5458c6d9
>>
>> net-wireless/gr-air-modes: python-single-r1
>>
>>  net-wireless/gr-air-modes/gr-air-modes-.ebuild | 16 +++-
>>  1 file changed, 7 insertions(+), 9 deletions(-)
>>
>> diff --git a/net-wireless/gr-air-modes/gr-air-modes-.ebuild 
>> b/net-wireless/gr-air-modes/gr-air-modes-.ebuild
>> index 130d60dfad..6b9482d54e 100644
>> --- a/net-wireless/gr-air-modes/gr-air-modes-.ebuild
>> +++ b/net-wireless/gr-air-modes/gr-air-modes-.ebuild
>> @@ -1,9 +1,9 @@
>> -# Copyright 1999-2016 Gentoo Foundation
>> +# Copyright 1999-2017 Gentoo Foundation
>>  # Distributed under the terms of the GNU General Public License v2
>>  # $Header: $
>>  
>>  EAPI=5
>> -inherit python cmake-utils git-2
>> +inherit python-single-r1 cmake-utils git-2
>>  
>>  DESCRIPTION="This module implements a complete Mode S and ADS-B receiver 
>> for Gnuradio"
>>  HOMEPAGE="https://www.cgran.org/wiki/gr-air-modes";
>> @@ -18,18 +18,16 @@ SLOT="0"
>>  IUSE="rtlsdr fgfs +gui uhd"
>>  DEPEND=">=net-wireless/gnuradio-3.7.0:=
>>  net-wireless/gr-osmosdr
>> -dev-python/pyzmq
>> +dev-python/pyzmq[${PYTHON_USEDEP}]
>>  fgfs? ( sci-libs/scipy
>>  games-simulation/flightgear )
>>  rtlsdr? ( net-wireless/rtl-sdr )
>>  uhd? ( >=net-wireless/uhd-3.4.0 )
>> -gui? ( dev-python/pyqwt )"
>> +gui? ( dev-python/pyqwt[${PYTHON_USEDEP}] )
>> +${PYTHON_DEPS}"
>>  RDEPEND="${DEPEND}"
>>  
>> -pkg_setup() {
>> -python_set_active_version 2
>> -python_pkg_setup
>> -}
>> +REQUIRED_USE="${PYTHON_REQUIRED_USE}"
>>  
>>  src_compile() {
>>  cmake-utils_src_compile -j1
>> @@ -37,5 +35,5 @@ src_compile() {
>>  
>>  src_install() {
>>  cmake-utils_src_install
>> -python_convert_shebangs 2 "${ED}"usr/bin/*
>> +python_fix_shebang "${ED}"usr/bin
>>  }
>>
Nice .. esp. coming from a QA dev ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Printer drivers and net-print

[M. J. Everitt]

On 20/02/17 21:47, Andreas K. Huettel wrote:
> Hey all, 
>
> 1) Putting printer drivers into "net-print" is silly.
>
> Something that converts format a to device-specific format b has absolutely 
> nothing to do with network.
> So, a new category "sys-print", emphasizing that it's hardware drivers, (or 
> "cups-drv"?) (or maybe "media-print"?) might make sense.
>
> 2) After introducing that, however, "net-print" becomes nearly empty.
>
> On a quick glance, the only *network*-specific packages in there are cups and 
> lprng. Maybe one or two more which I dont recognize.
>
> So move cups and lprng to "net-misc" and drop "net-print"? 
> Or move them to new "sys-print" as well?
>
> What do you think?
>
> Cheers, 
> Andreas
>
sys-print/cups seems perfectly logical .. its not unique to 'network
printing' ..

How about an actual listing of the remaining packages? We can throw them
into new cat's in the bikeshed ...

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Printer drivers and net-print

[M. J. Everitt]

On 21/02/17 08:53, Lars Wendler wrote:
> Hi,
>
> On Mon, 20 Feb 2017 22:47:17 +0100 Andreas K. Huettel wrote:
>
>> Hey all, 
>>
>> 1) Putting printer drivers into "net-print" is silly.
>>
>> Something that converts format a to device-specific format b has
>> absolutely nothing to do with network.
>> So, a new category "sys-print", emphasizing that it's hardware
>> drivers, (or "cups-drv"?) (or maybe "media-print"?) might make sense.
> Like I said in IRC, I'm all in favor of this. "media-print" seems
> reasonable as I don't consider printing related packages being
> system-relevant (and thus no sys-print).
>
>
Maybe we can shoot for "app-print" .. its not really a system package
any more than a networking one, nor a (multi-)media package per-se (cue
bikeshed on what 'media' means) .. so perhaps just 'app-print' or
'app-printing' .. I dunno ..

Just my 2c50 as usual ..

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Printer drivers and net-print

[M. J. Everitt]

On 22/02/17 02:48, Gordon Pettey wrote:
> On Tue, Feb 21, 2017 at 7:05 PM, M. J. Everitt  <mailto:m.j.ever...@iee.org>> wrote:
>
> On 21/02/17 08:53, Lars Wendler wrote:
> > On Mon, 20 Feb 2017 22:47:17 +0100 Andreas K. Huettel wrote:
> >
> >> Hey all,
> >>
> >> 1) Putting printer drivers into "net-print" is silly.
> >>
> >> Something that converts format a to device-specific format b has
> >> absolutely nothing to do with network.
> >> So, a new category "sys-print", emphasizing that it's hardware
> >> drivers, (or "cups-drv"?) (or maybe "media-print"?) might make
> sense.
> > Like I said in IRC, I'm all in favor of this. "media-print" seems
> > reasonable as I don't consider printing related packages being
> > system-relevant (and thus no sys-print).
> >
> >
> Maybe we can shoot for "app-print" .. its not really a system package
> any more than a networking one, nor a (multi-)media package per-se
> (cue
> bikeshed on what 'media' means) .. so perhaps just 'app-print' or
> 'app-printing' .. I dunno ..
>
>
> There is no requirement for category names to be x-y. Instead of
> forcing a prefix-suffix pattern that doesn't really fit, just call it
> "printing".
Whilst I don't think there is anything specified in PMS/devmanual ..
find me another category without X-Y pattern? I'm not sure about portage
internals, but there could be some exploiting of the fact this is
'normally' the case ..

I could, ofc, be mistaken ...


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] new package category: net-vpn

[M. J. Everitt]

On 16/03/17 23:02, Jason A. Donenfeld wrote:
> Hey folks,
>
> While VPNs weren't stylish back when most categories were added to our
> portage tree, they now are hot potatoes. Most VPN-related programs
> currently live in net-misc, which isn't quite right.
>
> If nobody voices reasonable objections, I plan on adding a net-vpn
> category soon and moving relevant packages into it.
>
> Thanks,
> Jason
>
> [Note to bikeshedders: do *not* let this thread devolve into a general
> discussion on "categories in general" or something terrible like
> that.]
>
To forestall the obvious question .. can you provide a list of packages
you would propose to 'move' into such a category?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[M. J. Everitt]

On 23/03/17 21:42, Alexis Ballier wrote:
>
> If we were to stop thinking and follow the rule by the letter: What are
> we waiting for to file bugs for every package having ${FILESDIR}
> somewhere in global scope then ?
> After all, those are the council approved versions and EAPIs cannot
> change.
>
>
I hear mgorny is very effective at filing boiler-plate bugs ... I'm not
sure he needs any /more/ encouragement ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)

[M. J. Everitt]

On 27/03/17 11:10, Mart Raudsepp wrote:
>
>> 3] Meaning of the three values "stable", "testing", "unstable" for
>> repoman
>>
>> * stable: When a profile of arch is tested, then repoman checks
>> consistency for 
>> "arch" and for "~arch" separately. 
>> Which profiles of the arch are tested is still controlled by
>> profiles.desc (and 
>> -d / -e switches). 
>> This is the current behaviour and should be the default if nothing is
>> specified 
>> for an arch.
>>
>> * testing: When a profile of arch is tested, then repoman treats
>> "arch" as 
>> "~arch", and tests consistency only for "~arch".
>> Which profiles of the arch are tested is still controlled by
>> profiles.desc (and 
>> -d / -e switches). 
>> A new switch for repoman may be provided to temporarily upgrade an
>> arch from 
>> "testing" to "stable" (for arch team work).
>>
>> * unstable: When a profile of arch is tested, then repoman treats
>> "arch" as an 
>> error and aborts. Consistency is only tested for "~arch".
>> Which profiles of the arch are tested is still controlled by
>> profiles.desc (and 
>> -d / -e switches). 
> This sounds more like "testing" to me - architecture is only meant to
> have "testing" keywords, which is what I tend to call ~arch because
> it's in testing to become "stable" in ~30days or so, instead of calling
> it "unstable" (which feels appropriate only for a package that doesn't
> carry any stable keywords in older versions either).
> While taken from another perspective, the meaning for "testing" as in
> this proposal makes sense too - treat all as "testing" keywords.
> This goes back to the overloaded terminology concerns that have been
> echoed by others as well.
> But I don't have any good suggestions for alternatives either right
> now. stable/no_stable_check/testing_only? shrug.
>
>
'unstable' should surely be applied to masked packages, no? Everything
not-stable and not-unstable becomes therefore 'testing' ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

[M. J. Everitt]

On 18/04/17 10:44, Mart Raudsepp wrote:
> Ühel kenal päeval, T, 18.04.2017 kell 11:16, kirjutas Jörg Schaible:
>> Hi Tomas,
>>
>> Tomas Mozes wrote:
>>
>>> On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
>>> joerg.schai...@bpm-inspire.com> wrote:
>>>
 Hi,

 according the logs, gcc 4.5.0-r3 is stable for amd64:
 https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showm
 sg=1

 However, after synching the tree, this version is still unstable
 for me.
 Looking at the packages overview, it becomes even more weird,
 because
 there seem to be two 4.5.0-r3 versions, one stable for amd64 and
 one
 unstable: https://packages.gentoo.org/packages/sys-devel/gcc

 Can someone shed some light on this?

 Cheers,
 Jörg



>>> On which platform do you have it unstable? The packages problem is
>>> probably related to:
>>> https://bugs.gentoo.org/show_bug.cgi?id=612178
>> Amd64.
>>
>> Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my
>> machine 
>> lists amd64 as unstable after synching the tree while the ebuild
>> available 
>> over packages.gentoo.org has a stable version in KEYWORDS.
>>
>> Even if some GIT mirrors might be out of sync, it does not explain
>> why 
>> https://packages.gentoo.org/packages/sys-devel/gcc lists the same
>> version 
>> more than once.
> This is a packages.gentoo.org Ruby on Rails webapp bug, and has
> absolutely nothing to do with some package being stable on an
> architecture or not. Don't let that disturb you.
>
>
> Mart
>
+1

CONFIRMED but fix unknown at present. Gcc is /not/ the only package that
is affected by the Ruby-on-Rails bug.

RESOLVED:DUPLICATE :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Warn if *-nspkg.pth files are installed

[M. J. Everitt]

On 05/05/17 22:14, Michał Górny wrote:
> Add a check for *-nspkg.pth files indicating implicit setuptools
> namespace hack. While they kept namespaces somewhat working without
> requiring explicit support in ebuilds, they were unreliable. They
> frequently required additional hacks (distutils_install_for_testing) to
> get the tests working, and they have proven even more broken for Python
> 3.5+.
>
> For this reason, those files were deprecated in favor of proper,
> explicit namespace support. If they are found to exist, the developer
> should ensure to remove them to avoid issues.
> ---
>  eclass/distutils-r1.eclass | 29 +
>  1 file changed, 29 insertions(+)
>
> **REVIEW NOTE**
>
> The wiki documentation update is not yet in place for the new policy
> is not yet in place. In fact, it's not even guaranteed that the policy
> will actually be approved. The discussion is taking place here:

The wiki documentation update is not yet in place for the new policy
is not yet in place. ???

Copy-pasta, sir .. :]

> https://archives.gentoo.org/gentoo-python/message/d74af64a795cb776ac7b4f285963072d
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 3be67bbf2a21..5df7234332d3 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -789,6 +789,33 @@ distutils-r1_src_test() {
>   fi
>  }
>  
> +# @FUNCTION: _distutils-r1_check_namespace_pth
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Check if any *-nspkg.pth files were installed (by setuptools)
> +# and warn about the policy non-conformance if they were.
> +_distutils-r1_check_namespace_pth() {
> + local f pth=()
> +
> + while IFS= read -r -d '' f; do
> + pth+=( "${f}" )
> + done < <(find "${ED}" -name '*-nspkg.pth' -print0)
> +
> + if [[ ${pth[@]} ]]; then
> + ewarn "The following *-nspkg.pth files were found installed:"
> + ewarn
> + for f in "${pth[@]}"; do
> + ewarn "  ${f#${ED%/}}"
> + done
> + ewarn
> + ewarn "The presence of those files may break namespaces in 
> Python 3.5+. Please"
> + ewarn "read our documentation on reliable handling of 
> namespaces and update"
> + ewarn "the ebuild accordingly:"
> + ewarn
> + ewarn "  
> https://wiki.gentoo.org/wiki/Project:Python/Namespace_packages";
> + fi
> +}
> +
>  distutils-r1_src_install() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> @@ -812,6 +839,8 @@ distutils-r1_src_install() {
>  
>   "${cmd}" "QA: python_install_all() didn't call 
> distutils-r1_python_install_all"
>   fi
> +
> + _distutils-r1_check_namespace_pth
>  }
>  
>  # -- distutils.eclass functions --




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 17.0 profile update

[M. J. Everitt]

On 12/05/17 16:54, Kristian Fiskerstrand wrote:
> On 05/12/2017 05:50 PM, Ulrich Mueller wrote:
>>> On Fri, 12 May 2017, Matthias Maier wrote:
>>> I will post an RFC for a profile update (and a news item) for 17.0
>> We used to count from 1999 (namely, 10.0 introducing the counting
>> appeared on our 10th anniversary).
>>
>> So shouldn't the above be 18.0?
> Interesting historical tidbit, but, 13.0 was done in 2013, I believe it
> makes sense to sticking to year and make it 17.0
>
>
A bikeshed about profile naming .. well I never ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

binsSfjd9wdyD.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 21/05/17 20:32, Kent Fredric wrote:
> But I'd also like a pony.
>
I'm hoping for a unicorn still ...

[apologies, resending as hit the wrong button in the Compose button..]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fixing elasticsearch maintainer

[M. J. Everitt]

On 22/05/17 05:12, Patrick Lauer wrote:
> On 05/22/2017 03:52 AM, Sam Jorna wrote:
>> On 18/05/17 02:38, Patrick Lauer wrote:
>>> Since proxy-maint refuses to be removed from packages (especially
>>> since they
>>> were unconditionally added to all packages with a non-gentoo-dev
>>> maintainer in
>>> metadata) they are the de facto maintainers, and overrule everything
>>> else.
>>
>> Just to clarify, the Proxy Maintainers project is not required to be
>> added to all packages maintained by non-Gentoo maintainers. If a Gentoo
>> developer is willing to work with and proxy commits for maintainer(s)
>> without commit access, Proxy Maintainers are happy to be removed. There
>> are several metadata.xml's in the tree with examples, including a few
>> for which you are one of the maintainers.
>>
> That's nice.
>
> Could proxy-maint as a team maybe try to agree on such things so that
> everyone is on the same page? It's a tiny bit annoying when the
> actions of some contradict the suggested rules of others, while
> appearing as a single team to the outside ...
>
>
>
You imply some level of organisation, and yet this /is/ Gentoo we're
talking about 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fixing elasticsearch maintainer

[M. J. Everitt]

On 22/05/17 21:05, Matthias Maier wrote:
>> Were this an actual office, this would be better solved with a "ok,
>> we've clearly been working too hard this week, everyone stop, ITS PUB
>> O-CLOCK!"
> This is most definitely true for almost everything going on for the last
> days in Gentoo.
Just *days* !!!

Try weeks, months, years 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Update to news item 2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt

[M. J. Everitt]

On 04/06/17 16:55, Anthony G. Basile wrote:
> Hi everyone,
>
> Kensington suggested updating the news item on the new c++11 abi for
> gcc.  Since this news item now appears for all new installations of gcc
> it can be annoying.  I'm proposing to change it as below, but I have one
> concern.  It is important for anyone upgrading from gcc-4 to gcc-5.  But
> if an upgrade to gcc-5 removes gcc-4, then the message won't show up
> while it is still relevant.
>
> Any suggestions on how to proceed?
>
> index d074dbe..25f1712 100644
> ---
> a/2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt
> +++
> b/2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt
> @@ -2,9 +2,9 @@ Title: GCC 4.7 Introduced the New C++11 ABI
>  Author: Anthony G. Basile 
>  Content-Type: text/plain
>  Posted: 2014-10-26
> -Revision: 1
> +Revision: 2
>  News-Item-Format: 1.0
> -Display-If-Installed: >=sys-devel/gcc-4.7.0
> +Display-If-Installed: <=sys-devel/gcc-5
>  Display-If-Keyword: amd64
>  Display-If-Keyword: arm
>  Display-If-Keyword: mips
>
fwiw, I think although the root causes are similar, the differences
between the major GCC versions probably warrant their own separate news
items, unless there is updated information relevant to first-time
viewers. I'd probably constrain the existing news items closer to
~sys-devel/gcc-5 perhaps - or >= gcc-4.7 

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: new category, app-containers

[M. J. Everitt]

On 14/06/17 17:11, William Hubbs wrote:
> All,
>
> I am about to write two new ebuilds for packages for Gentoo that are for
> container-related utilities.
>
> Currently, the best place to put them would be app-emulation, or
> app-misc or dev-util, probably app-emulation would be my first choice.
>
> Is it time to start thinking about an app-containers category?
> If so, is it ok for me to start an app-containers category with these
> packages then we can look into moving other packages to it?
>
> Thanks,
>
> William
>
Textbook questions -

- Application/package names
- draft ebuilds

Cheers.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates

[M. J. Everitt]

On 16/06/17 09:27, Matthias Maier wrote:
> On Wed, Jun 14, 2017, at 18:15 CDT, Matthias Maier  wrote:
>
>> Hello all,
>>
>> this is a series of patches against the toolchian-funcs and toolchain-glibc
>> eclasses, most notably
>>
> Pushed.
>
> Best,
> Matthias
>
.. That was quick ...

I swore there was something in the devmanual about a nice long period of
bikeshedding before changes to eclasses were approved ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: ruby21-only packages

[M. J. Everitt]

On 23/06/17 08:45, Hans de Graaff wrote:
> # Hans de Graaff  (23 Jun 2017)
> # Mask ruby21-only packages for removal in 30 days
>
> # ruby21-only, no maintainer
> www-apps/redmine
Really? I find it hard to believe that a common package like redmine is
ruby-21 only?!

http://www.redmine.org/projects/redmine/wiki/redmineinstall#Ruby-interpreter
seems to agree.

I could proxy this in the event no-one steps forward, as I quite like
the front-end.

Might need a bit of a hand on the R-on-R stuff if it was available
somewhere ... !

Best regards,

Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] lua upgrade plan

[M. J. Everitt]

On 02/07/17 21:12, Vadim A. Misbakh-Soloviov wrote:
> By the way, it will also brake some proprietary games, that distributes via 
> steam, humble, gog and so on.
>
> Some of them depends on shared lua and doesn't bundle it (instead, their 
> installer calls apt (since they're doing games for ubuntu), but since we have 
> no apt, we (gamerlay/games team) just writing proper DEPENDs, unpacking the 
> content, and installing it.
>
> So, if shared lua will be dropped, we will either have a bunch of broken 
> games 
> or used to create some kludgy "lua-shared" custom ebuild, which is worse way 
> of doing the things.
>
> So, I'm voting for status quo. 
>
>
A custom games-lua eclass ... ?!

*runs from mgorny et al *



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] stabilization candidates, July 2017

[M. J. Everitt]

On 10/07/17 09:41, Paweł Hajdan, Jr. wrote:
> Hey folks,
>
> If you'd like to help Gentoo stable be more up to date, please read on.
>
> See
> 
> for potential stabilization candidates (over 1000 of them).
>
> These are automatically checked to pass repoman, and bugzilla is also
> checked for bugs. Only ebuilds not modified in last 30 days are considered.
>
> Feel free to check out 
> for the script(s) which generate this. It's a project I've been working
> on throughout 2011-2014, and might now work more on it.
>
> Feedback about next steps would be welcome.
>
> Paweł
>
Looks great!

It would fit in well with the new stabilisation bot for pre-checking,
and the -grumpy project for a 'developer dashboard'.

Have you come across the -stable working group that was set up recently?

Best regards,
Michael.


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[M. J. Everitt]

On 10/07/17 12:43, Pacho Ramos wrote:
> El lun, 10-07-2017 a las 13:12 +0200, Kristian Fiskerstrand escribió:
>> On 07/10/2017 01:04 PM, Pacho Ramos wrote:
>>> Any issues on trying to go further into implementing this warning? 
>> Not an issue per se, but it should be pointed out that python 3.5 only
>> has a testing visibility, so this at the very least requires maintainers
>> to potentially have a separate testing chroot/VM to test when adding the
>> compat.
>>
> Yes, but it's similar as the cases when we need to fix our packages to work 
> with
> a newer library they depend on. In this case it would be even easier as we can
> have multiple python versions and switch to the newer one for testing while
> going back to the stable one (if preferred) later.
>
Is this something that could be aided any by the tinderbox'ing project?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] taking a break from arches stabilization

[M. J. Everitt]

On 10/07/17 20:53, Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 3:09 PM, Matt Turner  wrote:
>> For what it's worth, Jack Morgan was recently getting his sparc and
>> ia64 systems back up, but then decided to retire instead when he saw
>> all of the discussions about dropping the architectures he cares
>> about.
>>
> Honestly, I don't really get this sort of thing.  The reason arches
> get dropped is because they mark things stable that they can't keep up
> with.  If an arch never marked a package as stable nobody would be
> bothered.  If they only marked a few critical packages as stable and
> then kept up with them, again nobody would be bothered.  The conflict
> comes in when an arch team marks packages as stable, but then doesn't
> keep up with them.
>
> Marking a package as stable is a two-way commitment.  When an arch
> team marks a package as stable they make a promise to the maintainer
> to stabilize updates in a timely manner.  In return the maintainer
> promises to keep older versions around to suit the needs of the arch
> team for the short time it takes to do these stabilizations.
>
> When an arch team stabilizes something that they don't have time to
> maintain then they're making a promise they can't keep, and the deal
> breaks down.  Eventually the maintainers complain, and the council
> ends up revoking the right of the arch team to hold the maintainers to
> their side of the deal which has already been broken.
>
> There are no bad guys here.  There is just a certain amount of work it
> takes to make a stable arch viable, and it either happens or it
> doesn't.  Most people who use Gentoo are tinkerers by nature.  All
> things being equal we'd love to see every arch supported.  However,
> this requires discipline on the part of the arch team, because
> otherwise an arch that few people use starts impacting work for other
> arches that many more use as maintainers get buried in old bugs.
>
I dunno where you've been lately, Rich, but for most devs, would-be
devs, and observers .. there -are- no arch teams left .. just a few Arch
devs, or arch 'people' ..

This is why stabilisation, if not for individual package maintainers on
amd64, has become a joke, save for Ago's efforts, and recent efforts by
kensington to streamline the effort for the likes of ago with his bot,
and one or two other arch stabilisers (who I know exist, but not by name
or nick).

There is no, and has not been, in the time I've been involved with
Gentoo, any "pact" or "contract" between arch teams/devs and maintainers
whatsoever, anything is only ever done as a 'favour' or if someone
nudges the AT after the appropriate bug has been filed.

Keywording, unless for your own native arch, is a worse joke .. you have
to do it yourself .. there just aren't people with the less common
arches actively seeking packages out to keyword.

So, even for me, Thank You Ago for the packages you've kindly fixed
where I have nudged you, and also maekke on the few arm packages where
you have done the same. Your efforts are noted by some, pity not by others.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[M. J. Everitt]

On 12/07/17 04:22, Walter Dnes wrote:
>
>   Step back for a minute, and relax.  There is a reason you're getting
> blowback.  You're asking for changes that would affect everybody else.
> This is similar in principle to what Lennart Poettering did, and you're
> getting the same reaction he got.  I understand that *YOU* want changes
> to how Portage works on *YOUR* machine.  No problem.  Set
> EMERGE_DEFAULT_OPTS in make.conf.  If you want excruciating detail on
> --depclean then check the small script I posted elsewhere in this
> thread.  Portage has many customization options; use them.
>
>   If you can't be bothered to use available customization options to set
> up your machine to your liking, but ask for a change of defaults that
> also affects everybody else, don't be surprised at the negative reaction.
> You would've gotten a much better reception, if you had gone to the
> gentoo-user list and asked "How do I tweak Portage to do this, that, and
> the other".
>
+1

Of course, you can do what Poettering did, and write your own solution
.. or fork portage to do things the way -you- want .. but don't reinvent
the wheel for the rest of us .. that's what Choice and Gentoo is all
about ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[M. J. Everitt]

On 12/07/17 16:42, William Hubbs wrote:
> OpenRC 0.28 will mount efivars read only by default due to concerns
> about users bricking systems by writing to this filesystem unexpectedly.
>
> Here is the newsitem covering this change.
>
> William
>
Very sensible .. I seem to recall something about systemd doing the
reverse by default .. and this becoming a regular occurrence.

+1 for sanity.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[M. J. Everitt]

On 12/07/17 17:07, Gordon Pettey wrote:
> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> mailto:wlt...@o-sinc.com>> wrote:
>
> On Thu, 13 Jul 2017 01:03:00 +1000
> Sam Jorna mailto:wra...@gentoo.org>> wrote:
>
> > $ emerge -C apg
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean ` to check for reverse dependencies
> > before
> >  * removing packages.
>
> That is my point. That message is always there. The chance that it is
> ignored is very high.
>
>
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.
Can't help but think of "special snowflake" here 

*cue flamewar...*


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[M. J. Everitt]

On 13/07/17 12:09, Rich Freeman wrote:
> Presumably you'd only want to remount it if it was mounted ro to
> start, since it sounds like openrc will be diverging from systemd
> behavior here.
>
> While it seems like a good idea I'm not sure how big an improvement it
> is in the larger scheme.  We're worried about root accidentially
> modifying efivars, but we have no safeguards against root writing to
> /dev/sda, and the latter seems much more likely to cause harm, and is
> harder to fix.
>
In case you weren't aware, Rich, rewriting the efivars actually writes
to the system BIOS, which renders the computer completely unbootable ..
not quite the same as erasing the boot sector of your hard disk, where
you simply plug in another device, and Off you go ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: sys-boot/plymouth needs major fixes/maintainer

[M. J. Everitt]

On 05/08/17 03:16, Michael Palimaka wrote:
> On 08/05/2017 12:37 AM, Mart Raudsepp wrote:
>> On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
>>> I am looking into this for openrc. I copied it over to my personal
>>> overlay.
>> Ok, how about I mark myself as maintainer then and add you as co
>> -maintainer for OpenRC aspects, and you can e-mail me fixes for openrc
>> or otherwise?
>> sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too
>> still, right?
>>
>> I'm not sure about
>> kde-plasma/breeze-plymouth
>> kde-plasma/plymouth-kcm
>> do you use KDE/Plasma to care for those too?
> These two are still maintained by KDE team, they just got masked
> (without asking by the way...) because they depend on plymouth.
>
You mean to say treecleaners and QA should actually contact maintainers
before wielding their chainsaws ??  Musta missed that policy doc ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Revisions for USE flag changes

[M. J. Everitt]

On 13/08/17 11:11, Michael Orlitzky wrote:
> On 08/12/2017 10:52 PM, Duncan wrote:
>> How so?  Are you arguing that deciding to system-wide switch to/from 
>> pulseaudio, systemd, or gstreamer is nonsense?
>>
> The meaning of any one USE flag varies widely across packages. I could
> never say "I want to enable USE=gstreamer" for every package in the
> tree, because I have no idea what it does for most of them. Setting
> USE=whatever globally essentially means "make random changes to my
> system" -- hence my wording.
>
> The meaning of a USE flag is per-package, so per-package is the only
> meaningful way to set them.
>
Which is why we have GLOBAL use flags and LOCAL use flags, right?!

I'm not sure I'm actually reading this discussion right now?! and I'm
*not* a dev ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[M. J. Everitt]

On 15/08/17 18:49, tom...@gentoo.org wrote:
> I think we can find a proper formulation for the use flag description in
> metadata.xml, e.g.:
>
> director - Installs the backup director additional to the default file daemon.
> storage-daemon - Installs the storage daemon additional to the default file
> daemon.
>
> Thomas
>
>
s/additional to the default file daemon.//

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...

[M. J. Everitt]

On 18/09/17 10:56, Andreas K. Huettel wrote:
> So glibc-2.26 is already out for some time, but we still haven't keyworded it 
> yet. Why?
>
> * I want to use the opportunity to make the long-delayed switchover from 
> glibc-internal SunRPC (long deprecated and outdated) to external 
> implementations (libtirpc, and possibly ntirpc).
>
> * The (outdated and deprecated) NIS(YP) and NIS+ support (libnsl) has been 
> removed from glibc (except for a compatibility library that doesnt install 
> headers), and is now provided by net-libs/libnsl (increased soversion).
>
> This mail is mainly about how to best structure the transition.
> Comments, suggestions, corrections, feedback welcome.
>
> 1) About RPC. 
>
> AFACIS there are three implementations:
> a) SunRPC, headers in /usr/include, code provided by glibc
> b) net-libs/libtirpc, headers in /usr/include/libtirpc, library -l tirpc
> c) (?) net-libs/ntirpc, headers in /usr/include/ntirpc, library -l ntirpc
>
> Option a) is going away with sys-libs/glibc-2.26-r1. 
> Options b) and c) may in addition need headers from net-libs/rpcsvc-proto
> I haven't done any testing with c) yet, will do so.
> a), b), and c) are co-installable.
>
> My suggestion for an ideal implementation would be that any package that uses 
> RPC defines useflags:
> sunrpc - build against glibc
> libtirpc - build against net-libs/libtirpc
> ntirpc - build against net-libs/ntirpc
> with 
> REQUIRED_USE="^^ ( sunrpc libtirpc ntirpc )"
> If rpc support is optional with useflag rpc, then this becomes
> REQUIRED_USE="rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )"
>
> Since the three options are coinstallable I see no problems with a package 
> only supporting a subset, but I have no clue how this interacts at runtime.
>
> Of course this "ideal option" is also the most work-intensive.


Would a virtual help any? Probably overlooking a good number of factors,
but wasn't mentioned yet ...

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...

[M. J. Everitt]

On 18/09/17 16:36, Andreas K. Huettel wrote:
> Am Montag, 18. September 2017, 14:28:37 CEST schrieb M. J. Everitt:
>> 
>>
>> Would a virtual help any? Probably overlooking a good number of factors,
>> but wasn't mentioned yet ...
>>
> So far I don't see how...  Virtual would mean that the same functionality is 
> provided by different packages, and that they can be exchanged at runtime. 
> However, for rpc there are different library *names* (sonames) to be linked, 
> and for nls the soversion is different... Even if the headers were identical, 
> that wouldnt work :/
>
Gotcha, thanks for the explanation. So you'd even need a common API
(header, etc) to be able to do some fudgery linking the lib names even.

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] FEATURES=splitdebug and debugedit

[M. J. Everitt]

On 12/10/17 22:24, Francesco Riosa wrote:
> hi,
>
> FEATURES=splitdebug at the moment require package dev-util/debugedit
> which is a lagging behind upstream.
> However package app-arch/rpm (from which debugedit is forked) always
> install the same binary in ${ROOT}/usr/libexec/rpm/debugedit.
>
> In 2017 I don't see much value in maintaining a fork from a package
> (rpm) that weight less than 3MB when the functionality we need is
> already all upstreamed. But if there is someone willing to keep it up to
> date, that's totally fine.
>
> Provided we^W you keep dev-util/debugedit indefinitely  it's possible to
> provide more useful choices to the users with at least two courses of
> action:
>
> 1) instruct ${package_manager} to search for `debugedit` first in
> ${PATH} _and_ then in /usr/libexec/rpm/debugedit.
> This way dev-util/debugedit take precedence, if it's not installed and
> app-arch/rpm is, then the latter will be used.
>
> 2) optionally (via useflag) create a symlink in /usr/bin to the libexec
> debugedit when installing rpm. Obviously the two package must block each
> other.
> the rpm package implementing this solution (revbumped to latest) is
> available here:
> https://github.com/vivo75/vivovl/blob/master/app-arch/rpm/rpm-4.14.0.ebuild
>
> thanks for reading and please share your thoughts
>
> -- Francesco (vivo) Riosa
>
Sounds to me like a potential case of a 'virtual/debugedit' package,
depending on one of rpm or debugedit to be installed, perhaps?

MJE




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[M. J. Everitt]

On 28/10/17 03:41, Dean Stephens wrote:
> On 10/27/17 17:48, Hanno Böck wrote:
>> Should a package manager reject a sync if it is too old? or not install
>> packages if a sync hasn't happened for some time? What is considered
>> "outdated"? I think that should be clarified how exactly it's supposed
>> to work.
>>
> If such a rejection is to be the default, an override option should be
> required as part of the spec. There are use cases where using an "old"
> repository would be necessary, even if only temporarily.
>
I_KNOW_WHAT_I_AM_DOING=1

:]




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs: sys-process/parallel

[M. J. Everitt]

On 28/10/17 22:02, Jonas Stein wrote:
> Dear all,
>
> The following packages are up for grabs:
>
> sys-process/parallel
>
> after retirement of the proxied maintainer.
> (https://bugs.gentoo.org/633090)
>
> https://packages.gentoo.org/packages/sys-process/parallel
>
> The ebuild was defacto maintained by several gentoo developers who kept
> the package up to date.
>
> The tool is very powerful and it would be great to have one or more
> interested developers who want to maintain it.
>
Possibly worth CC'ing to the proxy-maint ML too? fwiw...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged.

[M. J. Everitt]

On 20/11/17 03:25, hero...@gentoo.org wrote:
> From: Benda Xu 
>
>   enewgroup and enewuser does not apply when executed as a normal
>   user, e.g. under Gentoo Prefix.
> ---
>  eclass/user.eclass | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index 86bcd282479..82ccc1100ac 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -103,6 +103,10 @@ egetent() {
>  # Default uid is (pass -1 for this) next available, default shell is
>  # /bin/false, default homedir is /dev/null, and there are no default groups.
>  enewuser() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the username
> @@ -262,6 +266,10 @@ enewuser() {
>  # do the rest.  You may specify the gid for the group or allow the group to
>  # allocate the next available one.
>  enewgroup() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the group
s/Donot have enough privilege/Insufficient privileges/ or "Needs root"

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged

[M. J. Everitt]

On 20/11/17 03:38, hero...@gentoo.org wrote:
> From: Benda Xu 
>
> Thanks MJ, how about "Unprivileged to execute"? Less bytes.
>
>   enewgroup and enewuser does not apply when executed as a normal
>   user, e.g. under Gentoo Prefix.
> ---
>  eclass/user.eclass | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index 86bcd282479..8ff06935277 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -103,6 +103,10 @@ egetent() {
>  # Default uid is (pass -1 for this) next available, default shell is
>  # /bin/false, default homedir is /dev/null, and there are no default groups.
>  enewuser() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Unprivileged to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the username
> @@ -262,6 +266,10 @@ enewuser() {
>  # do the rest.  You may specify the gid for the group or allow the group to
>  # allocate the next available one.
>  enewgroup() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Unprivileged to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the group
That's rather strange English .. perhaps "Unprivileged: cannot execute..."

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[M. J. Everitt]

On 21/11/17 21:01, Manuel Rüger wrote:
> Packages up for grabs:
>
> * app-crypt/yubikey-manager-qt
> * sys-apps/etckeeper
> * sys-auth/yubico-piv-tool
> * dev-libs/libsodium
> * app-editors/retext
> * sys-apps/rkflashtool
> * dev-embedded/esptool
> * app-shells/thefuck
> * app-crypt/paperkey
> * dev-util/bumpversion
> * dev-python/python-afl
> * dev-python/pyotherside
> * dev-util/docker-distribution-pruner
>
I can proxy etckeeper and esptool as I use both those ... will check for
bugs ..

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 18:44, Christopher Head wrote:
> For those of us who run mostly stable systems, there is one question I don’t 
> know a good answer to.
>
> If I add a specific version of a game to package.accept_keywords, I will get 
> that version forever. That’s not really what I want: I prefer to stay up to 
> date as new versions are packaged.
>
> If I add just a cat/pkg to p.a_k, Portage will always try to pull in the 
> latest version. If that version has some unstable dependencies which I 
> haven’t also accepted, Portage will yell at me. An example of this is 
> games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter of 
> which is unstable.
>
> What I really want to install is, “the latest version of the package that 
> doesn’t pull in any deps that aren’t available (stable or accepted),” but I 
> don’t know any way to tell Portage that. Am I missing something, or is that 
> indeed impossible?
Sounds to me a failure in adhering to the stabilisation criterion that
state that all deps must be stabilised FIRST .. as the bugzilla
stable-bot will now automagically check ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 20:34, Rich Freeman wrote:
> On Mon, Nov 27, 2017 at 3:15 PM, M. J. Everitt  wrote:
>> On 27/11/17 18:44, Christopher Head wrote:
>>> For those of us who run mostly stable systems, there is one question I 
>>> don’t know a good answer to.
>>>
>>> If I add a specific version of a game to package.accept_keywords, I will 
>>> get that version forever. That’s not really what I want: I prefer to stay 
>>> up to date as new versions are packaged.
>>>
>>> If I add just a cat/pkg to p.a_k, Portage will always try to pull in the 
>>> latest version. If that version has some unstable dependencies which I 
>>> haven’t also accepted, Portage will yell at me. An example of this is 
>>> games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter 
>>> of which is unstable.
>>>
>>> What I really want to install is, “the latest version of the package that 
>>> doesn’t pull in any deps that aren’t available (stable or accepted),” but I 
>>> don’t know any way to tell Portage that. Am I missing something, or is that 
>>> indeed impossible?
>> Sounds to me a failure in adhering to the stabilisation criterion that
>> state that all deps must be stabilised FIRST .. as the bugzilla
>> stable-bot will now automagically check ...
>>
> Nobody is stabilizing anything.  That is the whole reason he raised
> that concern.  He wants to use ~arch versions of games, with stable
> dependencies.
>
> To answer his question, there is not any way out-of-the-box to tell
> portage to install the latest ~arch version of a package that has only
> stable or already-accepted dependencies.  Certainly it should be
> possible to build such a feature, but it doesn't exist today.
>
Ah my apologies .. that's definitely what most would consider a bit of
an 'edge case' then ..

Thanks for the clarification, Rich.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 20:44, Michael Orlitzky wrote:
> On 11/27/2017 03:37 PM, Arve Barsnes wrote:
>> Sounds kind of weird? If he has keyworded the game package, shouldn't it
>> just never install that version if it depends on an unstable package?
> That's right, but if there are two available ~arch versions, one of
> which has all stable dependencies and (the newer) one of which has all
> ~arch dependencies, then portage will try to install the newer one and
> tell you to keyword a million things -- even though it could install the
> first one with less hassle.
>
> For example, if you're on a system with no ruby packages, then it's the
> difference between having to keyword 10 packages for rails-x.y.z versus
> 200 packages for rails-x.y.(z+1). I'd rather have the slightly older
> version that requires less configuration.
>
>
You might achieve something with one of the new
"autounmask-keep-keywords" -type parameters to portage .. although YMMV,
etc ...



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists

[M. J. Everitt]

On 04/12/17 00:37, Matt Turner wrote:
> A user requested I forward this information to the mailing list:
>
> There's been research, on this, and the study by harvard business
> school was summarized and discussed by NPR in 2015:
>
> [ Turns out toxic coworkers are more
> than just an annoyance. A new study
> out of the Harvard Business School
> warns that bullying workers are more costly,
> even if they are more productive. ] -- NPR description
>
> https://www.npr.org/2015/12/16/460024322/harvard-business-school-study-highlights-costs-of-toxic-workers
> https://goo.gl/g8Ujuk (short URL of the same)
>
> With gentoo being a non-profit organization, an alternative way to
> view it could be the trade-off of seeing developers / maintainers /
> staff leave, and any "lost profits" are in the form of community
> relations, image, and willingness for ongoing productive work by those
> who remain with the gentoo organization.
>
> Research paper itself (which includes supporting 57 citations)
>
> http://www.hbs.edu/faculty/Publication%20Files/16-057_d45c0b4f-fa19-49de-8f1b-4b12fe054fea.pdf
> https://goo.gl/42A8v7 (short URL of the same)
>
> ... and was itself cited a dozen or times:
>
> https://scholar.google.com/scholar?cites=5443947091657980238
> https://goo.gl/obvdzh (short URL of the same)
>
I refer you also to a former Gentoo developer's talk on "A$$holes on
your project" ... [1]

[1] - https://www.youtube.com/watch?v=-ZSli7QW4rg



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[M. J. Everitt]

On 15/12/17 01:17, R0b0t1 wrote (excerpted):
> I'm not trying to be confrontational, but asserting an opinion is
> correct without explaining why that it is so isn't really conducive to
> arriving at the truth. I understand not wanting to answer if I am
> completely clueless, and would like to apologize in advance for
> bothering the developers.
>
> I am not very smart, sir.
>
> Cheers,
>  R0b0t1
>
With all due respect, Gentoo is not renowned for spoon-feeding ...

Returning to the topic in hand, two key points strike out at me:-

1) Gentoo isn't really interested in having a 'stable' tree or it would
already be happening. As such, why not cut the Gordian knot, declare
that this is not something that will happen [soon] and let users make
their own choices. The [majority of] developers already seem to have ...

2) Whilst there has yet another fine bike-shed emerged on the subject, I
have only seen one volunteer willing or capable to actually take on
implementation of anything that has been discussed on this thread. As
such, you can talk all you like .. nothing will happen until somebody
actually *does* something .. For all the hating, I will duly credit
mgorny for producing a consistent quantity of commits across the board
in Gentoo, and whilst you may not agree with all his bitching (for want
of a better term) at least he can stand and say "well at least I did
*something* about it, whether You like it or not ...".

Damnit, there's another $2 from me .. my apologies.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

[M. J. Everitt]

On 16/12/17 17:45, Andreas K. Huettel wrote:
> Am Donnerstag, 14. Dezember 2017, 13:21:47 CET schrieb Fabian Groffen:
>> Can we make it a policy to list /what/ QA issues are the justification
>> for commits like these?  A description in the commit message would be
>> preferred, but a pointer to a location where said issues can be found
>> would do too.
>>
>> Thanks,
>> Fabian
>>
>> On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
>>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34e2c43f
> That would have been a good thing to do, yes. 
>
> Unfortunately I was between two meetings, just saw the message on #gentoo-qa 
> that someone had committed straight to m-n, and if it could be reverted by 
> someone with tree access, and decided to quickly help out.
>
> (And adding a new package straight to m-n is in my opinion enough reason for 
> an immediate revert.)
>
> That said I think we have sorted out things in the meantime.
>
Andreas,

Thanks for the explanation out in the clear!

Might I politely, with all due respect, suggest that drive-by tree
commits are avoided, without adequate prior investigation. Whilst I
think your intentions were indeed noble and justified, the resolution
was not ideal .. (not that perfection is ever achievable) .. but perhaps
alerting another member of QA to do said investigation may have been a
slightly better method! :]

Best regards,
Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] skel.ebuild: Update comments for inherit, SLOT, KEYWORDS.

[M. J. Everitt]

On 31/12/17 19:59, Ulrich Mueller wrote:
>
>> +1, but I'm not going to suggest what to replace it with.
> How about one of these examples:
> "eautoreconf function from autotools.eclass"
> "tc-getCC function from toolchain-funcs.eclass"
>
> Ulrich
I second eautoreconf (with mention of eapply_user and/or default) as I
recently mistakenly put it in the wrong phase function  [d'oh, the
n00bness!]

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.

[M. J. Everitt]

On 04/01/18 10:23, Pacho Ramos wrote:
> El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió:
>> Split off functions preserve_old_lib and preserve_old_lib_notify from
>> eutils.eclass into a dedicated preserve-libs.eclass. These functions
>> are rarely used and are independent of the rest of eutils, therefore
>> moving them into their own eclass will help clarifying eclass
>> inheritance in ebuilds.
>>
>> For backwards compatibility, eutils inherits the new eclass in
>> existing EAPIs.
>> ---
>>  eclass/eutils.eclass| 65 ++-
>>  eclass/preserve-libs.eclass | 74
>> +
>>  2 files changed, 76 insertions(+), 63 deletions(-)
>>  create mode 100644 eclass/preserve-libs.eclass
>>
>> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
>> index 7d4193e76b51..91d329e99c9e 100644
>> --- a/eclass/eutils.eclass
>> +++ b/eclass/eutils.eclass
>> @@ -1,4 +1,4 @@
>> -# Copyright 1999-2017 Gentoo Foundation
>> +# Copyright 1999-2018 Gentoo Foundation
>>  # Distributed under the terms of the GNU General Public License v2
>>  
>>  # @ECLASS: eutils.eclass
>> @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
>>  # implicitly inherited (now split) eclasses
>>  case ${EAPI:-0} in
>>  0|1|2|3|4|5|6)
>> -inherit desktop epatch estack ltprune multilib toolchain-funcs
>> +inherit desktop epatch estack ltprune multilib preserve-libs
>> toolchain-funcs
>>  ;;
>>  esac
>>  
>> @@ -172,67 +172,6 @@ _eutils_eprefix_init() {
>>  has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=}
>> ${EROOT:=${ROOT}}
>>  }
>>  
>> -# @FUNCTION: preserve_old_lib
>> -# @USAGE:  [more libs]
>> -# @DESCRIPTION:
>> -# These functions are useful when a lib in your package changes ABI SONAME.
>> -# An example might be from libogg.so.0 to libogg.so.1.  Removing libogg.so.0
>> -# would break packages that link against it.  Most people get around this
>> -# by using the portage SLOT mechanism, but that is not always a relevant
>> -# solution, so instead you can call this from pkg_preinst.  See also the
>> -# preserve_old_lib_notify function.
>> -preserve_old_lib() {
>> -_eutils_eprefix_init
>> -if [[ ${EBUILD_PHASE} != "preinst" ]] ; then
>> -eerror "preserve_old_lib() must be called from pkg_preinst()
>> only"
>> -die "Invalid preserve_old_lib() usage"
>> -fi
>> -[[ -z $1 ]] && die "Usage: preserve_old_lib 
>> [more libraries to preserve]"
>> -
>> -# let portage worry about it
>> -has preserve-libs ${FEATURES} && return 0
>> -
>> -local lib dir
>> -for lib in "$@" ; do
>> -[[ -e ${EROOT}/${lib} ]] || continue
>> -dir=${lib%/*}
>> -dodir ${dir} || die "dodir ${dir} failed"
>> -cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp ${lib} failed"
>> -touch "${ED}"/${lib}
>> -done
>> -}
>> -
>> -# @FUNCTION: preserve_old_lib_notify
>> -# @USAGE:  [more libs]
>> -# @DESCRIPTION:
>> -# Spit helpful messages about the libraries preserved by preserve_old_lib.
>> -preserve_old_lib_notify() {
>> -if [[ ${EBUILD_PHASE} != "postinst" ]] ; then
>> -eerror "preserve_old_lib_notify() must be called from
>> pkg_postinst() only"
>> -die "Invalid preserve_old_lib_notify() usage"
>> -fi
>> -
>> -# let portage worry about it
>> -has preserve-libs ${FEATURES} && return 0
>> -
>> -_eutils_eprefix_init
>> -
>> -local lib notice=0
>> -for lib in "$@" ; do
>> -[[ -e ${EROOT}/${lib} ]] || continue
>> -if [[ ${notice} -eq 0 ]] ; then
>> -notice=1
>> -ewarn "Old versions of installed libraries were
>> detected on your system."
>> -ewarn "In order to avoid breaking packages that
>> depend on these old libs,"
>> -ewarn "the libraries are not being removed.  You need
>> to run revdep-rebuild"
>> -ewarn "in order to remove these old dependencies.  If
>> you do not have this"
>> -ewarn "helper program, simply emerge the 'gentoolkit'
>> package."
>> -ewarn
>> -fi
>> -ewarn "  # revdep-rebuild --library '${lib}' && rm '${lib}'"
>> -done
>> -}
>> -
>>  # @FUNCTION: built_with_use
>>  # @USAGE: [--hidden] [--missing ] [-a|-o]  > flags>
>>  # @DESCRIPTION:
>> diff --git a/eclass/preserve-libs.eclass b/eclass/preserve-libs.eclass
>> new file mode 100644
>> index ..548c6411fcf0
>> --- /dev/null
>> +++ b/eclass/preserve-libs.eclass
>> @@ -0,0 +1,74 @@
>> +# Copyright 1999-2018 Gentoo Foundation
>> +# Distributed under the terms of the GNU General Public License v2
>> +
>> +# @ECLASS: preserve-libs.eclass
>> +# @MAINTAINER:
>> +# base-sys...@gentoo.org
>> +# @BLURB: preserve libraries after SONAME changes
>> +
>> +if [[ -z ${_PRESERVE_LIBS_ECLASS} ]]; then
>> +_PRESERVE_LIBS_ECLASS=1
>> +
>> +# @FUNCTION: preserve_old_lib
>> +# @USAGE:  [more

Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.

[M. J. Everitt]

On 04/01/18 11:21, David Seifert wrote:
> On Thu, 2018-01-04 at 10:43 +0000, M. J. Everitt wrote:
>> On 04/01/18 10:23, Pacho Ramos wrote:
>>> El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió:
>>>> Split off functions preserve_old_lib and preserve_old_lib_notify
>>>> from
>>>> eutils.eclass into a dedicated preserve-libs.eclass. These
>>>> functions
>>>> are rarely used and are independent of the rest of eutils,
>>>> therefore
>>>> moving them into their own eclass will help clarifying eclass
>>>> inheritance in ebuilds.
>>>>
>>>> For backwards compatibility, eutils inherits the new eclass in
>>>> existing EAPIs.
>>>> ---
>>>>  eclass/eutils.eclass| 65 ++-
>>>> 
>>>>  eclass/preserve-libs.eclass | 74
>>>> +
>>>>  2 files changed, 76 insertions(+), 63 deletions(-)
>>>>  create mode 100644 eclass/preserve-libs.eclass
>>>>
>>>> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
>>>> index 7d4193e76b51..91d329e99c9e 100644
>>>> --- a/eclass/eutils.eclass
>>>> +++ b/eclass/eutils.eclass
>>>> @@ -1,4 +1,4 @@
>>>> -# Copyright 1999-2017 Gentoo Foundation
>>>> +# Copyright 1999-2018 Gentoo Foundation
>>>>  # Distributed under the terms of the GNU General Public License
>>>> v2
>>>>  
>>>>  # @ECLASS: eutils.eclass
>>>> @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
>>>>  # implicitly inherited (now split) eclasses
>>>>  case ${EAPI:-0} in
>>>>  0|1|2|3|4|5|6)
>>>> -  inherit desktop epatch estack ltprune multilib
>>>> toolchain-funcs
>>>> +  inherit desktop epatch estack ltprune multilib preserve-
>>>> libs
>>>> toolchain-funcs
>>>>;;
>>>>  esac
>>>>  
>>>> @@ -172,67 +172,6 @@ _eutils_eprefix_init() {
>>>>has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=}
>>>> ${EROOT:=${ROOT}}
>>>>  }
>>>>  
>>>> -# @FUNCTION: preserve_old_lib
>>>> -# @USAGE:  [more libs]
>>>> -# @DESCRIPTION:
>>>> -# These functions are useful when a lib in your package changes
>>>> ABI SONAME.
>>>> -# An example might be from libogg.so.0 to libogg.so.1.  Removing
>>>> libogg.so.0
>>>> -# would break packages that link against it.  Most people get
>>>> around this
>>>> -# by using the portage SLOT mechanism, but that is not always a
>>>> relevant
>>>> -# solution, so instead you can call this from pkg_preinst.  See
>>>> also the
>>>> -# preserve_old_lib_notify function.
>>>> -preserve_old_lib() {
>>>> -  _eutils_eprefix_init
>>>> -  if [[ ${EBUILD_PHASE} != "preinst" ]] ; then
>>>> -  eerror "preserve_old_lib() must be called from
>>>> pkg_preinst()
>>>> only"
>>>> -  die "Invalid preserve_old_lib() usage"
>>>> -  fi
>>>> -  [[ -z $1 ]] && die "Usage: preserve_old_lib >>> preserve>
>>>> [more libraries to preserve]"
>>>> -
>>>> -  # let portage worry about it
>>>> -  has preserve-libs ${FEATURES} && return 0
>>>> -
>>>> -  local lib dir
>>>> -  for lib in "$@" ; do
>>>> -  [[ -e ${EROOT}/${lib} ]] || continue
>>>> -  dir=${lib%/*}
>>>> -  dodir ${dir} || die "dodir ${dir} failed"
>>>> -  cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp
>>>> ${lib} failed"
>>>> -  touch "${ED}"/${lib}
>>>> -  done
>>>> -}
>>>> -
>>>> -# @FUNCTION: preserve_old_lib_notify
>>>> -# @USAGE:  [more libs]
>>>> -# @DESCRIPTION:
>>>> -# Spit helpful messages about the libraries preserved by
>>>> preserve_old_lib.
>>>> -preserve_old_lib_notify() {
>>>> -  if [[ ${EBUILD_PHASE} != "postinst" ]] ; then
>>>> -  eerror "preserve_old_lib_notify() must be called
>>>> from
>>>> pkg_postinst() only"
>>>> -  die "Invalid preserve_old_lib_notify() usage"
>>>> -

Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.

[M. J. Everitt]

On 04/01/18 11:36, M. J. Everitt wrote:
> On 04/01/18 11:21, David Seifert wrote:
>> On Thu, 2018-01-04 at 10:43 +0000, M. J. Everitt wrote:
>>> On 04/01/18 10:23, Pacho Ramos wrote:
>>>> El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió:
>>>>> Split off functions preserve_old_lib and preserve_old_lib_notify
>>>>> from
>>>>> eutils.eclass into a dedicated preserve-libs.eclass. These
>>>>> functions
>>>>> are rarely used and are independent of the rest of eutils,
>>>>> therefore
>>>>> moving them into their own eclass will help clarifying eclass
>>>>> inheritance in ebuilds.
>>>>>
>>>>> For backwards compatibility, eutils inherits the new eclass in
>>>>> existing EAPIs.
>>>>> ---
>>>>>  eclass/eutils.eclass| 65 ++-
>>>>> 
>>>>>  eclass/preserve-libs.eclass | 74
>>>>> +
>>>>>  2 files changed, 76 insertions(+), 63 deletions(-)
>>>>>  create mode 100644 eclass/preserve-libs.eclass
>>>>>
>>>>> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
>>>>> index 7d4193e76b51..91d329e99c9e 100644
>>>>> --- a/eclass/eutils.eclass
>>>>> +++ b/eclass/eutils.eclass
>>>>> @@ -1,4 +1,4 @@
>>>>> -# Copyright 1999-2017 Gentoo Foundation
>>>>> +# Copyright 1999-2018 Gentoo Foundation
>>>>>  # Distributed under the terms of the GNU General Public License
>>>>> v2
>>>>>  
>>>>>  # @ECLASS: eutils.eclass
>>>>> @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
>>>>>  # implicitly inherited (now split) eclasses
>>>>>  case ${EAPI:-0} in
>>>>>  0|1|2|3|4|5|6)
>>>>> - inherit desktop epatch estack ltprune multilib
>>>>> toolchain-funcs
>>>>> + inherit desktop epatch estack ltprune multilib preserve-
>>>>> libs
>>>>> toolchain-funcs
>>>>>   ;;
>>>>>  esac
>>>>>  
>>>>> @@ -172,67 +172,6 @@ _eutils_eprefix_init() {
>>>>>   has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=}
>>>>> ${EROOT:=${ROOT}}
>>>>>  }
>>>>>  
>>>>> -# @FUNCTION: preserve_old_lib
>>>>> -# @USAGE:  [more libs]
>>>>> -# @DESCRIPTION:
>>>>> -# These functions are useful when a lib in your package changes
>>>>> ABI SONAME.
>>>>> -# An example might be from libogg.so.0 to libogg.so.1.  Removing
>>>>> libogg.so.0
>>>>> -# would break packages that link against it.  Most people get
>>>>> around this
>>>>> -# by using the portage SLOT mechanism, but that is not always a
>>>>> relevant
>>>>> -# solution, so instead you can call this from pkg_preinst.  See
>>>>> also the
>>>>> -# preserve_old_lib_notify function.
>>>>> -preserve_old_lib() {
>>>>> - _eutils_eprefix_init
>>>>> - if [[ ${EBUILD_PHASE} != "preinst" ]] ; then
>>>>> - eerror "preserve_old_lib() must be called from
>>>>> pkg_preinst()
>>>>> only"
>>>>> - die "Invalid preserve_old_lib() usage"
>>>>> - fi
>>>>> - [[ -z $1 ]] && die "Usage: preserve_old_lib >>>> preserve>
>>>>> [more libraries to preserve]"
>>>>> -
>>>>> - # let portage worry about it
>>>>> - has preserve-libs ${FEATURES} && return 0
>>>>> -
>>>>> - local lib dir
>>>>> - for lib in "$@" ; do
>>>>> - [[ -e ${EROOT}/${lib} ]] || continue
>>>>> - dir=${lib%/*}
>>>>> - dodir ${dir} || die "dodir ${dir} failed"
>>>>> - cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp
>>>>> ${lib} failed"
>>>>> - touch "${ED}"/${lib}
>>>>> - done
>>>>> -}
>>>>> -
>>>>> -# @FUNCTION: preserve_old_lib_notify
>>>>> -# @USAGE:  [more libs]
>>>>> -# @DESCRIPTION:
>>>>> -# Spit helpful messages about the libraries preserved by
>>

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[M. J. Everitt]

On 10/01/18 14:00, kuzetsa wrote:
> On 01/09/2018 08:21 AM, Aaron Bauman wrote:
>> On January 8, 2018 9:39:47 PM EST, Benda Xu  wrote:
>>> Hi kuzetsa,
>>>
>>> kuzetsa  writes:
>>>
 The term "beyond" feels wrong & confusing.
 (Not sure what to replace it with though)
>>> How about this?
>>>
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
>>>
>>> Yours,
>>> Benda
>> I like this as it is shorter and makes the version ranges more clear.  Lgtm.
>>
>> -Aaron
> Yes. Using a plus looks nicer / cleaner to me too.
>
Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
different between 2.6.16+ and 2.6.32+ .. should this potentially be
2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
and more confusing to others

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 13:49, kuzetsa wrote:
> On 01/10/2018 05:57 AM, David Seifert wrote:
>> On Wed, 2018-01-10 at 08:55 +0100, Lars Wendler wrote:
>>> On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote:
>>>
 On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote:
> * Posting to the list will only be possible to Gentoo developers
> and
>   whitelisted additional participants.  
 This is so contrary to what I and I thought Gentoo stands for:
 openness, transparency, inclusiveness even when these require a
 rather
 thick skin and result in high noise.  It's a price worth paying.

 I guess I should a) pay more attention to council elections b)
 consider
 the idea that the whole council thing as it stands now is just not
 working.

>>> Wow. I couldn't have said it better. 
>>> Seems we're turning into an elitist club or something... 
>>> I wonder how many users we're going to loose on this one. Well done
>>> council :-(
>>>
>> If your only reason to use Gentoo is because you can post to the main
>> developer ML, and not because we try to provide a great distribution
>> with lots of choice, a current toolchain and lots of customization,
>> then you're likely using the wrong distribution.
>>
> If development of a quality distribution which meets
> these goals requires thick skin, something is broken:
>
> I've never seen anything from the gentoo foundation
> which suggests that the gentoo developer mail list
> should be considered a safe space for disparaging
> remarks. Think of the messaging on this - for every
> 1 or 2 people who are willing to come forward to
> address these concerns, there are likely "not zero"
> who didn't want to deal with confrontation and the
> risk that rudeness and hostile behavior would be
> defended.
>
Your argument seems partially contradictory here, and I think the
interpretation may be muddled with language barriers for those
developers/users with English as a foreign language ...

Are you reinforcing the point [widely accepted by many whose heads
aren't in the proverbial sand[0]] that Gentoo is [or is becoming] an
elitist club, or condoning "bad behaviour" by both devs and non-devs on
the mailing lists

Your final point, however, makes a lot of sense .. [1]


[0] - https://www.merriam-webster.com/dictionary/head-in-the-sand
[1] - https://idioms.thefreedictionary.com/keep+head+down



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 14:55, Alexander Berntsen wrote:
> On 10/01/18 08:55, Lars Wendler wrote:
>> Seems we're turning into an elitist club or something... 
> Gentoo has already had the reputation of being an elitist club for
> years. As such I'd like to see steps to remedy this status, rather than
> taking steps like this, which just exacerbates the unfortunate status.
At the risk of earning myself an outright ban may I propose the following:

Perhaps some of the devs still reading this thread, may wish to table a
discussion at the forthcoming Gentoo council meeting, that this subject
is given some discussion by those [supposedly] steering the
distribution. Perhaps some of those elected representatives(!) who could
potentially be considered perpetrators of this problem would then be
tasked with addressing the issue properly, both in their own courts, and
more widely ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 19:31, Alec Warner wrote:
> On Wed, Jan 10, 2018 at 2:06 PM, Michał Górny  > wrote:
>
> W dniu śro, 10.01.2018 o godzinie 09∶11 -0800, użytkownik Matt Turner
> napisał:
> > On Wed, Jan 10, 2018 at 1:55 AM, Michał Górny  > wrote:
> > > W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt
> Turner
> > > napisał:
> > > > On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel
> mailto:dilfri...@gentoo.org>> wrote:
> > > > > During the last Gentoo council meeting, the decision was
> made to implement
> > > > > changes to the gentoo-dev mailing list [1].
> > > > >
> > > > > These changes affect only the gentoo-dev mailing list, and
> will come into
> > > > > effect on 23 January 2018.
> > > > >
> > > > > * Subscribing to the list and receiving list mail remains
> as it is now.
> > > > > * Posting to the list will only be possible to Gentoo
> developers and
> > > > >   whitelisted additional participants.
> > > > > * Whitelisting requires that one developer vouches for
> you. We intend this
> > > > >   to be as unbureaucratic as possible.
> > > > > * Obviously, repeated off-topic posting as well as
> behaviour against the
> > > > >   Code of Conduct [2] will lead to revocation of the
> posting permission.
> > > > >
> > > > > If, as a non-developer, you want to participate in a
> discussion on
> > > > > gentoo-dev,
> > > > > - either reply directly to the author of a list mail and
> ask him/her to
> > > > > forward your message,
> > > > > - or ask any Gentoo developer of your choice to get you
> whitelisted.
> > > > >
> > > > > If, as a developer, you want to have someone whitelisted,
> please comment on
> > > > > bug 644070 [3]. Similar to Bugzilla editbugs permission,
> if you are vouching
> > > > > for a contributor you are expected to keep an eye on their
> activity.
> > > >
> > > > It seems like the obvious way this fails is some Gentoo
> developer acks
> > > > one of the problem people. I don't think that's particularly
> unlikely.
> > > > Then what do we do?
> > > >
> > >
> > > Then it becomes comrel business.
> >
> > If that was an effective solution, wouldn't the problem already
> be solved?
>
> One of the problems mentioned before was that a person could easily
> evade the ban via subscribing from another e-mail address. In this
> case
> it's no longer possible, as he would need to obtain the vouching
> for his
> new e-mail address, and for that he would first have to have something
> positive to post.
>
> Of course this relies on developers not vouching for new people out of
> the blue but expecting them to have something to contribute first.
>
>
> This sounds like an amazing fundraising opportunity.
>
> https://www.gentoo.org/donate/
>
> Get membership posting privs.
>
> -A
>  
>
>
> --
> Best regards,
> Michał Górny
>
>
>
Do I read a hint of sarcasm there too Alec?! :]


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 23:20, Rich Freeman wrote:
> On Wed, Jan 10, 2018 at 5:28 PM, Roy Bamford  wrote:
>> Being somwhat old and cynical, I'm seeing signs of history
>> repeating itself.
>>
>> Does being 'struck off' the list in this way apply to devs, including
>> Council and comrel members?
>>
> It would seem that this question is already answered:
> https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct#Consequences
>
> Being banned from lists or removal of dev status (which would also
> remove posting privs unless whitelisted) are already listed as
> potential consequences for refusal to comply with the CoC.
>
I have to ask a stupid question here .. how do devs apply to return to
the list? Via other devs, council, Comrel, the Foundation, Infra, or
what? (the "select few"/clique/club/etc?)

I think Roy's point is quite valid .. if you want to cut out users from
contribution why are you even posting on -dev ML in the first place? Use
-core and/or #-dev IRC .. or is this simply an attempt to replicate
#-dev IRC as a ML .. and you simply move the "problem" elsewhere .. and
then apply sanctions to that system also .. you create a rod for your
own back ...

I'm tending towards the idea that this is a technical "solution" to a
non-technical problem, and as such, nobody is capable of "fixing" that ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 23:35, Rich Freeman wrote:
> On Wed, Jan 10, 2018 at 6:27 PM, M. J. Everitt  wrote:
>
>> I think Roy's point is quite valid .. if you want to cut out users from
>> contribution why are you even posting on -dev ML in the first place?
> Probably because we don't want to cut out users from contribution.
>
I think the proverb "don't throw the baby out with the bathwater"
probably applies here ...

[With apologies for all the proverbs and metaphors lately!]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[M. J. Everitt]

On 11/01/18 03:18, Benda Xu wrote:
> Hi MJ,
>
> "M. J. Everitt"  writes:
>
>> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
>> different between 2.6.16+ and 2.6.32+ .. should this potentially be
>> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
>> and more confusing to others
> 2.6.16+ means that it can be used in any cases when the kernel is newer
> than 2.6.16.  For example, you can use it on linux-4.14, just with
> unnecessary backward compatibility code.
>
> Besides, with the newest profile, kernel-3.2+, the ending kernel version
> is not known.  We will have to rename it when glibc jumps if the profile
> is named with a version range.
>
>
> Hope this addresses your concern.
>
> Cheers,
> Benda
Thanks, that does make sense!

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[M. J. Everitt]

On 16/01/18 21:56, Róbert Čerňanský wrote:
> On Tue, 16 Jan 2018 15:58:11 +0100
> Kristian Fiskerstrand  wrote:
>
>> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
>>> Given the situation, we have a choice: Remove GnuCash altogether, or
>>> press ahead with recommending a version upstream considers
>>> unstable.  
>> Or 3, discuss with upstream to see if they can release an updated
>> version as stable branch.
> 4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
> B. Manual action is required to continue using such package.
>
> I see this as the most obvious choice considering that I am still
> unable to find any possible attack vector against GnuCash.  If it is me
> and only me who enters data.  Webkit reports are generated from those
> data.  How can anyone hack me through GnuCash?
>
> In general, many times users use applications in a way that
> vulnerabilities does not apply to their use cases.  I would prefer to
> be informed and allowed to continue using such application as a part of
> the distro.
>
> Robert
>
>
Forgive my potential misunderstanding here .. but who's actively
preventing you from using GnuCash 2.6? You can take a copy locally to
/usr/local/portage so that When/If finally it gets removed from the
central package 'tree' it will run for you provided its requirements are
still met on your system ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [News item review] Portage rsync tree verification

[M. J. Everitt]

On 25/01/18 11:01, Kristian Fiskerstrand wrote:
> On 01/25/2018 11:04 AM, Michał Górny wrote:
>
>> The verification is implemented using app-portage/gemato. Currently, 
> ... "implemented in", as opposed to "using"? its implemented using
> various cryptographic primitives, but gemato is the implementation
> itself of sorts.
>
>

"implemented with gemato" ?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [News item review] Portage rsync tree verification (v3)

[M. J. Everitt]

On 27/01/18 14:26, Michał Górny wrote [excerpted]:
> The verification is implemented via using app-portage/gemato. Currently,
> the whole repository is verified after syncing.
>
I would drop either 'via' or 'using' - they both are the same
verb/meaning and one is hence redundant.
Just my 2c as a native English speaker :)

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] glep-0074: Remove single filesystem limitation

[M. J. Everitt]

On 08/02/18 17:09, Michał Górny wrote:
> Remove the limitation that all files covered by the Manifest must reside
> on a single filesystem. This breaks valid uses of overlayfs without
> providing any real advantage.
>
> The removal is justified further in the updated rationale section.
> ---
>  glep-0074.rst | 66 
> +++
>  1 file changed, 39 insertions(+), 27 deletions(-)
>
> RST:  https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst
> HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html
>
> diff --git a/glep-0074.rst b/glep-0074.rst
> index 3835247..2f8deb2 100644
> --- a/glep-0074.rst
> +++ b/glep-0074.rst
> @@ -6,10 +6,10 @@ Author: Michał Górny ,
>  Ulrich Müller 
>  Type: Standards Track
>  Status: Final
> -Version: 1
> +Version: 1.1
>  Created: 2017-10-21
> -Last-Modified: 2017-12-16
> -Post-History: 2017-10-26, 2017-11-16
> +Last-Modified: 2018-02-08
> +Post-History: 2017-10-26, 2017-11-16, 2018-02-08
>  Content-Type: text/x-rst
>  Requires: 59, 61
>  Replaces: 44, 58, 60
> @@ -126,13 +126,6 @@ a different file type. If the tree contain files of 
> other types
>  that are not otherwise ignored, they need to be covered by an explicit
>  ``IGNORE``.
>  
> -All the local (non-``DIST``) files covered by a Manifest tree must
> -reside on the same filesystem. It is an error to specify entries
> -applying to files on another filesystem. If files or directories that
> -are not otherwise ignored reside on a different filesystem, or symbolic
> -links point to targets on a different filesystem, they must
> -be explicitly excluded via ``IGNORE``.
> -
>  
>  Path and filename encoding
>  --
> @@ -325,22 +318,18 @@ Algorithm for finding parent Manifests
>  In order to find the top-level Manifest from the current directory
>  the following algorithm can be used:
>  
> -1. Store the current directory as *original* and the device ID
> -   of the containing filesystem (``st_dev``) as *startdev*,
> -
> -2. If the device ID of the containing filesystem (``st_dev``)
> -   of the current directory is different than *startdev*, stop.
> +1. Store the current directory as *original*,
>  
> -3. If the current directory contains a ``Manifest`` file:
> +2. If the current directory contains a ``Manifest`` file:
>  
> a. If an ``IGNORE`` entry in the ``Manifest`` file covers
>the *original* directory (or one of the parent directories), stop.
>  
> b. Otherwise, store the current directory as *last_found*.
>  
> -4. If the current directory is the root system directory (``/``), stop.
> +3. If the current directory is the root system directory (``/``), stop.
>  
> -5. Otherwise, enter the parent directory and jump to step 2.
> +4. Otherwise, enter the parent directory and jump to step 2.
>  
>  Once the algorithm stops, *last_found* will contain the relevant
>  top-level Manifest. If *last_found* is null, then the directory tree
>


Observation: does RST not support auto-numbering like other formats? It
would make renumbering lists like this much easier (and from programming
experience, less error-prone). If not, #FEATUREREQ ... :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[M. J. Everitt]

On 08/02/18 22:13, William Hubbs wrote:
> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
>> However, there are plenty of examples of commands that normal users
>> may run from sbin. Moving these commands often causes problems for
>> packages that either hard code absolute paths, or detect paths at
>> build time. I think it would be less disruptive to add sbin to PATH
>> than it would be to try and "fix" all the packages that install
>> commands in the wrong place.
> There are no reasons to remove the *sbin directories from PATH; I know
> of no other distros that do this.
>
> William
>
Pardon my ignorance, but does that mean you are essentially relying on
file system features/permissions and security settings to enforce
correct use of system tools?! Or is this just to make sudo/etc commands
'more convenient' ?!

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[M. J. Everitt]

On 08/02/18 22:33, William Hubbs wrote:
> All,
>
> here is a link to an old, but brief discussion about this.
>
> https://archives.gentoo.org/gentoo-dev/message/2fc1f62c7cf225787fe52f4dace7368c
>
> I think we have talked about this several other times, but not done
> anything about it.
>
> On Thu, Feb 08, 2018 at 10:17:59PM +, M. J. Everitt wrote:
>>
>> On 08/02/18 22:13, William Hubbs wrote:
>>> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
>>>> However, there are plenty of examples of commands that normal users
>>>> may run from sbin. Moving these commands often causes problems for
>>>> packages that either hard code absolute paths, or detect paths at
>>>> build time. I think it would be less disruptive to add sbin to PATH
>>>> than it would be to try and "fix" all the packages that install
>>>> commands in the wrong place.
>>> There are no reasons to remove the *sbin directories from PATH; I know
>>> of no other distros that do this.
>>>
>>> William
>>>
>> Pardon my ignorance, but does that mean you are essentially relying on
>> file system features/permissions and security settings to enforce
>> correct use of system tools?! Or is this just to make sudo/etc commands
>> 'more convenient' ?!
> The basic problem is that what goes in *bin vs *sbin is quite arbitrary
> and the best way to fix it is to make all of the *bin and *sbin
> directories accessible to all users.
>
> You can't rely on a path to separate system-only programs from
> programs that users might want to run, and some programs can be run by
> users to look around but not change things.
>
> Here is one non-gentoo source discussing this.
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>
> Even if we don't adopt the usr merge in Gentoo Linux as default, removing 
> *sbin
> from the path doesn't make sense.
>
> William
>
Thank you William, and also rich for your explanations! I do see where
you're coming from now.

Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Lastrite: app-crypt/monkeysign

[M. J. Everitt]

On 13/02/18 10:47, Michael Palimaka wrote:
> On 02/12/2018 08:59 AM, Kristian Fiskerstrand wrote:
>> # Kristian Fiskerstrand  (11 Feb 2018)
>> # Lastrite: app-crypt/monkeysign . Please use caff from
>> # app-crypt/signing-party instead. Removal in 30 days.
>> # Bug: #647352
>> app-crypt/monkeysign
>>
> What's the reason for the removal?
>
Wait, there have to be reasons for removal now?! 

The only good last-rites messages I've ever seen from from jstein where
there is indeed a good traceable path as to why the dev feels that the
package is "beyond repair". Otherwise it does seem like a lot of cases
of "can't be bothered with this any more, lets kill it off". Correct me
if I'm wrong, by all means ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[M. J. Everitt]

On 13/02/18 20:57, Rich Freeman wrote:
> On Tue, Feb 13, 2018 at 3:53 PM, Chí-Thanh Christopher Nguyễn
>  wrote:
>> Dean Stephens schrieb:
>>
 Suppose that the council decides to accept an appeal from comrel. Is it
 a conflict of interest for a member of the council who is also a member
 of comrel to vote in the appeal? If it isn't, it is at least a pretty
 strong perception that it is.

>>> Why? How? Exactly what sort of conflicting interest is supposed to be
>>> present?
>> I think in Comrel vs. Council is not a conflict of interest, but rather
>> throwing the appeals process off balance. Can you expect someone to neutrally
>> review material and actions (question the authenticity of evidence, identify
>> potential misconduct, etc.) that they themselves used to build the case
>> against the reprimanded?
>>
> I hope that Comrel does not consider it their main duty to build cases
> against community members.  They're supposed to investigate, mediate,
> and take action if necessary.  They aren't prosecutors.
>
Do you have evidence either to support or contradict your case? TIA...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Portage rsync tree verification unstable

[M. J. Everitt]

On 10/03/18 21:22, Zac Medico wrote:
> Please review. This is needed in order to resolve
> https://bugs.gentoo.org/650072.

> 2) Once the 'rsync-verify' USE flag has been unmasked as described
> in step 1, it can be enabled with a line like the folling in
> /etc/portage/package.use:
s/folling/following/

:)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

[M. J. Everitt]

On 12/03/18 04:53, Duncan wrote:
> Zac Medico posted on Sun, 11 Mar 2018 19:57:31 -0700 as excerpted:
>
>> I really don't want to spend a lot of time making revisions, and I think
>> "unstable" communicates well enough in this case.
> Very well then.  With robbat2's already accepted first paragraph changes 
> it's acceptable as-is.
>
> Thanks.  You put an awful lot of work into portage, and I'm sure I'm not 
> the only one who's thankful there's a steady hand at the portage wheel, 
> even if it doesn't always come thru.  Your efforts certainly make the 
> gentoo experience a better one! =:^)
>
+1 to that .. particularly through choppy waters lately .. keep up the
good work!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] things becoming better and better

[M. J. Everitt]

On 19/03/18 18:48, Toralf Förster wrote:
> honestly.
>
>
> When I started with my tinderbox 2 or 3 years ago I had often a fair
> amount of manual work to made to get an image up and running - moslty
> tweaking USE flags to get blockers being solved. This yielded into a
> growing list of fixed USE flags settings for certain packages.
>
> But over the time this list became small and smaller and eventually this
> month I kicked off the last few lines (famous last words?).
>
> Said that Gentoo has IMO a lot of success stories to tell too (beside
> the usual grumblings and annoyances) - and the quality of the Gentoo
> tree is IMO an example of that.
>
>
> /me was just in the mood for a statement like this
>
I think I speak for many readers of this list, in echo'ing a big
thank-you for your efforts on the Tinderbox project. Gentoo has been
slow to move to more automated testing methods, and this is a huge leap
forward in this regard. Hopefully, moving forward there will be less
human effort required to extend and maintain the tree of packages on
which we depend, and together with QA, huge strides forward are being
made to achieve this end.

It is quite useful to have a consistent means to test packages, and to
this end, hopefully we can eliminate some of the randomness that having
a very flexible build system creates!

Onwards and upwards ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[M. J. Everitt]

On 21/03/18 01:27, Kent Fredric wrote:
> On Tue, 20 Mar 2018 14:48:29 -0400
> Michael Orlitzky  wrote:
>
>> There's a real technical problem hidden in there. Since npm
>> (recursively!) bundles every dependency, nobody worries about
>> compatibility in their JS packages. You'll quickly find yourself stuck.
> Honestly, I expected at some point we'd reach for slotting and normalization,
> and recursive trees of symlinks
>
> eg: 
>   /usr/lib/nodejs///lib/  -> 
> /usr/lib/nodejs//
>
> Or something like that.
>
> So you'd wind up with
>
>   /usr/lib/nodejs/foo/1.0/lib/bar  -> /usr/lib/nodejs/bar/1.0
>   /usr/lib/nodejs/foo/1.0/lib/baz  -> /usr/lib/nodejs/baz/2.0
> /usr/lib/nodejs/bar/1.0/lib/baz  -> /usr/lib/nodejs/baz/1.0
> /usr/lib/nodejs/baz/1.0/...
> /usr/lib/nodejs/baz/2.0/...
>
> Or something like that. But I imagine constructing such a thing a
> rather painful exercise.
>
 Said the voice of bitter experience ... *eg* :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Mailing list moderation and community openness

[M. J. Everitt]

On 22/03/18 00:33, Kristian Fiskerstrand wrote:
> 
> Most contributions should happen via patches on b.g.o
>
Who was lamenting about the every-increasing bug queue on this Very list
recently?

And what about those 5+ year old bugs that are rotting for packages long
last-rited from the tree ?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Mailing list moderation and community openness

[M. J. Everitt]

On 27/03/18 17:39, Rich Freeman wrote:
> On Tue, Mar 27, 2018 at 12:12 PM, Martin Vaeth  wrote:
>> Rich Freeman  wrote:
>>> On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth  wrote:
 It is about openness vs. isolation.
>>> I'm pretty sure most developers, myself included, want to welcome
>>> contributions.
>> Closing of the mailing list does not sound like that.
>>
> Sure, but it is actually part of the motivation.
>
> Consider this scenario.
>
> Fred is a community member.  Fred consistently harasses and trolls new
> contributors in private.  New contributors end up leaving because of
> Fred.
>
> Fred gets booted out as a result.  No mention is made of why Fred as
> booted out, because everything happened in private.
>
> Now a bunch of community members get upset about Fred being booted out
> without reason.  Fred claims it is because he disagrees with the
> leadership on something.  People start arguing endlessly about
> openness.
>
> Ultimately the leaders just want Fred gone so that new contributors
> aren't getting driven away.  They can't explain that because then they
> create potential civil liability for the project.  The problem is that
> the debate goes on for over a year despite intervening elections and
> now this becomes the issue that is driving new contributors away.
>
> What solution would you propose for this problem?  It isn't
> hypothetical at all - I can think of one case in Gentoo's past where
> this happened that I'm aware of, and I'd be shocked if it were the
> only one.
>
>> And anyway, you can be sure that the problem will appear again,
>> no matter how closed the list will be.
> Sure, but we can at least force the negative advertising of Gentoo to
> go elsewhere, rather than basically paying to run a negative PR
> campaign against ourselves.
>
>>> A lot of this comes down to considering that most people in these
>>> debates probably are well-intended.
>> Taking away freedom is never justified by good intention.
> You might want to choose a BSD-based distro then.  :)
>
> And what about the freedom to endlessly troll and harass you and
> others?  Is this truly a freedom we want to stand for?  How about the
> freedom to harass members of legally-protected classes (something that
> also has happened historically in the community)?
>
> Surely Gentoo's mission isn't to run completely unrestricated forums
> for discussion of anything and everything.  Our main purpose here is
> to maintain a Linux distro, not provide a platform for anybody who has
> an opinion on anything.  Free expression has to be balanced against
> the interests of people who want to actually contribute to the distro
> without being endlessly trolled and harassed.
>
It sounds a lot to me like you're replacing one set of problems with
another .. solving not a lot. Whether you take action on "Fred" or not,
you're going to lose out, so what do you do... Where is the greater
damage, with one/two people, 10/20 people or 100/200 people .. its a
huge value judgement - certainly not one I'd like to make!

You may or may not have heard the expression "throwing out the baby with
the bathwater" .. alas I feel this measure is a good example of this. To
try to rid the mailing list of one or two bad apples, you've cut the
whole tree down so it can't bear fruit. I think this is a foolish step,
but only time will tell that for sure ... The next "logical" step would
simply be to delete the whole mailing list - I suppose that's the next
"measure" when the trolling from white-listed members resurfaces And
don't go telling me it doesn't exist .. set a bad example, others will
surely follow ...

Ooops, another $2 spent on a lost cause .. >,<



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

[M. J. Everitt]

On 09/05/18 18:10, Mike Gilbert wrote:
> On Wed, May 9, 2018 at 12:34 PM, Matt Turner  wrote:
>> On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde  wrote:
>>> Hello!
>>>
>>> I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/
>>> renderD128" pop up for more and more packages, probably since OpenCL becomes
>>> used more widely.  Hence I would like to ask: Could we in Gentoo treat GPUs
>>> just like CPUs and allow any process to access render nodes (i.e. the GPUs
>>> compute capabilities via the specific interface the Linux kernel's DRM 
>>> offers
>>> for that purpose) without sandbox restrictions?
>>>
>>> --Dennis
>>>
>>> See-Also: https://bugs.gentoo.org/654216
>> This seems like a bad idea. With CPUs we've had decades to work out
>> how to isolate processes and prevent them from taking down the system.
>>
>> GPUs are not there yet. It's simple to trigger an unrecoverable GPU
>> hang and not much harder to turn it into a full system lock up.
>>
>> This is not safe.
>>
> It's worth noting that the default rules shipped with udev assign mode
> 0666 to the /dev/dri/renderD* device nodes. So, outside of a sanbox
> environment, any user may access these devices.
>
> This was merged as part of this PR: 
> https://github.com/systemd/systemd/pull/7112
>
How does that pan out for other init systems?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

[M. J. Everitt]

On 09/05/18 19:50, Kent Fredric wrote:
> On Wed, 9 May 2018 18:12:32 +0100
> "M. J. Everitt"  wrote:
>
>>> On Wed, May 9, 2018 at 12:34 PM, Matt Turner  wrote:  
>>> It's worth noting that the default rules shipped with udev assign mode
>>> 0666 to the /dev/dri/renderD* device nodes. So, outside of a sanbox
>>> environment, any user may access these devices.
>>>
>>> This was merged as part of this PR: 
>>> https://github.com/systemd/systemd/pull/7112
>>>  
>> How does that pan out for other init systems?
> udev
>
> Which practically everyone uses regardless of init system. Even openrc users.
>
> Upstream, udev is part of systemd now.
^ That is relatively common knowledge .. my question was more steered
towards whether Eudev is carrying this feature through as well (which
likely as they might ... ) I believe eudev was voted to become the
default implementation for Gentoo, to complement openRC as it was
becoming impossible to maintain udev-standalone separate from systemd.

Do correct me if I'm mistaken ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

[M. J. Everitt]

On 09/05/18 20:31, William Hubbs wrote:
> On Wed, May 09, 2018 at 07:54:16PM +0100, M. J. Everitt wrote:
>> ^ That is relatively common knowledge .. my question was more steered
>> towards whether Eudev is carrying this feature through as well (which
>> likely as they might ... ) I believe eudev was voted to become the
>> default implementation for Gentoo, to complement openRC as it was
>> becoming impossible to maintain udev-standalone separate from systemd.
> Well, it is not impossible to maintain udev standalone, we are still
> doing it just fine, so if that is the reason eudev was made the default,
> we need to revisit that. Not in this thread, however.
>
> William
Probably over-simplified there a little.

Still, I think we've run round one loop, and still not learnt much new...
*fakes surprise*



signature.asc
Description: OpenPGP digital signature

Re: Implicit use of versionator.eclass in ebuilds and eclasses (was: Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/)

[M. J. Everitt]

On 19/05/18 01:01, Andreas Sturmlechner wrote:
> On Freitag, 18. Mai 2018 23:53:06 CEST Michał Górny wrote:
>> One of the reasons we do mailing list reviews of widely used eclasses is
>> to let people tell you that you've left 'version_is_at_least' here.
> I see the error of my ways.
>
> Meanwhile, here's a list of packages implicitly using versionator.eclass 
> functions:
>
> eclasses:
>
> haskell-cabal.eclass
> mozextension.eclass
>
> ebuilds:
>
> app-admin/rsyslog/rsyslog-8.28.0-r1.ebuild
> app-admin/rsyslog/rsyslog-8.32.0-r4.ebuild
> app-admin/rsyslog/rsyslog-8.33.1-r1.ebuild
> app-admin/rsyslog/rsyslog-8.34.0.ebuild
> app-admin/rsyslog/rsyslog-8.35.0.ebuild
> app-emulation/qemu/qemu-2.11.1-r2.ebuild
> app-emulation/qemu/qemu-2.11.1-r53.ebuild
> app-emulation/qemu/qemu-2.12.0.ebuild
> app-emulation/qemu/qemu-.ebuild
> dev-java/htmlparser-org/htmlparser-org-1.6.ebuild
> dev-java/vecmath/vecmath-1.6.0_pre12.ebuild
> dev-ruby/rspec-core/rspec-core-3.5.4.ebuild
> dev-ruby/rspec-core/rspec-core-3.6.0.ebuild
> dev-ruby/rspec-core/rspec-core-3.7.0.ebuild
> dev-ruby/rspec-core/rspec-core-3.7.1.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.5.0.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.6.0.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.7.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.5.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.6.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.7.0.ebuild
> dev-vcs/bzr/bzr-2.7.1_pre.ebuild
> net-fs/samba/samba-4.2.14.ebuild
> net-fs/samba/samba-4.5.16.ebuild
> net-fs/samba/samba-4.6.15.ebuild
> net-fs/samba/samba-4.7.7.ebuild
> net-fs/samba/samba-4.8.1.ebuild
> net-fs/samba/samba-4.8.2.ebuild
> net-misc/openvswitch/openvswitch-2.7.2.ebuild
> net-misc/openvswitch/openvswitch-2.7.2-r1.ebuild
> net-misc/openvswitch/openvswitch-2.8.1.ebuild
> sys-apps/lm_sensors/lm_sensors-3.4.0_p20170901.ebuild
> sys-apps/lm_sensors/lm_sensors-3.4.0_p20180318.ebuild
> sys-kernel/mips-sources/mips-sources-4.13.16.ebuild
> sys-kernel/mips-sources/mips-sources-4.4.110.ebuild
> sys-kernel/mips-sources/mips-sources-4.9.75.ebuild
>
>
>
>
Can that be parsed into a list of (unique) maintainers to ping maybe?

Someone might have to pick up any maintainer-needed ones I s'pose.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/4] xdg-utils.eclass: make EAPI 7 ready

[M. J. Everitt]

On 21/06/18 03:38, Jason Zaman wrote:
> On Wed, Jun 20, 2018 at 06:01:10PM -0500, Marty E. Plummer wrote:
>> On Wed, Jun 20, 2018 at 11:33:53PM +0100, James Le Cuirot wrote:
>>> On Wed, 20 Jun 2018 17:21:09 -0500
>>> "Marty E. Plummer"  wrote:
>>>
 On Wed, Jun 20, 2018 at 09:03:44PM +0800, Jason Zaman wrote:
> On Wed, Jun 20, 2018 at 02:10:50AM -0500, Marty E. Plummer wrote:  
>> Use ${EROOT%/} whereever possible, as the tools and directories which
>> are used with it are already prefixed with a /
>>
>> Package-Manager: Portage-2.3.40, Repoman-2.3.9
>> ---
>>  eclass/xdg-utils.eclass | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/eclass/xdg-utils.eclass b/eclass/xdg-utils.eclass
>> index ac075185d8e..8dba5ed6861 100644
>> --- a/eclass/xdg-utils.eclass
>> +++ b/eclass/xdg-utils.eclass
>> @@ -66,7 +66,7 @@ xdg_environment_reset() {
>>  # Updates the .desktop files database.
>>  # Generates a list of mimetypes linked to applications that can handle 
>> them
>>  xdg_desktop_database_update() {
>> -local updater="${EROOT}${DESKTOP_DATABASE_UPDATE_BIN}"
>> +local updater="${EROOT%/}${DESKTOP_DATABASE_UPDATE_BIN}"  
> Shouldn't things like this be $BROOT since they're being run? $EROOT
> might be a different architecture that may or may not run at all on the
> build machine.
>   
 Good point, but here's a question; if EROOT=${ROOT%/}${EPREFIX}, how do
 we use BROOT here? EBROOT? Or longhand ${BROOT%/}${EPREFIX} ? I think
 that may be a use case that got missed in the EAPI 7 discussions.
>>> BROOT is already prefixed as BROOT without a prefix would just be /.
>>>
>> I don't follow. Its my understanding that BROOT ~= ROOT for most
>> situations. But consider this setup:
>> Ubuntu amd64 with Gentoo Prefix, emerging a native arm @system to
>> /mnt/arm EPREFIX = /home/user/gentoo.
>>
>> In this situation, ROOT=/mnt/arm, EROOT=/mnt/arm, but what is BROOT? /,
>> or /home/usr/gentoo?
> https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html#broot-variable-for-bdepend
>
> Basically BROOT already contains EPREFIX or BPREFIX or whatever it would
> be called. There is like no need for an un-prefixed BROOT so its just
> merged in. so you should just need "${BROOT}/usr/bin/update-mime-database"
>
> -- Jason
>
>>> -- 
>>> James Le Cuirot (chewi)
>>> Gentoo Linux Developer
>>
>>
Obligatory n00b question .. how does this work in EAPI <= 6 ?! :D



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Hostile takeover of our github mirror. Don't use ebuild from there until new warning!

[M. J. Everitt]

On 28/06/18 22:54, Francisco Blas Izquierdo Riera (klondike) wrote:
> El 28/06/18 a las 23:15, Francisco Blas Izquierdo Riera (klondike) escribió:
>> Hi!
>>
>> I just want to notify that an attacker has taken control of the Gentoo
>> organization in Github and has among other things replaced the portage
>> and musl-dev trees with malicious versions of the ebuilds intended to
>> try removing all of your files.
>>
>> Whilst the malicious code shouldn't work as is and GitHub has now
>> removed the organization, please don't use any ebuild from the GitHub
>> mirror ontained before 28/06/2018, 18:00 GMT  until new warning.
>>
>> Sincerely,
>> Francisco Blas Izquierdo Riera (klondike)
>> Gentoo developer.
>>
>>
> Just to keep up with it. There is a more complete article published at
> https://www.gentoo.org/news/2018/06/28/Github-gentoo-org-hacked.html
>
>
>
Antarus has also posted on g-announce ML fyi ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [warning] the bug queue has 82 bugs

[M. J. Everitt]

On 06/02/16 22:00, Alex Alexander wrote:
> Our bug queue has 82 bugs!
>
> If you have some spare time, please help assign/sort a few bugs.
>
> To view the bug queue, click here: http://bit.ly/m8PQS5
>
> Thanks!
>
Only 82? that's not, like, 4k ... :) http://tinyurl.com/maintainer-wanted .

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[M. J. Everitt]

On 09/02/16 23:38, Alex McWhirter wrote:
> On 02/09/2016 05:39 PM, Duncan wrote:
>> I'd agree, except that the way we're running udev is strongly discouraged 
>> and generally not supported by upstream, with a statement that it /will/ 
>> break in the future, it's simply a matter of time. 
>>
>> Which makes a big difference when supporting that same specific use-case 
>> is the primary and arguably only reason the considered alternative exists.
>>
>> IOW, it's not about not liking upstream.  It's about choosing a default 
>> that supports our default use-case.
>>
> My point exactly. When this happens we either make something like eudev
> default or we have to make systemd default. I don't really care which as
> long as i still have the option to change it.
>
+1

Re: [gentoo-dev] "Lazy" use flags?

[M. J. Everitt]

On 11/02/16 12:55, Rich Freeman wrote:
> On Wed, Feb 10, 2016 at 11:57 PM, Kent Fredric  wrote:
>> On 11 February 2016 at 15:51, Rich Freeman  wrote:
>>> In this case you just wouldn't enable python 2.7 support, but you
>>> wouldn't disable it either.  Portage would just pull it in where it is
>>> needed.
>> But you still need a mechanism in place if you *dont* want that to happen.
>> ...
>>> Unless of course you're suggesting "USE=-python_targets_python2_7"
>> would not be "auto-enableable"
> That is correct.
>
>> But then you're *still* requiring a tri-state USE.
> Sure - it would be the same as how package-versions work today.
>
> Stick it in world, and you're pulling it in.
>
> Stick in in mask, and you're keeping it out.
>
> Don't do anything, and portage does what it thinks is best, guided by
> profiles/etc.
>
>> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
> This is the only thing that would change.  In all the other scenarios
> you described the behavior would be the same as today.  If you set
> USE=-foo then you'll get the same errors you get today.
>
> Now, auto-unmask could still propose sticking USE=+foo in your
> package.use if you have USE=-foo in your make.conf, which is already
> the behavior today.  If you've made any explicit USE setting in your
> configuration, portage would never ignore it, but only suggest that
> you change it.
>
> Perhaps it might make sense to introduce a new ~foo setting which
> undoes a +/-foo in make.conf but doesn't set it either + or - in
> package.use, allowing the setting to revert to the default behavior.
> That would actually be useful independent of lazy use flags, but would
> be more useful with lazy use flags.
>
>> Mentally keeping track of this accounting magic would be complicating 
>> matters.
>>
> I think you're overthinking this.  It is completely analogous as to
> what portage already does with package-versions.  I don't have libjpeg
> in my world file, and yet portage installs it, and I don't think about
> it either way.  If I wanted to pin a specific version of it or mask it
> I could, but of course the preference of most users is to micromanage
> as little as possible.
>
> Basically lazy use flags is intended for users to minimize the size of
> their package.use files, just as they already minimize the size of
> their @world and package.mask files today.
>
I would avoid complicating the USE flag system .. it's straightforward
as it is, and has already been 'tweaked' by the auto-unmask feature,
leading to large package.use files and has no support of per-category
files (that I know of).

I would propose the introduction of a 'LUSE' flag (lazy-use or
lightweight-use) which serves as a fall-back if the main USE system
"fails" - ok this requires duplication of the existing checking system
(and hence integration with portage) but it would allow you to set USE
flags per system at install .. and you could 'tweak' LUSE flags to suit
package implementations instead.

Re: [gentoo-dev] "Lazy" use flags?

[M. J. Everitt]

On 11/02/16 14:32, Kent Fredric wrote:
>> and has no support of per-category files (that I know of).
> # /etc/portage/package.use/dev-qt
> dev-qt/*  qt3support
>
> ^ Legal, works
>
>
Portage does, auto-unmask has a very inconsistent, unstable way of
working with a package.use folder not file ...

Re: [gentoo-dev] "Lazy" use flags?

[M. J. Everitt]

On 11/02/16 14:46, Kent Fredric wrote:
> On 12 February 2016 at 03:43, M. J. Everitt  wrote:
>> auto-unmask has a very inconsistent, unstable way of
>> working with a package.use folder not file ...
>
> auto-unmask consistently adds items to the file with the highest
> dictionary sort.
>
> So if you name all the files with numerical prefixes, 00 .. 99, "99"
> is where auto-unmask will write to.
>
Well, that's obvious 

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 15/02/16 02:16, Mike Frysinger wrote:
> On 14 Feb 2016 15:56, Anthony G. Basile wrote:
>> On 2/14/16 3:47 PM, Mike Frysinger wrote:
>>> On 14 Feb 2016 15:42, Anthony G. Basile wrote:
 On 2/14/16 3:23 PM, Mike Frysinger wrote:
> eudev: no one of any relevance outside of Gentoo runs it.
 that's not true, nor is it the central criticism, imo.
>>> can you list the projects that utilize eudev ?  the repo doesn't
>>> that i can see.  it is the central criticism imo when correct
>>> interaction with other projects is key.  people rely on rules being
>>> parsed & run correctly, as well as information provided by udev
>>> matching what they are running/testing everyday.
>> until patrick brought up the list of distros, i was only aware of
>> alpine which is a musl based distro.  then puppy and slack came
>> forward.  they build their entire system using eudev as the libudev
>> provider.  if there were issues, they would bring forward bug reports
>> like any other project.
>>
>> so when you say "people rely on rules being parsed ..." i don't know
>> why those user bases are dismissed.
> i'm not dismissing them per-se.  i'm being practical here: i think you
> can agree that the combined developer base of alpine/puppy/slack(ware?)
> is significantly smaller as compared to the distros using udev.
> -mike
by "udev" do you mean systemd (as they are losely one-and-the-same) or
the unsupported udev-severed-from-systemd ...
Of course there is no comparison between Anthony's work on eudev and the
systemd 'crowd' it's just a non-question.

I think people are confusing the fact that there IS no separate 'udev'
.. it is the work of a gentoo maintainer to make it work without
systemd. To this end, does it really matter that OpenRC users are
reliant on a gentoo developer applying heavy patching of 'upstream'
udev-for-systemd .. or another gentoo developer working on an
alternative that's roughly API-compatible. The discussion is how you
jump the inevitable shark, and perhaps by switching the default and
having a bit of time ahead to deal with issues, is surely better than
facing a large breakage ahead, when there remains an option to switch
back to the current udev if there are problems with eudev. It also gives
Anthony a chance to have a greater user-base to test and evaluate eudev
so that improvements can be made in a timely fashion before
udev-without-systemd becomes unavailable (for whatever set of reasons).

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 15/02/16 05:28, Mike Frysinger wrote:
> On 15 Feb 2016 02:31, M. J. Everitt wrote:
>> I think people are confusing the fact that there IS no separate
>> 'udev'
> 
> i'm fully aware of this fact and have been since it happened. i
> don't think it changes my point. -mike
> 
It wasn't necessarily aimed at you .. just clarifying the point that
for others the point may not have completely sunk in :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 17/02/16 13:38, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
>>> With the exception that Lennart Poettering is the lead developer of
>>> systemd/udev, while such a thing cannot be said about you and eudev.
>> He's lead developer of *systemd*. udev is a split part of systemd
>> codebase which has specific maintainers.
>
> systemd and udev share the same codebase. You can no longer build udev
> without systemd. udev is only a sub-project of systemd now, hence the
> name "systemd-udevd".
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>
How hard is it to understand that there really is no longer a standalone
udev .. it's part of another project .. therefore no longer separate.
One of the developers already works for systemd. The other is clearly
busy with kernel coding.

My two cents for today:

https://en.wikipedia.org/wiki/Udev
http://without-systemd.org/wiki/index.php/Main_Page

+5 for Chi-Thanh for keeping it factual and objective.

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[M. J. Everitt]

On 25/02/16 08:59, Kent Fredric wrote:
> On 25 February 2016 at 21:02, Consus  wrote:
>> Well, we do have one
>> 
>> https://gitweb.gentoo.org/repo/gentoo.git/log/dev-lang/perl
>> 
>> I bet folks want to check out what's new in their local copy of 
>> Portage tree.
> 
> 
> With a custom, portage oriented, on-demand log generator you could
>  produce a lot more detail ( and in a text format that doesn't 
> require a web browser to view ) , and potentially use
> understanding of portage conventions to generate change data
> outside those explicitly stated.
> 
> Though that would be a "later feature" you could potentially bolt 
> on after the main logic was sorted out.
> 
> The idea being you could request a changelog for a package with a 
> list of "interest aspects" and have the log reduced to changes
> that affect those interests.
> 
> For instance, you could do :
> 
> curl http://thing.gentoo.org/changes/dev-lang/perl?arch=~x86
> 
> And with a bit of effort, you could generate a changelog that is 
> only relevant for somebody who is on ~x86, eliding changes that
> x86 didn't get yet.
> 
> For instance, an ~x86 filter would elide stabilizations for ~x86, 
> because you don't care about stabilizations if you're assuming 
> ~arch. ( And it would elide changes that were only visible for 
> other arches )
> 
> And this filter wouldn't necessarily be implemented in "grep for 
> keywords in the commit message", but *analyse the change in the 
> directory* based, which would give the ability to do things that 
> would otherwise only be possible with a git clone.
> 
> 
> 
This idea is quite neat - you could do either some basic User-Agent
check and either render a web page for viewing online for changes, or
even have a specifier that gave you some other output options .. eg.
ChangeLog (rev. chron) or basic web or XML or JSON which you could
then post-process if you desired.

I know this is kind of bloating the idea, but the flexibility and such
would make it Really Useful .. I think, anyhow ...

MJE

Re: [gentoo-dev] Packages up for grab

[M. J. Everitt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/03/16 19:48, Christian Ruppert wrote:
> app-forensics/lynis
> dev-libs/log4cplus
> dev-vcs/colorsvn
> dev-vcs/git-deploy
> dev-vcs/topgit
> sci-electronics/fritzing
> sys-auth/libnss-cache
> media-video/nvidia-settings
>
> Feel free. If you need some more info please poke me on IRC.
>
I'll proxy fritzing until such time as I get 'devs' if nobody has spoken
up by end of month and agreed by others.

Christian: Will drop you a msg on IRC for a quick heads-up :).

Michael aka 'veremit'.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJW6pS9AAoJEEwwM0+TwiNxXjcP/0TiMUeZWn3aB2VJ2hP6OYvC
mr6c1LHukq6mm6ZfC4hAyDyZjCTI9r+ukTNTBGqcoASljOy4kHsee1H77uU4OzGb
xQczK1bQoSK/88MMvflZPgWj7gIHwvFd8gkcqG1zlJpCZHA0OI+KBnmE2E7LqwSu
vEti1B1rho8vOAO03/++YnbfJ/A1JamcI1Im4hNDA8nP9LuLttTrTQR0qTpkoBG0
l4Y3qgH4zbCRFmkhD2XgvU/8bXB78AgkNhAL00k8CjjAeKcCujzhUL+uxIAUcttg
TlszEYSAKjW+EFJDRtowBIx66OUkwrjrodpPfaXlFomLatjTUYgAx1nOQsj08Xj2
BVvzEompbPlys25dV21+IDXsJjOnFTbrjOhWxo1hdttxlrw7iS91SMsPtzEKcX8v
pt6ni9yRSdMQcPS3fgjqP1COI9C3GrL/6AXUnVRAWy4IlEFMmAED/VmjKOunL602
y+Rx8NuKtY8WD3MDWOihfNHTOgyTEY32r2g869Qd/jCQpYzFE6ev91i/WrGqmbXN
fKteUokiTms5NaoW5h3Smnaw53uV3YWF6F1f2w7HTcBMJOBEKrNzKTN3lQZLeS1l
TNX2wgnGJKnDZPJR9pRUnt51hsGQT+QoLtVfiNtuuBARyWPcesNiJAhniZVLN6ZM
b8l40UazJ1n5HFl0lZKm
=FUvC
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH v1 1/3] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490

[M. J. Everitt]

On 04/04/16 05:57, NP-Hardass wrote:
> On 04/04/2016 12:34 AM, Göktürk Yüksek wrote:
>> +sufficient for adding or removing a developer. Note that
>> different +projects have different requirements and procedures for
>> recruiting +developers, which may require prior arrangements to be
>> made before +modifying the member list.
> I'm not particularly fond of this statement.  The implication is that
> most projects require permission, whereas I believe that the opposite
> is true.  To the best of my knowledge, most projects are open, and
> ones that have special requirements almost always list them explicitly
> on their project pages.  As far as I know, the only exception to this
> is new developers, as they are noobs and thus project lead approval is
> a slight quality control. I'd rather see it worded more like:
> 
> Seasoned developers, generally speaking, can join any project at their
> leisure, however, some projects explicitly list restrictions or
> requirements to join such as training, apprenticing, or approval of
> the project lead.  When in doubt, consulting the project/lead prior to
> joining a project.
> 
> 
Still needs some work, I think ... :)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: upgrading to Plasma 5

[M. J. Everitt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/04/16 18:34, Michael Palimaka wrote:
> Hi,
>
> KDE team intends to stabilise Plasma 5 shortly, so please review the
> accompanying news items.
>
> Regards,
>
> Michael
>
> Title: KDE Plasma 5 Upgrade
> Author: Michael Palimaka 
> Content-Type: text/plain
> Posted: 2016-04-02
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: kde-base/plasma-workspace:4
>
> KDE Workspaces 4.11 has reached end of life and is no longer supported
> by upstream. It is therefore recommended for all users to upgrade to
> KDE Plasma 5.
>
> A detailed upgrade guide is available[1], but in most cases it enough to
> switch to the new desktop/plasma profile, update @world, and
> emerge kde-plasma/plasma-meta:
>
> # eselect profile list
> # eselect profile set 
> # emerge --ask --changed-use --newrepo --deep world
> # emerge --ask --verbose kde-plasma/plasma-meta
>
> If you normally use KDM to launch Plasma, note that it is no longer
> supported.
> Upstream recommends x11-misc/sddm instead which is pulled in by
> plasma-meta by
> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.
>
> Due to an an evolution of KDE upstream's release process[2], the
traditional
> monolithic KDE 4 release is now split into three distinct components. This
> means that KDE Applications are now separate from the Plasma desktop and
> older KDE 4-based applications will continue to function as normal
> inside Plasma 5.
>
> KDE Workspaces 4.11 will remain in the tree for a reasonable time, but
> be warned that it is unmaintained and may cause conflicts with
> newer versions of KDE Applications.
>
> [1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade
> [2] https://dot.kde.org/2013/09/04/kde-release-structure-evolves
>
>
>
In the event you're not explicitly using a desktop or KDE desktop
profile, can you provide a summary of the changes that should be made
manually when switching the the kde-plasma/* ebuilds please? I can
probably handle a display manager change over a network of systems, but
making a sensible transition to Plasma5 over many systems could be a
trial if a small step is overlooked Thanks!

Michael/veremit.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXBPb/AAoJEEwwM0+TwiNxxvAP/3+pJZdU+iQBwiGWep9iostE
mQFoIuP5uT4iraXBzxvZ9xzBPC8Tf0XegE9gXoLyWTEqc0/gtzGK+/Sfqv0TlQ0a
F3uUt8zRFZH45sdSrfHlbALCkhGpxeHe13WsIilNgS41u/0zIoV9+TszctbEQPam
XYt90iDT6eSfdVHfnL3vtaK5ymqe6gHFYVDuP4+08hcDn557IeVmKfZGZJOcVoFX
pk+p9zNrVP9971SGHJIjl/1DAcz34U4PmBrvXyE5/ziH5cgfAofuL1JulsPoldBy
RwJy3b0pCRYwoju+TxrkNtWxX9wFcG5J+ofTFTONO6Aez1vo/tP+WBiQD1MieDGN
2qyq4ATaIJhZj6hSuLZ2/GKws3eSihHLKMTRg+2WjeQnJNOHjJ2yFbHZ/1pCH4Gg
+Ql0KgIrcKkrwJdKVwP1FEsQPmAmAkS+7zgl987ITxqahJTB2bbqFWmwb8dudg/4
wjbH5YWLy6FRrFDkMqxF+//vMnpJ7TDssbsyAFXbVmFFuiBFCfgJ1lDjuy0anZH4
1VqYa3I4+ZrQy1LX0+pts28PUudLZgxArHotXd+hqdKmIUtyzppdgTdNMom3Ol2b
jSlTITqJePKa1HwOIt0G1eJMwRJy0P1mySJF0Uhi8NVZ0eT+he3J/KNnDsisB/ac
mGGHpOPmx8slMDQTLVg7
=ZRRc
-END PGP SIGNATURE-

[gentoo-dev] GPG key

[M. J. Everitt]

For those having a minor panic, I've just imported my home email GPG key
to my work PC .. so that's the reason I've sent out an erroneous email.
Rest assured the key is -right- and thanks to K_F I have two properly
functional Thunderbird/Enigmail installs working with kwalletcli from
pinkbyte's overlay.

Ping pinkbyte .. there's an update for kwalletcli up now, I'll proxy it
into main tree if you don't mind.
Cheers,

Michael/veremit.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

What, if any, is the benefit of squashing /usr out of the equation? I
happen to have a few workstations that load their /usr off an NFS share
presently, with some bodgery-workarounds I did pre the udev notification
about initramfs's which I have never got around to implementing
(although I'm pretty sure I have the tools now to do, along with UUIDs
for boot media).
Whilst these aren't currently scheduled for upgrade, I don't personally
see any merit, given discussions here about work needed to 'shore up' a
change to match some particular use case. I would therefore definitely
agree with those that have proposed that this is an Option and not a
standard gentoo install item unless there are some specific caveats that
this solves.

Michael/veremit.

On 05/04/16 02:19, William Hubbs wrote:
> All,
>
> I thought that since the usr merge is coming up again, and since I lost
> track of the message where it was brought up, I would open a
> new thread to discuss it.
>
> When it came up before, some were saying that the /usr merge violates
> the fhs. I don't remember the specifics of what the claim was at the
> time, (I'm sure someone will point it out if it is still a concern).
>
> I don't think creating usr merged stages would be that difficult. I
> think it would just be a matter of creating a new version of baselayout
> that puts these symlinks in place:
>
> /bin->usr/bin
> /lib->usr/lib
> /lib32->usr/lib32
> /lib64->usr/lib64
> /sbin->usr/bin
> /usr/sbin->bin
>
> Once that is in place in a new baselayout, I think portage's colission
> detection would be able to catch files that had the same names and were
> originally in different paths when building the new stages.
>
> I put some thought also in how to nigrate live systems, and I'm not sure
> what the best way to do that is. I wrote a script, which would do it in
> theory, but I haven't tested because I only have one system and if
> it breaks it the only way back would be to reinstall.
>
> The script is attached.
>
>
> Thoughts on any of this?
>
> William
>




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 06/04/16 17:06, Richard Yao wrote:
>
> That does not address the problems of supporting this configuration in a
> rolling release.
>
> Formats in /etc can fall out of sync with software in /usr. If boot
> options change, the stuff in /etc/init.d is not updated. If you add
> software, the update to /etc/init.d is omitted. If you have a baselayout
> change, it is not propagated. Whether or not the package manager can be
> used is not discussed. It definitely can be in Solaris when this feature
> is used in Solaris zones, although I am not sure how that interacts with
> updates as I never looked. I do not have a VM with a member of the
> OpenSolaris family handy to check.
/usr/etc .. or /usr/local/etc *ew* ... ?!?!
> Solaris and RHEL will see the benefits described on the Fedora page
> because they handled many of those problems. In most cases, they handled
> it by being stale non-rolling releases that do not support major version
> upgrades. Fedora handled it by having a disclaimer that things should be
> expected to break across Fedora versions. Neither are things that I
> expect us to do, so if we adopt this, we will need to do something
> entirely new to be able to gain these benefits.
>




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: upgrading to Plasma 5

[M. J. Everitt]

On 07/04/16 01:45, Jonathan Callen wrote:
> On 04/06/2016 07:46 AM, M. J. Everitt wrote:
>
> > In the event you're not explicitly using a desktop or KDE desktop
> > profile, can you provide a summary of the changes that should be
> > made manually when switching the the kde-plasma/* ebuilds please? I
> > can probably handle a display manager change over a network of
> > systems, but making a sensible transition to Plasma5 over many
> > systems could be a trial if a small step is overlooked Thanks!
>
> > Michael/veremit.
>
>
>
> The list of things that the plasma profiles add to the system can be
> found in ${PORTDIR}/profiles/targets/desktop/plasma/.  The
> make.defaults and package.use in there show which USE flags a default
> plasma install would need (in addition to the standard desktop profile
> and the flags enabled by default in the ebuilds).  Note that most of
> the changes are either a) disabling things in some old KDE 4 stuff
> that hasn't been ported completely, to just have the bits still
> required on a mostly-ported system, and b) choosing which
> implementation (Qt4/Qt5) on packages that require you to choose (the
> profile ends up enabling USE="qt4 qt5" for most packages, this turns
> off one of them for some packages).
>
Thanks, I'll dig over those and see if the wiki page can be tweaked
slightly :)

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 07/04/16 17:36, Alexis Ballier wrote:
> On Thursday, April 7, 2016 6:22:16 PM CEST, Rich Freeman wrote:
>> Again, I don't see this as a reason not to make it optional, but I
>> suspect that we will find bugs here from time to time which users who
>> run with the split /usr will have to report/fix.
>
>
> Considering the advantages of usr-merge are rather specific IMHO but
> risks during the migration are high, I think you're optimistic on the
> user base of usr-merged systems :)
>
> Heck, it hasn't happened yet because there hasn't been such a big need
> for it.
>
In the spirit of hearing arguments for/against .. could someone with the
appropriate 'fu' throw up a quick survey for those on this ML (and/or
possibly the g-users?) to indicate a preference for a change to a
flattened-/usr system?

I did think re: the eudev "debate" that it was really hard to quantify
the opinion for and against a change, and take it away from the  vocal
people that obviously feel passionately about their cause :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 02:42, William Hubbs wrote:
> On Thu, Apr 07, 2016 at 08:39:07PM -0500, William Hubbs wrote:
>> On Thu, Apr 07, 2016 at 01:18:01PM -0700, Raymond Jennings wrote:
>>> Personally I think that merging things into /usr is a major policy decision
>>> that is likely to contravene upstream installation locations.  I wouldn't
>>> do it lightly, if at all.
>> Actually, there are upstreams that already do this, and we are the ones
>> that move things around.
>>
>> Specifically, one example is coreutils. The ebuild installs everything
>> in /usr/bin, then we move all of the binaries around.
> There was a bypo here. "the ebuild" should be upstream. The default
> installation location of all coreutils binaries is /usr/bin, then we
> move everything around in the ebuild.
> We are deviating from upstream in this example.
>
> William
>
I would expect this isn't the only example of this in Gentoo .. we
customise the packages to make sense to the Gentoo distro, not conform
to a multitude of random "standards" applied by many developers. So,
whilst I accept that its desirable to match 'upstream' - this isn't
always going to be possible.

I would also re-iterate, as I'm sure you're aware .. there ARE
differences between sbin and bin .. unless of course you spend all your
time in a Rooted VM where it doesn't matter if you accidentally trash
your system. Some of us maintain a sensible user/superuser distinction
for a variety of reasons, and simplifying your filesystem to suit some
particular package style doesn't really sound like good reasoning for
causing a lot of headaches for maintainers and a distro overall.

*puts the paint can down*



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 03:36, Damien Levac wrote:
> Anybody who have this kind of misconception about 'usr merge' should
> read this:
>
> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
>
> Signed,
>
> a user who got scared by this thread and documented myself before
> freaking out too much...
>
>>> Personally I think that merging things into /usr is a major policy >>
> decision that is likely to contravene upstream installation
>>> locations.  I wouldn't do it lightly, if at all.
>
Three points :-
1) systemd - not all gentoo users subscribe to this 'philosophy' .. but
no, I don't want get drawn into debates of yes/no of systemd ..
2) "Today, a separate /usr partition already must be mounted by the
initramfs during early boot, thus making the justification for a
split-off moot." - no, not all gentoo users have an initramfs and
need/want one .. so this is a false assumption.
3) I still believe there is merit in distinguishing between binaries
that can/should be run as root, and those that can/should not. Those
that run as root 100% of the time, or use VMs, don't really 'use' linux
in the original sense of the OS ..

*hides in his bike-shed, awaiting the flaming torches*

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 15:20, William Hubbs wrote:
> On Fri, Apr 08, 2016 at 03:44:06AM +0100, M. J. Everitt wrote:
>> 3) I still believe there is merit in distinguishing between binaries
>> that can/should be run as root, and those that can/should not. Those
>> that run as root 100% of the time, or use VMs, don't really 'use' linux
>> in the original sense of the OS ..
> Here is more info about the split and why it exists. It turns out it hs
> nothing to do with system admininistration or permissions.
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/
> https://news.ycombinator.com/item?id=3519952
>
> In short, this is all a historical artifact with justifications thought
> up after the fact.
>
> William
I'll come back to the links a bit later, but is policykit and its
predecessor/derivatives now a mandatory part of a linux system?

Possibly crossing posts here, so apologies in advance .. ! :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 16:02, Rich Freeman wrote:
> On Fri, Apr 8, 2016 at 10:33 AM, M. J. Everitt  wrote:
>> I'll come back to the links a bit later, but is policykit and its
>> predecessor/derivatives now a mandatory part of a linux system?
>>
> The only mandatory component in a linux system, by definition, is the
> Linux kernel.
>
> A linux system could consist of nothing but a kernel with
> init=/usr/local/bin/hello-world.
>
> Most traditional linux distros are going to run policykit though.  Of
> course you can have a mostly-traditional distro that doesn't, at least
> until everything wants to use dbus or whatever ends up replacing it
> once son-of-kdbus comes along and gets accepted.
>
Surely, Rich, you mean init=/bin/hello-world ... ;]

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 16:02, Rich Freeman wrote:
>
> The only mandatory component in a linux system, by definition, is the
> Linux kernel.
>
> A linux system could consist of nothing but a kernel with
> init=/usr/local/bin/hello-world.
>
> Most traditional linux distros are going to run policykit though.  Of
> course you can have a mostly-traditional distro that doesn't, at least
> until everything wants to use dbus or whatever ends up replacing it
> once son-of-kdbus comes along and gets accepted.
>
Being serious though, and playing Devil's Advocate of course, assuming
you have no use for a desktop manager, etc, hence no need for dbus or
it's 'friends' and policykit or it's pals, and you're not a "systemd
fan" etc .. how are we granting the correct permissions for binaries ..
just relying now on the owner and execute bits being set perfectly for
each binary, assuming everything is arbitrarily moved to /xbin ...

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 09/04/16 20:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb  wrote:
>> I've always used Lilo, which is simple + reliable :
>> I never see questions re it here, but there are many re Grub.
>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>> When setting it up, I suppressed UEFI in the BIOS settings :
>> isn't that what anyone not running M$ would do ?
> That depends on how much you care about rootkits...  :)
>
Rootkits in linux ... why?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 09/04/16 23:50, Philip Webb wrote:
> 160409 Canek Peláez Valdés wrote:
>> On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb  wrote:
>>> I've always used Lilo, which is simple + reliable :
>>> I never see questions re it here, but there are many re Grub.
>>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>>> When setting it up, I suppressed UEFI in the BIOS settings :
>>> isn't that what anyone not running M$ would do ?
>> I just disabled secure boot, although it's possible to use it with Linux.
>> However, it would require to manually sign everything from boot loader
>> to kernel modules, since Gentoo has no infrastructure to do that.
>> I don't "supress" UEFI, since it's *obviously* so much better than BIOS
>> and since bootctl (the program formerly known as gummiboot)
>> it's incredible easy to use. You don't even notice it's there.
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.
>
>> I believe there are motherboards where you don't have the option
>> to "supress" UEFI, since they simply don't have BIOS anymore.
>> Seriously, UEFI is s much better.
> Thanks for the enlightment (smile).
>
> Can you or anyone else answer my other question re the origin of the thread ?
> -- ie is this a revival of not putting  /usr  on its own partition
> or is it a new proposal to alter the file system in some other way ?
>
Philip, the discussion was prompted from this original message by WilliamH:

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

Basically there is a desire to either (1) move /bin, /sbin to /usr/bin,
/usr/sbin or (2) the reverse (ie. eliminate /usr) for a variety of
reasons, but predominately to offer "more users more choice", and uphold
the principle of Gentoo being a distro of flexibility.

Whilst there is some good pros/cons being aired, there is also the usual
amount of gentoo bike-shedding, and personal preference distorting the
discussion :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 00:53, William Hubbs wrote:
>
> The original discussion was about the usr merge [1], which is taking the
> binary parts of / and putting them in /usr, then inserting symlinks in /
> to preserve backward compatibility. Yes, I'm pointing to a document on
> fdo, but the systemd guys have nothing to do with the /usr merge; it
> originally happened in Solaris.
>
> I never supported the reverse merge that has been discussed, it was just
> brought up I guess as an example of a Gentoo user being able to do his
> own setup. Reverse merge meaning moving everything from /usr to /.
>
I may have contributed to the latter point, but addressing the former
specifically, I, like others, have /usr mounted on an NFS server for
thin clients (not in the full-true sense, but with a very minimal /
currently residing on USB).
What you propose moving binaries from / to /usr would render them
completely unbootable without early mounting via initramfs. Granted,
what I have now is rather a bodge, but it's working fine, and provided I
am meticulous about any rare changes from the host build system to /,
this is a small problem in the grander scheme of things, and I have one
maintained 'install' on my build system. Ok, so a full thin-client would
probably be a better* option, but I'm running with what I got, rather
than investing a lot (of/more) time/energy in getting that solution
working, which failed on (several) previous attempts (hence *).



signature.asc
Description: OpenPGP digital signature