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

2017-12-16 Thread M. J. Everitt
On 16/12/17 17:45, Andreas K. Huettel wrote: > Am Donnerstag, 14. Dezember 2017, 13:21:47 CET schrieb Fabian Groffen: >> 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

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

2017-12-16 Thread Andreas K. Huettel
Am Donnerstag, 14. Dezember 2017, 13:21:47 CET schrieb Fabian Groffen: > 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

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

2017-12-14 Thread kuzetsa
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] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

2017-12-14 Thread Alexander Berntsen
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/

2017-12-14 Thread David Seifert
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/

2017-12-14 Thread Michał Górny
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/

2017-12-14 Thread grozin
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/

2017-12-14 Thread grozin
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/

2017-12-14 Thread Michał Górny
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/

2017-12-14 Thread Chí-Thanh Christopher Nguyễn
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/

2017-12-14 Thread Chí-Thanh Christopher Nguyễn
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/

2017-12-14 Thread Fabian Groffen
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/

2017-12-14 Thread Fabian Groffen
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/

2017-12-14 Thread Michał Górny
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/

2017-12-14 Thread Michał Górny
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/

2017-12-14 Thread Fabian Groffen
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/

2017-12-14 Thread Michał Górny
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/

2017-12-14 Thread Mike Gilbert
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

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

2017-12-14 Thread Michał Górny
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/

2017-12-14 Thread Mike Gilbert
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/

2017-12-14 Thread James Le Cuirot
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/

2017-12-14 Thread grozin
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/

2017-12-14 Thread Fabian Groffen
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/

2017-12-14 Thread Fabian Groffen
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/

2017-12-14 Thread grozin
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/

2017-12-14 Thread Michał Górny
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

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

2017-12-14 Thread Fabian Groffen
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: >