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

[Michael Orlitzky]

On 11/27/2017 10:16 AM, Mike Gilbert wrote:
> On Mon, Nov 27, 2017 at 6:46 AM, Aaron W. Swenson  
> wrote:
>>
>> You should now be able to do compilation and tests without having the
>> user/group created. For example, dev-db/postgresql doesn’t need the
>> postgres system user and group in order to successfully run through
>> src_test and src_install. It just needs the user/group at run time.
> 
> Sounds like the enewuser call should be moved from pkg_setup to
> pkg_postinst in that case.
> 

https://bugs.gentoo.org/525828

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] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

[Andreas K. Huettel]

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 K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH] meson.eclass: add meson_use function

[Jan Chren (rindeal)]

On 15 December 2017 at 17:38, Mike Gilbert  wrote:
> ---
>  eclass/meson.eclass | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 2c943dd6ae27..71735fbfc67d 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -137,6 +137,19 @@ _meson_create_cross_file() {
> EOF
>  }
>
> +# @FUNCTION: meson_use
> +# @USAGE:  [option name]
> +# @DESCRIPTION:
> +# Given a USE flag and meson project option, outputs a string like:
> +#
> +#   -Doption=true
> +#   -Doption=false
> +#
> +# If the project option is unspecified, it defaults to the USE flag.
> +meson_use() {
> +   usex "$1" "-D${2-$1}=true" "-D${2-$1}=false"
> +}
> +
>  # @FUNCTION: meson_src_configure
>  # @DESCRIPTION:
>  # This is the meson_src_configure function.
> --
> 2.15.1
>
>

Isn't this the beginning of this wheel
https://github.com/gentoo/gentoo/commit/e9116b1aebc819a10410960cbb4931aa5e399af1
?

Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

[Aaron W. Swenson]

On 2017-12-15 16:37, R0b0t1 wrote:
> Hello,
> 
> On Tue, Dec 5, 2017 at 4:18 PM, Nils Freydank  wrote:
> > Hello everyone,
> >
> > with regards to the current mailing list (ML) split discussion, and one
> > specific message deep down there by mgorny asked for someone providing
> > moderator rules, I would like to propose the following ruleset for 
> > gentoo-dev
> >
> > Right now the situation escalated in a way that forces to actually do
> > something and I hope we can recreate an atmosphere where technical
> > improvements can happen.
> >
> 
> To me, at least, this isn't self-evident. What specific actions make
> you think an immediate response is necessary?
> 
> self-evident
>   adj. Evident to one’s self and to nobody else.
> 
> Cheers,
>  R0b0t1
> 

According to Merriam-Webster:

self-evident
 adjective | self-ev·i·dent | ˌself-ˈe-və-dənt , -ˌdent
 evident without proof or reasoning

You have been a part of the conversations that devolved into the
non-technical, and even started your own decidedly non-technical
discussion on this list[1] where you’ve seen that rules for moderation,
or at least defining the expectations of moderators and participants,
would have been beneficial.

[1]: 


signature.asc
Description: Digital signature

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

[Michał Górny]

W dniu sob, 16.12.2017 o godzinie 16∶48 +1300, użytkownik Kent Fredric
napisał:
> On Fri, 15 Dec 2017 21:09:15 +0100
> Michał Górny  wrote:
> 
> > Sounds like you've put some awful self-symlink into this directory.
> > The script incorrectly follows top-level symlinks when removing, I'll
> > fix that.
> 
> If it helps, this is on a no-multilib install, and the tree if I roll back to 
> its state in may ( the last snapshot ) shows:
> 
> /usr # ls -la
> total 24
> drwxr-xr-x 1 root root   142 Dec  3  2016 .
> drwxr-xr-x 1 root root   126 Dec 15 21:10 ..
> drwxr-xr-x 1 root root 14018 Dec 16 01:07 bin
> drwxr-xr-x 1 root root  4596 Dec 16 01:02 include
> lrwxrwxrwx 1 root root 5 Nov 24  2016 lib -> lib64
> drwxr-xr-x 1 root root  9980 Dec 16 01:02 lib64
> 
>  / # ls -la
> total 36
> drwxr-xr-x   1 root root   126 Dec 15 21:10 .
> drwxr-xr-x   1 root root   126 Dec 15 21:10 ..
> drwxr-xr-x   1 root root  1010 Dec 16 01:02 bin
> drwxr-xr-x   1 root root10 Nov 24  2016 boot
> drwxr-xr-x  17 root root  3820 Dec 15 10:55 dev
> drwxr-xr-x   1 root root  1646 Dec 16 01:07 etc
> drwxr-xr-x   1 root root22 Jan 23  2017 home
> lrwxrwxrwx   1 root root 5 Dec 15 21:10 lib -> lib64
> drwxr-xr-x   1 root root  3534 Dec 16 00:56 lib64
> drwxr-xr-x   1 root root10 Nov 24  2016 media
> drwxr-xr-x   1 root root10 Nov 24  2016 mnt
> drwxr-xr-x   1 root root10 Jan 24  2017 opt
> dr-xr-xr-x 219 root root 0 Dec 15 10:54 proc
> drwxr-x---   1 root wheel  488 Dec 15 11:04 root
> drwxr-xr-x   1 root root22 Dec 15 21:36 run
> drwxr-xr-x   1 root root  1958 Dec 16 01:02 sbin
> dr-xr-xr-x  13 root root 0 Dec 15 10:55 sys
> drwxrwxrwt   1 root root   408 Dec 16 03:38 tmp
> drwxr-xr-x   1 root root   142 Dec  3  2016 usr
> drwxr-xr-x   1 root root92 Jan 24  2017 var
> 
> But as for "self-symlinks" I can't seem to find anything.

I suspect you have a stray '/lib64/lib64 -> /' or something like that.
In any case, this should be fixed by:

https://github.com/mgorny/unsymlink-lib/commit/b12feb90bdb72195f0ca5eede306783213bdacc9

I'd appreciate if you could retest with that commit on top (or taking
unsymlink-lib off git). This time it should not wipe your entire system,
hopefully.

> I should also point out that I had a bunch of bind-mounted directories in 
> /usr/src/* from the host OS  , and these were also recursively nuked. :/
> 
> But I couldn't see anything obvious in the source that explained that ( and 
> analysis didn't really have any indication of things that could get broken )

...except for suspicious 'lib64' file? ;-)

-- 
Best regards,
Michał Górny