On 05/20/2016 09:47 PM, Matt Turner wrote:
> On Thu, May 19, 2016 at 6:36 PM, Daniel Campbell wrote:
>> To make sure I understand what you're getting at, are you saying some
>> devs get on board and then request to add keywords to packages that they
>> already maintain?
>
> No, you've misundersto
On Thu, May 19, 2016 at 6:36 PM, Daniel Campbell wrote:
> To make sure I understand what you're getting at, are you saying some
> devs get on board and then request to add keywords to packages that they
> already maintain?
No, you've misunderstood.
He's saying people add new packages and then sp
On Sat, May 21, 2016 at 10:09:04AM +0800, Ian Delaney wrote:
> On Fri, 20 May 2016 16:00:02 +0200
> Jeroen Roovers wrote:
>
> > On Thu, 19 May 2016 18:36:22 -0700
> > Daniel Campbell wrote:
> >
> > > To make sure I understand what you're getting at, are you saying
> > > some devs get on board a
On Fri, 20 May 2016 16:00:02 +0200
Jeroen Roovers wrote:
> On Thu, 19 May 2016 18:36:22 -0700
> Daniel Campbell wrote:
>
> > To make sure I understand what you're getting at, are you saying
> > some devs get on board and then request to add keywords to packages
> > that they already maintain? I
Peter Stuge writes:
>> +pushd "${EPREFIX}$(get_erl_libs)" >/dev/null
>> +for p in ${pn} ${pn}-*; do
>> +if [[ -d ${p} ]]; then
>> +echo "${p#${pn}-}"
>> +return 0
>
> No popd on success?
Thanks for catching this up! Fixed.
>> +loca
Michał Górny writes:
>> +export ERL_LIBS="${EPREFIX}$(get_erl_libs)"
>
> I think calling get_libdir in global scope is forbidden. You should
> really export this somewhere in phase function.
Fixed.
>> +# @FUNCTION: _find_dep_version
>
> Namespace it, please. Just in case.
Fixed.
>> +_find_dep
On Fri, 20 May 2016 16:00:38 -0400
Ian Stakenvicius wrote:
> On 20/05/16 11:49 AM, Michał Górny wrote:
> > On Fri, 20 May 2016 11:40:39 -0400
> > Michael Orlitzky wrote:
> >
> >> On 05/20/2016 11:34 AM, Daniel Campbell wrote:
> >>>
> >>> ...and the user has this in their install.mask file:
> a) mawk doesn't support it.
> b) 4.1 is not stabilized, yet.
a) if you depend on mawk then you can really create your own wrapper
in your ebuild or do it inline
b) then perhaps put your efforts that way
Mike Frysinger writes:
> On 18 May 2016 22:25, aide...@gentoo.org wrote:
>> awk doesn't have the -i option like sed and if editing file in place is
>> desired, additional steps are required. eawk uses tmp file to make it
>> look to the caller editing happens in place.
>
> what's your real use case
rindeal writes:
> Have you guys read
> https://stackoverflow.com/questions/16529716/awk-save-modifications-inplace
> ?
a) mawk doesn't support it.
b) 4.1 is not stabilized, yet.
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
On 20/05/16 11:49 AM, Michał Górny wrote:
> On Fri, 20 May 2016 11:40:39 -0400
> Michael Orlitzky wrote:
>
>> On 05/20/2016 11:34 AM, Daniel Campbell wrote:
>>>
>>> ...and the user has this in their install.mask file:
>>>
>>> [bash-completion]
>>> path=/some/other/path
>>> desc=some other descrip
On Fri, 20 May 2016 19:47:55 + (UTC)
"Johannes Huber" wrote:
> commit: 548f4ee19c6b0fe0d5e87e84a5a82c421229e0ce
> Author: Michael Palimaka gentoo org>
> AuthorDate: Fri May 20 19:46:11 2016 +
> Commit: Johannes Huber gentoo org>
> CommitDate: Fri May 20 19:47:15 2016 +
Reasons for inplace editing are the same for any language and tool,
but having a wrapper just because some tool doesn't support it, is a
bloat. Especially when gawk>=4.1 supports it.
Thursday 19 May 2016 23:08:05, Mike Frysinger wrote :
> On 18 May 2016 22:25, aide...@gentoo.org wrote:
> > awk doesn't have the -i option like sed and if editing file in place is
> > desired, additional steps are required. eawk uses tmp file to make it
> > look to the caller editing happens in pla
Have you guys read
https://stackoverflow.com/questions/16529716/awk-save-modifications-inplace
?
"Robin H. Johnson" writes:
>> > cp -f "${tmpf}" "$f" || die "copy back failed"
>>
>> Why '-f' is required?
> Corner cases w/ copying and bad ebuild usage (specifically running
> ebuild as two different non-root users during development). Mostly
> habit.
Reading:
http://pubs.opengroup.org/onli
On 05/20/2016 12:48 PM, Michał Górny wrote:
>
> That's not a case since GLEP doesn't define how it is configured.
> And it's invalid to reference other groups in path=s of a defined
> group.
>
I'm just playing language lawyer. The spec does say,
A Package Manager implementing this specificati
Mart Raudsepp writes:
> Similarly, I would like that all ebuild that call 'sed' actually DEPEND
> on sed, not just half of them.
> I would also like that no ebuild would assume packages in @system to be
> present, beyond those dictated by PMS (unpackers and such).
Please don't divert from the sub
On Fri, 20 May 2016 12:15:36 -0400
Michael Orlitzky wrote:
> On 05/20/2016 11:44 AM, Michał Górny wrote:
> >
> > I'd make '@' signify group names, like we do for sets. This would have
> > the side limitation that it would make it impossible to filter
> > filenames starting with '@' with the curr
On 05/20/2016 11:44 AM, Michał Górny wrote:
>
> I'd make '@' signify group names, like we do for sets. This would have
> the side limitation that it would make it impossible to filter
> filenames starting with '@' with the currently supported
> path-or-filename syntax.
>
That may be the best we
On Fri, 20 May 2016 11:40:39 -0400
Michael Orlitzky wrote:
> On 05/20/2016 11:34 AM, Daniel Campbell wrote:
> >
> > ...and the user has this in their install.mask file:
> >
> > [bash-completion]
> > path=/some/other/path
> > desc=some other description
> >
>
> I don't think that's allowed; th
On Fri, 20 May 2016 11:30:59 -0400
Michael Orlitzky wrote:
> On 05/20/2016 11:21 AM, Michał Górny wrote:
> >
> > ...
> >
> > Getting into implementation details, I'd probably go for:
> >
> > INSTALL_MASK="@bash-completion"
> >
> > but the exact syntax is left for various package managers. P
On 05/20/2016 11:34 AM, Daniel Campbell wrote:
>
> ...and the user has this in their install.mask file:
>
> [bash-completion]
> path=/some/other/path
> desc=some other description
>
I don't think that's allowed; the groups are specified by each
repository's metadata/install-mask.conf, not by th
On 05/20/2016 07:01 AM, Michał Górny wrote:
> Hello,
>
> Sometime around a year ago, I started working on extending INSTALL_MASK
> to support well-defined locations. The work was never finished, and I
> just found my old specification for it. I've cleaned it up a bit,
> and extended it into a comp
On 05/20/2016 11:21 AM, Michał Górny wrote:
>
> ...
>
> Getting into implementation details, I'd probably go for:
>
> INSTALL_MASK="@bash-completion"
>
> but the exact syntax is left for various package managers. Paludis
> and pkgcore would probably prefer a proper configuration file.
>
Ok,
On Fri, 20 May 2016 11:12:02 -0400
Michael Orlitzky wrote:
> On 05/20/2016 10:01 AM, Michał Górny wrote:
> >
> > Please review the specification provided. The basic goal is to provide
> > an ability to use INSTALL_MASK alike USE flags -- with path groups that
> > are well-defined and described i
On 05/20/2016 10:01 AM, Michał Górny wrote:
>
> Please review the specification provided. The basic goal is to provide
> an ability to use INSTALL_MASK alike USE flags -- with path groups that
> are well-defined and described in the repository.
>
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLE
Hello,
Sometime around a year ago, I started working on extending INSTALL_MASK
to support well-defined locations. The work was never finished, and I
just found my old specification for it. I've cleaned it up a bit,
and extended it into a complete GLEP covering INSTALL_MASK [1].
Please review the
On Thu, 19 May 2016 18:36:22 -0700
Daniel Campbell wrote:
> To make sure I understand what you're getting at, are you saying some
> devs get on board and then request to add keywords to packages that
> they already maintain? If said arches are already supported in Gentoo
> I see little problem wi
On 20/05/16 14:11, Kristian Fiskerstrand wrote:
>
>> keywording for a new arch should normally only be done when necessary,
>> mainly if it is a direct dependency of another package. There is no need
>> to keywor it for an arch until it has been tested on that arch by some
>> user / developer ... c
On 05/20/2016 05:38 AM, Kristian Fiskerstrand wrote:
> On 05/20/2016 03:36 AM, Daniel Campbell wrote:
>> On 05/19/2016 07:51 AM, Jeroen Roovers wrote:
>
> ..
>
>>>
>> To make sure I understand what you're getting at, are you saying some
>> devs get on board and then request to add keywords to pac
On 05/20/2016 02:38 PM, Kristian Fiskerstrand wrote:
> On 05/20/2016 03:36 AM, Daniel Campbell wrote:
>> On 05/19/2016 07:51 AM, Jeroen Roovers wrote:
>
>
> keywording for a new arch should normally only be done when necessary,
> mainly if it is a direct dependency of another package. There is
On 05/20/2016 03:36 AM, Daniel Campbell wrote:
> On 05/19/2016 07:51 AM, Jeroen Roovers wrote:
..
>>
> To make sure I understand what you're getting at, are you saying some
> devs get on board and then request to add keywords to packages that they
> already maintain? If said arches are already su
> On Thu, 19 May 2016, Amadeusz Żołnowski wrote:
> Ulrich Mueller writes:
>> Yes, of course. "|| die -n || return" if you want the function to
>> return at that point, if it was called under nonfatal.
>>
>>> https://blogs.gentoo.org/mgorny/2015/11/13/the-ultimate-guide-to-eapi-6
>>
>> Note th
34 matches
Mail list logo
