Greetings,
On Sat, 19 Sep 2015 23:04:14 +0200 hasufell wrote:
> Friends,
>
> I think it is time to import LibreSSL[0]. There are not many packages
> left that don't compile OOTB and those can be patched (e.g. dev-lang/ruby).
>
> My idea would be:
>
> 1. import "dev-libs/libressl" (this will blo
Can a single project have multiple super-projects? If so, herds might
become redundant.
On Sat, Sep 19, 2015 at 5:07 PM, Rich Freeman wrote:
> On Sat, Sep 19, 2015 at 7:32 PM, Raymond Jennings
> wrote:
> > Is it possible for projects to be nested, possibly within multiple
> > super-projects?
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/19/2015 05:12 PM, Michael Orlitzky wrote:
> On 09/19/2015 05:16 PM, Daniel Campbell wrote:
>>
>> We'd just need a developer who's experienced in maintaining and
>> setting them up.
>>
>
> Has anyone ever set up Gitlab or Gerrit, managed by
On 09/19/2015 05:16 PM, Daniel Campbell wrote:
>
> We'd just need a developer who's experienced in maintaining and
> setting them up.
>
Has anyone ever set up Gitlab or Gerrit, managed by a package manager,
in a way that a small bug won't grant anonymous write access to every
single repository?
On Sat, Sep 19, 2015 at 7:32 PM, Raymond Jennings wrote:
> Is it possible for projects to be nested, possibly within multiple
> super-projects?
>
> Like, for example, a project dealing with a gnome chat client itself being
> members of both the gnome and the chat projects (hypothetically speaking)
Is it possible for projects to be nested, possibly within multiple
super-projects?
Like, for example, a project dealing with a gnome chat client itself being
members of both the gnome and the chat projects (hypothetically speaking)?
Maybe allow projects themselves to be members of other projects
On Sat, Sep 19, 2015 at 5:07 PM, Daniel Campbell wrote:
> +1 in general, but I'm a little pensive about allowing non-devs to
> become official project members. Becoming a developer can be a
> grueling process, so I understand that some don't have the time or
> motivation, and still want to help ou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/17/2015 12:40 PM, Michał Górny wrote:
> Dnia 2015-09-16, o godz. 23:25:33 Michał Górny
> napisał(a):
>
>> So, what are your thoughts for unmessing this?
>
> For completeness, a semi-conservative idea that could be
> implemented relatively ea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/16/2015 03:07 PM, Maciej Mrozowski wrote:
> On Saturday 12 of September 2015 21:12:25 Michał Górny wrote:
>
> | What are your thoughts? Any other proposals?
>
> Well, there's always an option to set up infra hosted Gerrit or
> Gitlab and forg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/18/2015 12:37 AM, Ulrich Mueller wrote:
>> On Thu, 17 Sep 2015, Michał Górny wrote:
>
>>> Let's please first decide on the greater scheme of projects,
>>> teams, and herds. Starting to change files before we have any
>>> plan doesn't make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/18/2015 03:16 PM, Andreas K. Huettel wrote:
> Am Freitag, 18. September 2015, 06:49:07 schrieb Robin H. Johnson:
>> On Wed, Sep 16, 2015 at 11:43:02PM +0200, Andreas K. Huettel
>> wrote:
>
>>> a) Disallow the term "herd". Noone uses it correc
Friends,
I think it is time to import LibreSSL[0]. There are not many packages
left that don't compile OOTB and those can be patched (e.g. dev-lang/ruby).
My idea would be:
1. import "dev-libs/libressl" (this will block dev-libs/openssl) and
introduce the global USE flag "libressl" with the foll
Saturday 19 Sep 2015 09:55:14, Anthony G. Basile wrote :
> On 9/19/15 8:56 AM, Ian Stakenvicius wrote:
> > Sent from an iPhone, sorry for the HTML...
> >
> > On Sep 19, 2015, at 8:31 AM, Vadim A. Misbakh-Soloviov
> > wrote:
> >
> >>> So, if an arch developer tests the package(s) on one architectu
Here's my old proposal: https://bugs.gentoo.org/show_bug.cgi?id=526456
Dnia 19 września 2015 14:59:35 CEST, konsolebox
napisał(a):
>On Sat, Sep 19, 2015 at 6:55 PM, Michał Górny
>wrote:
>> Dnia 19 września 2015 12:27:32 CEST, konsolebox
> napisał(a):
>>>On Sat, Sep 19, 2015 at 4:01 PM, Michał G
On 9/19/15 8:56 AM, Ian Stakenvicius wrote:
Sent from an iPhone, sorry for the HTML...
On Sep 19, 2015, at 8:31 AM, Vadim A. Misbakh-Soloviov wrote:
So, if an arch developer tests the package(s) on one architecture, he is
allowed to stabilize/keyword for all.
And how about the
some arches r
Sent from an iPhone, sorry for the HTML...
> On Sep 19, 2015, at 7:30 AM, Alexis Ballier wrote:
>
> On Sat, 19 Sep 2015 12:25:40 +0100
> Ciaran McCreesh wrote:
>
>> On Sat, 19 Sep 2015 12:08:21 +0200
>> Pacho Ramos wrote:
>>> On the other hand, if we start always setting the available slots
Sent from an iPhone, sorry for the HTML...
On Sep 19, 2015, at 8:31 AM, Vadim A. Misbakh-Soloviov wrote:
>> So, if an arch developer tests the package(s) on one architecture, he is
>> allowed to stabilize/keyword for all.
>
> And how about the
>> some arches rquires additional tests during sta
> So, if an arch developer tests the package(s) on one architecture, he is
> allowed to stabilize/keyword for all.
And how about the
> some arches rquires additional tests during stabilization, like so: mips*,
arm*, and some more exotic ones
definition in developer manuals? :)
--
Best regards,
Hello,
The ALLARCHES keyword is out since some time. For who does not remeber, the
announcement is here [1]
So, if an arch developer tests the package(s) on one architecture, he is
allowed to stabilize/keyword for all.
Unfortunately some people forget to look at the KEYWORDS field and stabiliz
Dnia 19 września 2015 00:30:02 CEST, "Andreas K. Huettel"
napisał(a):
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Am Freitag, 18. September 2015, 07:10:56 schrieb Michał Górny:
>>
>> 1. You can't list developers who are not subscribed on the wiki.
>
>- -EDEVELOPER, or PEBKAC
>
>I suspe
On 19/09/15 12:36, hasufell wrote:
> Hmm, you are suggesting to do this even for packages that only
> have one SLOT anyway? I'm really not sure about this. Depending on
> the SLOT-naming-scheme that will be introduced it may require
> massive changes as well. It's hard to look into the future. I
>
On Sat, 19 Sep 2015 12:25:40 +0100
Ciaran McCreesh wrote:
> On Sat, 19 Sep 2015 12:08:21 +0200
> Pacho Ramos wrote:
> > On the other hand, if we start always setting the available slots
> > that we know to work, we can avoid this issue, and this is also
> > completely future proof becase I don't
On Sat, 19 Sep 2015 12:08:21 +0200
Pacho Ramos wrote:
> On the other hand, if we start always setting the available slots that
> we know to work, we can avoid this issue, and this is also completely
> future proof becase I don't think we can assume that package B will
> always work with the latest
On 09/19/2015 12:51 PM, Pacho Ramos wrote:
> El sáb, 19-09-2015 a las 12:40 +0200, hasufell escribió:
>> On 09/19/2015 12:36 PM, hasufell wrote:
>>>
>>>
>>> I personally think
>>> it is enough to do that for multislot packages.
>>>
>>
>> And afais repoman already emits a warning for those on EAPI=5
El sáb, 19-09-2015 a las 12:51 +0200, Pacho Ramos escribió:
> El sáb, 19-09-2015 a las 12:40 +0200, hasufell escribió:
> > On 09/19/2015 12:36 PM, hasufell wrote:
> > >
> > >
> > > I personally think
> > > it is enough to do that for multislot packages.
> > >
> >
> > And afais repoman already e
El sáb, 19-09-2015 a las 12:40 +0200, hasufell escribió:
> On 09/19/2015 12:36 PM, hasufell wrote:
> >
> >
> > I personally think
> > it is enough to do that for multislot packages.
> >
>
> And afais repoman already emits a warning for those on EAPI=5.
>
Yes, I know... this is about always set
On 09/19/2015 12:36 PM, hasufell wrote:
>
>
> I personally think
> it is enough to do that for multislot packages.
>
And afais repoman already emits a warning for those on EAPI=5.
On 09/19/2015 12:08 PM, Pacho Ramos wrote:
Thanks for the thread, but I have a small remark...
>
> With we trying to move to finally disable dymamic-deps and stop relying
> on them completely, an old problem will be a bit more noticeable now:
>
> - Tons of package RDEPEND on A
> - Long time a
Pacho Ramos posted on Sat, 19 Sep 2015 12:08:21 +0200 as excerpted:
> Currently, [when a slot changes] we can see how most of us try to go as
> quick as possible to fix the dependencies retroactively setting the
> proper slot but this relies on dynamic-deps, if this feature gets
> disabled, we wil
Dnia 19 września 2015 12:08:21 CEST, Pacho Ramos napisał(a):
>Hello
>
>With we trying to move to finally disable dymamic-deps and stop relying
>on them completely, an old problem will be a bit more noticeable now:
>
>- Tons of package RDEPEND on A
>- Long time after that, A starts to have a new
Hello
With we trying to move to finally disable dymamic-deps and stop relying
on them completely, an old problem will be a bit more noticeable now:
- Tons of package RDEPEND on A
- Long time after that, A starts to have a new SLOT
- As most reverse deps need to be ported, we need to fix it
retroa
On Sat, Sep 19, 2015 at 3:43 PM, konsolebox wrote:
> On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny wrote:
>> And to save you some time reading: the rpm implementation is simpler
>> and more flexible. It's free of stupidities like hardcoded suffix
>> lists or forced component ordering. Ordering (p
Dnia 19 września 2015 09:43:14 CEST, konsolebox
napisał(a):
>On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny
>wrote:
>> Dnia 2015-09-19, o godz. 03:50:52
>> konsolebox napisał(a):
>>
>>> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny
>wrote:
>>> > And similarly to the current solution it's full
On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny wrote:
> Dnia 2015-09-19, o godz. 03:50:52
> konsolebox napisał(a):
>
>> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny wrote:
>> > And similarly to the current solution it's full of silly special cases and
>> > magical rules. If you really want some
34 matches
Mail list logo
