Re: [gentoo-dev] Re: The changes about the stabilization process

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

[gentoo-dev] Re: The changes about the stabilization process

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

Re: [gentoo-dev] Packages up for grabs due to retirement

Ü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,

Re: [gentoo-dev] RFC: Global USE cuda

Ü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

[gentoo-portage-dev] [PATCH] _dep_check_composite_db: select highest in slot conflict (bug 554070)

Fix the _dep_check_composite_db._visible method to select the highest version involved in a slot conflict, for consistency with the change in ab07ac68fa1e04ed64e2e0f6c753ff169a32d517. The included unit test fails without this fix. Fixes: ab07ac68fa1e ("depgraph: select highest version involved in

Re: [gentoo-dev] Re: The changes about the stabilization process

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

Re: [gentoo-dev] Re: The changes about the stabilization process

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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:

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: [gentoo-dev] RFC: global USE c++11

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

Re: [gentoo-dev] Packages up for grabs due to retirement

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

Re: [gentoo-dev] Packages up for grabs due to retirement

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

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

Re: [gentoo-dev] Package up for grabs: media-gfx/displaycal

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

Re: [gentoo-dev] Packages up for grabs due to retirement

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

Re: [gentoo-dev] Packages up for grabs due to retirement

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

Re: [gentoo-dev] [rfc] New global USE flag: rbd

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.

Re: [gentoo-dev] RFC: global USE c++11

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

Re: [gentoo-dev] Packages up for grabs due to retirement

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

Re: [gentoo-dev] [rfc] New global USE flag: rbd

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

Re: [gentoo-dev] RFC: global USE c++11

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

Re: [gentoo-dev] [rfc] New global USE flag: rbd

Shouldn't this >> app-backup/bareos:rados - Enable rados storage backend > storage backend go to the first list?

Re: [gentoo-dev] [rfc] New global USE flag: rbd

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

Re: [gentoo-dev] RFC: Global USE cuda

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:

Re: [gentoo-dev] RFC: global USE c++11

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