Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

[gentoo-dev] Re: AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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: > > >

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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 >

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

[gentoo-dev] Last rites: net-libs/polarssl

# 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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

On Thu, 14 Dec 2017, Michał Górny wrote: f7329bef1eb169d3363f040cefcc323cfd0a0bc53290a35a395e1d1adc849539 SHA512 43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2ccc0575a93d10d87bdcf82610452117ac081ddb73f47271a8c2a65897e11c WHIRLPOOL

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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 >

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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,

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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,

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

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