Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Kevin Fenzi]

On 02/15/2018 03:21 PM, Adam Williamson wrote:
> On Thu, 2018-02-15 at 18:05 -0500, Stephen John Smoogen wrote:
>>
>> You have been doing it but have you been wanting to do it or just
>> doing it because no one else seems to do it when it is needed. Was it
>> an 'official' part of your job that no one documented or the
>> documentation was lost? And is it a job you have with a lot of
>> responsibility but no 'power' to do anything about?
>>
>> Up until this conversation I thought the answer was "no one else was
>> doing it and someone had to, but I would much rather do the job people
>> pay me to do versus this".
> 
> I don't even know what the job people pay me to do *is* any more. :P
> 
> More people helping with things is always good, but I guess my concern
> is that just throwing in a new person whose job is to 'co-ordinate'
> isn't necessarily going to make anything any better, especially if that
> person is just being randomly delegated by FESCo, isn't actually being
> paid to do it full-time, and maybe doesn't have the experience of
> having actually been doing it for years that some of us do have.

Yeah, I don't want that either... but I think it might help to spread
things around and increase communication if there's a known point of
contact for each release, so if you have some issue you can ask them and
they can at least find out whats going on, and that person knows they
should jump in on issues about the release they are looking after
without waiting/hoping someone else will. ;)

It's possible that just doing better tracking of issues would do this I
guess... give people a good idea where to look when things are broken
and what is going on (if known). (Which we are just trying to do now).

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Chicago]

I would also like to thank the release engineering folks at fedora. Thank you! 

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Jason L Tibbitts III]

> "LT" == Luya Tshimbalanga  writes:

LT> When you get a chance, would you also update the spec guideline as
LT> well?

Which spec guideline did you mean?  If you were referring to the
packaging guidelines, they have said that BuildRoot: should not be used
since 2016:

The BuildRoot: tag, Group: tag, and %clean section SHOULD NOT be used.

https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self-introduction: Kaushal

[Chicago]

Glad to have you here! 

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Adam Williamson]

On Thu, 2018-02-15 at 18:15 -0500, Matthew Miller wrote:
> 
> My intention here wasn't, actually, to complain, but to figure out if
> we could do something to spread the work around a little bit -- or
> maybe to attach some recognition to what's being done, and make a clear
> process for where, say, FPgM or someone should go for status on Rawhide
> in specific.

I mean...#fedora-releng ? This is kinda what release engineering *does*
- they engineer releases. So if a release is not being engineered
optimally, go ask release engineering. I guess I'm just not seeing what
all would actually be improved by putting another fancy named position
into the loop.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Adam Williamson]

On Thu, 2018-02-15 at 18:05 -0500, Stephen John Smoogen wrote:
> 
> You have been doing it but have you been wanting to do it or just
> doing it because no one else seems to do it when it is needed. Was it
> an 'official' part of your job that no one documented or the
> documentation was lost? And is it a job you have with a lot of
> responsibility but no 'power' to do anything about?
> 
> Up until this conversation I thought the answer was "no one else was
> doing it and someone had to, but I would much rather do the job people
> pay me to do versus this".

I don't even know what the job people pay me to do *is* any more. :P

More people helping with things is always good, but I guess my concern
is that just throwing in a new person whose job is to 'co-ordinate'
isn't necessarily going to make anything any better, especially if that
person is just being randomly delegated by FESCo, isn't actually being
paid to do it full-time, and maybe doesn't have the experience of
having actually been doing it for years that some of us do have.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Sérgio Basto]

On Thu, 2018-02-15 at 16:39 -0600, Rex Dieter wrote:
> Matthew Miller wrote:
> 
> > As shown at https://www.happyassassin.net/nightlies.html, we
> > haven't
> > had a successful compose for almost two weeks. AIUI this is mostly
> > worked out now, but it raises the question: who should be keeping
> > track
> > of this and coordinating fixes? 
> 
> ...
> > What do you think?
> 
> Having a rawhide coordinator (aka herder-of-cats) is an excellent
> idea.


Branch more earlier , 2 months without branch ok , but 5 no, is
stretching too much . Some software have 3 months cycle ,  so after one
soname bump on beginning of rawhide , now we a second soname bump
before branch. 

Another idea , is classify packages by importance not just in critical
path or not, at least 3 or 4 levels, where level 1 just can be
"upgraded" in an early rawhide and level 4, 5, or 6 can be upgraded
anytime and in any branch .




-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Matthew Miller]

On Thu, Feb 15, 2018 at 02:39:53PM -0800, Adam Williamson wrote:
> > I suspect that right now, the answer is kind of "It's all of us
> > together", which unfortunately practically speaking often comes down to
> > 0.02% per person and rounds down to 0.
> I...kinda disagree.

Sorry, that came out way more mean then I meant. In fact you and other
people who care do an amazing job of making it work over and over again
despite all sorts of problems. 

> > least, if it was someone who isn't already deeply involved in that. I'm
> > thinking probably someone selected from FESCo — but it also could be a
> > way for people with the particular set of skills required here to get
> > involved in a way that's different from FESCo membership.
> This is...pretty much what I do for every release, and have been doing
> since like Fedora 14 or something?

I know you do for the releases -- and heroically so, including on
things like "holidays", and "weekends" and "when most human beings are
sleeping". That's generally pretty thankless, so... thank you.

My intention here wasn't, actually, to complain, but to figure out if
we could do something to spread the work around a little bit -- or
maybe to attach some recognition to what's being done, and make a clear
process for where, say, FPgM or someone should go for status on Rawhide
in specific.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Stephen John Smoogen]

On 15 February 2018 at 17:39, Adam Williamson
 wrote:
> On Thu, 2018-02-15 at 17:34 -0500, Matthew Miller wrote:
>> As shown at https://www.happyassassin.net/nightlies.html, we haven't
>> had a successful compose for almost two weeks. AIUI this is mostly
>> worked out now, but it raises the question: who should be keeping track
>> of this and coordinating fixes? For the releases, the blocker bug
>> process basically handles this, so functionally the ownership ends up
>> with QA (and the various heroes of QA who then track down all the
>> problems). For rawhide, we don't have any such thing. Is it rel-eng? Is
>> it FESCo? Is it the FPgM? Is it QA after all?
>>
>> I suspect that right now, the answer is kind of "It's all of us
>> together", which unfortunately practically speaking often comes down to
>> 0.02% per person and rounds down to 0.
>
> I...kinda disagree.
>
> In practice it tends to boil down to "me, nirik, and puiterwijk". So,
> QA plus releng. And we don't ignore it. The current case is just
> turning out to be rather hard because it's not one case, it's about 15.
> So far we've found *four separate issues* in just the latest compose,
> never mind all the ones we fixed already:
>
> https://pagure.io/dusty/failed-composes/issue/1
>
> Note that any failed compose is implicitly a release blocking bug for
> whatever the next milestone release happens to be, and whenever we have
> something particularly intransigent blocking the compose, I usually
> file an actual blocker bug for it, so it bubbles up to the release
> blocking process that way.
>
>> Or if the answer is: "Matthew, you are the FPL. It's you!" … then fine,
>> but I'm going to then have to find some way to turn around and
>> delegate. :)
>>
>> I was chatting with Kevin Fenzi and he suggested naming a release
>> manager for each release — someone who would keep track of stuff
>> starting at branch, and help coordinate things like this.
>>
>> This would help with more than just Rawhide — I'm sure everyone
>> involved in the blocker bug process would be grateful for more help. At
>> least, if it was someone who isn't already deeply involved in that. I'm
>> thinking probably someone selected from FESCo — but it also could be a
>> way for people with the particular set of skills required here to get
>> involved in a way that's different from FESCo membership.
>
> This is...pretty much what I do for every release, and have been doing
> since like Fedora 14 or something?

You have been doing it but have you been wanting to do it or just
doing it because no one else seems to do it when it is needed. Was it
an 'official' part of your job that no one documented or the
documentation was lost? And is it a job you have with a lot of
responsibility but no 'power' to do anything about?

Up until this conversation I thought the answer was "no one else was
doing it and someone had to, but I would much rather do the job people
pay me to do versus this".


> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning scram

[Olzhas Rakhimov]

On Wed, Feb 14, 2018 at 12:00 AM, Vascom  wrote:
> I can take package and upgrade it.
>
Thanks Vascom.

Olzhas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Rex Dieter]

Matthew Miller wrote:

> As shown at https://www.happyassassin.net/nightlies.html, we haven't
> had a successful compose for almost two weeks. AIUI this is mostly
> worked out now, but it raises the question: who should be keeping track
> of this and coordinating fixes? 
...
> What do you think?

Having a rawhide coordinator (aka herder-of-cats) is an excellent idea.

-- rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Adam Williamson]

On Thu, 2018-02-15 at 17:34 -0500, Matthew Miller wrote:
> As shown at https://www.happyassassin.net/nightlies.html, we haven't
> had a successful compose for almost two weeks. AIUI this is mostly
> worked out now, but it raises the question: who should be keeping track
> of this and coordinating fixes? For the releases, the blocker bug
> process basically handles this, so functionally the ownership ends up
> with QA (and the various heroes of QA who then track down all the
> problems). For rawhide, we don't have any such thing. Is it rel-eng? Is
> it FESCo? Is it the FPgM? Is it QA after all?
> 
> I suspect that right now, the answer is kind of "It's all of us
> together", which unfortunately practically speaking often comes down to
> 0.02% per person and rounds down to 0.

I...kinda disagree.

In practice it tends to boil down to "me, nirik, and puiterwijk". So,
QA plus releng. And we don't ignore it. The current case is just
turning out to be rather hard because it's not one case, it's about 15.
So far we've found *four separate issues* in just the latest compose,
never mind all the ones we fixed already:

https://pagure.io/dusty/failed-composes/issue/1

Note that any failed compose is implicitly a release blocking bug for
whatever the next milestone release happens to be, and whenever we have
something particularly intransigent blocking the compose, I usually
file an actual blocker bug for it, so it bubbles up to the release
blocking process that way.

> Or if the answer is: "Matthew, you are the FPL. It's you!" … then fine,
> but I'm going to then have to find some way to turn around and
> delegate. :)
> 
> I was chatting with Kevin Fenzi and he suggested naming a release
> manager for each release — someone who would keep track of stuff
> starting at branch, and help coordinate things like this.
> 
> This would help with more than just Rawhide — I'm sure everyone
> involved in the blocker bug process would be grateful for more help. At
> least, if it was someone who isn't already deeply involved in that. I'm
> thinking probably someone selected from FESCo — but it also could be a
> way for people with the particular set of skills required here to get
> involved in a way that's different from FESCo membership.

This is...pretty much what I do for every release, and have been doing
since like Fedora 14 or something?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Should we have a release manager for each release? (or, "who owns rawhide"?)

[Matthew Miller]

As shown at https://www.happyassassin.net/nightlies.html, we haven't
had a successful compose for almost two weeks. AIUI this is mostly
worked out now, but it raises the question: who should be keeping track
of this and coordinating fixes? For the releases, the blocker bug
process basically handles this, so functionally the ownership ends up
with QA (and the various heroes of QA who then track down all the
problems). For rawhide, we don't have any such thing. Is it rel-eng? Is
it FESCo? Is it the FPgM? Is it QA after all?

I suspect that right now, the answer is kind of "It's all of us
together", which unfortunately practically speaking often comes down to
0.02% per person and rounds down to 0.

Or if the answer is: "Matthew, you are the FPL. It's you!" … then fine,
but I'm going to then have to find some way to turn around and
delegate. :)

I was chatting with Kevin Fenzi and he suggested naming a release
manager for each release — someone who would keep track of stuff
starting at branch, and help coordinate things like this.

This would help with more than just Rawhide — I'm sure everyone
involved in the blocker bug process would be grateful for more help. At
least, if it was someone who isn't already deeply involved in that. I'm
thinking probably someone selected from FESCo — but it also could be a
way for people with the particular set of skills required here to get
involved in a way that's different from FESCo membership.

What do you think?


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Jonathan Wakely]

On 14/02/18 21:59 +0100, Igor Gnatenko wrote:

* Fix up packages and tell package names I should not touch because you did
that already.



boostdenisarnaud jwakely


Done in 
https://src.fedoraproject.org/rpms/boost/c/4c456d525c8779b5ea8ef8b2031ad4eab6b66c61?branch=master


mysql++  jwakely rombobeorn


I've created a pull request for Björn to approve:
https://src.fedoraproject.org/rpms/mysql++/pull-request/1

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Pierre-Yves Chibon]

On Thu, Feb 15, 2018 at 08:12:27PM +, Tomasz Kłoczko wrote:
>It took me personally more than few years to come to conclusion that rpm
>packages scriptlets idea is wrong.

That exact sentence makes me wonder, did you watch the videos from Will at flock
or DevConf?
Because what you're talking about here, is *exactly* what Will is trying to
address, to the dots.

So let's stop playing the game of I think I know better than you do because I
know what I know while I can only assume what you know.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Tomasz Kłoczko]

On 15 February 2018 at 15:19, David Shea  wrote:
[..]

> Can we maybe step back and give other developers the benefit of the doubt
> instead of immediately attacking an attempt to provide information? This is
> really unnecessarily hostile.
>

What I wrote is not about hostility or attacking anyone.
It is only pure conclusion about Will current understanding of the subject.
So what I wrote it is only clear signal from my side that Will (as probably
many other people here) still do not understand where all those changes are
going.
I'm sure that sooner or later he will understand
People are different and by definition each of us are able to understand
different things with different speed.
I'm sure that probably someone will be able to find some other subject
which I will have difficulty to understand .. not because I'm stupid or
idiot but because I have exact baggage of my current knowledge and
experience.
The same is with Will .. he is *ONLY* trying to understand the subject and
so far he been failing trying to use words which have no meaning in context
of exactly scriptlets subject.
So guys .. if you still do not understand nature of this change *just
please give yourselves a little more time* :)

I really do not understand what more is possible to say about remove
ldconfig execution from %post/%postun scriptlets than only this that this
change is about remove bits which only elongates install/upgrade time, That
is really all ..  just one sentence.

I've been really thinking that as long as Igor accepted my and few other
people arguments, and started removing ldconfig scriptlets critical mass of
the understanding has been reached.
Igor even wrote about this change some documentation so we don't need to
discuss anything here. Everything is explained in this doc :)
In other words: trying to discuss anything here/now is kind of result of
miscommunication, misunderstanding or even disrespect to time and work
which Igor spend on prepare to this change.

So "Roma locuta, causa finita". Fedora rawhide *already* incorporated
ldconfig scriptlets reduction.
I see some overuse some %ldconfig* macros but this could be corrected in
next few iterations.

What has been already done with ldconfig it was *only* one step on
evolutionary change of the state of all Fedora packages on the path going
to state where it will be no per package scriptlets!!!
Such change cannot be done by revolution because many Fedora packages are
sill not able to spot that all those per package scriptlets is possible to
abandon (if few other things will be changed outside packaging layer).
Other reason why this cannot bi introduced in revolutionary way is related
to "death by thousands cuts" effect.
As I wrote here only way of fixing results of this effect is *ONLY* undo
one by one each of those single cuts.

My plan is not to fight with believers but show by reduction one by one
sets of the scriptets that all together those scriptles could be removed ..
(again: if few other bits could be added outside of pure packaging or if
rpm as PM tool will incorporate few functionalities which already has been
integrated into PM like Solaris IPS).
Smaller set of those scriplets than easier will be spot that *they are not
needed*.

It took me personally more than few years to come to conclusion that rpm
packages scriptlets idea is wrong.
Now whole Fedora community is progressing on the same path even faster than
it was in my case.

So stay tuned and please be a bit more patient ..  (even if you still do
not understand whole/wider picture).

klocek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Sérgio Basto]

On Fri, 2018-02-09 at 11:05 +0100, Vít Ondruch wrote:
> Dne 9.2.2018 v 09:21 Kevin Kofler napsal(a):
> > Matthew Miller wrote:
> > > Second, there's package maintainer changelogs. These are really
> > > redundant with the dist-git log. We don't really need this
> > > anymore.
> > > It's just a chore.
> > 
> > My %changelog entries are not identical to the dist-git commit
> > messages:
> > 
> > 1. It often takes me several git commits to make a new EVR that
> > builds.
> >Also, typos in commit messages cannot be fixed. (Both of those
> > issues
> >could be solved if we were to allow force pushes to dist-git,
> > but that
> >would open a much bigger can of worms, as you certainly know.)
> > 
> > 2. Most of my git commit messages are of the form:
> > 
> >one-line summary
> > 
> >full copy of the RPM changelog entry, including the line
> > with date,
> >author and EVR.
> > 
> >(The only ones that deviate from that format are followup fixup
> > commits
> >as per point 1.) If you are going to generate RPM changelogs
> > from those
> >commit messages, they will look really messy, with the date-
> > author-EVR
> >line duplicated.
> > 
> > 3. Some of my commit messages contain additional notes that are not
> > intended
> >for the package changelog. (Typically a full paragraph of
> > explanatory
> >text.)
> > 
> > Thus, I think autogenerating the %changelog from dist-git commit
> > messages 
> > would degrade its quality a lot, at least for my packages.
> 
> This doesn't mean it could not work. There are, for example, well
> established [skip ci] marks [1] used to skip CI for minor changes. We
> could have something similar such as [skip changelog], or something
> of
> opposite meaning to include just some specific part of commit
> message.
> 
> In the end it would save you at least the "full copy of the RPM
> changelog entry, including the line with date,   author and EVR."
> work.
> 
> BTW I assume you know "fedpkg clog" and "git commit -F clog" to save
> you
> copy ;)

Even less work with : 

fedpkg ci -c 


-c, --clog Generate the commit message from the Changelog section

> Vít
> 
> 
> [1] https://www.google.cz/search?q=skip+ci
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New "tests" namespace to share test code

[Adam Williamson]

On Thu, 2018-02-15 at 13:11 +0100, Petr Šplíchal wrote:
> 
> > The question 'who decides which tests block which packages' is
> > left a bit up in the air, but in fact no more so than it already
> > was for package-specific tests...
> 
> Right. Do we want to change this? Specify this more strictly?
> Like exactly defining requirements which an Always Ready Operating
> System has to meet? And then mapping these requirements to the
> test coverage? (Here again FMF mentioned above might come handy.)

Maybe we should just *formalize* it a bit, so folks know where they
stand. So far we've basically done three things that implicitly
describe the policy on this:

1) Bodhi has a mechanism by which the person submitting an update can
specify some tests that block the update

2) FESCo accepted, voted on and approved a ticket which involved a
decision that certain tests blocked some/all updates

3) We built and deployed WaiverDB and Greenwave such that Greenwave
currently accepts waivers submitted to WaiverDB by...(anybody??? this
point I'm not sure on)

So, effectively, we have communicated that FESCo can set mandatory
policies here, and packagers can also make voluntary choices. Point 3)
is rather a crucial one, and I don't know that it's been formally
discussed anywhere; I think we have been rather heavily focused on
building the tools as opposed to setting the policy so far. But we've
at least clearly implied so far that FESCo claims to some extent the
power to set automated test gating requirements for updates, and that
packagers have some ability to extend those requirements voluntarily,
and also submit waivers. I guess the natural thing to do from here, if
we want to be a bit more explicit about it, would be to extend the
Updates Policy:

https://fedoraproject.org/wiki/Updates_Policy

either in-line or with a subsidiary document, to define this stuff a
bit more clearly/formally.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2018-02-16)

[Randy Barlow]

On 02/14/2018 10:06 PM, Devrim Gündüz wrote:
> On Wed, 2018-02-14 at 17:36 -0500, Randy Barlow wrote:
>> #topic #1842 Nonresponsive maintainer: devrim
>> .fesco 1842
>> https://pagure.io/fesco/issue/1842

> I thought other folks was already taking care of this package -- and to be
> honest, I was not even aware that pkgdb was obsoleted, so I am not sure how to
> pass the ownership of the package.
> 
> Anyway, I'm fine with giving the ownership to MarkusN, he is maintaining the
> upstream as well.

Hi Devrim,

You can give the package to MarkusN by visiting:

https://src.fedoraproject.org/rpms/grass

Click on Settings in the upper right and you will see a section called
"Users and Groups". You can use this to grant ACLs to other developers.

If you want to give the package away, you can scroll a little further to
the "Give Project" section.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RANT: Packaging is changing too fast and is not well documented

[Brian Exelbierd]

On Mon, Feb 12, 2018, at 7:37 PM, Kevin Fenzi wrote:
> On 02/12/2018 10:14 AM, Ken Dreyer wrote:
> > On Sat, Feb 10, 2018 at 6:48 AM, Richard Shaw  wrote:
> >> Not coming from a programming background I found the learning curve pretty
> >> steep when I first tried to become a packager, I'm not sure I wouldn't have
> >> given up if I had to do it now.
> > 
> > Thanks for speaking up about this. I'm having trouble following along
> > with the latest changes too.
> > 
> > Pagure brings a ton of benefits to dist-git management, so I don't
> > diss Pagure and all the hard work folks have put into making that a
> > reality. I just miss the easy birds-eye-view that the pkgdb web UI
> > provided.
> 
> I agree things are rough around the edges. Thats why I proposed the
> number one deliverable from our upcoming Infrastructure Hackfest (
> https://fedoraproject.org/wiki/Infrastructure_Hackathon_2018 ) be
> cleaning up all our documentation and improving any workflows and
> scripts we can.

I look forward to helping you publish this on docs.fedorproject.org ... which 
will be easier after the upcoming docs hackfest at the end of the month.

regards,

bex

> 
> I hope we can fix some of these issues there...
> 
> kevin
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora27: NFS v4 terrible write performance, is async working

[Terry Barnaby]

On 15/02/18 16:48, J. Bruce Fields wrote:

On Tue, Feb 13, 2018 at 07:01:22AM +, Terry Barnaby wrote:

The transaction system allows the write delegation to send the data to the
servers RAM without the overhead of synchronous writes to the disk.

As far as I'm concerned this problem is already solved--did you miss the
discussion of WRITE/COMMIT in other email?

The problem you're running into is with metadata (file creates) more
than data.
Not quite, I think, unless I missed something ? With the transaction 
method on top of write delegations the NFS server is always effectively 
in "async" mode so actual disk writes are asynchronous with the final 
real NFS WRITE's from the write delegation and thus the disk writes can 
be optimised by the OS as normal, as and when, without the data being 
lost if the server dies. So no requirement for the bottleneck of server 
side "sync" mode and special disk systems unless needed for a particular 
requirement. As this method protects the data, even the metadata can be 
passed through asynchronously apart from the original open, assuming the 
particular requirements are such that other clients don't need access to 
this metadata live. As far as I can see, with only quick thoughts so may 
be missing something major (!),  this method could almost fully remove 
latency issues with NFS writes with small files while using conventional 
disk systems in the server.
As someone suggested that this is not the right place for this sort of 
discussion, I will try and start a discussion on the NFS kernel mailing 
when I have some time. It would be good to see an improved performance 
with NFS writes with small files while still being secure and also find 
out why fsync() does not work when the NFS export is in "async" mode!



PS: I have some RPC latency figures for some other NFS servers at work. The
NFS RPC latency on some of them is nearer the ICMP ping times, ie about
100us. Maybe quite a bit of CPU is needed to respond to an NFS RPC call
these days. The 500us RPC time was on a oldish home server using an Intel(R)
Core(TM)2 CPU 6300 @ 1.86GHz.

Tracing to figure ou the source of the latency might still be
interesting.

Will see if I can find some time to do this, away for a bit at the moment.


--b.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1074  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 837  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 419  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 316  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 148  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  85  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  49  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  35  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df   
knot-resolver-1.5.3-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-18ea640f19   
tomcat-native-1.2.16-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f09712d924   
pdns-3.4.11-4.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-069884a87f   
p7zip-16.02-10.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-097b4381c7   
exim-4.90.1-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

fedpkg-1.31-5.el7
htop-2.1.0-1.el7
microdns-0.0.8-1.el7
nwipe-0.24-2.el7
pan-0.144-1.el7
perl-Convert-ASCII-Armour-1.4-32.el7
php-justinrainbow-json-schema5-5.2.7-1.el7
python-hexdump-3.4-0.2.20160818hg66325cb5fed8.el7

Details about builds:



 fedpkg-1.31-5.el7 (FEDORA-EPEL-2018-f41cd20be2)
 Fedora utility for working with dist-git

Update Information:

fix broken syntax in bash completion    - Include missing conf file in test
(cqi) - Add more document to request-repo and request-branch (cqi) - Stop
allowing EPEL branches on official EL packages (mprahl) - Port fedrepo-req and
fedrepo-req-branch to fedpkg (mprahl) - Fix test for unsupported Bodhi version
(lsedlar) - Work with Bodhi 3 - rhbz#1507410 (lsedlar) - Allow any parameters in
construct_build_url (cqi) - Fix the anongiturl (patrick)

References:

  [ 1 ] Bug #1544133 - fedpkg update from 1.30-4 to 1.31-1 broke bash completion
https://bugzilla.redhat.com/show_bug.cgi?id=1544133
  [ 2 ] Bug #1507410 - fedpkg update fails with: "This system has bodhi v3, 
which is unsupported"
https://bugzilla.redhat.com/show_bug.cgi?id=1507410




 htop-2.1.0-1.el7 (FEDORA-EPEL-2018-e6eca7cd53)
 Interactive process viewer

Update Information:

- Update to 2.1.0

References:

  [ 1 ] Bug #1541785 - Fedora does not install a ".desktop" file for htop.
https://bugzilla.redhat.com/show_bug.cgi?id=1541785




 microdns-0.0.8-1.el7 (FEDORA-EPEL-2018-0b2cfbc4a9)
 Minimal mDNS resolver and announcer library

Update Information:

New package

References:

  [ 1 ] Bug #1545347 - Review Request: microdns - Minimal mDNS resolver and 
announcer library
https://bugzilla.redhat.com/show_bug.cgi?id=1545347




 nwipe-0.24-2.el7 (FEDORA-EPEL-2018-0bda25f2be)
 Securely erase disks using a variety of recognized methods

Update Information:

bugfix update to upstream release 0.24

References:

  [ 1 ] Bug #1523430 - nwipe-0.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1523430




 pan-0.144-1.el7 (FEDORA-EPEL-2018-73bafd172a)
 A Usenet newsreader for GNOME/GTK+

Re: Fedora27: NFS v4 terrible write performance, is async working

[J. Bruce Fields]

On Tue, Feb 13, 2018 at 07:01:22AM +, Terry Barnaby wrote:
> The transaction system allows the write delegation to send the data to the
> servers RAM without the overhead of synchronous writes to the disk.

As far as I'm concerned this problem is already solved--did you miss the
discussion of WRITE/COMMIT in other email?

The problem you're running into is with metadata (file creates) more
than data.

> PS: I have some RPC latency figures for some other NFS servers at work. The
> NFS RPC latency on some of them is nearer the ICMP ping times, ie about
> 100us. Maybe quite a bit of CPU is needed to respond to an NFS RPC call
> these days. The 500us RPC time was on a oldish home server using an Intel(R)
> Core(TM)2 CPU 6300 @ 1.86GHz.

Tracing to figure ou the source of the latency might still be
interesting.

--b.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Non-responsive maintainer: Lubomir Rintel (lkundrak)

[Dan Williams]

On Wed, 2018-02-14 at 23:49 +0100, Sandro Mani wrote:
> Hi
> 
> Does anyone know how to contact Lubomir Rintel (lkundrak)? He is 
> obviously still active since his last koji build is as recent as
> last 
> Sunday the 11th, but he isn't answering to this ticket [1] and I
> also 
> had no luck e-mailing him directly.

As a follow-up, he replied on the bug.

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libevent-2.1.8 SONAME change.

[Steve Dickson]

On 02/15/2018 07:04 AM, Peter Robinson wrote:
> On Thu, Feb 15, 2018 at 11:51 AM, Steve Dickson  wrote:
>> Hello,
>>
>> Yesterday I updated libevent to the latest upstream release.
>>
>> I mistakenly did not realized there was a SONAME change
>> in this update. So if your package is dependent on
>> libevent, you are going to have to rebuild.
>>
>> My apologies for this oversight...
> 
> Specifying major version numbers in the library files (extract below)
> will ensure a build failure when the soname bumps to ensure this
> doesn't happen and that you're aware of it can do do appropriate
> communication/side tag builds/etc so it doesn't break rawhide for
> everyone else that's trying to get things done in the future.
> 
> %{_libdir}/libevent-*.so.*
> %{_libdir}/libevent_core-*.so.*
> %{_libdir}/libevent_extra-*.so.*
> %{_libdir}/libevent_openssl-*.so.*
> %{_libdir}/libevent_pthreads-*.so.*

Excellent idea! The rawhide rpm has been updated.

Again... sorry for the pain. 

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2018-02-15 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-02-15 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2018-02-15 09:00 PST  US/Pacific
2018-02-15 12:00 EST  --> US/Eastern <--
2018-02-15 17:00 GMT  Europe/London 
2018-02-15 17:00 UTC  UTC   
2018-02-15 18:00 CET  Europe/Berlin 
2018-02-15 18:00 CET  Europe/Paris  
2018-02-15 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2018-02-16 01:00 HKT  Asia/Hong_Kong
2018-02-16 01:00 +08  Asia/Singapore
2018-02-16 02:00 JST  Asia/Tokyo
2018-02-16 03:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =

#topic #691 noarch *sub*packages with arch-specific dependencies
.fpc 691
https://pagure.io/packaging-committee/issue/691

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

#topic #694 Packaging guidelines for application independence 
.fpc 694
https://pagure.io/packaging-committee/issue/694

#topic #702 C/C++ guidelines should say using clang needs an exception
.fpc 702
https://pagure.io/packaging-committee/issue/702

#topic #708 Allocating a static uid and gid for openvswitch
.fpc 708
https://pagure.io/packaging-committee/issue/708

#topic #710 Ruby packaging guidelines update
.fpc 710
https://pagure.io/packaging-committee/issue/710

#topic #713 Forward-looking conditionals by default
.fpc 713
https://pagure.io/packaging-committee/issue/713

#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714

#topic #715 Separately building package documentation
.fpc 715
https://pagure.io/packaging-committee/issue/715

#topic #719 Simplify packaging of forge-hosted projects 
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #723 Guidelines for handling deprecated dependencies during
review 
.fpc 723
https://pagure.io/packaging-committee/issue/723

#topic #726 Review for SELinux Independent Policy packaging Draft   
.fpc 726
https://pagure.io/packaging-committee/issue/726

#topic #743 Add link to C/C++ build flag documentation in redhat-rpm-
config
.fpc 743
https://pagure.io/packaging-committee/issue/743

= New business =

#topic #741 Clarify the PyPI URL template
.fpc 741
https://pagure.io/packaging-committee/issue/741

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://pagure.io/packaging-committee
,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Jonathan Wakely]

On 15/02/18 11:10 -0500, David Cantrell wrote:

On 02/15/2018 11:02 AM, Jonathan Wakely wrote:

On 15/02/18 08:46 -0500, David Cantrell wrote:

First, I actually don't care if this change is made or not.  My personal
opinion is that it's a nice-to-have cleanup that will probably not cause
problems, but you never know with that many packages.  So that's why I
feel it should be approached using pull requests.  We have that
functionality now thanks to Pagure, which is something we *never* had in
dist-cvs or the former git system.  Is that tedious?  Yeah, it is.  But
pushing a change like that across many packages will not necessarily
explain to package maintainers why that was done.  If packages have not
been cleaned up in that amount of time and things are still building, I
question the urgency of the change.  Pull requests give package
maintainers an opportunity to be part of this change.  Others have
pointed this out too.  Otherwise things like this will likely continue
happening and package maintainers will overwhelming remain in the dark
about what changes should be made in spec files.


What's the real benefit to getting each maintainer to remove the tag
themselves via a pull request? After they get the pull request and
understand the motivation they now know about something that should
not be in their spec files. Is it really necessary for them to know a
negative? Should they also remember a list of other tags that
shouldn't be in there, or should we just remove the cruft, make sure
the docs, examples and templates don't have those tags, and move on?

Remaining in the dark about a tag that has no meaning doesn't seem
harmful.


My thinking there is that the PR serves as a way to communicate this
change to package maintainers who have been copying existing spec files
and templates to make new packages.  Concern was mentioned that package
maintainers keep using this tag when they don't need to, so the message
has not been received.  I think a PR serves as a good way to communicate
that to maintainers.


So remove it from all our specs and templates and let it be forgotten.

People keep copying it from existing specs because nobody has done the
work of removing all the existing uses before now.

Once it's gone we can make rpmlint warn about it, so it doesn't keep
coming back.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[David Cantrell]

On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
> On 15/02/18 08:46 -0500, David Cantrell wrote:
>> First, I actually don't care if this change is made or not.  My personal
>> opinion is that it's a nice-to-have cleanup that will probably not cause
>> problems, but you never know with that many packages.  So that's why I
>> feel it should be approached using pull requests.  We have that
>> functionality now thanks to Pagure, which is something we *never* had in
>> dist-cvs or the former git system.  Is that tedious?  Yeah, it is.  But
>> pushing a change like that across many packages will not necessarily
>> explain to package maintainers why that was done.  If packages have not
>> been cleaned up in that amount of time and things are still building, I
>> question the urgency of the change.  Pull requests give package
>> maintainers an opportunity to be part of this change.  Others have
>> pointed this out too.  Otherwise things like this will likely continue
>> happening and package maintainers will overwhelming remain in the dark
>> about what changes should be made in spec files.
> 
> What's the real benefit to getting each maintainer to remove the tag
> themselves via a pull request? After they get the pull request and
> understand the motivation they now know about something that should
> not be in their spec files. Is it really necessary for them to know a
> negative? Should they also remember a list of other tags that
> shouldn't be in there, or should we just remove the cruft, make sure
> the docs, examples and templates don't have those tags, and move on?
> 
> Remaining in the dark about a tag that has no meaning doesn't seem
> harmful.

My thinking there is that the PR serves as a way to communicate this
change to package maintainers who have been copying existing spec files
and templates to make new packages.  Concern was mentioned that package
maintainers keep using this tag when they don't need to, so the message
has not been received.  I think a PR serves as a good way to communicate
that to maintainers.

Thanks,

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Luya Tshimbalanga]

On 2018-02-13 02:05 PM, Igor Gnatenko wrote:
> Just a small heads up, BuildRoot tag is not needed since RHEL6 (which
> is oldest
> supported one nowadays, it's been year or so after EL5 retirement). And we
> don't support EL5 anymore, so...
>
> I wanted to send this heads up before I actually did that, but I hit
> "enter"
> button too early.
>
> Anyway, this is straitghtforward change, so no one should notice anything
> (apart from one commit with, hopefully, useful description in their
> repositories) 
Thank you Igor. When you get a chance, would you also update the spec
guideline as well?
-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net



0xD8A2609A.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Jonathan Wakely]

On 15/02/18 08:46 -0500, David Cantrell wrote:

First, I actually don't care if this change is made or not.  My personal
opinion is that it's a nice-to-have cleanup that will probably not cause
problems, but you never know with that many packages.  So that's why I
feel it should be approached using pull requests.  We have that
functionality now thanks to Pagure, which is something we *never* had in
dist-cvs or the former git system.  Is that tedious?  Yeah, it is.  But
pushing a change like that across many packages will not necessarily
explain to package maintainers why that was done.  If packages have not
been cleaned up in that amount of time and things are still building, I
question the urgency of the change.  Pull requests give package
maintainers an opportunity to be part of this change.  Others have
pointed this out too.  Otherwise things like this will likely continue
happening and package maintainers will overwhelming remain in the dark
about what changes should be made in spec files.


What's the real benefit to getting each maintainer to remove the tag
themselves via a pull request? After they get the pull request and
understand the motivation they now know about something that should
not be in their spec files. Is it really necessary for them to know a
negative? Should they also remember a list of other tags that
shouldn't be in there, or should we just remove the cruft, make sure
the docs, examples and templates don't have those tags, and move on?

Remaining in the dark about a tag that has no meaning doesn't seem
harmful.


I recognize the work is difficult and time consuming.


But removing a useless tag from spec files shouldn't be difficult and
time consuming. One of Fedora's most productive and valuable
maintainers is working on this, and you want to make it more difficult
and slow him down?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Jonathan Wakely]

On 15/02/18 08:52 -0500, David Cantrell wrote:

Does it actually hurt or is it just unnecessary?  Removing unnecessary
things from spec files is fine with me, but I was not seeing this as
actually breaking things at the moment.  If BuildRoot lines have been in
spec files for 10+ years and we are still building fine, is this really
urgent or is it a nice to have?


If it's not urgent does that mean it shouldn't happen? If not now,
when? Is March non-urgent change month? Is another 10 years the right time?

Personally I think right before a mass rebuild is a good time to do
such things, because we're re-verifying everything builds. Until every
package is in Koschei we have a big problem with packages bitrotting
and FTBFS going unnoticed for months.


Not trying to speak for others here, but I have seen posts where package
maintainers are annoyed by proven packager commits that touch a lot of
packages.  If we want the old timers to stop using unnecessary
boilerplate, we should loop them in to that change.  A pull request does
exactly that.  I get pull requests for spec cleanups from time to time
and I appreciate it.  The comment from the author usually explains why
and sometimes even points to the current policy.  This is great because
otherwise I am not going to go and reread the policy for packages I have
already created and currently maintain.


Somebody who maintains 10 packages might get 10 pull requests, but you
only need to loop them in once. Email does it once.

If a maintainer doesn't care why it was done, they don't even need to
read the email. "Oh, somebody removed a line from the spec, but it
still builds ... I guess they knew what they were doing."


Maybe we could also do re-reviews for packages that have existed for a
long time and make sure they comply with current packaging policies?


Do we have the resources to do that?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1543336] please provide missing Fedora 27 Perl modules

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1543336

Petr Pisar  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1545816



--- Comment #19 from Petr Pisar  ---
Bug #1545816 is perl-CryptX review.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Miroslav Suchý]

Dne 14.2.2018 v 21:59 Igor Gnatenko napsal(a):
> msuchy abrt satyr

* You should not touch because I done the change in upstream, it will be 
propagated during next release.

Miroslav



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Self-introduction: Kaushal

[Kaushal M]

Hi all,

I've just been accepted into the packagers group, so that I can submit
and maintain a few packages. For anyone wondering why though, here's a
small introduction about me.

I'm Kaushal. I'm a developer who works out of Mysuru, India. I'm one
of the maintainers of the GlusterFS project [1], where I maintain the
distributed management framework, Glusterd.

We in the Gluster project, are developing a new version of the
management framework, called GlusterD2 (GD2) [2], which is scheduled
for release with the upcoming Gluster-4.0 release.

GD2 is a Golang application and is developed in a seperate tree from
GlusterFS. This is where me becoming a packager comes in.

I will be maintaining the glusterd2 Fedora package, and its required
dependencies. The main GD2 package [3] is still under-review. At the
moment I'm working on getting its dependencies update or added to the
packages. I know this is not an easy task, but I hope I can depend on
your assistance when needed.

I hope I enjoy my stay here.
Thanks!

~kaushal

[1]: https://www.gluster.org
[2]: https://github.com/gluster/glusterd2
[3]: https://bugzilla.redhat.com/1540553
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[David Shea]

> Determinism level is about level of *variations* of the results on
> repeating the same operations starting from exactly the same initial state.
> Executing ldconfig after each package libraries installation/upgrade or
> executing the same ldconfig only one time after install/upgrade libraries
> batch still produces *exactly* the same final result. It does not change
> anything in context of reliability as well.

The fact that ldconfig is being executed by an arbitrary, user-written shell 
script is exactly what makes it non-introspectable and non-deterministic. 
Running %post -p /sbin/ldconfig is the most common case, but it might also be 
part of a larger %post/%postun script. It might be in a conditional. It might 
be expanded from another macro. It might be executed by a helper script. It 
might be executed from lua. And since shell (and lua) is a turing complete 
language, and since on top of that the scripts can be modified by arbitrary 
macros that can only be evaluated by executing every shell script embedded in a 
spec file, it's impossible to look at a spec file and determine exactly what it 
is doing, and exactly what it is doing is dependent upon the environment.

Can we maybe step back and give other developers the benefit of the doubt 
instead of immediately attacking an attempt to provide information? This is 
really unnecessarily hostile. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Robert-André Mauchin]

On mercredi 14 février 2018 21:59:27 CET Igor Gnatenko wrote:
> * Tell package names you want to remove ldconfig scriptlets entirely instead
> of replacing them with %ldconfig_scriptlets and get fix **for free**.

I wish you remove the scriplets entirely for Rawhide only on my packages:

eclipseo   cmrt libfilteraudio toxcore webkit2-sharp

Thanks!

Robert-André.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 946  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 836  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 808  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 419  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 148  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  67  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  49  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
  39  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  34  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc6e2820ab   
tomcat-7.0.84-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc1949f307   
p7zip-16.02-10.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

clamav-0.99.3-8.el6
exim-4.90.1-1.el6
fedpkg-1.31-5.el6

Details about builds:



 clamav-0.99.3-8.el6 (FEDORA-EPEL-2018-be69c94866)
 Anti-virus software

Update Information:

reverting clamav el6 to old state and update to 0.99.3    ClamAV 0.99.3
=  This release is a security release and is recommended for all
ClamAV users.  Please see details below:   1. ClamAV UAF (use-after-free)
Vulnerabilities (CVE-2017-12374)
---  The ClamAV
AntiVirus software versions 0.99.2 and prior contain a vulnerability that could
allow an unauthenticated, remote attacker to cause a denial of service (DoS)
condition on an affected device.  The vulnerability is due to a lack of input
validation checking mechanisms during certain mail parsing operations. If
successfully exploited, the ClamAV software could allow a variable pointing to
the mail body which could cause a used after being free (use-after-free)
instance which may lead to a disruption of services on an affected device to
include a denial of service condition.*
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H   *
https://bugzilla.clamav.net/show_bug.cgi?id=11939   2. ClamAV Buffer Overflow
Vulnerability (CVE-2017-12375)
  The ClamAV AntiVirus
software versions 0.99.2 and prior contain a vulnerability that could allow an
unauthenticated, remote attacker to cause a denial of service (DoS) condition on
an affected device.  The vulnerability is due to a lack of input validation
checking mechanisms during certain mail parsing functions. An unauthenticated,
remote attacker could exploit this vulnerability by sending a crafted email to
the affected device. This action could cause a buffer overflow condition when
ClamAV scans the malicious email, allowing the attacker to potentially cause a
DoS condition on an affected device.*
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N /A:L   *
https://bugzilla.clamav.net/show_bug.cgi?id=11940   3. ClamAV Buffer Overflow in
handle_pdfname Vulnerability (CVE-2017-12376)
--
ClamAV AntiVirus software versions 0.99.2 and prior contain a vulnerability that
could allow an unauthenticated, remote attacker to cause a denial of service
(DoS) condition or potentially execute arbitrary code on an affected device.
The vulnerability is due to improper input validation checking mechanisms when
handling Portable Document Format (.pdf) files sent to an affected device. An
unauthenticated, remote attacker could exploit this vulnerability by sending a
crafted .pdf file to an affected device. This action could cause a buffer
overflow when ClamAV scans the malicious file, allowing the attacker to cause a
DoS condition or potentially execute arbitrary code.*
https://bugzilla.clamav.net/show_bug.cgi?id=11942   *
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H   4. ClamAV Mew Packet Heap
Overflow Vulnerability (CVE-2017-12377)
-  ClamAV
AntiVirus software versions 0.99.2 and prior contain a vulnerability that could
allow an unauthenticated, remote attacker to cause a denial of service (DoS)
condition or potentially execute arbitrary code on an affected device.  The
vulnerability is due to improper input validation checking mechanisms in mew
packet files sent to an affected device. A successful exploit could cause a heap
overflow condition 

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Tomasz Kłoczko]

On 14 February 2018 at 23:26, Will Woods  wrote:
[..]

> I don't think this single change will make a huge difference within
> the existing ecosystem, but I think it's an important step in a larger
> shift toward make package installation & image composition a)
> introspectable and b) deterministic, so that we _can_ make
> installs/composes faster and more reliable.
>

No offence but are you sure that you know meaning of the words which you
are trying to use?
Longer install time still provides *exactly* the same determinism level as
shorter install time.
Determinism level is about level of *variations* of the results on
repeating the same operations starting from exactly the same initial state.
Executing ldconfig after each package libraries installation/upgrade or
executing the same ldconfig only one time after install/upgrade libraries
batch still produces *exactly* the same final result. It does not change
anything in context of reliability as well.
And .. "introspectable" -> capable of being observed by introspection.
http://www.learnersdictionary.com/definition/introspection

In other words: replace per package scriplets with ldconfig execution and
replace it by per whole transaction of packages operations one time
executed ldconfig has nothing to do with introspectability, determinism or
reliability.
It is only about total *time* of whole transaction in context of use
packages without such scriptlets .. only this and nothing more.
Remove those scriplets provides additionally *simpler/shorter* packages
spec files.

[1] If you want to know more about the proposed Scriptlet Reforms you
> could watch the recording from DevConf:
> https://www.youtube.com/watch?v=kE-8ZRISFqA#t=2m33


It is funny and at the same time really creepy to see someone who is trying
to explain "scriptlets reform" by someone who doesn't know that there are
other packaging software which have *NO packages scriptlrts at all* (look:
IPS).

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Miro Hrončok]

On 15.2.2018 10:17, Michal Novotny wrote:
I feel PRs are better for this sort of stuff. Mainly because people are 
informed why exactly this change is made,
they can read the guidelines and then merge the change when they are 
sure they understand it. It helps spreading knowledge
and keeping community involved. Python team did it very well in their 
"Fedora's Switch to Python 3 effort 
", i think.


We tried to be nice, but honestly I think it's too much effort. Some 
fake numbers (i.e. no actual stats, but rather how I feel it):


 * ~49% goes without reply and is merged by our proven packager after 
the announced 14 days

 * ~48% is merged right away
 * ~1% says: oh we've already done this in our upstream repo and it 
will propagate

 * ~1% says: please do it in our upstream repo and later it will propagate
 * ~1% says: your are destroying my life
 * ~0.1% says: here's an actual mistake

Since I consider the upstream repo thing against the guidelines, the 
outcome here is that we are burning precious time of people who 
semi-automatically create, test, manage, watch and merge, comment etc. 
on the PRs as well as the time of the packagers who receive those PRs. 
Mass committing/pushing the change would have been much easier.


We'll definitively consider doing this in another way next time.

(An automation of merging those PR would help as well, see [1].)

[1] https://pagure.io/pagure/issue/2926


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1543336] please provide missing Fedora 27 Perl modules

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1543336



--- Comment #18 from Petr Pisar  ---
It looks like 0.053 can be packaged if I disable ECC support. I will try that
and put the package on review.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Randy Barlow]

On 02/15/2018 02:11 AM, Vít Ondruch wrote:
>> Sadly, commit notifications does NOT work for months
>> (works for old packages, not for newly imported one)
> 
> It does not work at all. I did not get any notification about mass
> rebuild changes what so ever. No build notifications, no commit
> notifications, anything ...

There is an open issue about this:

https://github.com/fedora-infra/fmn/issues/275



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1545652] perl-XML-SAX-1.00 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1545652

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-XML-SAX-1.00-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-15 09:10:23



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[David Cantrell]

On 02/15/2018 03:08 AM, Panu Matilainen wrote:
> On 02/14/2018 11:27 PM, David Cantrell wrote:
>> On 02/14/2018 02:41 PM, Igor Gnatenko wrote:
>>> On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
 On 02/14/2018 11:44 AM, Remi Collet wrote:
> Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
>> Just a small heads up, ...
>
>
> As I said on IRC
>
> - waste of time
> - waste of energy
> - absolutely no value
>
> And
>
> - abuse proven packager privileges
>>>
 +1
>>>
>>> Ralf, Remi, David,
>>>
>>> Please, read policy[0] once more.
>>>
 Sometimes there are situations where it's simply a lot easier to fix
 stuff
>>> directly in Git than via bugzilla and the proper maintainers. So much
>>> easier
>>> that we should leave this path open. These situations shouldn't arise
>>> that
>>> often. Some examples of situations were bypassing the proper
>>> maintained is
>>> considered fine:
 […]
 * small fixes or adjustments for new or modified packaging
>>> guidelines can be done directly in Git after being announced some days
>>> in advance.
>>>
>>> I just missed waiting for few days (kinda intentionally), because it
>>> would not
>>> help anyone and will just disturb maintainers to do the actual work
>>> whereas it
>>> doesn't make any sense because cleanup is automated.
>>>
>>>
>>> [0]
>>> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Mino
>>>
>>> r.2C_general_or_cleanup_changes
>>>
>>
>> I am not disputing the policy.  I feel this change is pointless and is a
>> lot of commits for no real benefit.  They are not fixes.  You're just
>> scrubbing spec files that are not broken.  Who cares?  Update the
>> packaging policy and be done with it.  Leaving this tag there hurts
>> nothing.
>>
>> It's also worth noting that Pagure gives us pull requests for these sort
>> of changes.  While a proven packager can drive a monster truck through
>> the package repositories unchecked, the nice thing to do in the
>> community is to bring the issue to the attention of the package
>> maintainer and let them handle it.  Pagure lets you send pull requests
>> for this (you can even automate it) and then leave it with the package
>> maintainer to take or ignore on their own.
>>
>> Just because we have removed something like the BuildRoot tag from the
>> packaging policy does not automatically invalidate every existing spec
>> file.
> 
> I can't believe what I'm seeing here.
> 
> That old unused cruft hurts because old like Igor said, new people will
> copy it over to new specs thinking this is some magic necessary
> incantation (which is once was but no longer is). And no doubt some old
> timers might not be aware that it's no longer needed and/or still add it
> just out of habit, spreading the disease.

Does it actually hurt or is it just unnecessary?  Removing unnecessary
things from spec files is fine with me, but I was not seeing this as
actually breaking things at the moment.  If BuildRoot lines have been in
spec files for 10+ years and we are still building fine, is this really
urgent or is it a nice to have?

> At the same time people love to complain how much stupid boilerplate
> stuff there is in every spec. Well hello, BuildRoot was made unnecessary
> in rpm almost ten years ago, the packaging policy for Fedora already
> updated accordingly many years ago, the last EL version requiring it
> finally EOL'ed. And yet people have the nerve to complain when somebody
> voluntarily cleans up this useless cryptic crap from their spec files!

Not trying to speak for others here, but I have seen posts where package
maintainers are annoyed by proven packager commits that touch a lot of
packages.  If we want the old timers to stop using unnecessary
boilerplate, we should loop them in to that change.  A pull request does
exactly that.  I get pull requests for spec cleanups from time to time
and I appreciate it.  The comment from the author usually explains why
and sometimes even points to the current policy.  This is great because
otherwise I am not going to go and reread the policy for packages I have
already created and currently maintain.

Maybe we could also do re-reviews for packages that have existed for a
long time and make sure they comply with current packaging policies?
Another way to loop in the maintainers.

Thanks,

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[David Cantrell]

On 02/14/2018 04:47 PM, Reindl Harald wrote:
> Am 14.02.2018 um 22:27 schrieb David Cantrell:
>> I am not disputing the policy.  I feel this change is pointless and is a
>> lot of commits for no real benefit.  They are not fixes.  You're just
>> scrubbing spec files that are not broken.  Who cares?  Update the
>> packaging policy and be done with it
> 
> yeah, that's how most rpm-specs in Fedora look like "who cares, it works
> somehow, i can live with the mess" - for packages where i decided to
> start maintain them on my own i started with remove evrything i don't
> understand why it is needed and a large part of the specs was just gone
> and the remaining ones are clear
> 
> WTF - instead say thank you that somebody *does something* in Fedora
> instead talking and write pointless guidelines nobody seems to care
> about in the project  a view people are pissed that he did the work teey
> should have been done long before as maintainer - seriously?

I'll back up.  I combined both my opinion of the change itself and how I
feel the change should be approached in Fedora.

First, I actually don't care if this change is made or not.  My personal
opinion is that it's a nice-to-have cleanup that will probably not cause
problems, but you never know with that many packages.  So that's why I
feel it should be approached using pull requests.  We have that
functionality now thanks to Pagure, which is something we *never* had in
dist-cvs or the former git system.  Is that tedious?  Yeah, it is.  But
pushing a change like that across many packages will not necessarily
explain to package maintainers why that was done.  If packages have not
been cleaned up in that amount of time and things are still building, I
question the urgency of the change.  Pull requests give package
maintainers an opportunity to be part of this change.  Others have
pointed this out too.  Otherwise things like this will likely continue
happening and package maintainers will overwhelming remain in the dark
about what changes should be made in spec files.

I recognize the work is difficult and time consuming.

Again, this is my own opinion on how to approach the matter and however
it is ultimately handled is fine with me.

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1543336] please provide missing Fedora 27 Perl modules

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1543336



--- Comment #17 from Petr Pisar  ---
I don't think this ever happen. CryptX author always develops on his
libtomcrypt fork. I'd rather try packaging an older CryptX version that could
work with upstream libtomcrypt. I don't think it's wise to bundle, especially a
cryptographic library.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Rex Dieter]

Michal Novotny wrote:

> I feel PRs are better for this sort of stuff.

In theory yes.  In practice (in my experience so far), it's still not very 
practical to go through the process of:
* fork
* commit
* file PR
for anything more than a handful of packages.

Unless, anyone knows of a way to (semi?)automate the step of forking, 
besides going through pagure web UI with quite a few clicks and waiting.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1545652] New: perl-XML-SAX-1.00 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1545652

Bug ID: 1545652
   Summary: perl-XML-SAX-1.00 is available
   Product: Fedora
   Version: rawhide
 Component: perl-XML-SAX
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
caol...@redhat.com, john.j5l...@gmail.com,
jples...@redhat.com, ka...@ucw.cz,
mbar...@fastmail.com,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com



Latest upstream release: 1.00
Current version/release in rawhide: 0.99-21.fc28
URL: http://search.cpan.org/dist/XML-SAX/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3534/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Usefulness of `copr mock-config ` feature?

[Michael Šimáček]

On 2018-02-13 21:51, Michal Novotny wrote:

Hello,

On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček > wrote:


On 2018-02-13 11:47, Pavel Raiskup wrote:

Sorry, I wanted to CC fedora devel before, forwarding.

Pavel

On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:

Because we are unable to find a consensus on implementation
details, it's
likely we'll drop this feature from copr API and it will be
probably a bit
more complicated to setup mock chroot for local tests in
future (you'll
need to have builder machine with copr-rpmbuild installed,
which brings a
lot more runtime dependencies at least).

  From user perspective, do you mind if we dropped `copr
mock-config` command?


I didn't know this command existed, but there were multiple times in
the past where I wished something like this had been available (It
didn't exist back then). It was usually situation like this: "Hi,
I'm trying to build $package in $copr and it fails because of
$build_tool that you maintain, can you help me?". And since I had no
idea how his copr was set up, it took me a lot of time before I was
able to reproduce the problem. So, I would find the feature useful,
especially in instances outside Fedora, which usually have more
complex configurations.
If it had to be dropped, I'd appreciate if copr could display the
configuration of given project for non-owners. That way it would be
easier to construct my own config, without trying to guess stuff
based on the logs.


First, thanks for your input. This is very useful information for us. 
Next, I would like to ask if it was ok to put all the functionality 
about build-testing and building itself into just a single package: 
copr-rpmbuild. I think having things on just one place can help us focus 
on doing them really well and as the copr-rpmbuild tool is already 
responsible for building, I think it would be a perfect place to add 
additional build-debugging functionality like printing-out/dumping mock 
configs, enablement to run just a part of the build process, possibility 
to enter the build environment interactively etc. Would this be alright?




Yes, that would work for me. I don't mind additional deps.

Thank you,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC 8: camotics fails to build for i686, ARMv7 arches (reading 31 bytes from a region of size 16)

[Jonathan Wakely]

On 15/02/18 07:05 -, Samuel Rakitničan wrote:

Hello,

Need help figuring this out since I have no idea what this means.


It means the package should probably not be using -Werror


The cbang code that is included in camotics fails to build with the following 
messages. It is failing only for i686 and armv7hl architectures.


So presumably some structure is smaller on 32-bit targets than the
code expects.



g++ -o build/cbang/log/Logger.o -c -std=c++11 -ggdb -Wall -Werror 
-I/usr/include/v8-3.14/ -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
-fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection 
-Wno-error=parentheses -Wno-deprecated-declarations -DDEBUG -D_REENTRANT 
-DHAVE_EXPAT -DHAVE_PTHREADS -DHAVE_LIBSQLITE -DHAVE_V8 -DDEBUG_LEVEL=1 
-DUSING_CBANG -Iinclude -Isrc -Isrc/boost src/cbang/log/Logger.cpp
In file included from /usr/include/string.h:494,
from src/boost/boost/range/detail/implementation_help.hpp:18,
from src/boost/boost/range/end.hpp:24,
from src/boost/boost/range/functions.hpp:19,
from src/boost/boost/range/iterator_range_core.hpp:38,
from src/boost/boost/range/iterator_range.hpp:13,
from src/boost/boost/iostreams/traits.hpp:38,
from src/boost/boost/iostreams/detail/dispatch.hpp:17,
from src/boost/boost/iostreams/flush.hpp:17,
from src/boost/boost/iostreams/close.hpp:18,
from src/boost/boost/iostreams/operations.hpp:16,
from src/cbang/http/ChunkedStreamFilter.h:41,
from src/cbang/http/Transaction.h:37,
from src/cbang/http/Transaction.cpp:33:
In function 'void* memcpy(void*, const void*, size_t)',
   inlined from 'std::streamsize cb::HTTP::ChunkedStreamFilter::write(Sink&, const char*, 
std::streamsize) [with Sink = boost::iostreams::detail::linked_streambuf]' at src/cbang/http/ChunkedStreamFilter.h:131:19,


This code looks like:

   std::string l = String((uint64_t)n);
   writeLengthBytes = l.length() < 31 ? l.length() : 31;
   memcpy(writeLength, l.c_str(), writeLengthBytes);
   writeLength[writeLengthBytes] = 0;

That should be OK. It reads no more than l.length() from l.c_str(),
which doesn't overflow, but it says:


/usr/include/bits/string_fortified.h:34:33: error: 'void* 
__builtin_memcpy(void*, const void*, unsigned int)' reading 31 bytes from a 
region of size 16 [-Werror=stringop-overflow=]
  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
 ~~~^~~


This might be a GCC bug. We'll need the preprocessed source file
Transaction.ii to analyze it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New "tests" namespace to share test code

[Petr Šplíchal]

On 14 February 2018 at 18:18, Adam Williamson
 wrote:
> On Wed, 2018-02-14 at 17:28 +0100, Petr Šplíchal wrote:
>> Hi!
>>
>> During the last days there have been concerns raised regarding
>> what is an appropriate content for the tests namespace. [1] My
>> original idea was to enable sharing tests even across branches
>> of the same component, not only for tests to be used by
>> completely different packages. The initial examples might have
>> been a bit misleading in this respect. One of the main points
>> still holds:
>>
>> >  * Tests might follow a different branching pattern than the
>> >  dist-git repo, leading to code duplication
>>
>> From the feedback from developers I feel they always keep on
>> mind and care a lot about the maintenance costs. So it
>> perfectly makes sense to me if they want to keep and maintain
>> tests in a separate repo instead of merging/cherry-picking
>> between dist-git branches.
>>
>> When, for a particular package, it is the most efficient way to
>> maintain tests in a separate repo why should we discourage from
>> this approach? There are packages where it makes more sense to
>> store test code directly in dist-git. And it is still an
>> option.  But why should we enforce this for all?
>>
>> Please share your thoughts and real-life examples. For those
>> who are not familiar with the topic there is a new wiki page
>> with a summary of the Share Test Code approach [2].
>
> I don't have any problem with the concept *in itself*; in fact I
> know of another reason to have something like it. That is
> 'generic' tests, tests we want to run on all packages, or at
> least a very large set of packages - like the tests currently
> running in Taskotron, which are generally run on all packages
> (rpmgrill, rpmdeplint...) or a large subset (the Python tests).

Yes, sharing tests useful for multiple packages makes sense in
general. Test code for generic tests can be stored basically
anywhere but not in specific components. However I see some
additional benefits of having a dedicated tests namespace:

* Source of inspiration and real-life examples (at one place)
* Potential for workflow automation (tests CI, fedpkg --tests)
* Easy cherry-picking/backporting upstream/downstream tests

The difference I see when comparing these shared tests to generic
tests mentioned above like rpmdeplint is that you don't want to
reference these from the individual package repos (e.g. using the
Standard Test Interface), but just run them on all packages.

If the expectation is to run tests only on a subset of rpms then a
question comes: How to store the list of relevant components or
criteria to decide which packages are to be tested or not. Here
the Flexible Metadata Format might come handy in the future:

https://github.com/psss/fmf

> What I did think was maybe a concern is that we should figure
> out in advance the squishy human consequences of different
> technical approaches.
>
> Basically this boiled down to "who is responsible for these
> 'shared' tests, and who gets to decide which 'shared' tests
> can/should block packages?"
>
> Looking at the proposal, I think it actually has at least
> workable initial explicit/implicit answers to this, if I'm
> reading it correctly.  Anyone can create a shared test
> repository (and is therefore "responsible" for maintaining it),
> but the definition of which tests are run on which packages
> remains in the package repositories. Thus the package
> maintainer(s) retain the ultimate choice over which tests are
> run against their packages (and thus can pick which shared tests
> are run, and disable shared tests if they are no longer properly
> testing their package).

Yes. This is exactly true. The maintainer of the package repo has
always the last word on what is to be executed for qualification.
It can be done by referencing only suitable tests from the shared
repo or selecting an appropriate branch or even a specific commit
to ensure that future test development does not break stable
gating (and only manually update reference after review of shared
test updates) or even completely disable tests by removing the
reference.

> The question 'who decides which tests block which packages' is
> left a bit up in the air, but in fact no more so than it already
> was for package-specific tests...

Right. Do we want to change this? Specify this more strictly?
Like exactly defining requirements which an Always Ready Operating
System has to meet? And then mapping these requirements to the
test coverage? (Here again FMF mentioned above might come handy.)

psss...

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libevent-2.1.8 SONAME change.

[Peter Robinson]

On Thu, Feb 15, 2018 at 11:51 AM, Steve Dickson  wrote:
> Hello,
>
> Yesterday I updated libevent to the latest upstream release.
>
> I mistakenly did not realized there was a SONAME change
> in this update. So if your package is dependent on
> libevent, you are going to have to rebuild.
>
> My apologies for this oversight...

Specifying major version numbers in the library files (extract below)
will ensure a build failure when the soname bumps to ensure this
doesn't happen and that you're aware of it can do do appropriate
communication/side tag builds/etc so it doesn't break rawhide for
everyone else that's trying to get things done in the future.

%{_libdir}/libevent-*.so.*
%{_libdir}/libevent_core-*.so.*
%{_libdir}/libevent_extra-*.so.*
%{_libdir}/libevent_openssl-*.so.*
%{_libdir}/libevent_pthreads-*.so.*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1479864] Upgrade perl-Net-SSH-Perl to 2.12

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1479864

Paul Howarth  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1543336



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1543336] please provide missing Fedora 27 Perl modules

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1543336

Paul Howarth  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1479864



--- Comment #16 from Paul Howarth  ---
(In reply to Jitka Plesnikova from comment #15)
> The other packages are owned by different users and I don't want to maintain
> EPEL 7 branches for them. 
> 
> FAS: ixs
>  perl-Crypt-Blowfish
> 
> FAS: berrange
>  perl-Test-YAML-Meta
> 
> FAS: pghmcfc
>  perl-Net-SSH-Perl
>  perl-Crypt-RSA
>  perl-Math-Pari
>  perl-Text-SpellChecker
>  perl-Class-Loader
>  perl-Crypt-Primes
>  perl-Crypt-Random
>  perl-Tie-EncryptedHash

None of these (apart from perl-Net-SSH-Perl) are needed if we get perl-CryptX
and the new version of Net-SSH-Perl that uses it.

Given that CryptX is bundling a patched version of libtomcrypt, I think it's
viable to create a perl-CryptX package that includes the bundled libtomcrypt
(with Provides: bundled(libtomcrypt) = 1.18) until such time as the differences
are merged upstream. Anyone disagree?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

libevent-2.1.8 SONAME change.

[Steve Dickson]

Hello,

Yesterday I updated libevent to the latest upstream release.

I mistakenly did not realized there was a SONAME change
in this update. So if your package is dependent on 
libevent, you are going to have to rebuild. 

My apologies for this oversight... 

steved.
  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Michal Novotny]

On Thu, Feb 15, 2018 at 10:36 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Thu, 2018-02-15 at 10:17 +0100, Michal Novotny wrote:
> > I feel PRs are better for this sort of stuff. Mainly because people are
> > informed why exactly this change is made,
> > they can read the guidelines and then merge the change when they are sure
> > they understand it. It helps spreading knowledge
> > and keeping community involved. Python team did it very well in their
> > "Fedora's
> > Switch to Python 3 effort
> > ", i
> think.
>
> Python changes are needed to be carefully inspected while this thing is
> about
> removing **single line** which is not needed for **10 years**. Also
> guidelines
> for Python changed recently while BuildRoot tag is not needed for many
> years
> and everyone should be aware of that.
>
Also look what's the progress of python→python2. It's not close to complete
> in
> any way. Most of PRs are opened and no one looks into them.
>

As far as I know, they are going to auto-merge the PR after some period of
time,
which is probably a pretty good solution.


>
> > There are other reasons too. Some projects might keep the original spec
> > file somewhere
> > else than in DistGit and they need to port those changes back to the
> > original spec files. It is much more pleasant to have those
> > changes placed in a PR with a relevant description, which will also give
> > them a proper notification. Otherwise, they might end
> > up solving some unexpected conflicts next time they import their new spec
> > files into DistGit.
>
> You probably not aware, but we have guidelines about exactly this thing[0].
> > Fedora's git repository is the canonical location for Fedora spec files.
> Maintainers MUST expect that other maintainers and automated tooling will
> make
> changes to their packages, potentially without communicating prior to
> doing so
> (though communication is always encouraged). If some maintainers are also
> attempting to keep copies of a spec in an outside repository, they MUST be
> prepared to merge changes made to the spec in Fedora's repository, and
> MUST NOT
> overwrite those changes with a copy from an external repository or using
> fedpkg
> import.
>

I am overwriting changes in %changelog from auto-rebuilds all the time
because I don't
really want messages in %changelog like:

"Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild;

I think that by PRs (that would get automatically merged after some time)
more could be actually achieved in a long run. If you make a PR and you give
it a good description, it will probably reach more people. But I admit it's
more
difficult to do than a single commit.


>
> > Maybe it would be nice if proven packagers had some tooling for doing
> those
> > changes.
>
> If you will develop one, we could talk about it 
>
> [0] https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Mai
> ntenance_and_Ca
> nonicity
> >
> > clime
> >
> > On Thu, Feb 15, 2018 at 9:34 AM, Miroslav Suchý 
> wrote:
> >
> > > Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a):
> > > > On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
> > > > > On 02/14/2018 11:44 AM, Remi Collet wrote:
> > > > > > - abuse proven packager privileges
> > > > >
> > > > > +1
> > >
> > > +1
> > >
> > > > Please, read policy[0] once more.
> > > >
> > > > > Sometimes there are situations where it's simply a lot easier to
> fix
> > >
> > > stuff
> > > > directly in Git than via bugzilla and the proper maintainers. So much
> > >
> > > easier
> > > > that we should leave this path open. These situations shouldn't arise
> > >
> > > that
> > > > often. Some examples of situations were bypassing the proper
> maintained
> > >
> > > is
> > > > considered fine:
> > > > > […]
> > > > > * small fixes or adjustments for new or modified packaging
> > > >
> > > > guidelines can be done directly in Git after being announced some
> days
> > > > in advance.
> > > >
> > > > I just missed waiting for few days (kinda intentionally), because it
> > >
> > > would not
> > > > help anyone and will just disturb maintainers to do the actual work
> > >
> > > whereas it
> > > > doesn't make any sense because cleanup is automated.
> > >
> > > It state:
> > > fixes or adjustments for **new or modified** packaging guidelines
> > >
> > > This is obviously meant for changes, which would block progress.
> Change of
> > > BuildRoot tag is pretty old. It could wait
> > > few more days just fine.
> > >
> > >
> > > Miroslav
> > >
> > >
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > >
> > >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email 

Re: RFC: BugURL in packages

[Miroslav Suchý]

Dne 15.2.2018 v 12:09 Vít Ondruch napsal(a):
> Good you mention it. But probably adding RH bugzilla there does not make 
> sense, because hopefully everybody knows and it
> should be the default.

Nope. I think even some power users will have to look hard for the right URL.

> But it could be utilized by packages, whose maintainers notoriously ignore RH 
> bugzilla (Gnome
> components comes to my mind).

Can we have this defined by Mock/Koji/Copr and let package maintainers override 
it (e.g., to point to upstream, the
Gnome is good example)?

Miroslav



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: BugURL in packages

[Vít Ondruch]

Good you mention it. But probably adding RH bugzilla there does not make
sense, because hopefully everybody knows and it should be the default.
But it could be utilized by packages, whose maintainers notoriously
ignore RH bugzilla (Gnome components comes to my mind).

Vít


Dne 15.2.2018 v 11:22 Igor Gnatenko napsal(a):
> Hello,
>
> it's been just 9 years since BugURL has been added to RPM, but it has
> not been
> used.
>
> I think it would be helpful for users to have it defined in RPMs, so
> when they
> do `dnf info`, `rpm -qi` they would just click on it and it would
> select right
> component, right version and such for it.
>
> Do you think same way? If so, which URL should we put there?
> ___ > devel mailing list -- 
> devel@lists.fedoraproject.org > To unsubscribe
send an email to devel-le...@lists.fedoraproject.org



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: BugURL in packages

[Fabio Valentini]

On Feb 15, 2018 11:52, "Pierre-Yves Chibon"  wrote:

On Thu, Feb 15, 2018 at 11:22:27AM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello,
>
> it's been just 9 years since BugURL has been added to RPM, but it has not
been
> used.
>
> I think it would be helpful for users to have it defined in RPMs, so when
they
> do `dnf info`, `rpm -qi` they would just click on it and it would select
right
> component, right version and such for it.
>
> Do you think same way? If so, which URL should we put there?

I think bugz.fedoraproject.org/ is potentially a good url to
use
for this.


Linking to fedora bugzilla was my first "instinct". However, it is
completely redundant and doesn't add any new information to the package,
since it's the same URL for every package in fedora. Additionally, such
URLs don't even work right now (certificate errors and 404s, at least for
me).

In contrast, adding a link to upstream bug tracking (which is actually
different
everywhere) would provide useful additional  information.

Fabio


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

9.02.2018 11:34 Rafal Luzynski  wrote:
> [...]
> Please:
> - backport the solution to F26 and F27 as well, this should be much
> easier than in F28 (my pull requests may be helpful),
> - mark my pull requests as merged/obsolete/whatever is appropriate,
> - mark the bugzilla tickets as fixed (hopefully this is automatic).

PING

Any chance to fix compat-gcc-34 in F27 and F26 as well? Pull requests
have been waiting for about 1.5 months now.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: BugURL in packages

[Pierre-Yves Chibon]

On Thu, Feb 15, 2018 at 11:22:27AM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hello,
> 
> it's been just 9 years since BugURL has been added to RPM, but it has not been
> used.
> 
> I think it would be helpful for users to have it defined in RPMs, so when they
> do `dnf info`, `rpm -qi` they would just click on it and it would select right
> component, right version and such for it.
> 
> Do you think same way? If so, which URL should we put there?

I think bugz.fedoraproject.org/ is potentially a good url to use
for this.

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Unannounced soname bump in libevent

[Vít Ondruch]

It appears that yesterday build of libevent bumped its soname. That
means that, at minimum, Memcahed is broken now.

BTW it is well possible, that the packager did not noticed the soname
bump, since the libraries are included into package by wildcards in
files section [1]. I consider this bad practice precisely due to
consequences like this.


Vít



[1]
https://src.fedoraproject.org/rpms/libevent/blob/master/f/libevent.spec#_104

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: BugURL in packages

[Dominik 'Rathann' Mierzejewski]

On Thursday, 15 February 2018 at 11:22, Igor Gnatenko wrote:
> Hello,
> 
> it's been just 9 years since BugURL has been added to RPM, but it has not been
> used.

Wow! You're right:
$ rpm -q --querytags|grep -i bug
BUGURL

> I think it would be helpful for users to have it defined in RPMs, so when they
> do `dnf info`, `rpm -qi` they would just click on it and it would select right
> component, right version and such for it.
> 
> Do you think same way? If so, which URL should we put there?

Sure. Obviously:

BugURL: https://bugz.fedoraproject.org/%{name}

And this should be added by our rpm config, much like BuildRoot:,
not put in every spec file.

Regards,
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

RFC: BugURL in packages

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

it's been just 9 years since BugURL has been added to RPM, but it has not been
used.

I think it would be helpful for users to have it defined in RPMs, so when they
do `dnf info`, `rpm -qi` they would just click on it and it would select right
component, right version and such for it.

Do you think same way? If so, which URL should we put there?
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqFX2MACgkQaVcUvRu8
X0wB7g//TKeZAueQA8wuY8obJG3puVYQA0DUQxAY0/TUyGGlwxVyhLukHndxVE05
hNV+f7PGxdgyFne8V04K1b/akoNNxezL7jLgSlDk88brG8TG/ihok6y8ynIFKV5r
8lIMpaJ1Yg4PXBvteSMVRD+zX3maOYA0LwmZFsKgrq7FVYE9LeMtZ5hhwyOsw/fU
dKjbvtLZ5OCtsutF8j6NOpAGEaOPa/LKf8ZQZjKC1Q2idurBE13JmY9udc95x+Zp
Z4MX3weBipggBoZBVJc9c8C4ltzj9lqY6SFDYLPuzqGkso91jgfrqCZogPBzD0uI
MPKwUo5J+NAGbHKJ3UA3NsYjlFHKDZpwPNjPjJW1G9dylS4MQYf+7/Ci+vVYdFxW
YZ+kleLpS0p8BI14L64B1yMx4BDzJTkIo7GqRRYQTJr22aW3oEUnM3ZFYmpxnNuP
OPah+lXbaqN1E8xzoIyd62qacQn/WczETyBFzVPvX42nwa/QgECkVCLk/sL/NQvA
fd04q218Cq55tYM2y8OXXzAKHhyVBqTcVdAgKAnPUbXk2N2nwdm9oyBwF+zRAiG1
Y0+idZR/8+jK3IfBZ+Q9DJKOhVZfJntxp99sBXAuSK5pPbOWho2BbbFNK/QVgRpG
tKdgJESO0xXGj9Eg9+FMWUyvx7BQEnTNej5nyhwDULzlEGLvTss=
=A43B
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1501159] Segmentation fault in spawn_proc_prog calling apr_palloc

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1501159



--- Comment #1 from Matti Linnanvuori  ---
I could reproduce this by calling spawn_proc_prog on an old object.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-02-15 at 10:17 +0100, Michal Novotny wrote:
> I feel PRs are better for this sort of stuff. Mainly because people are
> informed why exactly this change is made,
> they can read the guidelines and then merge the change when they are sure
> they understand it. It helps spreading knowledge
> and keeping community involved. Python team did it very well in their
> "Fedora's
> Switch to Python 3 effort
> ", i think.

Python changes are needed to be carefully inspected while this thing is about
removing **single line** which is not needed for **10 years**. Also guidelines
for Python changed recently while BuildRoot tag is not needed for many years
and everyone should be aware of that.

Also look what's the progress of python→python2. It's not close to complete in
any way. Most of PRs are opened and no one looks into them.

> There are other reasons too. Some projects might keep the original spec
> file somewhere
> else than in DistGit and they need to port those changes back to the
> original spec files. It is much more pleasant to have those
> changes placed in a PR with a relevant description, which will also give
> them a proper notification. Otherwise, they might end
> up solving some unexpected conflicts next time they import their new spec
> files into DistGit.

You probably not aware, but we have guidelines about exactly this thing[0].
> Fedora's git repository is the canonical location for Fedora spec files.
Maintainers MUST expect that other maintainers and automated tooling will make
changes to their packages, potentially without communicating prior to doing so
(though communication is always encouraged). If some maintainers are also
attempting to keep copies of a spec in an outside repository, they MUST be
prepared to merge changes made to the spec in Fedora's repository, and MUST NOT
overwrite those changes with a copy from an external repository or using fedpkg
import.

> Maybe it would be nice if proven packagers had some tooling for doing those
> changes.

If you will develop one, we could talk about it 

[0] https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Ca
nonicity
> 
> clime
> 
> On Thu, Feb 15, 2018 at 9:34 AM, Miroslav Suchý  wrote:
> 
> > Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a):
> > > On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
> > > > On 02/14/2018 11:44 AM, Remi Collet wrote:
> > > > > - abuse proven packager privileges
> > > > 
> > > > +1
> > 
> > +1
> > 
> > > Please, read policy[0] once more.
> > > 
> > > > Sometimes there are situations where it's simply a lot easier to fix
> > 
> > stuff
> > > directly in Git than via bugzilla and the proper maintainers. So much
> > 
> > easier
> > > that we should leave this path open. These situations shouldn't arise
> > 
> > that
> > > often. Some examples of situations were bypassing the proper maintained
> > 
> > is
> > > considered fine:
> > > > […]
> > > > * small fixes or adjustments for new or modified packaging
> > > 
> > > guidelines can be done directly in Git after being announced some days
> > > in advance.
> > > 
> > > I just missed waiting for few days (kinda intentionally), because it
> > 
> > would not
> > > help anyone and will just disturb maintainers to do the actual work
> > 
> > whereas it
> > > doesn't make any sense because cleanup is automated.
> > 
> > It state:
> > fixes or adjustments for **new or modified** packaging guidelines
> > 
> > This is obviously meant for changes, which would block progress. Change of
> > BuildRoot tag is pretty old. It could wait
> > few more days just fine.
> > 
> > 
> > Miroslav
> > 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> > 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqFVJMACgkQaVcUvRu8
X0zFxBAAgT91bOniQKMtoWJua4CcEL8jIsyegzER0i4/as/8nahnzHDZkPYtkaEA
89Jtd+RyMacyZ0Pg2Bj/hRuyJWohYp/tDxJP+oP2M36oHrbDr4oyGxGg08f60x3z
SX6RwVtrdBwYPiIczDoOgcxNdE7FuIFRl+KXyvTVAdy8XeLniwZBLN5pRvHp9MMg
f2rzf3Wxz3R61DewegT3/UdQ0CDo30zf2PvWZtQhWBOu99JQqLqbKLBoH/42A1VC
tyRkfpwqMSG6vPzIPjQvDoLyjhF0j51hnYRahoigM3+PFOazHmI4+RCpW2FpUWcB
MLtfWIMaFv3GjQx4WIoDef9Nl7y/2gMLQf7HUCeXYyjc8rGC24RKG9Zkpi3tT5ks
xppLmHQEdpuJWcSN6OknEQAmo+UDeoPtHSCrJFqQngTxCQ72sfFQIcRwHXBO0tTN
y6AJ8kZw91gmQfwIy2e1tf5CXTlfwlIUAWKUEwT24hmLfF8LiOPn6qukrziqB/y4
573cskxhfPumD4JAz95F8aCQheBUaBuXTgTAcL4ZwJi/Xu1v+J1Sip2Nr1GWl891
iVtGMeNlBszJUYdahR/Fg4Ed7mKm/q5o3bifbGVzur6r7reLTozzg0OsxNTXjI9h
h1Pa9zGTWYWF5vXP+KWvZi1BKZoaObSXjpVtuubdBjN/J7SGn1M=
=Ejay
-END PGP SIGNATURE-

Re: Removal of BuildRoot

[Paul Howarth]

On Thu, 15 Feb 2018 08:11:17 +0100
Vít Ondruch  wrote:

> Dne 15.2.2018 v 07:55 Remi Collet napsal(a):
> > Le 15/02/2018 à 07:47, Igor Gnatenko a écrit :  
> >> On Wed, 2018-02-14 at 14:06 -0500, Rob Crittenden wrote:  
> >>> nicolas.mail...@laposte.net wrote:  
>  Hi,
> 
>  Thank you for cleaning up the cruft in the repository !
> 
>  Regards,
>   
> >>> Agreed. I'm usually pretty anal about others touching packages I
> >>> maintain without at least a heads-up but in this case it doesn't
> >>> bother me. I guess particularly since he didn't spin up a build
> >>> or poke the n-v-r so reverting it if I really hated it or it
> >>> broke something would be trivially easy.
> >>> As an aside, it might be nice though to be able to watch a
> >>> package and get automated notifications when things change. I
> >>> don't maintain that many packages though. I'd imagine that for
> >>> some this could be rather onerous, but I had no idea these
> >>> changed were applied until I went and looked.  
> >> It is possible with fedmsg which we use. You can set notifications
> >> in special webservice[0] (although I find settings in it
> >> counter-intuitive). Simplest one is to set up notifications on all
> >> packages you maintain.  
> > Sadly, commit notifications does NOT work for months
> > (works for old packages, not for newly imported one)  
> 
> It does not work at all. I did not get any notification about mass
> rebuild changes what so ever. No build notifications, no commit
> notifications, anything ...

Same here. Whilst I don't mind this change, as it stands I'm getting no
notifications when the packages I maintain are changed by other people,
and that's supposed to be one of the safeguards against potential
errors by provenpackagers.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Michal Novotny]

I feel PRs are better for this sort of stuff. Mainly because people are
informed why exactly this change is made,
they can read the guidelines and then merge the change when they are sure
they understand it. It helps spreading knowledge
and keeping community involved. Python team did it very well in their "Fedora's
Switch to Python 3 effort
", i think.

There are other reasons too. Some projects might keep the original spec
file somewhere
else than in DistGit and they need to port those changes back to the
original spec files. It is much more pleasant to have those
changes placed in a PR with a relevant description, which will also give
them a proper notification. Otherwise, they might end
up solving some unexpected conflicts next time they import their new spec
files into DistGit.

Maybe it would be nice if proven packagers had some tooling for doing those
changes.

clime

On Thu, Feb 15, 2018 at 9:34 AM, Miroslav Suchý  wrote:

> Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a):
> > On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
> >> On 02/14/2018 11:44 AM, Remi Collet wrote:
> >>> - abuse proven packager privileges
> >> +1
> +1
>
> > Please, read policy[0] once more.
> >
> >> Sometimes there are situations where it's simply a lot easier to fix
> stuff
> > directly in Git than via bugzilla and the proper maintainers. So much
> easier
> > that we should leave this path open. These situations shouldn't arise
> that
> > often. Some examples of situations were bypassing the proper maintained
> is
> > considered fine:
> >> […]
> >> * small fixes or adjustments for new or modified packaging
> > guidelines can be done directly in Git after being announced some days
> > in advance.
> >
> > I just missed waiting for few days (kinda intentionally), because it
> would not
> > help anyone and will just disturb maintainers to do the actual work
> whereas it
> > doesn't make any sense because cleanup is automated.
>
> It state:
> fixes or adjustments for **new or modified** packaging guidelines
>
> This is obviously meant for changes, which would block progress. Change of
> BuildRoot tag is pretty old. It could wait
> few more days just fine.
>
>
> Miroslav
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1545467] perl-IPC-Cmd-1.00 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1545467

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-IPC-Cmd-1.00-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-15 04:05:08



--- Comment #1 from Petr Pisar  ---
This is a bug-fix release delivering a workaround for HPUX. I don't like the
workaround so I push it only into Rawhide. If needed this release can be pushed
into older Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Panu Matilainen]

On 02/15/2018 10:34 AM, Miroslav Suchý wrote:

Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a):

On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:

On 02/14/2018 11:44 AM, Remi Collet wrote:

- abuse proven packager privileges

+1

+1


Please, read policy[0] once more.


Sometimes there are situations where it's simply a lot easier to fix stuff

directly in Git than via bugzilla and the proper maintainers. So much easier
that we should leave this path open. These situations shouldn't arise that
often. Some examples of situations were bypassing the proper maintained is
considered fine:

[…]
* small fixes or adjustments for new or modified packaging

guidelines can be done directly in Git after being announced some days
in advance.

I just missed waiting for few days (kinda intentionally), because it would not
help anyone and will just disturb maintainers to do the actual work whereas it
doesn't make any sense because cleanup is automated.


It state:
fixes or adjustments for **new or modified** packaging guidelines

This is obviously meant for changes, which would block progress. Change of 
BuildRoot tag is pretty old. It could wait
few more days just fine.


This is like somebody voluntarily taking out your garbage that's been 
accumulating for years, and you thank by complaining "BUT IT WAS MY 
GARBAGE! IT WAS ONLY FIVE YEARS OLD! IT COULD'VE WAITED A FEW MORE DAYS!"


For deitys sake.

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Miroslav Suchý]

Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a):
> On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
>> On 02/14/2018 11:44 AM, Remi Collet wrote:
>>> - abuse proven packager privileges
>> +1
+1

> Please, read policy[0] once more.
> 
>> Sometimes there are situations where it's simply a lot easier to fix stuff
> directly in Git than via bugzilla and the proper maintainers. So much easier
> that we should leave this path open. These situations shouldn't arise that
> often. Some examples of situations were bypassing the proper maintained is
> considered fine: 
>> […]
>> * small fixes or adjustments for new or modified packaging 
> guidelines can be done directly in Git after being announced some days 
> in advance.
> 
> I just missed waiting for few days (kinda intentionally), because it would not
> help anyone and will just disturb maintainers to do the actual work whereas it
> doesn't make any sense because cleanup is automated.

It state:
fixes or adjustments for **new or modified** packaging guidelines

This is obviously meant for changes, which would block progress. Change of 
BuildRoot tag is pretty old. It could wait
few more days just fine.


Miroslav



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Panu Matilainen]

On 02/14/2018 11:27 PM, David Cantrell wrote:

On 02/14/2018 02:41 PM, Igor Gnatenko wrote:

On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:

On 02/14/2018 11:44 AM, Remi Collet wrote:

Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :

Just a small heads up, ...



As I said on IRC

- waste of time
- waste of energy
- absolutely no value

And

- abuse proven packager privileges



+1


Ralf, Remi, David,

Please, read policy[0] once more.


Sometimes there are situations where it's simply a lot easier to fix stuff

directly in Git than via bugzilla and the proper maintainers. So much easier
that we should leave this path open. These situations shouldn't arise that
often. Some examples of situations were bypassing the proper maintained is
considered fine:

[…]
* small fixes or adjustments for new or modified packaging

guidelines can be done directly in Git after being announced some days
in advance.

I just missed waiting for few days (kinda intentionally), because it would not
help anyone and will just disturb maintainers to do the actual work whereas it
doesn't make any sense because cleanup is automated.


[0] https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Mino
r.2C_general_or_cleanup_changes



I am not disputing the policy.  I feel this change is pointless and is a
lot of commits for no real benefit.  They are not fixes.  You're just
scrubbing spec files that are not broken.  Who cares?  Update the
packaging policy and be done with it.  Leaving this tag there hurts nothing.

It's also worth noting that Pagure gives us pull requests for these sort
of changes.  While a proven packager can drive a monster truck through
the package repositories unchecked, the nice thing to do in the
community is to bring the issue to the attention of the package
maintainer and let them handle it.  Pagure lets you send pull requests
for this (you can even automate it) and then leave it with the package
maintainer to take or ignore on their own.

Just because we have removed something like the BuildRoot tag from the
packaging policy does not automatically invalidate every existing spec file.


I can't believe what I'm seeing here.

That old unused cruft hurts because old like Igor said, new people will 
copy it over to new specs thinking this is some magic necessary 
incantation (which is once was but no longer is). And no doubt some old 
timers might not be aware that it's no longer needed and/or still add it 
just out of habit, spreading the disease.


At the same time people love to complain how much stupid boilerplate 
stuff there is in every spec. Well hello, BuildRoot was made unnecessary 
in rpm almost ten years ago, the packaging policy for Fedora already 
updated accordingly many years ago, the last EL version requiring it 
finally EOL'ed. And yet people have the nerve to complain when somebody 
voluntarily cleans up this useless cryptic crap from their spec files!


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1543336] please provide missing Fedora 27 Perl modules

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1543336



--- Comment #15 from Jitka Plesnikova  ---
I requested new branch and built these packages for EPEL 7. I am maintainer of
them.

perl-Convert-ASCII-Armour-1.4-32.el7
perl-Net-SSH-0.09-26.el7
perl-Term-ReadPassword-0.11-27.el7

The other packages are owned by different users and I don't want to maintain
EPEL 7 branches for them. 

FAS: ixs
 perl-Crypt-Blowfish

FAS: berrange
 perl-Test-YAML-Meta

FAS: pghmcfc
 perl-Net-SSH-Perl
 perl-Crypt-RSA
 perl-Math-Pari
 perl-Text-SpellChecker
 perl-Class-Loader
 perl-Crypt-Primes
 perl-Crypt-Random
 perl-Tie-EncryptedHash

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org