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 location where said issues can be found
>> would do too.
>>
>> Thanks,
>> Fabian
>>
>> On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
>>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34e2c43f
> That would have been a good thing to do, yes. 
>
> Unfortunately I was between two meetings, just saw the message on #gentoo-qa 
> that someone had committed straight to m-n, and if it could be reverted by 
> someone with tree access, and decided to quickly help out.
>
> (And adding a new package straight to m-n is in my opinion enough reason for 
> an immediate revert.)
>
> That said I think we have sorted out things in the meantime.
>
Andreas,

Thanks for the explanation out in the clear!

Might I politely, with all due respect, suggest that drive-by tree
commits are avoided, without adequate prior investigation. Whilst I
think your intentions were indeed noble and justified, the resolution
was not ideal .. (not that perfection is ever achievable) .. but perhaps
alerting another member of QA to do said investigation may have been a
slightly better method! :]

Best regards,
Michael.



signature.asc
Description: OpenPGP digital signature


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 too.
> 
> Thanks,
> Fabian
> 
> On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34e2c43f

That would have been a good thing to do, yes. 

Unfortunately I was between two meetings, just saw the message on #gentoo-qa 
that someone had committed straight to m-n, and if it could be reverted by 
someone with tree access, and decided to quickly help out.

(And adding a new package straight to m-n is in my opinion enough reason for 
an immediate revert.)

That said I think we have sorted out things in the meantime.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.


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 AM, gro...@gentoo.org wrote:
> 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 removing the improved fbreader-0.99.4-r4. libunibreak
> allows fbreader to correctly hyphenate words in languages other than
> English (I am now reading a Russian book in this new revision of
> fbreader, and it is substantially better than doing the same in the
> previous version). I am definitely against removing libunibreak and
> fbreader-0.99.4-r4, and returning to the old
> no-hyphenation-in-non-English-books behaviour.
>
> Andrey
>




signature.asc
Description: OpenPGP digital signature


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 absolutely
>> ridiculous.
Your tone is unnecessary. Moreover, you are misrepresenting what
Christopher wrote. He did not bring it up for the reason you are
implying. He even explicitly said that the lastrite-violation was not
bad, and that the actual mistake must be fixed.
-- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander



signature.asc
Description: OpenPGP digital signature


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 package in violation of Gentoo policy was fully 
> intentional from what I can see. There was no 30-day prior notice + 
> p.mask which is required before removing a package.
> 
> But even that it is not bad, just fix that mistake.
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 
> 
> 

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 absolutely ridiculous.



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
> > > > > 43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2ccc0575a93d10d87bdcf82610452117ac081ddb73f47271a8c2a65897e11c
> > > > > WHIRLPOOL
> > > > > ad71bc5910ca3dff994651022a5a6c6093cd4023852270fa243848f7576287b7cec4ad02a6b27686149491cb52824a93fdb6a6dac4c878d67db2f4041282d300
> > 
> > Those are not correct checksums for a newly added distfile.
> 
> I have portage-2.3.18 (python-3.6.3) and repoman-2.3.6 (pyblake2-1.1.0 
> installed). When I do
> 
> ebuild libunibreak-4.0.ebuild manifest
> 
> or
> 
> repoman manifest
> 
> a Manifest file with SHA256, SHA512 and WHIRLPOOL is generated. What 
> should I change to generate BLAKE2B and SHA512?
> 

Maybe you should do it in the correct repository because
metadata/layout.conf clearly makes that impossible.


-- 
Best regards,
Michał Górny




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
ad71bc5910ca3dff994651022a5a6c6093cd4023852270fa243848f7576287b7cec4ad02a6b27686149491cb52824a93fdb6a6dac4c878d67db2f4041282d300


Those are not correct checksums for a newly added distfile.
I have portage-2.3.18 (python-3.6.3) and repoman-2.3.6 (pyblake2-1.1.0 
installed). When I do


ebuild libunibreak-4.0.ebuild manifest

or

repoman manifest

a Manifest file with SHA256, SHA512 and WHIRLPOOL is generated. What 
should I change to generate BLAKE2B and SHA512?


Andrey

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 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.
> > > > 
> > > > Maintainer-needed is reason enough. If somebody couldn't be bothered to 
> > > > maintain what he committed, why should we bother to list the issues?
> > > > 
> > > > Using repoman and looking at CI mails is also a good idea.
> > > 
> > > Obviously for me to learn something, I won't/can't use repoman here.  So
> > > a pointer to said CI mails from the message of the QA commit would be
> > > nice.
> > 
> > Last I checked, I wasn't personally responsible for teaching people
> > ebuild writing 101 while on phone. But here you go (in malformed paste
> > of ebuild below).
> 
> You simply replied, and therefore took ownership from QA point of view.
> I can't help it you do that whilst on the phone.  In fact, this is
> email, so being on the phone is not a good reason to be vague and avoid
> answering questions in the first place.
> 
> [snip issues]
> 
> Thanks, much appreciated.  I'm completely convinced now.  I'm referring
> back to my earlier suggestion to include such list or the type of issues
> found when a drastic commit like the one we discuss is done under the QA
> flag.  It's good to know that the QA issue complaint was valid, and
> improvements can be made.
> 
> A final suggestion is to talk to the committer before taking such
> drastic actions, in a situation where our users aren't endangered.  As
> this one is, in my opinion.
> There is more problematic stuff in the tree, but teach a man to fish ...
> next time the problems may be avoided.
> 

The point of taking this 'drastic' action is to prevent people from
starting to depend on the package, and therefore blocking its removal.
In this case, the revert was already too late.


-- 
Best regards,
Michał Górny




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 could alternatively have used a pkgmove from liblinebreak to 
libunibreak, then do the bump.



Best regards,
Chí-Thanh Christopher Nguyễn



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 30-day prior notice + 
p.mask which is required before removing a package.


But even that it is not bad, just fix that mistake.


Best regards,
Chí-Thanh Christopher Nguyễn





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 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.
> > > 
> > > Maintainer-needed is reason enough. If somebody couldn't be bothered to 
> > > maintain what he committed, why should we bother to list the issues?
> > > 
> > > Using repoman and looking at CI mails is also a good idea.
> > 
> > Obviously for me to learn something, I won't/can't use repoman here.  So
> > a pointer to said CI mails from the message of the QA commit would be
> > nice.
> 
> Last I checked, I wasn't personally responsible for teaching people
> ebuild writing 101 while on phone. But here you go (in malformed paste
> of ebuild below).

You simply replied, and therefore took ownership from QA point of view.
I can't help it you do that whilst on the phone.  In fact, this is
email, so being on the phone is not a good reason to be vague and avoid
answering questions in the first place.

[snip issues]

Thanks, much appreciated.  I'm completely convinced now.  I'm referring
back to my earlier suggestion to include such list or the type of issues
found when a drastic commit like the one we discuss is done under the QA
flag.  It's good to know that the QA issue complaint was valid, and
improvements can be made.

A final suggestion is to talk to the committer before taking such
drastic actions, in a situation where our users aren't endangered.  As
this one is, in my opinion.
There is more problematic stuff in the tree, but teach a man to fish ...
next time the problems may be avoided.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature


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 Andrey upfront
to establish how honest his mistake was?

> Andrey pretty clearly stated that he did this *on purpose*.

Andreas also did his commit *on purpose*.  Honestly.  And he made things
worse, now actually *affecting* our users.  ...

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature


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 
> > > 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?
> > 
> > No, it wouldn't be fine. We might not even have noticed it if you
> > at least bothered to update the Manifest. Please stop looking for
> > excuses and loopholes, and start doing something good for Gentoo.
> 
> So, breaking the tree, just because someone forgot to set the
> maintainer field is doing something good for Gentoo?  (That's called QA?)
> https://archives.gentoo.org/gentoo-commits/message/7f34111f0e45f451d5b3a5a58b057d51
> 

Bull-shit.

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

-- 
Best regards,
Michał Górny




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 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.
> > 
> > Maintainer-needed is reason enough. If somebody couldn't be bothered to 
> > maintain what he committed, why should we bother to list the issues?
> > 
> > Using repoman and looking at CI mails is also a good idea.
> 
> Obviously for me to learn something, I won't/can't use repoman here.  So
> a pointer to said CI mails from the message of the QA commit would be
> nice.

Last I checked, I wasn't personally responsible for teaching people
ebuild writing 101 while on phone. But here you go (in malformed paste
of ebuild below).

> diff --git a/dev-libs/libunibreak/Manifest
> > > 
> > > b/dev-libs/libunibreak/Manifest
> > > > deleted file mode 100644
> > > > index 487fd898f5d..000
> > > > --- a/dev-libs/libunibreak/Manifest
> > > > +++ /dev/null
> > > > @@ -1 +0,0 @@
> > > > -DIST libunibreak-4.0.tar.gz 629403 SHA256
> > > 
> > > f7329bef1eb169d3363f040cefcc323cfd0a0bc53290a35a395e1d1adc849539 SHA512
> > > 43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2ccc0575a93d10d87bdcf82610452117ac081ddb73f47271a8c2a65897e11c
> > > WHIRLPOOL
> > > ad71bc5910ca3dff994651022a5a6c6093cd4023852270fa243848f7576287b7cec4ad02a6b27686149491cb52824a93fdb6a6dac4c878d67db2f4041282d300

Those are not correct checksums for a newly added distfile.

> > > > 
> > > > diff --git a/dev-libs/libunibreak/libunibreak-4.0.ebuild
> > > 
> > > b/dev-libs/libunibreak/libunibreak-4.0.ebuild
> > > > deleted file mode 100644
> > > > index f531bb66e38..000
> > > > --- a/dev-libs/libunibreak/libunibreak-4.0.ebuild
> > > > +++ /dev/null
> > > > @@ -1,39 +0,0 @@
> > > > -# Copyright 1999-2017 Gentoo Foundation
> > > > -# Distributed under the terms of the GNU General Public License v2
> > > > -
> > > > -EAPI=6
> > > > -inherit versionator
> > > > -
> > > > -DESCRIPTION="Line and word breaking library"
> > > > -HOMEPAGE="http://vimgadgets.sourceforge.net/libunibreak/;
> > > > 
> > > 
> > > -SRC_URI="https://github.com/adah1972/${PN}/releases/download/${PN}_$(replace_all_version_separators
> > > '_')/${P}.tar.gz"
> > > > -
> > > > -LICENSE="ZLIB"
> > > > -SLOT="0"
> > > > -KEYWORDS="~amd64 ~arm ~ppc ~x86"
> > > > -IUSE="doc +man static-libs"
> > > > -
> > > > -DEPEND="man? ( app-doc/doxygen )"
> > > > -RDEPEND="!dev-libs/liblinebreak"
> > > > -
> > > > -src_prepare() {
> > > > -   use man && echo -e 'GENERATE_MAN=YES\nGENERATE_HTML=NO' >> 
> > > > Doxyfile

Missing || die. Also don't use 'echo -e', it teaches people bad
practices and it's awfully unreadable.

> > > > -   default
> > > > -}
> > > > -
> > > > -src_configure() {
> > > > -   econf \
> > > > -   $(use_enable static-libs static)
> > > > -   use doc && export HTML_DOCS=( doc/html/. )

Why is this exported? And what does it have to do with src_configure?

> > > > -}
> > > > -
> > > > -src_compile() {
> > > > -   default
> > > > -   use man && doxygen || die

Gratz, USE=-man dies.

> > > > -}
> > > > -
> > > > -src_install() {
> > > > -   default
> > > > -   prune_libtool_files

Deprecated.

> > > > -   use man && find "${D}/usr/include" -type f -execdir doman
> > > "${S}/doc/man/man3/{}.3" \;
> > > > -}

Why this hackery? Can't you just doman doc/man/man3/*.3?

> > > > 
> > > > diff --git a/dev-libs/libunibreak/metadata.xml
> > > 
> > > b/dev-libs/libunibreak/metadata.xml
> > > > deleted file mode 100644
> > > > index a8bbb441f29..000
> > > > --- a/dev-libs/libunibreak/metadata.xml
> > > > +++ /dev/null
> > > > @@ -1,14 +0,0 @@
> > > > -
> > > > - > > 
> > > "http://www.gentoo.org/dtd/metadata.dtd;>;
> > > > -
> > > > -   
> > > > -   
> > > > -   Libunibreak is an implementation of the line breaking 
> > > > and word
> > > 
> > > breaking algorithms
> > > > -   as described in Unicode Standard Annex 14 and Unicode 
> > > > Standard
> > > 
> > > Annex 29. It is
> > > > -   designed to be used in a generic text renderer.
> > > > -   
> > > > -   
> > > > -   Generate man pages with doxygen.
> > > > -   Install html API documentation.

Sort by name.

> > > > -   
> > > > -
> > > > 
> > > > 
> > 
> > 
> > -- 
> > Best regards,
> > Michał Górny (by phone)
> > 
> 
> 

-- 
Best regards,
Michał Górny




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 
> > maintainer-needed, right?
> > Am I personally responsible for their decision to use the new name 
> > libunibreak?
> 
> No, it wouldn't be fine. We might not even have noticed it if you
> at least bothered to update the Manifest. Please stop looking for
> excuses and loopholes, and start doing something good for Gentoo.

So, breaking the tree, just because someone forgot to set the
maintainer field is doing something good for Gentoo?  (That's called QA?)
https://archives.gentoo.org/gentoo-commits/message/7f34111f0e45f451d5b3a5a58b057d51

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature


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 for their decision to use the new name 
> libunibreak?

No, it wouldn't be fine. We might not even have noticed it if you
at least bothered to update the Manifest. Please stop looking for
excuses and loopholes, and start doing something good for Gentoo.

-- 
Best regards,
Michał Górny




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 (the new revision 
> -r4 depends on libunibreak). Removing libunibreak would require also 
> removing the improved fbreader-0.99.4-r4. libunibreak allows fbreader to 
> correctly hyphenate words in languages other than English (I am now 
> reading a Russian book in this new revision of fbreader, and it is 
> substantially better than doing the same in the previous version). I am 
> definitely against removing libunibreak and fbreader-0.99.4-r4, and 
> returning to the old no-hyphenation-in-non-English-books behaviour.
> 

If you need it, then take it and make it maintained. Gentoo is not going
to get better with people trying hard to avoid any responsibility. It's
going to only turn into a silly package dump.

-- 
Best regards,
Michał Górny




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 the new name
> libunibreak?
> If there are QA problems in libunibreak-4.0.ebuild, they are surely shared
> by liblinebreak-2.1.ebuild (which is stable on amd64, ppc and x86, and
> ~arm). Why these problems were not cought for many years
> liblinebreak-2.1.ebuild is in the tree? (it is there from before the git
> migration, git log only shows trivial commits not changing its
> functionality)

If you are maintaining software that uses the new library, just make
yourself the maintainer.

Not sure what these "QA" issues might be; if repoman likes it, and the
ebuild works, please go ahead and re-add it.



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 interested in the
> "other" QA issues, which seems to suggest 2+ problems in this
> *ebuild*.

I believe I found one.

  use man && doxygen || die

This will die when "man" is disabled?

While I do agree that the maintainer-needed issue was reason enough, if
you're going to say there are other issues then you should have the
decency to say what they are.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer



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 libunibreak-4.0.ebuild, they are surely shared 
by liblinebreak-2.1.ebuild (which is stable on amd64, ppc and x86, and 
~arm). Why these problems were not cought for many years 
liblinebreak-2.1.ebuild is in the tree? (it is there from before the git 
migration, git log only shows trivial commits not changing its 
functionality)


Andrey



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, but a pointer to a location where said issues can be found
> >would do too.
> 
> Maintainer-needed is reason enough. If somebody couldn't be bothered to 
> maintain what he committed, why should we bother to list the issues?

It seems to me you are avoiding the question.  There are no issues with
the ebuild.  It seems like there is just a false claim there are QA
issues, and that is used as waiver to remove the package.

> Using repoman and looking at CI mails is also a good idea.

repoman full (stable) is happy on 8b4ea0f6d2bed140116f69855d1d3100ea0cf020.
qa-reports.gentoo.org has nothing to report
gentoo-qa@ ML has nothing to report

Please list the QA issues:

> >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
"other" QA issues, which seems to suggest 2+ problems in this *ebuild*.

For the record, I didn't commit this ebuild.  I'm just extremely unhappy
about the tiggerhippy response of QA which in my opinion is totally
uncalled for, and am extremely worried about the integrity of QA because
of seemingly false claims to justify actions.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature


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, but a pointer to a location where said issues can be found
> >would do too.
> 
> Maintainer-needed is reason enough. If somebody couldn't be bothered to 
> maintain what he committed, why should we bother to list the issues?
> 
> Using repoman and looking at CI mails is also a good idea.

Obviously for me to learn something, I won't/can't use repoman here.  So
a pointer to said CI mails from the message of the QA commit would be
nice.

Thanks,
Fabian

> >
> >Thanks,
> >Fabian
> >
> >On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
> >> URL:   
> >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34e2c43f
> >> 
> >> Revert "dev-libs/libunibreak: initial import"
> >> 
> >> Please write on the chalkboard 100 times: "I will not add ebuilds as
> >maintainer-needed".
> >> Also other QA issues.
> >> This reverts commit 8b4ea0f6d2bed140116f69855d1d3100ea0cf020.
> >> 
> >>  dev-libs/libunibreak/Manifest   |  1 -
> >>  dev-libs/libunibreak/libunibreak-4.0.ebuild | 39
> >-
> >>  dev-libs/libunibreak/metadata.xml   | 14 ---
> >>  3 files changed, 54 deletions(-)
> >> 
> >> diff --git a/dev-libs/libunibreak/Manifest
> >b/dev-libs/libunibreak/Manifest
> >> deleted file mode 100644
> >> index 487fd898f5d..000
> >> --- a/dev-libs/libunibreak/Manifest
> >> +++ /dev/null
> >> @@ -1 +0,0 @@
> >> -DIST libunibreak-4.0.tar.gz 629403 SHA256
> >f7329bef1eb169d3363f040cefcc323cfd0a0bc53290a35a395e1d1adc849539 SHA512
> >43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2ccc0575a93d10d87bdcf82610452117ac081ddb73f47271a8c2a65897e11c
> >WHIRLPOOL
> >ad71bc5910ca3dff994651022a5a6c6093cd4023852270fa243848f7576287b7cec4ad02a6b27686149491cb52824a93fdb6a6dac4c878d67db2f4041282d300
> >> 
> >> diff --git a/dev-libs/libunibreak/libunibreak-4.0.ebuild
> >b/dev-libs/libunibreak/libunibreak-4.0.ebuild
> >> deleted file mode 100644
> >> index f531bb66e38..000
> >> --- a/dev-libs/libunibreak/libunibreak-4.0.ebuild
> >> +++ /dev/null
> >> @@ -1,39 +0,0 @@
> >> -# Copyright 1999-2017 Gentoo Foundation
> >> -# Distributed under the terms of the GNU General Public License v2
> >> -
> >> -EAPI=6
> >> -inherit versionator
> >> -
> >> -DESCRIPTION="Line and word breaking library"
> >> -HOMEPAGE="http://vimgadgets.sourceforge.net/libunibreak/;
> >>
> >-SRC_URI="https://github.com/adah1972/${PN}/releases/download/${PN}_$(replace_all_version_separators
> >'_')/${P}.tar.gz"
> >> -
> >> -LICENSE="ZLIB"
> >> -SLOT="0"
> >> -KEYWORDS="~amd64 ~arm ~ppc ~x86"
> >> -IUSE="doc +man static-libs"
> >> -
> >> -DEPEND="man? ( app-doc/doxygen )"
> >> -RDEPEND="!dev-libs/liblinebreak"
> >> -
> >> -src_prepare() {
> >> -  use man && echo -e 'GENERATE_MAN=YES\nGENERATE_HTML=NO' >> Doxyfile
> >> -  default
> >> -}
> >> -
> >> -src_configure() {
> >> -  econf \
> >> -  $(use_enable static-libs static)
> >> -  use doc && export HTML_DOCS=( doc/html/. )
> >> -}
> >> -
> >> -src_compile() {
> >> -  default
> >> -  use man && doxygen || die
> >> -}
> >> -
> >> -src_install() {
> >> -  default
> >> -  prune_libtool_files
> >> -  use man && find "${D}/usr/include" -type f -execdir doman
> >"${S}/doc/man/man3/{}.3" \;
> >> -}
> >> 
> >> diff --git a/dev-libs/libunibreak/metadata.xml
> >b/dev-libs/libunibreak/metadata.xml
> >> deleted file mode 100644
> >> index a8bbb441f29..000
> >> --- a/dev-libs/libunibreak/metadata.xml
> >> +++ /dev/null
> >> @@ -1,14 +0,0 @@
> >> -
> >> - >"http://www.gentoo.org/dtd/metadata.dtd;>
> >> -
> >> -  
> >> -  
> >> -  Libunibreak is an implementation of the line breaking and word
> >breaking algorithms
> >> -  as described in Unicode Standard Annex 14 and Unicode Standard
> >Annex 29. It is
> >> -  designed to be used in a generic text renderer.
> >> -  
> >> -  
> >> -  Generate man pages with doxygen.
> >> -  Install html API documentation.
> >> -  
> >> -
> >> 
> >> 
> 
> 
> -- 
> Best regards,
> Michał Górny (by phone)
> 

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature


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 
removing the improved fbreader-0.99.4-r4. libunibreak allows fbreader to 
correctly hyphenate words in languages other than English (I am now 
reading a Russian book in this new revision of fbreader, and it is 
substantially better than doing the same in the previous version). I am 
definitely against removing libunibreak and fbreader-0.99.4-r4, and 
returning to the old no-hyphenation-in-non-English-books behaviour.


Andrey



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
>would do too.

Maintainer-needed is reason enough. If somebody couldn't be bothered to 
maintain what he committed, why should we bother to list the issues?

Using repoman and looking at CI mails is also a good idea.

>
>Thanks,
>Fabian
>
>On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
>> URL:   
>https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34e2c43f
>> 
>> Revert "dev-libs/libunibreak: initial import"
>> 
>> Please write on the chalkboard 100 times: "I will not add ebuilds as
>maintainer-needed".
>> Also other QA issues.
>> This reverts commit 8b4ea0f6d2bed140116f69855d1d3100ea0cf020.
>> 
>>  dev-libs/libunibreak/Manifest   |  1 -
>>  dev-libs/libunibreak/libunibreak-4.0.ebuild | 39
>-
>>  dev-libs/libunibreak/metadata.xml   | 14 ---
>>  3 files changed, 54 deletions(-)
>> 
>> diff --git a/dev-libs/libunibreak/Manifest
>b/dev-libs/libunibreak/Manifest
>> deleted file mode 100644
>> index 487fd898f5d..000
>> --- a/dev-libs/libunibreak/Manifest
>> +++ /dev/null
>> @@ -1 +0,0 @@
>> -DIST libunibreak-4.0.tar.gz 629403 SHA256
>f7329bef1eb169d3363f040cefcc323cfd0a0bc53290a35a395e1d1adc849539 SHA512
>43da73f66fabd8fdef444c5a06ad1800464a0aeab590938522d6c19973950a242f2ccc0575a93d10d87bdcf82610452117ac081ddb73f47271a8c2a65897e11c
>WHIRLPOOL
>ad71bc5910ca3dff994651022a5a6c6093cd4023852270fa243848f7576287b7cec4ad02a6b27686149491cb52824a93fdb6a6dac4c878d67db2f4041282d300
>> 
>> diff --git a/dev-libs/libunibreak/libunibreak-4.0.ebuild
>b/dev-libs/libunibreak/libunibreak-4.0.ebuild
>> deleted file mode 100644
>> index f531bb66e38..000
>> --- a/dev-libs/libunibreak/libunibreak-4.0.ebuild
>> +++ /dev/null
>> @@ -1,39 +0,0 @@
>> -# Copyright 1999-2017 Gentoo Foundation
>> -# Distributed under the terms of the GNU General Public License v2
>> -
>> -EAPI=6
>> -inherit versionator
>> -
>> -DESCRIPTION="Line and word breaking library"
>> -HOMEPAGE="http://vimgadgets.sourceforge.net/libunibreak/;
>>
>-SRC_URI="https://github.com/adah1972/${PN}/releases/download/${PN}_$(replace_all_version_separators
>'_')/${P}.tar.gz"
>> -
>> -LICENSE="ZLIB"
>> -SLOT="0"
>> -KEYWORDS="~amd64 ~arm ~ppc ~x86"
>> -IUSE="doc +man static-libs"
>> -
>> -DEPEND="man? ( app-doc/doxygen )"
>> -RDEPEND="!dev-libs/liblinebreak"
>> -
>> -src_prepare() {
>> -use man && echo -e 'GENERATE_MAN=YES\nGENERATE_HTML=NO' >> Doxyfile
>> -default
>> -}
>> -
>> -src_configure() {
>> -econf \
>> -$(use_enable static-libs static)
>> -use doc && export HTML_DOCS=( doc/html/. )
>> -}
>> -
>> -src_compile() {
>> -default
>> -use man && doxygen || die
>> -}
>> -
>> -src_install() {
>> -default
>> -prune_libtool_files
>> -use man && find "${D}/usr/include" -type f -execdir doman
>"${S}/doc/man/man3/{}.3" \;
>> -}
>> 
>> diff --git a/dev-libs/libunibreak/metadata.xml
>b/dev-libs/libunibreak/metadata.xml
>> deleted file mode 100644
>> index a8bbb441f29..000
>> --- a/dev-libs/libunibreak/metadata.xml
>> +++ /dev/null
>> @@ -1,14 +0,0 @@
>> -
>> -"http://www.gentoo.org/dtd/metadata.dtd;>
>> -
>> -
>> -
>> -Libunibreak is an implementation of the line breaking and word
>breaking algorithms
>> -as described in Unicode Standard Annex 14 and Unicode Standard
>Annex 29. It is
>> -designed to be used in a generic text renderer.
>> -
>> -
>> -Generate man pages with doxygen.
>> -Install html API documentation.
>> -
>> -
>> 
>> 


-- 
Best regards,
Michał Górny (by phone)