On Fri, 3 Feb 2017 14:29:04 -0500
Michael Orlitzky wrote:
> > However, it is no rocket science to write a race-free chown command
> > in C: Just open the file and use stat() and fchown() to be sure to
> > change only files from the "correct" user.
> >
> > Since this works on the filehandle and n
I am not interested on this package anymore... then, feel free to take it
Thanks!
On Sat, Feb 4, 2017 at 1:40 AM, Christopher Head wrote:
>
> Why? It’s just another dependency. Why does DEPEND="dev-libs/bar" work
> so beautifully but DEPEND="dev-libs/bar[baz]" work so horribly? If I
> haven’t explicitly said I want baz, and I haven’t explicitly said I
> *don’t* want baz, and en
Introduce an eclass to support dependencies building against slotted
LLVM. It provides a function to find the newest installed LLVM version
that is not newer than the max supported slot, and a trivial pkg_setup()
implementation that adds executable directory of this install to PATH.
This ensures t
On 02/03/2017 08:07 PM, Patrick McLean wrote:
>
> I think the current policy of "maintainer's discretion" is probably the
> only reasonable way to approach IUSE defaults...
>
> Leaving the IUSE defaults up to the maintainer allows said maintainer
> to select what they consider reasonable defaults
On 02/04/2017 03:50 AM, Christopher Head wrote:
>>
>> Not a bad idea... we chould ship that safe-chown utility, and then
>> tell users how to use it to fix their UIDs. The draft that I wrote up
>> was for the "fixed UID with random fallback" model, but said utility
>> could still be useful for peop
I am not interested on then anymore... then, feel free to take them if you want
Thanks
I am not using it for ages.. feel free to take it if you want
I am not using it for ages, feel free to take it if you want, thanks!
Does anyone have existing collections of git hooks they use locally on portage
to prevent themselves making dumb mistakes?
For example, one I just discovered I made back in December was I accidentally
keyworded a package for arches I don't have while doing an edit, and I'd imagine
the cause was bl
On Saturday, February 4, 2017 9:57:01 AM EST Michael Orlitzky wrote:
> On 02/03/2017 08:07 PM, Patrick McLean wrote:
> > I think the current policy of "maintainer's discretion" is probably the
> > only reasonable way to approach IUSE defaults...
> >
> > Leaving the IUSE defaults up to the maintain
Christopher Head wrote:
>
> Are you sure that said utility isn't simply chown --from=?
As usual, I just checked the POSIX standard and not the
GNU extensions before posting ;)
I did now a quick audit of the coreutils-8.25 source:
It seems to be safely implemented in the way I mentioned.
On Sat, 04 Feb 2017 12:44:38 -0500
"William L. Thomson Jr." wrote:
> The question to ask is who do you want to create more work for?
> People maintaining packages, or people maintaining profiles.
I would probably say "yes" to both of those, because the main objective here
is to create less work
On Sunday, February 5, 2017 7:14:45 AM EST Kent Fredric wrote:
> On Sat, 04 Feb 2017 12:44:38 -0500
>
> "William L. Thomson Jr." wrote:
> > The question to ask is who do you want to create more work for?
> > People maintaining packages, or people maintaining profiles.
>
> I would probably say "y
Our bug queue has 85 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!
On Sat, 04 Feb 2017 16:05:50 -0500
"William L. Thomson Jr." wrote:
> Putting increased requirements on the maintainers may be demotivating, and
> create other problems. New profile added they are not aware of. Now they have
> to go add IUSE defaults etc. There are a fair amount of profiles.
>
On Sat, 4 Feb 2017 14:00:04 -0800 (PST)
Alex Alexander wrote:
> To view the bug queue, click here: http://bit.ly/m8PQS5
>
> Thanks!
Errant thought: It may be useful for the tool that you use to generate this
mail to
embed a list of bug summaries, in the hope it will generate more interest and
17 matches
Mail list logo
