> On Jun 17, 2016, at 11:48 PM, Jonathan Callen wrote:
>
>> On 06/17/2016 06:22 PM, Ian Stakenvicius wrote:
>>> On 17/06/16 06:17 PM, Ian Stakenvicius wrote:
On 17/06/16 05:22 PM, Michał Górny wrote:
On Sat, 18 Jun 2016 00:06:10 +0300
Andrew Savchenko wrote:
>> On Fri,
On 06/17/2016 06:22 PM, Ian Stakenvicius wrote:
> On 17/06/16 06:17 PM, Ian Stakenvicius wrote:
>> On 17/06/16 05:22 PM, Michał Górny wrote:
>>> On Sat, 18 Jun 2016 00:06:10 +0300
>>> Andrew Savchenko wrote:
>>>
On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote:
> Hello,
>
> S
Ah, that would make sense. Sorry, I'm new to this, as you can probably tell.
deven
On Fri, Jun 17, 2016 at 6:25 PM, M. J. Everitt wrote:
> On 18/06/16 00:08, Deven Lahoti wrote:
> > I wrote a patch to make OpenAFS work with grsecurity kernels. I'm
> > working on getting it submitted upstream, b
On 18/06/16 00:08, Deven Lahoti wrote:
> I wrote a patch to make OpenAFS work with grsecurity kernels. I'm
> working on getting it submitted upstream, but for now it would be nice
> to have it in portage.
>
> http://web.mit.edu/deywos/www/openafs-grsec.patch
>
> deven
At the risk of stating the obv
I wrote a patch to make OpenAFS work with grsecurity kernels. I'm working
on getting it submitted upstream, but for now it would be nice to have it
in portage.
http://web.mit.edu/deywos/www/openafs-grsec.patch
deven
On 17/06/16 06:17 PM, Ian Stakenvicius wrote:
> On 17/06/16 05:22 PM, Michał Górny wrote:
>> On Sat, 18 Jun 2016 00:06:10 +0300
>> Andrew Savchenko wrote:
>>
>>> On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote:
Hello,
Since this is a major issue involving a lot of packages, an
On 17/06/16 05:22 PM, Michał Górny wrote:
> On Sat, 18 Jun 2016 00:06:10 +0300
> Andrew Savchenko wrote:
>
>> On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote:
>>> Hello,
>>>
>>> Since this is a major issue involving a lot of packages, and it needs
>>> to be fixed *quickly*, I'm forwarding t
On Sat, 18 Jun 2016 00:06:10 +0300
Andrew Savchenko wrote:
> On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote:
> > Hello,
> >
> > Since this is a major issue involving a lot of packages, and it needs
> > to be fixed *quickly*, I'm forwarding the new check results to
> > gentoo-dev.
> >
> >
On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote:
> Hello,
>
> Since this is a major issue involving a lot of packages, and it needs
> to be fixed *quickly*, I'm forwarding the new check results to
> gentoo-dev.
>
> If the below list contains your package, please fix it ASAP. I will
> file b
Hello,
Since this is a major issue involving a lot of packages, and it needs
to be fixed *quickly*, I'm forwarding the new check results to
gentoo-dev.
If the below list contains your package, please fix it ASAP. I will
file bugs for the remaining packages then.
Long story short, using := operat
On Fri, Jun 17, 2016 at 1:26 PM, Kristian Fiskerstrand wrote:
> On 06/17/2016 07:05 PM, Brian Dolbec wrote:
>>
>> Then everyone PLEASE stop referring to the Gentoo ebuild tree as
>> portage. Reserve portage for the upstream PACKAGE MANAGER.
>
> indeed
>
Agree, though this wasn't the sense I mean
On 06/17/2016 07:05 PM, Brian Dolbec wrote:
> On Fri, 17 Jun 2016 18:46:16 +0200
> Kristian Fiskerstrand wrote:
>
>> On 06/17/2016 06:41 PM, Rich Freeman wrote:
>>> On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
>>> wrote:
On 06/17/2016 03:58 PM, Rich Freeman wrote:
>
>
On Fri, 17 Jun 2016 18:46:16 +0200
Kristian Fiskerstrand wrote:
> On 06/17/2016 06:41 PM, Rich Freeman wrote:
> > On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
> > wrote:
> >> On 06/17/2016 03:58 PM, Rich Freeman wrote:
> >>>
> >>> That could actually be generalized. I could see m
On 06/17/2016 06:41 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
> wrote:
>> On 06/17/2016 03:58 PM, Rich Freeman wrote:
>>>
>>> That could actually be generalized. I could see many types of bugs
>>> where the issue is with upstream, and we might want to trac
On Fri, Jun 17, 2016 at 11:33 AM, Kristian Fiskerstrand wrote:
> On 06/17/2016 03:48 PM, Rich Freeman wrote:
>>
>> Also, in the case of STABLEREQs would we treat them more like security
>> bugs - the last arch would just post a comment that all archs are
>> stable and un-CC themselves, but leave t
On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand wrote:
> On 06/17/2016 03:58 PM, Rich Freeman wrote:
>>
>> That could actually be generalized. I could see many types of bugs
>> where the issue is with upstream, and we might want to track the
>> progress as upstream implements a fix, relea
On 06/17/2016 03:58 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny wrote:
>> On Thu, 16 Jun 2016 15:14:44 +0200
>> Kristian Fiskerstrand wrote:
>>
>>> On 06/16/2016 03:02 PM, Michał Górny wrote:
Hello, everyone.
>>>
>>>
>>>
What I'd like to introduce i
On 06/17/2016 03:48 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 9:02 AM, Kristian Fiskerstrand
> wrote:
>> On 06/17/2016 02:18 PM, Rich Freeman wrote:
>>
>>> If I'm a maintainer and I resolve a bug, how do I know if I should
>>> mark it resolved or not before it is stable?
>>
>> If package
On Fri, 17 Jun 2016 09:58:52 -0400
Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny wrote:
> > On Thu, 16 Jun 2016 15:14:44 +0200
> > Kristian Fiskerstrand wrote:
> >
> >> On 06/16/2016 03:02 PM, Michał Górny wrote:
> >> > Hello, everyone.
> >> >
> >>
> >>
> >>
> >> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 17/06/16 15:58, Rich Freeman wrote:
> That could actually be generalized. I could see many types of
> bugs where the issue is with upstream, and we might want to track
> the progress as upstream implements a fix, releases it, and then it
> is sta
On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny wrote:
> On Thu, 16 Jun 2016 15:14:44 +0200
> Kristian Fiskerstrand wrote:
>
>> On 06/16/2016 03:02 PM, Michał Górny wrote:
>> > Hello, everyone.
>> >
>>
>>
>>
>> >
>> > What I'd like to introduce instead is a new STABILIZED state. It would
>> > -- li
On Thu, 16 Jun 2016 15:14:44 +0200
Kristian Fiskerstrand wrote:
> On 06/16/2016 03:02 PM, Michał Górny wrote:
> > Hello, everyone.
> >
>
>
>
> >
> > What I'd like to introduce instead is a new STABILIZED state. It would
> > -- like VERIFIED now -- be only available for bugs already RESOLVE
On Fri, Jun 17, 2016 at 9:02 AM, Kristian Fiskerstrand wrote:
> On 06/17/2016 02:18 PM, Rich Freeman wrote:
>
>> If I'm a maintainer and I resolve a bug, how do I know if I should
>> mark it resolved or not before it is stable?
>
> If package is in stable to begin with, I would certainly prefer it
On 06/17/2016 03:02 PM, Kristian Fiskerstrand wrote:
>> Can you clarify what you mean by that?
>>
>> If I have a tracker with 47 resolved blockers, how do I know which of
>> those made it to stable?
>>
>
> The once that are RESOLVED FIXED, before they are in stable they should
> be open with InVC
On 06/17/2016 02:18 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand
> wrote:
>> On 06/17/2016 01:50 PM, Rich Freeman wrote:
>>> It might be better to just close the original bug, and then open a new
>>> STABLEREQ bug on the tracker whenever we're interested in tra
On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand wrote:
> On 06/17/2016 01:50 PM, Rich Freeman wrote:
>> It might be better to just close the original bug, and then open a new
>> STABLEREQ bug on the tracker whenever we're interested in tracking
>> stabilization. That also serves as a remin
On 06/17/2016 01:50 PM, Rich Freeman wrote:
> It might be better to just close the original bug, and then open a new
> STABLEREQ bug on the tracker whenever we're interested in tracking
> stabilization. That also serves as a reminder to the maintainer that
> somebody actually wants it stabilized.
On Fri, Jun 17, 2016 at 3:37 AM, Alexander Berntsen wrote:
>
> I would not want to tie our choosing RESOLVED to be tied to whether
> there is a stabilised package in the tree or not, because there are
> other Portage users than Gentoo. But I would not oppose such an
> enforcement too strongly at t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I *seriously* object to a RFC that affects so many people lasting
*less than 24h*.
- --
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCgAGBQJXY77iAAoJENQqWdRUGk8BCKIP/3ZG
On Thu, 16 Jun 2016 14:04:19 +0200
Michał Górny wrote:
> On Wed, 15 Jun 2016 21:11:30 +0200
> Michał Górny wrote:
>
> > Right now we have the following components:
> >
> > - Applications,
> > - baselayout,
> > - Core system,
> > - Development,
> > - Eclasses and Profiles,
> > - Games,
> > - GC
On Thu, 16 Jun 2016 15:02:13 +0200
Michał Górny wrote:
> Hello, everyone.
>
> Here's the third bugs.g.o redesign RFC.
>
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
>
> RESOLVED is the usual state that the developers use when they close
>
On Thu, 16 Jun 2016 10:23:39 -0400
Mike Gilbert wrote:
> On Thu, Jun 16, 2016 at 9:52 AM, Joshua Kinard wrote:
> > It'd be nice if, when replying in a comment, a flag
> > could be made available to automatically to state that "I've encountered
> > this
> > issue, too", and once 2, 3, or 4 of th
On 17 June 2016 at 06:05, Marc Schiffbauer wrote:
> How about "ON HOLD: Need Info" instead?
"STALLED" is better for me than "ON HOLD".
But I can't really see much value in such a breakdown unless we can
find at *least* 2 sub-categories of "STALLED"
--
Kent
KENTNL - https://metacpan.org/auth
[No OpenPGP signature atm, smartcard not cooperating, this is really bad
form :|]
On 06/17/2016 09:50 AM, Michał Górny wrote:
>
> Bugzilla supports adding any number of extra fields. However, isn't
> the URL field sufficient for this? I'd rather not increase the size of
> the form if there's not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 17/06/16 09:50, Michał Górny wrote:
> However, isn't the URL field sufficient for this?
This is useful in many cases for describing the bug and similar things
when the bug is being reported. Is it possible to have multiple URLs
sensibly in this fi
On Fri, 17 Jun 2016 09:37:22 +0200
Alexander Berntsen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> What we have been doing in Portage so far is that when we fix it in
> git, we put IN_PROGRESS + InVCS, and write a comment that links to the
> commit on gitweb. Then when we actua
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I would like to keep CONFIRMED as I use it and find it useful.
I also think that renaming UNCONFIRMED to OPEN is silly and
misleading, since any non-RESOLVED bug is indeed an open bug. I don't
have anything against renaming it to NEW, although I thi
* Kent Fredric schrieb am 16.06.16 um 16:05 Uhr:
> On 17 June 2016 at 01:52, Joshua Kinard wrote:
> > because
> > sometimes, issues can get reported that are really obscure and, for example,
> > tied to a particular hardware configuration, thus cannot be easily and
> > independently confirmed
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
What we have been doing in Portage so far is that when we fix it in
git, we put IN_PROGRESS + InVCS, and write a comment that links to the
commit on gitweb. Then when we actually release Portage, we consider
it to be fixed, and make it RESOLVED.
I w
Modify the tc-getCPP and tc-getBUILD_CPP functions to use "$(tc-getCC)
-E" (i.e. the C compiler's preprocessing call) instead of falling back
to 'cpp'. This ensures that in environment with CC (and CXX) overriden
the correct compiler is used rather than the one selected by gcc-config,
which in turn
40 matches
Mail list logo
