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

[R0b0t1]

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 answer if I am
>> completely clueless, and would like to apologize in advance for
>> bothering the developers.
>>
>> I am not very smart, sir.
>>
>> Cheers,
>>  R0b0t1
>>
> With all due respect, Gentoo is not renowned for spoon-feeding ...
>

That is exactly right, sir! I am trying my best to not impose on the
goodwill of the mailing list participants. At the same time, I feel
like I could understand an explanation if one was offered. If any
person's judgement suggests otherwise, however, surely they are
correct and no time should be wasted on such a person as myself.

> Returning to the topic in hand, two key points strike out at me:-
>
> 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 choices. The [majority of] developers already seem to have ...
>

This is one of the valid conclusions, especially if the criteria for
stable packages are not changed.

> 2) Whilst there has yet another fine bike-shed emerged on the subject, I
> have only seen one volunteer willing or capable to actually take on
> implementation of anything that has been discussed on this thread. As
> such, you can talk all you like .. nothing will happen until somebody
> actually *does* something .. For all the hating, I will duly credit
> mgorny for producing a consistent quantity of commits across the board
> in Gentoo, and whilst you may not agree with all his bitching (for want
> of a better term) at least he can stand and say "well at least I did
> *something* about it, whether You like it or not ...".
>
> Damnit, there's another $2 from me .. my apologies.
>

I did some initial work trying to fix issues with erlang and rebar,
but I was unable to duplicate the errors due to how tinderboxes work.
A buildbot may not be any more repeatable depending on how it is set
up. Before any work is done I think the problem could be better
characterized, but then you have another long mailing list discussion
that people may or may not be willing to read. People want to do
something, not think about doing something.

In a lot of times that is the better option, even. But not always.

Cheers,
 R0b0t1

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

[Duncan]

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 choices. The [majority of] developers already seem to have ...

The (general) argument for keeping stable seems to consist of two points 
which together have always (to the present at least) tended to 
overwhelmingly tip things in favor of keeping it.  Indeed, either one 
alone can do so, even when the other one is discounted for some reason 
(like some people not putting value in that point).

a) The world of FLOSS isn't a zero-sum game.  People tend to contribute 
where they have interest (whether it's theirs personally or that of their 
employer), and attempting to ban whatever "wasted effort" project in 
favor of what they "should" be contributing to seldom results in /that/ 
much more effort going to the "favored" project after all (and may result 
in less), because if people were interested in that they'd already be 
contributing to it, and the fact that they aren't, or aren't very much, 
tends to mean their interest is elsewhere, and they'll either go 
somewhere else or simply stop contributing as much if they can't 
contribute to what they were interested in, in the first place.

By this point (again, keep in mind we're talking /general/ here, the 
apparent current exception is addressed below), stable exists because 
it's of enough interest to certain contributors that it /continues/ to 
exist, and however much people such as myself (for I'm simply not 
interested in stal^Hble) might consider it a waste of time, killing it 
would be very unlikely to result in invigorating the ~arch I'm primarily 
interested in.  In fact, likely the opposite due to less people as a 
whole contributing.

That's the idealistic point, now perhaps the more practical one...

b) As a point of fact many gentoo sponsors, including those providing 
hosting and/or paying a few gentoo devs to actually do the gentoo work  
they'd very possibly be doing in their spare time anyway (even if it's 
just payment for the 20% aka one day a week open source community 
contribution that's a thing in the tech world), are primarily interested 
in gentoo-stable.

One big and public example is Google, which uses a gentoo base for its 
ChromeOS product.  I'm not privy to details, but from what I've read it 
seems they start with snapshots of gentoo stable, then stabilize them 
further, often feeding their additional patches back upstream to gentoo 
(of course as gentoo feeds stuff back upstream as well, but for some 
things, gentoo /is/ the upstream).  Tho of course if they have reason to 
they can and do pick individual ~arch packages to supplement the stable 
base as well, but the point is, they're interested in /stable/.

And google sponsors, directly or indirectly (some gentooers apparently 
work at unrelated google jobs), a number of gentoo devs, in addition to 
the testing and patches they feed back to us.

Similarly, some of those in our mirror network, for instance, are 
commercial hosters doing it because some of their customers wanted gentoo, 
and providing that local mirror for them, but usable by the public as 
well, is a nice point of convenience to keep those customers /as/ 
customers.

And that's commercial server biz, where the general rule is if it's not 
broke, don't try to "fix" it and in the process risk your view/income/etc 
stream.  So a slow stable actually works well there.


So while I'm personally very much an ~arch and even live-git-build on 
some sets of packages (kde-frameworks/plasma/apps, primarily, with 
occasional others) type of guy and don't /personally/ see much practical 
use for stal^Hble, I certainly see how keeping it makes gentoo bigger and 
better for all of us, including those of us that don't use it personally.


> 2) Whilst there has yet another fine bike-shed emerged on the subject, I
> have only seen one volunteer willing or capable to actually take on
> implementation of anything that has been discussed on this thread. As
> such, you can talk all you like .. nothing will happen until somebody
> actually *does* something ..

Given the context above, What seems to be the problem here is that the 
people that /had/ been interested in, and thus contributing to, gentoo/
amd64-stable, basically the (a) point folks above, seem to have moved on 
to other things, whether inside gentoo or out.

But the (b) point surely remains, so we have a problem.

One could argue that in that case the sponsors should sponsor amd64-
stable folks, but it's not generally that direct, and even if it were, 
getting that worked into the sponsorship pipeline would take time.


I don't have a solution (my reason for posting was to point out that it's 
not as simple as just dropping stable, not really to provide an answer I 
don't 

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

[Michael Orlitzky]

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

[Brian Dolbec]

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:  
> > > > In  my discussions with other developers, I've found that this
> > > > is the
> > > ​> ​  
> > > biggest concern. Most devs are runnning ~amd64, so they don't
> > > feel that ​> ​  
> > > they can mark things stable.
> > >
> > > W
> > > ​hat about running a stable chroot?​ Are there any tools that can
> > > be used to automate this process?  
> >
> > Yes, a stable chroot is okay, and there is app-portage/tatt that
> > can run through the various USE flag combinations for you.
> >
> > It’s output isn’t terribly helpful, so it takes a little while to
> > understand what it’s trying to tell you.
> >  
> 
> 
> 

Lucas, ping me on irc/email me directly.  I have been maintaining
buildbot in gentoo for awhile and my day job is working on/developing
buildbot scripts.  I am planning out some pkg bumping scripts to help
with regular pkg maintenance.  I hope to have some initial code running
during the holiday break.

There should be a bunch of shared factory code possible as there will
be some overlap in their needs.

-- 
Brian Dolbec 

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

[M. J. Everitt]

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 apologize in advance for
> bothering the developers.
>
> I am not very smart, sir.
>
> Cheers,
>  R0b0t1
>
With all due respect, Gentoo is not renowned for spoon-feeding ...

Returning to the topic in hand, two key points strike out at me:-

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 choices. The [majority of] developers already seem to have ...

2) Whilst there has yet another fine bike-shed emerged on the subject, I
have only seen one volunteer willing or capable to actually take on
implementation of anything that has been discussed on this thread. As
such, you can talk all you like .. nothing will happen until somebody
actually *does* something .. For all the hating, I will duly credit
mgorny for producing a consistent quantity of commits across the board
in Gentoo, and whilst you may not agree with all his bitching (for want
of a better term) at least he can stand and say "well at least I did
*something* about it, whether You like it or not ...".

Damnit, there's another $2 from me .. my apologies.



signature.asc
Description: OpenPGP digital signature

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

[R0b0t1]

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
>>> packages.
>>
>> I run stable only on most of my systems.
>>
>
> That is fine, but this thread exists because at least the OP thinks
> stabilization is not happening quickly enough, likely because there
> are not enough people working on it. Allowing stabilization work from
> mixed systems might allow more people to help.
>
>>> They seem to move too slowly, and people switch to unstable
>>> packages because they contain bugfixes and sometimes new features.
>>
>> slow isn't necessarily a problem, as long as security fixes are handled.
>> There is some balancing for large performance gains, but most existing
>> systems are scaled based on the current estimates so it would only be
>> relevant for the up sizing of the server park for growth needs etc.
>>
>>>
>>> Could the criteria for stability be reconsidered? Mixed systems might
>>
>> why would it?
>>
>
> Per the question posed by OP the current state of affairs does not
> seem to be working, and I have tried to point out one likely cause. If
> it's hard to justify the criteria for stability then maybe the
> criteria don't make sense.
>
>>> not be supported, but save for cases of ABI/API breakage (which can
>>> happen when transitioning from stable->stable) I do not know why the
>>> packages would not play well with each other. I am sure there are
>>> examples where things have blown up, but it seems like expecting that
>>> to be the case isn't helping.
>>
>> There are plenty of cases where this fails in miserable ways, so thats
>> not a good idea (not to mention the dependency hell from it). That said,
>> you can have a stable chroot, or just use a VM for testing etc.
>>
>
> Can you be specific? Human memory is biased towards negative
> experiences. If it's hard to actually describe the multitude of issues
> that mixed systems cause then it is very likely mixed systems do not
> cause many issues.
>
> Personally, I have very few problems due to my mixed system, and less
> than I would have on a stable system.
>
> Cheers,
>  R0b0t1

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 apologize in advance for
bothering the developers.

I am not very smart, sir.

Cheers,
 R0b0t1

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

[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] AMD64 Arch Testers needed urgently

[R0b0t1]

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

That is fine, but this thread exists because at least the OP thinks
stabilization is not happening quickly enough, likely because there
are not enough people working on it. Allowing stabilization work from
mixed systems might allow more people to help.

>> They seem to move too slowly, and people switch to unstable
>> packages because they contain bugfixes and sometimes new features.
>
> slow isn't necessarily a problem, as long as security fixes are handled.
> There is some balancing for large performance gains, but most existing
> systems are scaled based on the current estimates so it would only be
> relevant for the up sizing of the server park for growth needs etc.
>
>>
>> Could the criteria for stability be reconsidered? Mixed systems might
>
> why would it?
>

Per the question posed by OP the current state of affairs does not
seem to be working, and I have tried to point out one likely cause. If
it's hard to justify the criteria for stability then maybe the
criteria don't make sense.

>> not be supported, but save for cases of ABI/API breakage (which can
>> happen when transitioning from stable->stable) I do not know why the
>> packages would not play well with each other. I am sure there are
>> examples where things have blown up, but it seems like expecting that
>> to be the case isn't helping.
>
> There are plenty of cases where this fails in miserable ways, so thats
> not a good idea (not to mention the dependency hell from it). That said,
> you can have a stable chroot, or just use a VM for testing etc.
>

Can you be specific? Human memory is biased towards negative
experiences. If it's hard to actually describe the multitude of issues
that mixed systems cause then it is very likely mixed systems do not
cause many issues.

Personally, I have very few problems due to my mixed system, and less
than I would have on a stable system.

Cheers,
 R0b0t1

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

[Thomas Deutschmann]

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 -> Testing workflow.

If a package has multiple users, a serious problem will popup very soon.
So stabilization would be blocked.

If a package hasn't many users and a problem also affects only a special
configuration we maybe won't notice before "regular" stabilization and
after some time...

So why should we wait...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

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

[Thomas Deutschmann]

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 open against the version it is
> looking at, then check the keywords or severity of that bug and  use one
> or the other of those to decide whether or not to skip stabilizing that 
> version
> of the package.

How would you identify such a bug? Someone reports a bug. He/she is
using app-misc/foo-1.2-r2 at the moment. It is often not clear if the
bug affects only =app-misc/foo-1.2-r2, >=, ... What's about foo-2.0?
Maybe foo-1.1 is also affected but wasn't (yet) tested...


> In other words, the first stabilization for a package on an architecture
> should be done the way we currently do them, by filing a stable request
> then using the current stabilization process.

I am not sure if something like this should be a general rule. But like
said, maintainer could either opt-in or opt-out from auto-stabilization.
So if you think your new package is somehow special...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

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

[Alec Warner]

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 being a good idea is for the kernel, given
> the strict no break of userland policy (but even they fail from time to
> time). For rest of the applications, even if we add tools to help
> automate part of the stabilization, I'd very much oppose it being
> automated without being initiated / acked by the maintainer.
>

This reminds me a bit of advertising actually:

"Nineteenth century Philadelphia retailer John Wanamaker supposedly said
“Half the money I spend on advertising is wasted; the trouble is I don't
know which half.” "

I feel like stabilization are similar; we know many of them are likely safe
and don't need humans. But many are unsafe and require validation.
Can we tell them apart? Perhaps Rich's flag is sufficient?

Its also a risk mitigation problem. Is it better for Gentoo to have more
packages marked stable (so that stable is closer to HEAD). Or is it more
valauble
for Gentoo to have a very old stable (like debian) and then have a split
keywords system?

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.

-A




>
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>

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

[Kristian Fiskerstrand]

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 policy (but even they fail from time to
time). For rest of the applications, even if we add tools to help
automate part of the stabilization, I'd very much oppose it being
automated without being initiated / acked by the maintainer.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

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 because they contain bugfixes and sometimes new features.

slow isn't necessarily a problem, as long as security fixes are handled.
There is some balancing for large performance gains, but most existing
systems are scaled based on the current estimates so it would only be
relevant for the up sizing of the server park for growth needs etc.

> 
> Could the criteria for stability be reconsidered? Mixed systems might

why would it?

> not be supported, but save for cases of ABI/API breakage (which can
> happen when transitioning from stable->stable) I do not know why the
> packages would not play well with each other. I am sure there are
> examples where things have blown up, but it seems like expecting that
> to be the case isn't helping.

There are plenty of cases where this fails in miserable ways, so thats
not a good idea (not to mention the dependency hell from it). That said,
you can have a stable chroot, or just use a VM for testing etc.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[R0b0t1]

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 testing. That's the
> whole idea of arch testing... ;)
>
> Remember that mixed systems aren't officially supported.
>

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. They seem to move too slowly, and people switch to unstable
packages because they contain bugfixes and sometimes new features.

Could the criteria for stability be reconsidered? Mixed systems might
not be supported, but save for cases of ABI/API breakage (which can
happen when transitioning from stable->stable) I do not know why the
packages would not play well with each other. I am sure there are
examples where things have blown up, but it seems like expecting that
to be the case isn't helping.

Cheers,
 R0b0t1

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

[Thomas Deutschmann]

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 mixed systems aren't officially supported.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

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

[R0b0t1]

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 extremely hard to replicate and
lead to sporadic errors.

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?

Cheers,
 R0b0t1

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

[Thomas Deutschmann]

# 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



signature.asc
Description: OpenPGP digital signature

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

[Harald Weiner]

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 starting point...

Best wishes,

Harald.

>>> Thomas Deutschmann  12/13/17 9:59 PM >>>

> 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
> everything passes. If for some reason maintainer want to block a
> specific version they could create a bug or set a flag in an already
> existing bug which will cause build bot to ignore this version.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Rich Freeman]

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, it flips to
>> y and the stable bot gets queued up.
>>
>> If its set to 'n', then stable bot never does anything.
>>
>> This way maintainers who want to rush the stablebot on things they
>> consider "safe" can get ahead of the queue.
>
> Well, we kind of have that already with “Runtime testing required” (RTR).
>
> RTR=no stablereqs are good candidates for automation.
>
> If everything has been properly handled in the ebuild, then an emerge
> should succeed. And, RTR being set to “No” indicates that there aren’t any
> tests to perform other than those defined and handled within the ebuild.

I'm not sure runtime testing is the only use case for preventing
auto-stabilization.

The example of KDE/Gnome was brought up where large number of packages
need to be stabilized at the same time.  I'm not sure this is actually
a factor that should prevent auto-stabilization, since these packages
should have the correct dependencies and the stabilization system
would definitely need to be dependency-aware (which would lead to them
being stabilized as a group automatically).  If these require runtime
testing then they fall into the existing use case.

Does anybody actually have a reason to prevent stabilization other
than for runtime testing, assuming that stabilization is done in a
manner where all dependencies are satisfied at all times?

Maybe runtime testing really ought to be the only reason to prevent
auto stabilization...

-- 
Rich

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

[Aaron W. Swenson]

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 set to 'n', then stable bot never does anything.
> 
> This way maintainers who want to rush the stablebot on things they
> consider "safe" can get ahead of the queue.

Well, we kind of have that already with “Runtime testing required” (RTR).

RTR=no stablereqs are good candidates for automation.

If everything has been properly handled in the ebuild, then an emerge
should succeed. And, RTR being set to “No” indicates that there aren’t any
tests to perform other than those defined and handled within the ebuild.

Restricting the set to RTR=no would eliminate special cases needing to
be taken into consideration.

Of course, RTR being unset or set to yes should be skipped.

We could initially start with stablebot only adding a comment to a bug
that it thinks it’s safe to stabilize the subject. This would give us
some time to gain confidence in it and/or weed out the bugs.


signature.asc
Description: Digital signature

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

[Rich Freeman]

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 stabilization bugs.
>

I think this has all been gone over in a list post previously, but it
seems like the most straightforward solution here is flags in metadata
where individual packages can be flagged for auto-stabilization.

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.

Maybe initially for testing you could keep the whitelist outside of
the repository, but then you need to make it straightforward for
maintainers to have their packages added to the whitelist if they
wish.  Long-term if this becomes the standard workflow it would make
sense for the flags to go inside the repository.

-- 
Rich

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

[Thomas Deutschmann]

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 and mark the package stable
>> if everything passes. If for some reason maintainer want to block a
>> specific version they could create a bug or set a flag in an already
>> existing bug which will cause build bot to ignore this version.
> 
> Slightly modified suggestion:
> 
> Add a flag called "autostabilize" with [unset], [y], [n]

Flag in Bugzilla?


> Default is 'unset', and if found unset after a given time, it flips to
> y and the stable bot gets queued up.
> 
> If its set to 'n', then stable bot never does anything.
> 
> This way maintainers who want to rush the stablebot on things they
> consider "safe" can get ahead of the queue.

Sounds good but the variant b was about full auto-stabilization. I.e.
the idea that we even don't require stabilization bugs anymore (like
Debian, where a package will move from SID to testing after some time if
nobody created a blocker bug).

We could auto-generate bugs but I am not sure if this is a good idea.
When mgorny set up autolinking of Github PRs there was some "bug spam"
when people lost control over Git and messed up the rebase (now
prevented via limits).

Also I am not sure how we should handle things like Gnome/KDE
stabilization which requires that a bunch of packages will be stabilized
at once. I.e. if bot detects a new ebuild of kde-frameworks/kservice
auto-stabilization is only allowed to kick in if it is a rev bump of an
already stable ebuild but shouldn't auto-start stabilization of next KDE
version on its own (at least I guess this is what we want).

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 stabilization bugs.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature