On 04/01/17 07:09, Michael Palimaka wrote:
> On 04/01/17 12:57, Andrew Savchenko wrote:
>> Hi all,
>>
>> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
>> [...]
>>> Another question: do we steel need to set STABLEREQ keyword for
>>> stabilization bugs? Since we now have a dedicated Stab
On 04/01/17 12:57, Andrew Savchenko wrote:
> Hi all,
>
> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
> [...]
>> Another question: do we steel need to set STABLEREQ keyword for
>> stabilization bugs? Since we now have a dedicated Stabilization
>> component, STABLEREQ looks redundant.
Ühel kenal päeval, T, 03.01.2017 kell 09:34, kirjutas Damien LEVAC:
>
> On 01/03/2017 09:31 AM, M. J. Everitt wrote:
> >
> > On 03/01/17 11:05, Michał Górny wrote:
> > >
> > > On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> > > gro...@gentoo.org wrote:
> > >
> > > >
> > > > On Mon, 2 Jan 2017, Brian
Ühel kenal päeval, T, 03.01.2017 kell 11:02, kirjutas Andrew Savchenko:
> Hi,
>
> On Mon, 2 Jan 2017 21:37:43 + Justin wrote:
> >
> > Hi all
> >
> > How about making USE=cuda a global USE?
> >
> > Description: Enable support for nVidia CUDA
>
> Sounds reasonable.
If this gets implemented
Hi all,
On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
[...]
> Another question: do we steel need to set STABLEREQ keyword for
> stabilization bugs? Since we now have a dedicated Stabilization
> component, STABLEREQ looks redundant.
Ping here.
Best regards,
Andrew Savchenko
pgpU78p
On Tue, Jan 3, 2017 at 6:28 PM, Kent Fredric wrote:
>
> In that, by making the submitter resolve it all, its either "good" or "bad"
>
> Instead of leaving the person doing the testing in a confused state about
> which packages
> are expected to be used.
>
Well, assuming that a human is actually
On Mon, 2 Jan 2017 12:49:59 -0500
Rich Freeman wrote:
> However, in this case why would we want to rule out sets, "and all the
> other shenanigans?" We've already established that a single stable
> request bug can apply to multiple package-versions, so why not allow
> full dependency specificati
On 01/03/2017 09:10 AM, Kristian Fiskerstrand wrote:
> On 01/03/2017 03:57 PM, Michael Mol wrote:
>> For security's sake, even mature software needs, at minimum, routine
>> auditing.
>> Unless someone's doing that work, the package should be considered for
>> removal. (Call that reason # π, in h
On 01/03/2017 09:11 AM, Damien LEVAC wrote:
> But routine auditing, while being wishful thinking in the open-source
> world (even when the projects are alive), are not meant to find those
> kind of bugs anyway (and wouldn't be effective at doing so either).
>
I think it's wishful thinking in ever
On 01/03/2017 10:41 AM, Alice Ferrazzi wrote:
On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman wrote:
On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote:
For security's sake, even mature software needs, at minimum, routine auditing.
Unless someone's doing that work, the package should be conside
On Tue, Jan 3, 2017 at 11:09 AM, Michael Mol wrote:
>
> Ideas like this is one reason I'm looking for a corpus of pros and cons for
> treecleaning. I don't see it as black and white. But having ideas like these
> brought up is at least useful.
>
Sure, and almost any rule has its exceptions. My t
On Tuesday, January 3, 2017 10:23:02 AM EST Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote:
> > For security's sake, even mature software needs, at minimum, routine
> > auditing. Unless someone's doing that work, the package should be
> > considered for removal. (Call that
On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote:
>>
>> For security's sake, even mature software needs, at minimum, routine
>> auditing.
>> Unless someone's doing that work, the package should be considered for
>> removal. (Call that reaso
On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote:
>
> For security's sake, even mature software needs, at minimum, routine auditing.
> Unless someone's doing that work, the package should be considered for
> removal. (Call that reason #π, in honor of TeX.)
>
Are you suggesting that we should
On 03/01/17 14:57, Michael Mol wrote:
> On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
>> On 01/03/2017 09:14 AM, Michael Mol wrote:
>>> On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
>>
On 01/03/2017 09:57 AM, Michael Mol wrote:
On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
On 01/03/2017 09:14 AM, Michael Mol wrote:
On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
On Mon, 2 Ja
On 01/03/2017 03:57 PM, Michael Mol wrote:
> For security's sake, even mature software needs, at minimum, routine
> auditing.
> Unless someone's doing that work, the package should be considered for
> removal. (Call that reason # π, in honor of TeX.)
A distinction here likely needs to be made
On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
> On 01/03/2017 09:14 AM, Michael Mol wrote:
> > On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> >> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> >>
> >> gro...@gentoo.org wrote:
> >>> On Mon, 2 Jan 2017, Brian Evans wrot
On 1/3/17 4:08 AM, Justin wrote:
> On 03/01/2017 08:51, Kristian Fiskerstrand wrote:
>> On 01/02/2017 10:34 PM, Justin wrote:
>>>
>>> Seems to be very consistent in usage.
>>
>> But I'm not convinced it is a correct approach to have use flag changing
>> this. First thing that springs to mind is i
On 01/03/2017 09:31 AM, M. J. Everitt wrote:
On 03/01/17 11:05, Michał Górny wrote:
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
On Mon, 2 Jan 2017, Brian Evans wrote:
IMO, this one should be given last-rites as upstream is dead and it
heavily depends on wireless-tools a
On 03/01/17 11:05, Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> gro...@gentoo.org wrote:
>
>> On Mon, 2 Jan 2017, Brian Evans wrote:
>>> IMO, this one should be given last-rites as upstream is dead and it
>>> heavily depends on wireless-tools and WEXT.
>> I use it on 2 notebook
On 01/03/2017 09:14 AM, Michael Mol wrote:
On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
On Mon, 2 Jan 2017, Brian Evans wrote:
IMO, this one should be given last-rites as upstream is dead and it
heavily depe
On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
>
> gro...@gentoo.org wrote:
> > On Mon, 2 Jan 2017, Brian Evans wrote:
> > > IMO, this one should be given last-rites as upstream is dead and it
> > > heavily depends on wireless-tools and WE
Le 22/12/2016 11:56, Gokturk Yuksek a écrit :
Hi,
This a slightly delayed up for grabs notice for: media-gfx/displaycal
ArgyllCMS is already in my list, so I can help with this one too.
But co-maintainers are still welcome of course!
--
Bernard Cafarelli (Voyageur)
Gentoo developer
Hi,
On Tue, 3 Jan 2017 16:00:52 +0700 (+07) gro...@gentoo.org wrote:
>On Mon, 2 Jan 2017, Brian Evans wrote:
>> IMO, this one should be given last-rites as upstream is dead and it
>> heavily depends on wireless-tools and WEXT.
this is plain wrong. Upstream is not dead, just not very active any
On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
gro...@gentoo.org wrote:
> On Mon, 2 Jan 2017, Brian Evans wrote:
> > IMO, this one should be given last-rites as upstream is dead and it
> > heavily depends on wireless-tools and WEXT.
> I use it on 2 notebooks. It works fine, and is (from my point of vie
On Tue, 03 Jan 2017 15:43:16 +0700 Vadim A. Misbakh-Soloviov wrote:
> Shouldn't this
> >> app-backup/bareos:rados - Enable rados storage backend
> > storage backend
> go to the first list?
No, judging from its source code in uses librados directly.
Though current description is indeed ambiguous.
On 03/01/2017 08:51, Kristian Fiskerstrand wrote:
> On 01/02/2017 10:34 PM, Justin wrote:
>>
>> Seems to be very consistent in usage.
>
> But I'm not convinced it is a correct approach to have use flag changing
> this. First thing that springs to mind is if introducing something like
> that it sh
On Mon, 2 Jan 2017, Brian Evans wrote:
IMO, this one should be given last-rites as upstream is dead and it
heavily depends on wireless-tools and WEXT.
I use it on 2 notebooks. It works fine, and is (from my point of view) the
most convenient tool to control ethernet and wifi connections on a
no
Hi,
On Mon, 26 Dec 2016 20:05:58 +0100 Kristian Fiskerstrand wrote:
> On 12/26/2016 08:45 AM, Andrew Savchenko wrote:
> > 8 packages are using either rbd or rados USE flag for Rados
> > Block Device support:
>
> Are there other possibly conflicting issues of using "rados" rather than
> "rbd" as n
On 01/02/2017 10:34 PM, Justin wrote:
>
> Seems to be very consistent in usage.
But I'm not convinced it is a correct approach to have use flag changing
this. First thing that springs to mind is if introducing something like
that it should be done consistently across Gentoo, so a GLEP. But
presu
Shouldn't this
>> app-backup/bareos:rados - Enable rados storage backend
> storage backend
go to the first list?
Hi,
On Mon, 26 Dec 2016 19:25:29 + Robin H. Johnson wrote:
> On Mon, Dec 26, 2016 at 10:45:26AM +0300, Andrew Savchenko wrote:
> > 8 packages are using either rbd or rados USE flag for Rados
> > Block Device support:
> RBD != RADOS.
Thanks for pointing this out.
> RBD is the block-device-ma
Hi,
On Mon, 2 Jan 2017 21:37:43 + Justin wrote:
> Hi all
>
> How about making USE=cuda a global USE?
>
> Description: Enable support for nVidia CUDA
Sounds reasonable.
> Current Situation:
> dev-lang/pgi: Install PGI's CUDA components (e.g. for OpenACC)
> dev-libs/libflatarray: E
On Tue, 03 Jan 2017 06:40:44 +0700 Vadim A. Misbakh-Soloviov wrote:
> I bet it is not about ABIs, but about a vallue for '-std' flag for gcc/clang
> compiler. Some packages allows to select between -std=c++1{1,4,7} (and some -
> defaults with older ones otherwise).
Yes, -std and some package-rel
35 matches
Mail list logo
