On 2017-12-14 01:58, Kent Fredric wrote:
> On Wed, 13 Dec 2017 21:58:05 +0100
> Thomas Deutschmann wrote:
>
>> b) Because not all devs care about stable Gentoo, I would recommend
>> auto-stabilization: I.e. if a package is in the repository for x days
>> build bot would try to build the package a
On Thu, Dec 14, 2017 at 5:39 AM, Thomas Deutschmann wrote:
>
> But well, for the beginning we don't need the perfect solution. We can
> start with an easy mode and blacklist most packages. So devs interested
> can remove their packages from blacklist. And like said, build bot would
> still handle
On 2017-12-14 13:58, Kent Fredric wrote:
> On Wed, 13 Dec 2017 21:58:05 +0100
> Slightly modified suggestion:
>
> Add a flag called "autostabilize" with [unset], [y], [n]
>
> Default is 'unset', and if found unset after a given time, it flips to
> y and the stable bot gets queued up.
>
> If its
On Thu, Dec 14, 2017 at 7:07 AM, Aaron W. Swenson wrote:
> On 2017-12-14 13:58, Kent Fredric wrote:
>> On Wed, 13 Dec 2017 21:58:05 +0100
>> Slightly modified suggestion:
>>
>> Add a flag called "autostabilize" with [unset], [y], [n]
>>
>> Default is 'unset', and if found unset after a given time,
Can we make it a policy to list /what/ QA issues are the justification
for commits like these? A description in the commit message would be
preferred, but a pointer to a location where said issues can be found
would do too.
Thanks,
Fabian
On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
> URL
Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen
napisał(a):
>Can we make it a policy to list /what/ QA issues are the justification
>for commits like these? A description in the commit message would be
>preferred, but a pointer to a location where said issues can be found
>would do too.
Maint
This is in fact a newer version of liblinebreak (under a new name).
liblinebreak is m-n. The ebuild is just a slightly improved
liblinebreak-2.1.
This new version improves the functionality of fbreader (the new revision
-r4 depends on libunibreak). Removing libunibreak would require also
removi
On 14-12-2017 13:39:18 +0100, Michał Górny wrote:
> Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen
> napisał(a):
> >Can we make it a policy to list /what/ QA issues are the justification
> >for commits like these? A description in the commit message would be
> >preferred, but a pointer to a l
On 14-12-2017 13:39:18 +0100, Michał Górny wrote:
> Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen
> napisał(a):
> >Can we make it a policy to list /what/ QA issues are the justification
> >for commits like these? A description in the commit message would be
> >preferred, but a pointer to a l
If the developers of liblinebreak had not decided to rename their library,
I could safely bump it from 2.1 to 4.0, in spite of the fact that it is
maintainer-needed, right?
Am I personally responsible for their decision to use the new name
libunibreak?
If there are QA problems in libunibreak-4.0
On Thu, 14 Dec 2017 14:14:19 +0100
Fabian Groffen wrote:
> > >On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
> > >> Also other QA issues.
>
> Apart from that maintainer-needed has nothing to do with Quality of an
> ebuild, you mentioned it as an QA issue, so I am interested in the
> "ot
On Thu, Dec 14, 2017 at 8:24 AM, wrote:
> If the developers of liblinebreak had not decided to rename their library, I
> could safely bump it from 2.1 to 4.0, in spite of the fact that it is
> maintainer-needed, right?
> Am I personally responsible for their decision to use the new name
> libunib
W dniu czw, 14.12.2017 o godzinie 19∶56 +0700, użytkownik
gro...@gentoo.org napisał:
> This is in fact a newer version of liblinebreak (under a new name).
> liblinebreak is m-n. The ebuild is just a slightly improved
> liblinebreak-2.1.
> This new version improves the functionality of fbreader (t
On Thu, Dec 14, 2017 at 8:30 AM, James Le Cuirot wrote:
> On Thu, 14 Dec 2017 14:14:19 +0100
> Fabian Groffen wrote:
>
>> > >On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
>> > >> Also other QA issues.
>>
>> Apart from that maintainer-needed has nothing to do with Quality of an
>> ebuild, yo
W dniu czw, 14.12.2017 o godzinie 20∶24 +0700, użytkownik
gro...@gentoo.org napisał:
> If the developers of liblinebreak had not decided to rename their library,
> I could safely bump it from 2.1 to 4.0, in spite of the fact that it is
> maintainer-needed, right?
> Am I personally responsible for
On 14-12-2017 14:34:51 +0100, Michał Górny wrote:
> W dniu czw, 14.12.2017 o godzinie 20∶24 +0700, użytkownik
> gro...@gentoo.org napisał:
> > If the developers of liblinebreak had not decided to rename their library,
> > I could safely bump it from 2.1 to 4.0, in spite of the fact that it is
> >
W dniu czw, 14.12.2017 o godzinie 13∶56 +0100, użytkownik Fabian Groffen
napisał:
> On 14-12-2017 13:39:18 +0100, Michał Górny wrote:
> > Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen
> > napisał(a):
> > > Can we make it a policy to list /what/ QA issues are the justification
> > > for commit
W dniu czw, 14.12.2017 o godzinie 14∶38 +0100, użytkownik Fabian Groffen
napisał:
> On 14-12-2017 14:34:51 +0100, Michał Górny wrote:
> > W dniu czw, 14.12.2017 o godzinie 20∶24 +0700, użytkownik
> > gro...@gentoo.org napisał:
> > > If the developers of liblinebreak had not decided to rename their
On 14-12-2017 14:43:11 +0100, Michał Górny wrote:
> Bull-shit.
>
> Breaking the dependency tree was a *honest* mistake on the person who
> reverted this commit.
Honestly, so making mistakes is evaluated based on honesty, then still,
did Andreas (not a QA member as far as I can see) contact Andrey
On 14-12-2017 14:41:17 +0100, Michał Górny wrote:
> W dniu czw, 14.12.2017 o godzinie 13∶56 +0100, użytkownik Fabian Groffen
> napisał:
> > On 14-12-2017 13:39:18 +0100, Michał Górny wrote:
> > > Dnia 14 grudnia 2017 13:21:47 CET, Fabian Groffen
> > > napisał(a):
> > > > Can we make it a policy t
Michał Górny schrieb:
Breaking the dependency tree was a *honest* mistake on the person who
reverted this commit.
Andrey pretty clearly stated that he did this *on purpose*.
The removal of the package in violation of Gentoo policy was fully
intentional from what I can see. There was no 30-day
gro...@gentoo.org schrieb:
If the developers of liblinebreak had not decided to rename their
library, I could safely bump it from 2.1 to 4.0, in spite of the fact
that it is maintainer-needed, right?
Am I personally responsible for their decision to use the new name
libunibreak?
I think you c
W dniu czw, 14.12.2017 o godzinie 14∶56 +0100, użytkownik Fabian Groffen
napisał:
> On 14-12-2017 14:41:17 +0100, Michał Górny wrote:
> > W dniu czw, 14.12.2017 o godzinie 13∶56 +0100, użytkownik Fabian Groffen
> > napisał:
> > > On 14-12-2017 13:39:18 +0100, Michał Górny wrote:
> > > > Dnia 14 gru
On Thu, 14 Dec 2017, Chí-Thanh Christopher Nguyễn wrote:
I think you could alternatively have used a pkgmove from liblinebreak to
libunibreak, then do the bump.
This would break the old liblinebreak-2.1.ebuild which is stable on 3
arches.
Andrey
On Thu, 14 Dec 2017, Michał Górny wrote:
f7329bef1eb169d3363f040cefcc323cfd0a0bc53290a35a395e1d1adc849539 SHA512
43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2ccc0575a93d10d87bdcf82610452117ac081ddb73f47271a8c2a65897e11c
WHIRLPOOL
ad71bc5910ca3dff994651022a5a6c6093cd402385227
W dniu czw, 14.12.2017 o godzinie 22∶16 +0700, użytkownik
gro...@gentoo.org napisał:
> On Thu, 14 Dec 2017, Michał Górny wrote:
> > > > > f7329bef1eb169d3363f040cefcc323cfd0a0bc53290a35a395e1d1adc849539
> > > > > SHA512
> > > > > 43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2c
On Thu, 2017-12-14 at 15:04 +0100, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > Breaking the dependency tree was a *honest* mistake on the person
> > who
> > reverted this commit.
> >
> > Andrey pretty clearly stated that he did this *on purpose*.
>
> The removal of the package
On 14/12/17 17:09, David Seifert wrote:
>> So I can add tons of broken packages, sprinkled over different
>> days, hidden between other valid bumps, and can then tell people
>> they need to lastrite this stuff first and do the 30-day rain
>> dance? Come on, even for Gentoo standards, that's absolut
Dear Thomas and everyone else interested!
Before re-inventing the wheel, you might take a closer look at this Google
summer of code project in 2016:
https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Ideas/Continuous_Stabilization
I do not know how far the author got but it might be a good
# Thomas Deutschmann (14 Dec 2017)
# Unpatched security vulnerability per bug #537108
# Removal in 30 days. Please migrate to net-libs/mbedtls if you have
# not done yet.
net-libs/polarssl
--
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
On Wed, Dec 13, 2017 at 09:58:05PM +0100, Thomas Deutschmann wrote:
*snip*
> b) Because not all devs care about stable Gentoo, I would recommend
> auto-stabilization: I.e. if a package is in the repository for x days
> build bot would try to build the package and mark the package stable if
> ever
On Wed, Dec 13, 2017 at 2:55 PM, Lucas Ramage
wrote:
> I see, well I can setup buildbot to do that. Is there some place in
> particular that I should send my test results?
>
Is this part of the point of a Tinderbox? The only problem I can see is
that the configurations being tested can be extrem
On 2017-12-14 21:06, R0b0t1 wrote:
> In response to the concerns about stability: If I run a lot of unstable
> packages, would that preclude my system from being able to help?
Yes. Only clean stable systems are eligible for arch testing. That's the
whole idea of arch testing... ;)
Remember that m
On Thu, Dec 14, 2017 at 2:13 PM, Thomas Deutschmann wrote:
> On 2017-12-14 21:06, R0b0t1 wrote:
>> In response to the concerns about stability: If I run a lot of unstable
>> packages, would that preclude my system from being able to help?
>
> Yes. Only clean stable systems are eligible for arch te
On 12/14/2017 09:21 PM, R0b0t1 wrote:
> It seems like lagging stability is due to a lack of resources. I do
> not know a single person who would be able to run only stable
> packages.
I run stable only on most of my systems.
> They seem to move too slowly, and people switch to unstable
> packages
On 12/14/2017 01:01 PM, Rich Freeman wrote:
> In the beginning the system would be opt-in. Then once we have
> confidence that it is working well the flag could potentially be made
> opt-out.
The only place I imagine this being a good idea is for the kernel, given
the strict no break of userland
On Thu, Dec 14, 2017 at 3:34 PM, Kristian Fiskerstrand
wrote:
> On 12/14/2017 01:01 PM, Rich Freeman wrote:
> > In the beginning the system would be opt-in. Then once we have
> > confidence that it is working well the flag could potentially be made
> > opt-out.
>
> The only place I imagine this
On 2017-12-14 20:45, William Hubbs wrote:
> I tend to like this better. Let's try to move away from filing stable
> requests for new versions of packages once an old version is stable and
> have a way to block newer versions from going stable. Maybe buildbot
> could check to see if there is a bug o
On 2017-12-14 21:53, Alec Warner wrote:
> I'm skeptical the keywords for most packages matter, particularly on
> common arches. Remember this is usually software that upstream
> already tested and released; so most of the bugs would be ebuild /
> Gentoo related.
That's why I prefer Debian's SID ->
On Thu, Dec 14, 2017 at 2:32 PM, Kristian Fiskerstrand wrote:
> On 12/14/2017 09:21 PM, R0b0t1 wrote:
>> It seems like lagging stability is due to a lack of resources. I do
>> not know a single person who would be able to run only stable
>> packages.
>
> I run stable only on most of my systems.
>
Neat. I didn't spot those new fbreader feature(s).
I also didn't notice m-n status on fbreader deps.
I'll review this thread, research upstream(s), etc.
(if it's within my abilities & available time, I'll maint)
- kuzetsa
P.S. yes: at times, QA messages are a tad vague
On 12/14/2017 07:56 AM
On Thu, Dec 14, 2017 at 4:04 PM, R0b0t1 wrote:
> On Thu, Dec 14, 2017 at 2:32 PM, Kristian Fiskerstrand
> wrote:
>> On 12/14/2017 09:21 PM, R0b0t1 wrote:
>>> It seems like lagging stability is due to a lack of resources. I do
>>> not know a single person who would be able to run only stable
>>>
On 15/12/17 01:17, R0b0t1 wrote (excerpted):
> I'm not trying to be confrontational, but asserting an opinion is
> correct without explaining why that it is so isn't really conducive to
> arriving at the truth. I understand not wanting to answer if I am
> completely clueless, and would like to apol
On Wed, 13 Dec 2017 15:55:59 -0500
Lucas Ramage wrote:
> I see, well I can setup buildbot to do that. Is there some place in
> particular that I should send my test results?
>
> On Wed, Dec 13, 2017 at 1:28 PM, Aaron W. Swenson
> wrote:
>
> > On 2017-12-13 13:20, Lucas Ramage wrote:
> > > >
On 12/12/2017 01:24 PM, Rich Freeman wrote:
>
> As far as I'm aware the standing policy already exists that
> maintainers can stabilize their own packages on amd64.
https://bugs.gentoo.org/510198
is this thing on
M. J. Everitt posted on Fri, 15 Dec 2017 01:25:38 + as excerpted:
> 1) Gentoo isn't really interested in having a 'stable' tree or it would
> already be happening. As such, why not cut the Gordian knot, declare
> that this is not something that will happen [soon] and let users make
> their own
On Thu, Dec 14, 2017 at 7:25 PM, M. J. Everitt wrote:
> On 15/12/17 01:17, R0b0t1 wrote (excerpted):
>> I'm not trying to be confrontational, but asserting an opinion is
>> correct without explaining why that it is so isn't really conducive to
>> arriving at the truth. I understand not wanting to
47 matches
Mail list logo
