Re: What to I have to do....

[Steve Dickson]

Hey,

On 12/07/2017 03:49 PM, Adam Williamson wrote:
> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> 
>> Where committed to the master branch and not to any other
>> branch make the maintenance of those branches a pain 
>> because I can no longer cherry-pick between branches.
>> I have to make multiple commits to multiple branches
>> which sucks... Something random people do not understand!
> 
> You can bring branches back into line with merge commits. Can require a
> bit of git juggling, but it's always doable in the end.
> 
Fair enough... I understand git and how to bring things back
into sync.. But the question is why does a maintainer have
jump through these hoops for change they didn't make.

All I'm trying to do is nip in the bud the notion that
anybody can make any change they want to any package
without going through the maintainer of that package.

I don't know what any of the polices say but we can
not let that happen if we hope to maintain stability.

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

Re: What to I have to do....

[Steve Dickson]

On 12/07/2017 06:13 PM, Sérgio Basto wrote:
> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
>> Hello,
>>
>> What do I have to do to stop random people 
>> from making random changes to packages I maintain? 
>>
>> How do people get this type of permission?
>>
>> Case in point;
>>
>> commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
>> origin/master, origin/HEAD)
>> Author: Igor Gnatenko 
>> Date:   Tue Nov 7 16:31:21 2017 +0100
>>
>> Remove old crufty coreutils requires
>> 
>> Signed-off-by: Igor Gnatenko 
>>
>> commit 66851ea12370a786844262620a40b0a2ac9632ce
>> Author: Igor Gnatenko 
>> Date:   Tue Nov 7 16:31:14 2017 +0100
>>
>> systemd-units -> systemd
>> 
>> Signed-off-by: Igor Gnatenko 
>>
>> Where committed to the master branch and not to any other
>> branch make the maintenance of those branches a pain 
>> because I can no longer cherry-pick between branches.
>> I have to make multiple commits to multiple branches
>> which sucks... Something random people do not understand!
>>
>> There is a pull mechanism... Why was that not used??
>>
>> Maintaining the stability of packages is hard enough
>> esp packages everybody uses... but that stability
>> goes out the window when random people allowed to
>> make random changes...
>>
>> Who are these super humans, how do they become 
>> super humans and why aren't they required to 
>> use the pull mechanism?? 
> 
> I don't agree with you, you may contact the super human and ask him why
> ? you may revert the commit . 
Overhead that is simply not needed if the maintainer was consulted first.

> 
> IMHO we shouldn't inhibit people do his best, we already have lots of
> work, is kernel updates , glibc updates , gcc updates , systemd , etc
> etc ... (hopefully) 
Ah so you can make a changes to Linus' kernel at anytime you what?? 
Wow I'm impressed 8-) (sarcasm... probably not necessary)

My point is this... People with the best intentions can easily
introduce stability issues by changes packages they don't fully
understand. All changes, other than time critical ones, should
go through the maintainer... I just don't understand why that
is too much to ask?
 
> 
> As wrote in coreuitls commit 
> " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> stat) Those are gone in fc9, more than decade ago."
> 
> Nobody takes care of opencv for example , despite a very long bug
> report, we got bugs like  822844 [1] opened in 2012-05-18  to update
> giflib, my problem here is I don't know if giflib is used anymore or if
> have a replacement etc, so just do a monkey update is not enough for
> me. 
> I got more and more SELinux bugs, people more and more enable SELinux ,
> but SE team doesn't have time to fix it or something like that . 
> 
> So I think you should write (offlist) to the people which made the
> commits , and understand the motivation , and organize with him the
> best way of committing in "your" packages. 
This is the second this happen and the first time I did go offlist. 

So I'm going onlist because I'm seeing a trend... People seems
to think they can make any changes they want w/out going 
through the maintainer. That is a very bad trend... IMHO.

steved.

> 
> Best regards,
> 
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=822844
> 
>> steved.
>> ___
>> 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: What to I have to do....

[Florian Weimer]

On 12/08/2017 02:40 PM, Steve Dickson wrote:

Hey,

On 12/07/2017 02:31 PM, Florian Weimer wrote:

On 12/07/2017 04:31 PM, Steve Dickson wrote:

Where committed to the master branch and not to any other
branch make the maintenance of those branches a pain
because I can no longer cherry-pick between branches.


Maybe you can elaborate on how this causes problems for your
development process, and we can find a way to avoid that?



I think the best way to avoid these problems is have any all changes
go through the maintainer...


That doesn't work if the maintainer doesn't react in a timely fashion to 
bug reports, as it is the case for many maintainers unfortunately.  For 
non-critical issues, this is quite understandable, too.


If cleanups have to go through the maintainer, it's pretty much like 
saying that they should not happen, ever.



Now when something breaks from a change like this... Who are you going to call? 
:-)
Not the Ghostbusters... the maintainer and if the maintainer didn't even know
about the change... how fair that??


I don't understand the problem.  If the change came with an upstream 
import, most maintainers would be surprised as well (because they are 
not upstream or have not reviewed any single upstream change).


Again, if there is a Git proces issue here, we can provide guidelines to 
avoid that with bulk changes (and perhaps a minor Koji enhancement on 
top).  But if you don't say what the technical problems are that you are 
dealing with, we can't make such improvements.


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

Re: What to I have to do....

[Steve Dickson]

On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
> On 2017-12-07 09:31, Steve Dickson wrote:
>> What do I have to do to stop random people 
>> from making random changes to packages I maintain? 
>>
>> How do people get this type of permission?
> 
> https://fedoraproject.org/wiki/Provenpackager_policy
> 
>> Case in point;
> [snip]
> 
> These were properly announced:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> 
> This is proper use of the provenpackager privileges.
Which will lead to the instability... IMHO... Allowing people to
to change technology that they are clueless of is just wrong.

What is the point of maintainers-ship if any one and everyone can 
make changes? Any and all changes must go through the maintainer
if that is not the case the way even have them?
 
steved.
 
> 
> 
> 
> ___
> 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

no updates since Monday

[Chuck Anderson]

Does anyone know why there have been no updates or changes to any of
the Fedora repos (including rawhide) since Monday?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: no updates since Monday

[Chuck Anderson]

On Fri, Dec 08, 2017 at 09:25:05AM -0500, Chuck Anderson wrote:
> Does anyone know why there have been no updates or changes to any of
> the Fedora repos (including rawhide) since Monday?

Darn, I just found the announcement about the data center move.  Never mind...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

Hey,

On 12/07/2017 02:31 PM, Florian Weimer wrote:
> On 12/07/2017 04:31 PM, Steve Dickson wrote:
>> Where committed to the master branch and not to any other
>> branch make the maintenance of those branches a pain
>> because I can no longer cherry-pick between branches.
> 
> Maybe you can elaborate on how this causes problems for your 
> development process, and we can find a way to avoid that?
I think the best way to avoid these problems is have any all changes
go through the maintainer... Now I understand build issue where 
the flux capacitor breaks and the issue needs to be fix relatively
quickly... fine... but is was not the case... This was remove/changing
logic in the packaging... which easily gone through the maintainer 
via the push mechanism.

Now when something breaks from a change like this... Who are you going to call? 
:-)
Not the Ghostbusters... the maintainer and if the maintainer didn't even know
about the change... how fair that??

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

Re: What to I have to do....

[Steve Dickson]

On 12/07/2017 05:38 PM, Kevin Kofler wrote:
> Steve Dickson wrote:
>> Where committed to the master branch and not to any other
>> branch make the maintenance of those branches a pain
>> because I can no longer cherry-pick between branches.
>> I have to make multiple commits to multiple branches
>> which sucks... Something random people do not understand!
> 
> Huh? Normally, just committing to the master branch is the right thing to do 
> for such cleanups. The other branches will either get the changes when I 
> fast-forward-merge master into them (remember that you should always work in 
> Rawhide first), or I don't merge and they don't get the changes, which is 
> typically fine too for this kind of cosmetic cleanups.
> 
> Committing the changes to all branches separately is exactly what I DON'T 
> want provenpackagers to do because that would break fast-forward 
> mergeability (and fixing that is painful and will pollute the history with 
> several merge commits: I have to merge master into the branch, and then 
> fast-forward-merge the branch back into master, which pollutes all branches 
> including the master with one merge commit per branch). I always curse at 
> rel-eng when they do a mass rebuild in a branch, bumping the branch directly 
> with their scripts instead of merging from master.
Good for you... you have a process of keeping your branches insync.. 
and it sounds very reasonable... 

Now when a random nobody make a change behind your back that disrupts
that process and you are ok with that??? Well.. I'm not. 

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

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 02:07:51AM +, Michael Cullen wrote:
> > because I can no longer cherry-pick between branches.
> 
> Not true at all - you’d be surprised how well git deals with cherry
> picks across diverse branches. And even when it doesn’t there’s very
> rarely anything in a spec file that would be a difficult conflict to
> resolve. At work I often cherry pick across branches that have diverged
> sometimes by hundreds of commits without too many problems!
> Michael

Yeah, git is usually able to cherry-pick most of the commit between
different fedora branches. There's usually a conflict in the
%changelog section, but it's really trivial, usually a few keystrokes
to solve.

This was mentioned elsewhere in the thread: it's easiest to
fast-forward the other branches to master, if the changes done in
rawhide apply also to released Fedoras. Then there's even no need to
cherry-pick anything.

But even if copying the changes wasn't almost trivial, those changes
would still be OK. After all, that's exactly the way that
release-engineering does mass rebuilds and also how rebuilds for
so-bumps are done. So a maintainer will occasionally get an "external"
commit in rawhide. I really don't see why a cleanup done by a pp
would be any different.

... and, having said all that, I think that even if the cleanups
were not done exactly as the maintainer would want them to be done,
the maintainer should be OK with them: the net benefit of having
the cleanup done is higher then the surprise/need-of-adjustment/annoyance
of the maintainer. If somebody else does a change on our package we're
prone to seeing all the warts, more so then in our own work.

Zbyszek

> On Thu, 7 Dec 2017, at 11:13 PM, Sérgio Basto wrote:
> > On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> > > Hello,
> > >
> > > What do I have to do to stop random people
> > > from making random changes to packages I maintain?
> > >
> > > How do people get this type of permission?
> > >
> > > Case in point;
> > >
> > > commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> > > origin/master, origin/HEAD)
> > > Author: Igor Gnatenko 
> > > Date:   Tue Nov 7 16:31:21 2017 +0100
> > >
> > > Remove old crufty coreutils requires
> > >
> > > Signed-off-by: Igor Gnatenko > >
> > > commit 66851ea12370a786844262620a40b0a2ac9632ce
> > > Author: Igor Gnatenko 
> > > Date:   Tue Nov 7 16:31:14 2017 +0100
> > >
> > > systemd-units -> systemd
> > >
> > > Signed-off-by: Igor Gnatenko > >
> > > Where committed to the master branch and not to any other
> > > branch make the maintenance of those branches a pain
> > > because I can no longer cherry-pick between branches.
> > > I have to make multiple commits to multiple branches
> > > which sucks... Something random people do not understand!
> > >
> > > There is a pull mechanism... Why was that not used??
> > >
> > > Maintaining the stability of packages is hard enough
> > > esp packages everybody uses... but that stability
> > > goes out the window when random people allowed to
> > > make random changes...
> > >
> > > Who are these super humans, how do they become
> > > super humans and why aren't they required to
> > > use the pull mechanism??
> >
> > I don't agree with you, you may contact the super human and ask him
> > why> ? you may revert the commit .
> >
> > IMHO we shouldn't inhibit people do his best, we already have lots of> 
> > work, is kernel updates , glibc updates , gcc updates , systemd , etc> etc 
> > ... (hopefully)
> >
> > As wrote in coreuitls commit
> > " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> > stat) Those are gone in fc9, more than decade ago."
> >
> > Nobody takes care of opencv for example , despite a very long bug
> > report, we got bugs like  822844 [1] opened in 2012-05-18  to update
> > giflib, my problem here is I don't know if giflib is used
> > anymore or if> have a replacement etc, so just do a monkey update is not 
> > enough for
> > me.
> > I got more and more SELinux bugs, people more and more enable
> > SELinux ,> but SE team doesn't have time to fix it or something like that .
> >
> > So I think you should write (offlist) to the people which made the
> > commits , and understand the motivation , and organize with him the
> > best way of committing in "your" packages.
> >
> > Best regards,
> >
> > [1]
> > https://bugzilla.redhat.com/show_bug.cgi?id=822844
> >
> > > steved.
> > > ___
> > > 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: debug facilities

[Mark Wielaard]

On Mon, 2017-12-04 at 15:47 -0500, Przemek Klosowski wrote:
> The bottom line is that it's pretty tricky to figure this out, which is 
> a pity because easy debuggability is one of the important cultural 
> features of Fedora and FOSS. It's a regression: GDB used to point to 
> integrated .debuginfo packages, which was sufficient. Now, maybe GDB 
> should suggest installing the source RPM?

Sorry I only saw this now. I think this is simply a bug in dnf.
dnf debuginfo-install really should do the right thing by default:
https://bugzilla.redhat.com/show_bug.cgi?id=1494628

There is a patch, but the dnf maintainer doesn't seem to like it. The
next version of rpmbuild will generate a soft depends Recommends
between debuginfo and debugsource packages, which should pull in
debugsources automatically. But of course that needs a rebuild of every
package and won't help you in Fedora 27.

Cheers,

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

Re: [Ambassadors] Re: Autumn Elections 2017 are cancelled

[Robert Mayr]

Il 08/dic/2017 12:39 AM, "Dominik 'Rathann' Mierzejewski" <
domi...@greysector.net> ha scritto:

On Thursday, 07 December 2017 at 18:54, Jan Kurik wrote:
> During the Autumn 2017 Election cycle we wanted to try a new approach
> in the way how Elections are organized [1]. Unfortunately, at the
> beginning of the Voting period we realized the new way does not work
> as expected [2] and even we tried to put some mitigation plan in place
> [3], we have not succeeded. To come up with some workable solution we
> have decided to cancel the currently running Autumn 2017 Elections and
> start it again in early January 2018. In upcoming days I will publish
> a schedule for the January 2018 Elections as well as more details on
> how we are going to organize it.

Who is "we" that "decided" to cancel the running elections? What were the
reasons for this "decision"? I object to this strongly. It doesn't look
like this "decision" was made through an open process as is the usual
Fedora way. I can't even find a Council ticket for this or a thread
in the council-discuss mailing list.

I'm afraid I'm losing confidence that the current Council is capable
of leading Fedora if they cannot even hold an election according to
the current documented rules without breaking them in more than one way.

I haven't checked if elections to the Council and Mindshare were
organized according to policy (maybe I should!), but with FESCo
elections, the following were broken:
1. Candidate nominations were accepted later than 3 days before
   the voting period started. This contradicts
   https://fedoraproject.org/wiki/FESCo_election_policy#Candidates
2. Candidates whose interviews weren't ready for publication before the
   start of the voting period were not disqualified. This contradicts
   https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

Due to not having enough (number of open seats + 25%) candidates on the
day before the voting period, the nomination period was extended by 3
days. Arguably, the extension should have happened 3 days earlier
and should have been made longer than 3 days because extending by 3 days
on the eve of the voting period start still doesn't give anyone a chance
to be nominated according to
https://fedoraproject.org/wiki/FESCo_election_policy#Candidates .
I'd have extended by at least a week, also due to infrastructure
instability this week. The interview readiness deadline was,
suprisingly, extended by a week, allowing candidates who couldn't be
bothered to write their interviews to be voted in anyway. Nothing was
said about disqualifying candidates who'd fail to publish their interviews
despite getting votes in the first few days of the elections.

Last but not least, I wonder why all elections are being cancelled
instead of just FESCo. This was not explained, either.

With sad regards,
Dominik
--
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
___
ambassadors mailing list -- ambassad...@lists.fedoraproject.org
To unsubscribe send an email to ambassadors-le...@lists.fedoraproject.org


It think you stated your opinion more than once now and I also know "we"
(Council) gave you all the reasons for any decision we took in public. We
wanted to try something new and it didn't work, it is not constructive at
all to continue with the same concerns neither by deleting interviews in
sign of protest.
I also think you know perfectly why all elections have been cancelled,
interviews were missing for several candidates and if we would have
cancelled just FESCo you probably would complain about the decision because
we treat bodies in different ways.
So, let's be constructive and eventually make proposals, we all are part of
a community, we are not politicians or either role, but want to have equal
elections with a smooth process.
If you have ideas to improve that (and I think you already did in some way)
we will and want to take that in consideration. We also have some new
tickets in Council pagure too about that.
Thanks.
Kind regards

==
Robert Mayr
(robyduck)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 09:14:35AM -0500, Steve Dickson wrote:
> 
> 
> On 12/07/2017 06:13 PM, Sérgio Basto wrote:
> > On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> >> Hello,
> >>
> >> What do I have to do to stop random people 
> >> from making random changes to packages I maintain? 
> >>
> >> How do people get this type of permission?
> >>
> >> Case in point;
> >>
> >> commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> >> origin/master, origin/HEAD)
> >> Author: Igor Gnatenko 
> >> Date:   Tue Nov 7 16:31:21 2017 +0100
> >>
> >> Remove old crufty coreutils requires
> >> 
> >> Signed-off-by: Igor Gnatenko 
> >>
> >> commit 66851ea12370a786844262620a40b0a2ac9632ce
> >> Author: Igor Gnatenko 
> >> Date:   Tue Nov 7 16:31:14 2017 +0100
> >>
> >> systemd-units -> systemd
> >> 
> >> Signed-off-by: Igor Gnatenko 
> >>
> >> Where committed to the master branch and not to any other
> >> branch make the maintenance of those branches a pain 
> >> because I can no longer cherry-pick between branches.
> >> I have to make multiple commits to multiple branches
> >> which sucks... Something random people do not understand!
> >>
> >> There is a pull mechanism... Why was that not used??
> >>
> >> Maintaining the stability of packages is hard enough
> >> esp packages everybody uses... but that stability
> >> goes out the window when random people allowed to
> >> make random changes...
> >>
> >> Who are these super humans, how do they become 
> >> super humans and why aren't they required to 
> >> use the pull mechanism?? 
> > 
> > I don't agree with you, you may contact the super human and ask him why
> > ? you may revert the commit . 
> Overhead that is simply not needed if the maintainer was consulted first.

How would the overhead be lower? Instead of a single clean commit that
does what needs to be done you want the person doing this cleanup on a
hundred packages to send you a special message and wait while you make
the decision whether to allow a three line change or not? Please explain.

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

Schedule for Friday's FESCo Meeting (2017-12-08)

[Jared K. Smith]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting onirc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2017-12-08 16:00 UTC'


Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda


= New business =

#topic #1799 The ProvenPackager rubric needs more formality
.fesco 1799https://pagure.io/fesco/issue/1799

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found
athttps://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue athttps://pagure.io/fesco,
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: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 10:31:58AM -0500, Steve Dickson wrote:
> 
> 
> On 12/08/2017 10:07 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Dec 08, 2017 at 08:31:44AM -0500, Steve Dickson wrote:
> >>
> >>
> >> On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
> >>> On 2017-12-07 09:31, Steve Dickson wrote:
>  What do I have to do to stop random people 
>  from making random changes to packages I maintain? 
> 
>  How do people get this type of permission?
> >>>
> >>> https://fedoraproject.org/wiki/Provenpackager_policy
> >>>
>  Case in point;
> >>> [snip]
> >>>
> >>> These were properly announced:
> >>>
> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> >>>
> >>> This is proper use of the provenpackager privileges.
> >> Which will lead to the instability... IMHO... Allowing people to
> >> to change technology that they are clueless of is just wrong.
> > 
> > I think that's exactly the point ;)
> > We are allowing people who have the knack and inclination to do "boring"
> > cleanups to do them so that _maintainers_ can actually concentrate on
> > _technology_.
> > 
> > From your message one could think that the changes are some massive
> > reworking, but both commits are completely trivial updates of
> > dependencies on package names that have been gone for _years_.
> > 
> > Unless you want to say that the change is somehow wrong, please
> > don't say that "poeple [...] are clueless", because that's disingenuous.
> Fair enough... "clueless" was probably not the most appropriate 
> term to use... But I just read this policy.
> 
>https://fedoraproject.org/wiki/Provenpackager_policy
> 
> It is very broad... IHMO.. You open a ticket, get three acks
> a boom! You know have complete access every Fedora package
> including the kernel... hmm...

Well, I'd say this works great. There's maybe a hundred or two hundred
proven packagers and somehow none of them decide to mess up the kernel
any day. In fact, the commits which caused this thread are _correct_:
so far I haven't heard one word to the contrary. I don't see any point
in discussing hypotheticals.

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

Re: What to I have to do....

[Sérgio Basto]

On Fri, 2017-12-08 at 09:14 -0500, Steve Dickson wrote:
> 
> On 12/07/2017 06:13 PM, Sérgio Basto wrote:
> > On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> > > Hello,
> > > 
> > > What do I have to do to stop random people 
> > > from making random changes to packages I maintain? 
> > > 
> > > How do people get this type of permission?
> > > 
> > > Case in point;
> > > 
> > > commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> > > origin/master, origin/HEAD)
> > > Author: Igor Gnatenko 
> > > Date:   Tue Nov 7 16:31:21 2017 +0100
> > > 
> > > Remove old crufty coreutils requires
> > > 
> > > Signed-off-by: Igor Gnatenko  > > g>
> > > 
> > > commit 66851ea12370a786844262620a40b0a2ac9632ce
> > > Author: Igor Gnatenko 
> > > Date:   Tue Nov 7 16:31:14 2017 +0100
> > > 
> > > systemd-units -> systemd
> > > 
> > > Signed-off-by: Igor Gnatenko  > > g>
> > > 
> > > Where committed to the master branch and not to any other
> > > branch make the maintenance of those branches a pain 
> > > because I can no longer cherry-pick between branches.
> > > I have to make multiple commits to multiple branches
> > > which sucks... Something random people do not understand!
> > > 
> > > There is a pull mechanism... Why was that not used??
> > > 
> > > Maintaining the stability of packages is hard enough
> > > esp packages everybody uses... but that stability
> > > goes out the window when random people allowed to
> > > make random changes...
> > > 
> > > Who are these super humans, how do they become 
> > > super humans and why aren't they required to 
> > > use the pull mechanism?? 
> > 
> > I don't agree with you, you may contact the super human and ask him
> > why
> > ? you may revert the commit . 
> 
> Overhead that is simply not needed if the maintainer was consulted
> first.
> 
> > 
> > IMHO we shouldn't inhibit people do his best, we already have lots
> > of
> > work, is kernel updates , glibc updates , gcc updates , systemd ,
> > etc
> > etc ... (hopefully) 
> 
> Ah so you can make a changes to Linus' kernel at anytime you what?? 
> Wow I'm impressed 8-) (sarcasm... probably not necessary)

I mean, I (and others packagers maintainers) have lots of work after
one gcc or kernel or other features update. I can enumerate lots of
changes that requires me to work on updates of the packages, if you
saw, my emails on this list, now I'm try to deal with drop of
the webkitgtk and webkitgtk3, just for example.

> My point is this... People with the best intentions can easily
> introduce stability issues by changes packages they don't fully
> understand. All changes, other than time critical ones, should
> go through the maintainer... I just don't understand why that
> is too much to ask?

I think we live in 2 different worlds (one is the world of well
maintained packages and other is the world of abandoned packages), as
described above the lots of work to well maintain the packages leads in
abandoned packages. Even I, which do my best, I don't have all packages
well maintained, so make one pull request may be a waste of time. 
Even have to wait some hours or days for a reply is a problem for who
want help to maintain the packages. 

> > 
> > As wrote in coreuitls commit 
> > " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> > stat) Those are gone in fc9, more than decade ago."
> > 
> > Nobody takes care of opencv for example , despite a very long bug
> > report, we got bugs like  822844 [1] opened in 2012-05-18  to
> > update
> > giflib, my problem here is I don't know if giflib is used anymore
> > or if
> > have a replacement etc, so just do a monkey update is not enough
> > for
> > me. 
> > I got more and more SELinux bugs, people more and more enable
> > SELinux ,
> > but SE team doesn't have time to fix it or something like that . 
> > 
> > So I think you should write (offlist) to the people which made the
> > commits , and understand the motivation , and organize with him the
> > best way of committing in "your" packages. 
> 
> This is the second this happen and the first time I did go offlist. 
> 

But the commit that I mention here, should be done 10 years ago ! , so
for me, that is the main problem, why the package wasn't not updated
before ?  

Best regards, 

> So I'm going onlist because I'm seeing a trend... People seems
> to think they can make any changes they want w/out going 
> through the maintainer. That is a very bad trend... IMHO.
> 
> steved.
> 
> > 
> > Best regards,
> > 
> > [1]
> > https://bugzilla.redhat.com/show_bug.cgi?id=822844
> > 
> > > steved.
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-leave@lists.fedoraproject.o
> > > rg
-- 
Sérgio M. B.
___

Re: What to I have to do....

[Pierre-Yves Chibon]

On Fri, Dec 08, 2017 at 11:21:10AM -0500, Charalampos Stratakis wrote:
> - Original Message -
> > > Unless you want to say that the change is somehow wrong, please
> > > don't say that "poeple [...] are clueless", because that's disingenuous.
> > Fair enough... "clueless" was probably not the most appropriate
> > term to use... But I just read this policy.
> > 
> >https://fedoraproject.org/wiki/Provenpackager_policy
> > 
> > It is very broad... IHMO.. You open a ticket, get three acks
> > a boom! You know have complete access every Fedora package
> > including the kernel... hmm...
> > 
> 
> The kernel is actually blacklisted from proven packager access, you can't 
> make changes there.

While this used to be true it hasn't been for a while now, I think the last
packages that are restricted are: xulrunner, thunderbird and firefox due to
mozilla's trademark policy on them.


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

Re: What to I have to do....

[Steve Dickson]

On 12/07/2017 03:37 PM, R P Herrold wrote:
> On Thu, 7 Dec 2017, Yaakov Selkowitz wrote:
> 
>> https://fedoraproject.org/wiki/Provenpackager_policy
> 
>> These were properly announced:
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> 
> That section provides in relevant part:
> 
>> Provenpackagers should try to communicate with owners of a 
> package in bugzilla, irc or email prior to making changes
> 
> IMHO, A general email to a high traffic mailing list is 
> insufficient
> 
> IRC is even worse for notification
> 
> Absent some pressing need (which was NOT present here -- this 
> was just 'distribution housecleaning'), this was insufficient 
> notice on a non-urgent matter, to my thinking
I've been using the the term "push mechanism" but I should
have should been using the term pull-requests

These pull-request are wonderful things! They should be *required*
any and all non-critical, cleanup, etc changes to packages
by non maintainers... It it is time critical... mark it time critical.

This process documents the need for a change, notifies the maintainer
and allow the maintainer a chance to respond... If now response 
the super human makes the change... 

We have tools and process to maintain stability Lets use them!

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 10:07 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Dec 08, 2017 at 08:31:44AM -0500, Steve Dickson wrote:
>>
>>
>> On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
>>> On 2017-12-07 09:31, Steve Dickson wrote:
 What do I have to do to stop random people 
 from making random changes to packages I maintain? 

 How do people get this type of permission?
>>>
>>> https://fedoraproject.org/wiki/Provenpackager_policy
>>>
 Case in point;
>>> [snip]
>>>
>>> These were properly announced:
>>>
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
>>>
>>> This is proper use of the provenpackager privileges.
>> Which will lead to the instability... IMHO... Allowing people to
>> to change technology that they are clueless of is just wrong.
> 
> I think that's exactly the point ;)
> We are allowing people who have the knack and inclination to do "boring"
> cleanups to do them so that _maintainers_ can actually concentrate on
> _technology_.
> 
> From your message one could think that the changes are some massive
> reworking, but both commits are completely trivial updates of
> dependencies on package names that have been gone for _years_.
> 
> Unless you want to say that the change is somehow wrong, please
> don't say that "poeple [...] are clueless", because that's disingenuous.
Fair enough... "clueless" was probably not the most appropriate 
term to use... But I just read this policy.

   https://fedoraproject.org/wiki/Provenpackager_policy

It is very broad... IHMO.. You open a ticket, get three acks
a boom! You know have complete access every Fedora package
including the kernel... hmm...

steved.

> 
> Zbyszek
> 
>> What is the point of maintainers-ship if any one and everyone can 
>> make changes? Any and all changes must go through the maintainer
>> if that is not the case the way even have them?
>>  
>> steved.
>>  
>>>
>>>
>>>
>>> ___
>>> 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
> ___
> 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: What to I have to do....

[Charalampos Stratakis]

- Original Message -
> From: "Steve Dickson" 
> To: "Development discussions related to Fedora" 
> , "Zbigniew Jędrzejewski-Szmek"
> 
> Cc: "Yaakov Selkowitz" 
> Sent: Friday, December 8, 2017 4:31:58 PM
> Subject: Re: What to I have to do
> 
> 
> 
> On 12/08/2017 10:07 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Dec 08, 2017 at 08:31:44AM -0500, Steve Dickson wrote:
> >>
> >>
> >> On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
> >>> On 2017-12-07 09:31, Steve Dickson wrote:
>  What do I have to do to stop random people
>  from making random changes to packages I maintain?
> 
>  How do people get this type of permission?
> >>>
> >>> https://fedoraproject.org/wiki/Provenpackager_policy
> >>>
>  Case in point;
> >>> [snip]
> >>>
> >>> These were properly announced:
> >>>
> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> >>>
> >>> This is proper use of the provenpackager privileges.
> >> Which will lead to the instability... IMHO... Allowing people to
> >> to change technology that they are clueless of is just wrong.
> > 
> > I think that's exactly the point ;)
> > We are allowing people who have the knack and inclination to do "boring"
> > cleanups to do them so that _maintainers_ can actually concentrate on
> > _technology_.
> > 
> > From your message one could think that the changes are some massive
> > reworking, but both commits are completely trivial updates of
> > dependencies on package names that have been gone for _years_.
> > 
> > Unless you want to say that the change is somehow wrong, please
> > don't say that "poeple [...] are clueless", because that's disingenuous.
> Fair enough... "clueless" was probably not the most appropriate
> term to use... But I just read this policy.
> 
>https://fedoraproject.org/wiki/Provenpackager_policy
> 
> It is very broad... IHMO.. You open a ticket, get three acks
> a boom! You know have complete access every Fedora package
> including the kernel... hmm...
> 
> steved.
> 

The kernel is actually blacklisted from proven packager access, you can't make 
changes there.

Apart from that though, I don't really see any reasons for creating this thread.

Proven packagers do trivial and non-trivial cleanups all the time. While I 
agree that a PR would be better,
when dealing with changes on a vast amount of packages that should be ideally 
done in a timely manner, waiting for a
timely response from every single maintainer of the respective packages is just 
not realistic.

> > 
> > Zbyszek
> > 
> >> What is the point of maintainers-ship if any one and everyone can
> >> make changes? Any and all changes must go through the maintainer
> >> if that is not the case the way even have them?
> >>  
> >> steved.
> >>  
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> > ___
> > 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
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Kalev Lember]

On 12/08/2017 05:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Dec 08, 2017 at 10:59:20AM -0500, Steve Dickson wrote:
>>
>>
>> On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>> How would the overhead be lower? Instead of a single clean commit that
>>> does what needs to be done you want the person doing this cleanup on a
>>> hundred packages to send you a special message and wait while you make
>>> the decision whether to allow a three line change or not? Please explain.
>> Who determines "needs to be done" Shouldn't the owner of the package be in
>> on the determination, with silents being acceptance after a certain amount
>> of time? I think so.
> 
> This is completely infeasible to contact each maintainer individually
> when doing massive changes. The policy specifies that the mass change
> should be pre-announced, discussed, and announced on the mailing list.
> This procedure was followed, the changes are simple and correct.
> 
>> Yes to your second question... For one reason... maintaining stability.
>> You give people the ability to change anything and everything they
>> want w/out any review... that is called instability... 
> 
> No, those changes don't have any effect on the way that your package
> operates, they just change the reference from an obsolete name to
> one that actually exists. Without such changes we would have more
> and more obsolete cruft in packages. It's great that somebody is willing
> to spend their time keeping the distro tidy. Change, if done carefully,
> does not mean instability.

I wholeheartedly agree with Zbyszek here. Well said.

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 09:00 AM, Florian Weimer wrote:
> On 12/08/2017 02:40 PM, Steve Dickson wrote:
>> Hey,
>>
>> On 12/07/2017 02:31 PM, Florian Weimer wrote:
>>> On 12/07/2017 04:31 PM, Steve Dickson wrote:
 Where committed to the master branch and not to any other
 branch make the maintenance of those branches a pain
 because I can no longer cherry-pick between branches.
>>>
>>> Maybe you can elaborate on how this causes problems for your
>>> development process, and we can find a way to avoid that?
> 
>> I think the best way to avoid these problems is have any all changes
>> go through the maintainer...
> 
> That doesn't work if the maintainer doesn't react in a timely fashion to bug 
> reports, as it is the case for many maintainers unfortunately.  For 
> non-critical issues, this is quite understandable, too.
Yes and No... If there is a bug report and the maintainer is unresponsive... 
that is one thing 
because the maintainer has gotten bugzilla email about it

If the problem is that critical the maintainer usually gets
pinged... I know I have been in the past.

Define "non-critical issues" is changing dependencies on systemd non-critical? 
No!
non-critical is too broad of a term and should be determined by the maintainer
not somebody that has no or little knowledge... IMHO.

> 
> If cleanups have to go through the maintainer, it's pretty much like saying 
> that they should not happen, ever.
This is not true with in every case. But in the cases this is true, maybe there
should be a time limited? 48hrs?? 

> 
>> Now when something breaks from a change like this... Who are you going to 
>> call? :-)
>> Not the Ghostbusters... the maintainer and if the maintainer didn't even know
>> about the change... how fair that??
> 
> I don't understand the problem.  If the change came with an upstream import, 
> most maintainers would be surprised as well (because they are not upstream or 
> have not reviewed any single upstream change).
Upstream changes are not a problem... Its these random packaging changes that 
are not
document (aka no bz) no reason why... Just done... That is not good... again 
IMHO..

We have this "new" push/pull mechanism that works just great! Why can't these 
non-critical
fixed go through that?

> 
> Again, if there is a Git proces issue here, we can provide guidelines to 
> avoid that with bulk changes (and perhaps a minor Koji enhancement on top).  
> But if you don't say what the technical problems are that you are dealing 
> with, we can't make such improvements.
Its not that... I just me whining about having to do more "cleanup" work.. ;-) 

steved.

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

Re: debug facilities

[Przemek Klosowski]

On 12/08/2017 06:29 AM, Mark Wielaard wrote:

On Mon, 2017-12-04 at 15:47 -0500, Przemek Klosowski wrote:

The bottom line is that it's pretty tricky to figure this out, which is
a pity because easy debuggability is one of the important cultural
features of Fedora and FOSS. It's a regression: GDB used to point to
integrated .debuginfo packages, which was sufficient. Now, maybe GDB
should suggest installing the source RPM?

Sorry I only saw this now. I think this is simply a bug in dnf.
dnf debuginfo-install really should do the right thing by default:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1494628=02%7C01%7Cprzemek.klosowski%40nist.gov%7C9b51d028c82b480ec83608d53e2effa3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636483293944728074=Xfyb%2FfxQaCL1GWplbwgxgx%2B7cmyWfjQME1jCIkp7WzE%3D=0

Thanks for the info---that's good news.

I still don't quite understand why only some packages have the 
debuginfo/debugsource split (I counted ~10k debugsources to ~30k 
debuginfo). Is that an automatic process that just needs to happen over 
time, or do the maintainers need to hand-polish individual packages?

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Dec 08, 2017 at 09:14:35AM -0500, Steve Dickson wrote:
>>
>>
>> On 12/07/2017 06:13 PM, Sérgio Basto wrote:
>>> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
 Hello,

 What do I have to do to stop random people 
 from making random changes to packages I maintain? 

 How do people get this type of permission?

 Case in point;

 commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
 origin/master, origin/HEAD)
 Author: Igor Gnatenko 
 Date:   Tue Nov 7 16:31:21 2017 +0100

 Remove old crufty coreutils requires
 
 Signed-off-by: Igor Gnatenko 

 commit 66851ea12370a786844262620a40b0a2ac9632ce
 Author: Igor Gnatenko 
 Date:   Tue Nov 7 16:31:14 2017 +0100

 systemd-units -> systemd
 
 Signed-off-by: Igor Gnatenko 

 Where committed to the master branch and not to any other
 branch make the maintenance of those branches a pain 
 because I can no longer cherry-pick between branches.
 I have to make multiple commits to multiple branches
 which sucks... Something random people do not understand!

 There is a pull mechanism... Why was that not used??

 Maintaining the stability of packages is hard enough
 esp packages everybody uses... but that stability
 goes out the window when random people allowed to
 make random changes...

 Who are these super humans, how do they become 
 super humans and why aren't they required to 
 use the pull mechanism?? 
>>>
>>> I don't agree with you, you may contact the super human and ask him why
>>> ? you may revert the commit . 
>> Overhead that is simply not needed if the maintainer was consulted first.
> 
> How would the overhead be lower? Instead of a single clean commit that
> does what needs to be done you want the person doing this cleanup on a
> hundred packages to send you a special message and wait while you make
> the decision whether to allow a three line change or not? Please explain.
Who determines "needs to be done" Shouldn't the owner of the package be in
on the determination, with silents being acceptance after a certain amount
of time? I think so.

Yes to your second question... For one reason... maintaining stability.
You give people the ability to change anything and everything they
want w/out any review... that is called instability... 

With the only accept being the mass rebuild that are done.
If something is breaking that then that has to be fixed, asap.
 
steved. 
   
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: no updates since Monday

[Kevin Fenzi]

On 12/08/2017 06:26 AM, Chuck Anderson wrote:
> On Fri, Dec 08, 2017 at 09:25:05AM -0500, Chuck Anderson wrote:
>> Does anyone know why there have been no updates or changes to any of
>> the Fedora repos (including rawhide) since Monday?
> 
> Darn, I just found the announcement about the data center move.  Never mind...

Yep.

The good news is that we have completed all the moves and only have
cleanup/cabling and such to do. There's some updates pushes just started
this morning that should be out this afternoon.

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

[Mark Wielaard]

On Fri, 2017-12-08 at 10:17 -0500, Przemek Klosowski wrote:
> I still don't quite understand why only some packages have the 
> debuginfo/debugsource split (I counted ~10k debugsources to ~30k 
> debuginfo). Is that an automatic process that just needs to happen
> over time, or do the maintainers need to hand-polish individual
> packages?

No, that is expected.

There is one debugsources package per source rpm.
And there is one debuginfo package per binary subpackage.

This is because the subpackages are build from the same sources, so
they cannot easily be split.

See also:
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 08:31:44AM -0500, Steve Dickson wrote:
> 
> 
> On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
> > On 2017-12-07 09:31, Steve Dickson wrote:
> >> What do I have to do to stop random people 
> >> from making random changes to packages I maintain? 
> >>
> >> How do people get this type of permission?
> > 
> > https://fedoraproject.org/wiki/Provenpackager_policy
> > 
> >> Case in point;
> > [snip]
> > 
> > These were properly announced:
> > 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> > 
> > This is proper use of the provenpackager privileges.
> Which will lead to the instability... IMHO... Allowing people to
> to change technology that they are clueless of is just wrong.

I think that's exactly the point ;)
We are allowing people who have the knack and inclination to do "boring"
cleanups to do them so that _maintainers_ can actually concentrate on
_technology_.

From your message one could think that the changes are some massive
reworking, but both commits are completely trivial updates of
dependencies on package names that have been gone for _years_.

Unless you want to say that the change is somehow wrong, please
don't say that "poeple [...] are clueless", because that's disingenuous.

Zbyszek

> What is the point of maintainers-ship if any one and everyone can 
> make changes? Any and all changes must go through the maintainer
> if that is not the case the way even have them?
>  
> steved.
>  
> > 
> > 
> > 
> > ___
> > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 10:59:20AM -0500, Steve Dickson wrote:
> 
> 
> On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Dec 08, 2017 at 09:14:35AM -0500, Steve Dickson wrote:
> >>
> >>
> >> On 12/07/2017 06:13 PM, Sérgio Basto wrote:
> >>> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
>  Hello,
> 
>  What do I have to do to stop random people 
>  from making random changes to packages I maintain? 
> 
>  How do people get this type of permission?
> 
>  Case in point;
> 
>  commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
>  origin/master, origin/HEAD)
>  Author: Igor Gnatenko 
>  Date:   Tue Nov 7 16:31:21 2017 +0100
> 
>  Remove old crufty coreutils requires
>  
>  Signed-off-by: Igor Gnatenko 
> 
>  commit 66851ea12370a786844262620a40b0a2ac9632ce
>  Author: Igor Gnatenko 
>  Date:   Tue Nov 7 16:31:14 2017 +0100
> 
>  systemd-units -> systemd
>  
>  Signed-off-by: Igor Gnatenko 
> 
>  Where committed to the master branch and not to any other
>  branch make the maintenance of those branches a pain 
>  because I can no longer cherry-pick between branches.
>  I have to make multiple commits to multiple branches
>  which sucks... Something random people do not understand!
> 
>  There is a pull mechanism... Why was that not used??
> 
>  Maintaining the stability of packages is hard enough
>  esp packages everybody uses... but that stability
>  goes out the window when random people allowed to
>  make random changes...
> 
>  Who are these super humans, how do they become 
>  super humans and why aren't they required to 
>  use the pull mechanism?? 
> >>>
> >>> I don't agree with you, you may contact the super human and ask him why
> >>> ? you may revert the commit . 
> >> Overhead that is simply not needed if the maintainer was consulted first.
> > 
> > How would the overhead be lower? Instead of a single clean commit that
> > does what needs to be done you want the person doing this cleanup on a
> > hundred packages to send you a special message and wait while you make
> > the decision whether to allow a three line change or not? Please explain.
> Who determines "needs to be done" Shouldn't the owner of the package be in
> on the determination, with silents being acceptance after a certain amount
> of time? I think so.

This is completely infeasible to contact each maintainer individually
when doing massive changes. The policy specifies that the mass change
should be pre-announced, discussed, and announced on the mailing list.
This procedure was followed, the changes are simple and correct.

> Yes to your second question... For one reason... maintaining stability.
> You give people the ability to change anything and everything they
> want w/out any review... that is called instability... 

No, those changes don't have any effect on the way that your package
operates, they just change the reference from an obsolete name to
one that actually exists. Without such changes we would have more
and more obsolete cruft in packages. It's great that somebody is willing
to spend their time keeping the distro tidy. Change, if done carefully,
does not mean instability.

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

Re: What to I have to do....

[Stephen John Smoogen]

On 8 December 2017 at 11:40, Steve Dickson  wrote:
>
>
> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>> Well, I'd say this works great. There's maybe a hundred or two hundred
>> proven packagers and somehow none of them decide to mess up the kernel
>> any day. In fact, the commits which caused this thread are _correct_:
>> so far I haven't heard one word to the contrary. I don't see any point
>> in discussing hypotheticals.
> You are telling me there hundreds of people that have complete
> control over all the packages in fedora with no boundaries???
> They can do anything they what??? Wow...
>

This seems to come up after every major release.. a change is
announced, it goes through the process, and then the proven developer
makes the change.. and then some developer has their package changed
and complains that they didn't read the announcements, they don't like
the fact that proven packagers can touch their packages, and similar
things. We then have a long thread war where the developer finds out
how many proven packagers there are and go on a tear about how did
this happen?

In the past, the next step is "If you don't like it open a ticket with
FESCO with a plan on how to deal with this because the mailing list is
just going to be an echo chamber and nothing will be changed".

I believe in the past this has led to some changes but I am not as
much a developer as someone with a long memory of regular flamewars.

> steved.
> ___
> 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: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:28 AM, Kalev Lember wrote:
> On 12/08/2017 05:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Fri, Dec 08, 2017 at 10:59:20AM -0500, Steve Dickson wrote:
>>>
>>>
>>> On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
 How would the overhead be lower? Instead of a single clean commit that
 does what needs to be done you want the person doing this cleanup on a
 hundred packages to send you a special message and wait while you make
 the decision whether to allow a three line change or not? Please explain.
>>> Who determines "needs to be done" Shouldn't the owner of the package be in
>>> on the determination, with silents being acceptance after a certain amount
>>> of time? I think so.
>>
>> This is completely infeasible to contact each maintainer individually
>> when doing massive changes. The policy specifies that the mass change
>> should be pre-announced, discussed, and announced on the mailing list.
>> This procedure was followed, the changes are simple and correct.
My apologies for not making myself clear... I understand the
need to make massive changes... The problem I have is a single
change is made because it "feels" right... Those changes need to
go by the maintainer.

>>
>>> Yes to your second question... For one reason... maintaining stability.
>>> You give people the ability to change anything and everything they
>>> want w/out any review... that is called instability... 
>>
>> No, those changes don't have any effect on the way that your package
>> operates, they just change the reference from an obsolete name to
>> one that actually exists. Without such changes we would have more
>> and more obsolete cruft in packages. It's great that somebody is willing
>> to spend their time keeping the distro tidy. Change, if done carefully,
>> does not mean instability.
> 
> I wholeheartedly agree with Zbyszek here. Well said.
I too agree WRT massive build and/or changes... but anything
else need to go through them maintainer. 

steved.

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 12:10 PM, Mathieu Bridon wrote:
> On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
>> On 12/08/2017 11:46 AM, Mathieu Bridon wrote:
>>> You're blowing this way out of proportion, as if this was a
>>> catastrophe. History shows that it isn't.
>>
>> Maybe I am... Would not be the first time! ;-)
>>
>> In last couple of months there were a couple of changes
>> that were non-critical so I'm getting the feeling
>> people are getting a bit embolden... which is worrisome.
>>
>> Then on the other hand I get these pull-requests that
>> work so well! 
>>
>> So I just don't understand why for non-massive changes
>> why is it not required to go through the pull-request
>> process?
> 
> This wasn't a trivial change.
> 
> It certainly was trivial for each package it got applied to, but it got
> applied to quite a few packages.
> 
> That's essentially a similar change to mass-rebuilds, just at a smaller
> scale.
> 
> It was also announced properly on this list, enough time in advance, so
> it shouldn't have taken you by surprise.
> 
> If you really want to insist on the maintainers's responsibilities,
> start by reading announcements on this list.
:-) This is a very tough list to keep up with I generally 
look for things on delve-annou...@lists.fedoraproject.org
I must have missed it... 

pull-request go directly to my in box... much easier to find ;-)

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

Re: What to I have to do....

[Dominik 'Rathann' Mierzejewski]

On Friday, 08 December 2017 at 18:07, Steve Dickson wrote:
[...]
> > A proven packager is not someone random, they were given access
> > based on various criteria and that IMHO includes the fact that
> > their perception or "feels" about what has to be done on other
> > people's packages, is aligned with what has to be done for the
> > overall improvement of the distribution. 
> Fine... I understand your point... they have broader perspective...
> 
> But can't they ask the maintainer to act on their feeling via a
> pull-request?

Who says they can't or shouldn't? I think you're preaching to the
choir here... Before pagure, I used to open a bug on bugzilla
and threaten to commit the proposed change myself if there was no
reaction in a week or two. Now, for one-off change I'd definitely
open a pull request.

Regards,
Dominik (provenpackager)
-- 
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

Summary/Minutes from today's FESCo Meeting (2017-12-08)

[Till Maas]

===
#fedora-meeting: FESCO (2017-12-08)
===


Meeting started by tyll at 16:05:46 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2017-12-08/fesco.2017-12-08-16.05.log.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2017-12-08)

[Till Maas]

===
#fedora-meeting: FESCO (2017-12-08)
===


Meeting started by tyll at 16:05:46 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2017-12-08/fesco.2017-12-08-16.05.log.html



Meeting summary
---
* LINK: https://pagure.io/fesco/issue/1799   (orc_fedo, 16:07:22)
* init process  (tyll, 16:08:37)

* #1799 The ProvenPackager rubric needs more formality  (tyll, 16:10:01)
  * orc_fedo would be ok to table the issue since it was filed yesterday
(tyll, 16:10:39)
  * LINK: https://pagure.io/fesco/issue/1799#comment-483725   (tyll,
16:11:11)
  * AGREED: delay a week to discuss this and allow the proposal to be
refined (+7, 0, 0)  (tyll, 16:20:25)

* Next week's chair  (tyll, 16:21:22)
  * ACTION: dgilmore will chair next meeting  (tyll, 16:22:19)
  * next two meetings will be December 15th then  January 5th
(dgilmore, 16:23:30)

* Open Floor  (tyll, 16:23:50)
  * elections are expected to be in January  (tyll, 16:24:33)
  * all candidates for election please be on top of questions when they
come up. report to #fedora-admin and/or
https://pagure.io/fedora-infrastructure/ any issues with infra when
submitting  (dgilmore, 16:32:36)
  * ACTION: everyone think about how to make sure the next election runs
smoothly  (tyll, 16:33:29)

Meeting ended at 16:35:21 UTC.




Action Items

* dgilmore will chair next meeting
* everyone think about how to make sure the next election runs smoothly




Action Items, by person
---
* dgilmore
  * dgilmore will chair next meeting
* **UNASSIGNED**
  * everyone think about how to make sure the next election runs
smoothly




People Present (lines said)
---
* tyll (36)
* dgilmore (27)
* orc_fedo (13)
* jforbes (13)
* zodbot (12)
* nirik (10)
* bowlofeggs (9)
* kalev (8)
* sgallagh (5)
* steved (3)
* jsmith (0)
* maxamillion (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


16:05:46  #startmeeting FESCO (2017-12-08)
16:05:46  Meeting started Fri Dec  8 16:05:46 2017 UTC.  The chair is 
tyll. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:46  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
16:05:46  The meeting name has been set to 'fesco_(2017-12-08)'
16:05:50  #meetingname fesco
16:05:50  The meeting name has been set to 'fesco'
16:05:50  .hellow2
16:05:53  .hello2
16:05:54  bowlofeggs: bowlofeggs 'Randy Barlow' 

16:05:56  #chair maxamillion dgilmore nirik jforbes jsmith kalev sgallagh 
bowlofeggs tyll
16:05:56  Current chairs: bowlofeggs dgilmore jforbes jsmith kalev 
maxamillion nirik sgallagh tyll
16:05:59  .hello2
16:06:00  sgallagh: sgallagh 'Stephen Gallagher' 
16:06:02  .hello2
16:06:03  I guess we could just try to start
16:06:04  kalev: kalev 'Kalev Lember' 
16:06:05  .hello2
16:06:06  jforbes: jforbes 'Justin M. Forbes' 
16:06:10  .hello till
16:06:11  tyll: till 'Till Maas' 
16:06:28  morning
16:07:00 * orc_fedo said, pre logging: I have no problem with my bug being held 
over to let it be considered by more attendees
16:07:16  what's your bug?
16:07:22  https://pagure.io/fesco/issue/1799
16:07:30  only thing on the agenda
16:07:45 * kalev nods.
16:08:00  ... I just filed it yestarday pm, so it really has not 
'aged' yet
16:08:36  hey all
16:08:37  #topic init process
16:09:08  I count six members, so we have quorum
16:10:01  #topic #1799 The ProvenPackager rubric needs more formality
16:10:14  .fesco 1799
16:10:15  tyll: Issue #1799: The ProvenPackager rubric needs more 
formality - fesco - Pagure - https://pagure.io/fesco/issue/1799
16:10:39  #info orc_fedo would be ok to table the issue since it was 
filed yesterday
16:10:52  tyll: I suggested that in the bug
16:11:09  oops -- ment to but the post did not take
16:11:09  orc_fedo: ah, ok
16:11:11  https://pagure.io/fesco/issue/1799#comment-483725
16:11:33  I am fine with holding it over a week to let it be more 
thoughtfully considered
16:11:40  this is being discussed extensively on the devel list right now
16:11:40  guess it DID take
16:11:48  kalev: I know
16:12:06  Yup, just like it is roughly once a year...
16:12:13  for what it's worth, I'm with zbyszek here and think that 
adding more process to doing distro wide cleanups makes them just too painful 
to do
16:12:43  some thoughts are tecninical workflow questions, but the 
real problem a PP is not considering what the maintainer might have in mind
16:12:43  kalev: indeed
16:12:46 * steved to agrees with zbyszek with massive builds... if something 
gets in the way it has to be fixed
16:12:56  yeah i also am not in favor of this proposal
16:13:30  I am good with delaying discussion a week to aloow for more 
discussion and refinement of the proposal
16:13:32  its hard to make it more 

Re: What to I have to do....

[Charalampos Stratakis]

- Original Message -
> From: "Steve Dickson" 
> To: "Development discussions related to Fedora" 
> , "Charalampos Stratakis"
> 
> Cc: "Zbigniew Jędrzejewski-Szmek" , "Yaakov Selkowitz" 
> 
> Sent: Friday, December 8, 2017 5:46:03 PM
> Subject: Re: What to I have to do
> 
> 
> 
> On 12/08/2017 11:21 AM, Charalampos Stratakis wrote:
> > The kernel is actually blacklisted from proven packager access, you can't
> > make changes there.
> This is good to know... how do you get on that list? ;-)
> > 
> > Apart from that though, I don't really see any reasons for creating this
> > thread.
> > 
> > Proven packagers do trivial and non-trivial cleanups all the time. While I
> > agree that a PR would be better,
> > when dealing with changes on a vast amount of packages that should be
> > ideally done in a timely manner, waiting for a
> > timely response from every single maintainer of the respective packages is
> > just not realistic.
> I understand the need to make massive changes... I no problem with that...
> The problem is random people are making non-critical, non-massive
> changes because they "feel" its the right thing to do. Those
> changes should go through the maintainer.
> 
> steved.
> 

You will have to realize though, that at the moment you are currently talking 
from your perspective and only, so basically about your "feels" on the matter.

And while certainly there might have been cases where a proven packager acted 
inappropriately, I don't see that particular case as such.

A proven packager is not someone random, they were given access based on 
various criteria and that IMHO includes the fact that their perception or 
"feels"
about what has to be done on other people's packages, is aligned with what has 
to be done for the overall improvement of the distribution. 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:46 AM, Mathieu Bridon wrote:
> On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
>>
>> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>> Well, I'd say this works great. There's maybe a hundred or two
>>> hundred proven packagers and somehow none of them decide to mess up
>>> the kernel any day. In fact, the commits which caused this thread
>>> are _correct_:
>>> so far I haven't heard one word to the contrary. I don't see any
>>> point in discussing hypotheticals.
>>
>> You are telling me there hundreds of people that have complete
>> control over all the packages in fedora with no boundaries???
>> They can do anything they what??? Wow...
> 
> And it's working just fine, because overall people understand their
> responsibilities and don't abuse their powers.
> 
> If someone ever does go too far, their probvenpackagers permissions can
> be revoked and the bad changes they made can be reverted.
Good to know... 
> 
> You're blowing this way out of proportion, as if this was a
> catastrophe. History shows that it isn't.
Maybe I am... Would not be the first time! ;-)

In last couple of months there were a couple of changes
that were non-critical so I'm getting the feeling
people are getting a bit embolden... which is worrisome.

Then on the other hand I get these pull-requests that
work so well! 

So I just don't understand why for non-massive changes
why is it not required to go through the pull-request
process?

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

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 10:45:47AM -0600, Michael Cronenworth wrote:
> On 12/08/2017 10:40 AM, Steve Dickson wrote:
> >You are telling me there hundreds of people that have complete
> >control over all the packages in fedora with no boundaries???
> >They can do anything they what??? Wow...
> 
> Not really. There are a handful of packages that are protected. I
> tried to push a grub2 update for a change that maintainers ignored
> for years. I couldn't create updates in Bodhi and my rawhide build,
> although successful, was not properly signed for release to the
> repos.

That's true. I made a stab [1] at having those "special" packages
documented in the spec file a while back, so that proven packagers
would know that certain packages should not be touched, but it never
went anywhere (FPC only clarified the guideline that dist-git is the
canonical source of the spec file).

[1] https://pagure.io/packaging-committee/issue/613

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:54 AM, Simo Sorce wrote:
> On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
>>
>> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>> Well, I'd say this works great. There's maybe a hundred or two hundred
>>> proven packagers and somehow none of them decide to mess up the kernel
>>> any day. In fact, the commits which caused this thread are _correct_:
>>> so far I haven't heard one word to the contrary. I don't see any point
>>> in discussing hypotheticals.
>>
>> You are telling me there hundreds of people that have complete
>> control over all the packages in fedora with no boundaries???
>> They can do anything they what??? Wow...
> 
> 
> Steve, this is not really shocking.
> Git has history, so you can always see anything that changes, and
> maintainers are supposed to keep an eye on their packages and so they
> will see any malicious intent immediately, right ?
Right.
> If it is not malicious it is just helping, and there is nothing wrong
> with that.
But if it is non-massive, non-critical shouldn't the maintainer be notified?
All I'm saying yes, via a pull-request.

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

Re: What to I have to do....

[Emmanuel Seyman]

* Steve Dickson [08/12/2017 12:11] :
>
> But if it is non-massive, non-critical shouldn't the maintainer be notified?

If it's trivial, I'm ok with being informed via fedmsg telling me a commit has
been made. In this case, this was a trivial fix that the maintainer should have
done years ago so I can understand the provenpackager not going through the
whole pull-request song and dance.

In another thread, another fedora packager is asking that we stop sending all
email to packagers, arguing that nobody actually needs to know the history of
their packages, only their current state. The contrast between this packager's
opinion and yours is... interesting.

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

Re: What to I have to do....

[Justin Forbes]

On Fri, Dec 8, 2017 at 10:33 AM, Pierre-Yves Chibon  wrote:
> On Fri, Dec 08, 2017 at 11:21:10AM -0500, Charalampos Stratakis wrote:
>> - Original Message -
>> > > Unless you want to say that the change is somehow wrong, please
>> > > don't say that "poeple [...] are clueless", because that's disingenuous.
>> > Fair enough... "clueless" was probably not the most appropriate
>> > term to use... But I just read this policy.
>> >
>> >https://fedoraproject.org/wiki/Provenpackager_policy
>> >
>> > It is very broad... IHMO.. You open a ticket, get three acks
>> > a boom! You know have complete access every Fedora package
>> > including the kernel... hmm...
>> >
>>
>> The kernel is actually blacklisted from proven packager access, you can't 
>> make changes there.
>
> While this used to be true it hasn't been for a while now, I think the last
> packages that are restricted are: xulrunner, thunderbird and firefox due to
> mozilla's trademark policy on them.
>
Kernel has a different protection mechanism, where anyone with commit
access can do a build, but only the kernel team can do a signed build.
Even people who contribute to the kernel regularly cannot do signed
builds.

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

Re: What to I have to do....

[Adam Williamson]

On Fri, 2017-12-08 at 10:45 -0600, Michael Cronenworth wrote:
> On 12/08/2017 10:40 AM, Steve Dickson wrote:
> > You are telling me there hundreds of people that have complete
> > control over all the packages in fedora with no boundaries???
> > They can do anything they what??? Wow...
> 
> Not really. There are a handful of packages that are protected. I tried to 
> push a 
> grub2 update for a change that maintainers ignored for years. I couldn't 
> create 
> updates in Bodhi and my rawhide build, although successful, was not properly 
> signed 
> for release to the repos.

The whole boot chain is restricted in this way due to Secure Boot,
basically; we have to restrict who is allowed to build boot chain
packages to satisfy requirements of the Secure Boot signing program.
-- 
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: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Well, I'd say this works great. There's maybe a hundred or two hundred
> proven packagers and somehow none of them decide to mess up the kernel
> any day. In fact, the commits which caused this thread are _correct_:
> so far I haven't heard one word to the contrary. I don't see any point
> in discussing hypotheticals.
You are telling me there hundreds of people that have complete
control over all the packages in fedora with no boundaries???
They can do anything they what??? Wow...

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

Re: What to I have to do....

[Michael Cronenworth]

On 12/08/2017 10:40 AM, Steve Dickson wrote:

You are telling me there hundreds of people that have complete
control over all the packages in fedora with no boundaries???
They can do anything they what??? Wow...


Not really. There are a handful of packages that are protected. I tried to push a 
grub2 update for a change that maintainers ignored for years. I couldn't create 
updates in Bodhi and my rawhide build, although successful, was not properly signed 
for release to the repos.

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

Re: What to I have to do....

[Mathieu Bridon]

On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
> 
> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Well, I'd say this works great. There's maybe a hundred or two
> > hundred proven packagers and somehow none of them decide to mess up
> > the kernel any day. In fact, the commits which caused this thread
> > are _correct_:
> > so far I haven't heard one word to the contrary. I don't see any
> > point in discussing hypotheticals.
> 
> You are telling me there hundreds of people that have complete
> control over all the packages in fedora with no boundaries???
> They can do anything they what??? Wow...

And it's working just fine, because overall people understand their
responsibilities and don't abuse their powers.

If someone ever does go too far, their probvenpackagers permissions can
be revoked and the bad changes they made can be reverted.

You're blowing this way out of proportion, as if this was a
catastrophe. History shows that it isn't.


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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:21 AM, Charalampos Stratakis wrote:
> The kernel is actually blacklisted from proven packager access, you can't 
> make changes there.
This is good to know... how do you get on that list? ;-) 
> 
> Apart from that though, I don't really see any reasons for creating this 
> thread.
> 
> Proven packagers do trivial and non-trivial cleanups all the time. While I 
> agree that a PR would be better,
> when dealing with changes on a vast amount of packages that should be ideally 
> done in a timely manner, waiting for a
> timely response from every single maintainer of the respective packages is 
> just not realistic.
I understand the need to make massive changes... I no problem with that...
The problem is random people are making non-critical, non-massive 
changes because they "feel" its the right thing to do. Those
changes should go through the maintainer. 

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:59 AM, Charalampos Stratakis wrote:
> 
> 
> - Original Message -
>> From: "Steve Dickson" 
>> To: "Development discussions related to Fedora" 
>> , "Charalampos Stratakis"
>> 
>> Cc: "Zbigniew Jędrzejewski-Szmek" , "Yaakov Selkowitz" 
>> 
>> Sent: Friday, December 8, 2017 5:46:03 PM
>> Subject: Re: What to I have to do
>>
>>
>>
>> On 12/08/2017 11:21 AM, Charalampos Stratakis wrote:
>>> The kernel is actually blacklisted from proven packager access, you can't
>>> make changes there.
>> This is good to know... how do you get on that list? ;-)
>>>
>>> Apart from that though, I don't really see any reasons for creating this
>>> thread.
>>>
>>> Proven packagers do trivial and non-trivial cleanups all the time. While I
>>> agree that a PR would be better,
>>> when dealing with changes on a vast amount of packages that should be
>>> ideally done in a timely manner, waiting for a
>>> timely response from every single maintainer of the respective packages is
>>> just not realistic.
>> I understand the need to make massive changes... I no problem with that...
>> The problem is random people are making non-critical, non-massive
>> changes because they "feel" its the right thing to do. Those
>> changes should go through the maintainer.
>>
>> steved.
>>
> 
> You will have to realize though, that at the moment you are currently talking 
> from your perspective and only, so basically about your "feels" on the matter.
> 
> And while certainly there might have been cases where a proven packager acted 
> inappropriately, I don't see that particular case as such.
I agree..
> 
> A proven packager is not someone random, they were given access based on 
> various criteria and that IMHO includes the fact that their perception or 
> "feels"
> about what has to be done on other people's packages, is aligned with what 
> has to be done for the overall improvement of the distribution. 
Fine... I understand your point... they have broader perspective...

But can't they ask the maintainer to act on their feeling via a pull-request?

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

Re: What to I have to do....

[Adam Williamson]

On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
> Then on the other hand I get these pull-requests that
> work so well! 
> 
> So I just don't understand why for non-massive changes
> why is it not required to go through the pull-request
> process?

There is a pedestrian reason, which is that the pull request system is
very *new*. It's only been there a couple of months. So it's not
surprising that all existing policies haven't been rewritten around it.

But there are also the practical reasons others have given several
times but you have just ignored in your multiple replies. Put yourself
in the shoes of a provenpackager who needs to make corresponding
changes to, say, 50 packages. All those changes need to go through
before an important modernization/cleanup to another package can be
completed, for instance.

Now you file 50 pull requests. And wait. And wait. And wait...

How long will it be before you can get the modernization/cleanup
finished? You're going to be sitting there waiting for 50 people to
respond to pull requests, and it's a racing certainty at least one of
them just *won't*. In the mean time you'll be working on other things,
and losing track. It just makes it much harder to get important stuff
done. Fedora is a *distribution*, and a large part of being a
distribution is some level of consistency in the way we provide
software to people. It's *important* that we have a mechanism by which
we can make a reasonable cut at having multiple packages, maintained by
different people, do things the same way - and have the packages
changed promptly when those policies change.

I wouldn't say this is an open-and-shut case, there are reasonable
arguments in favor of using the PR process for changes, sometimes or
always. But I agree with other folks that you're not doing yourself any
favours by acting as if this policy is clearly insane and you're the
only sane person in the room, and as if there had been some sort of
major controversy or disaster when there hasn't. Someone fixed up some
dependencies in your package which you should've fixed yourself years
ago. That's the sum total of what happened. Your git complaints don't
seem to make sense to anyone else and you've refused to explain exactly
what this special workflow you have is despite more than one person
specifically asking you.

Important note: I'm a proven packager. I make changes to other packages
when I judge that it's appropriate to do so, under the policy.
-- 
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: What to I have to do....

[Kevin Fenzi]

On 12/08/2017 08:33 AM, Pierre-Yves Chibon wrote:
> On Fri, Dec 08, 2017 at 11:21:10AM -0500, Charalampos Stratakis wrote:
>> - Original Message -
 Unless you want to say that the change is somehow wrong, please
 don't say that "poeple [...] are clueless", because that's disingenuous.
>>> Fair enough... "clueless" was probably not the most appropriate
>>> term to use... But I just read this policy.
>>>
>>>https://fedoraproject.org/wiki/Provenpackager_policy
>>>
>>> It is very broad... IHMO.. You open a ticket, get three acks
>>> a boom! You know have complete access every Fedora package
>>> including the kernel... hmm...
>>>
>>
>> The kernel is actually blacklisted from proven packager access, you can't 
>> make changes there.
> 
> While this used to be true it hasn't been for a while now, I think the last
> packages that are restricted are: xulrunner, thunderbird and firefox due to
> mozilla's trademark policy on them.

The be 100% clear, there's 2 different kinds of packages that
provenpackagers cannot "affect":

1. as mentioned, firefox and thunderbird due to trademark (xulrunner
used to be, but it's dead now) provenpackagers cannot commit to these
packages.

2. There's a small number of packages in the secure-boot channel that
build on secure boot builders, but only if submitted by users with the
secure-boot permission. Provenpackages can commit changes to these
packages fine, but any builds they do will not be tagged in.
These packages currently are: kernel shim grub2 fedora-release
fedora-repos pesign.

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: What to I have to do....

[Simo Sorce]

On Fri, 2017-12-08 at 12:11 -0500, Steve Dickson wrote:
> 
> On 12/08/2017 11:54 AM, Simo Sorce wrote:
> > On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
> > > 
> > > On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > Well, I'd say this works great. There's maybe a hundred or two hundred
> > > > proven packagers and somehow none of them decide to mess up the kernel
> > > > any day. In fact, the commits which caused this thread are _correct_:
> > > > so far I haven't heard one word to the contrary. I don't see any point
> > > > in discussing hypotheticals.
> > > 
> > > You are telling me there hundreds of people that have complete
> > > control over all the packages in fedora with no boundaries???
> > > They can do anything they what??? Wow...
> > 
> > 
> > Steve, this is not really shocking.
> > Git has history, so you can always see anything that changes, and
> > maintainers are supposed to keep an eye on their packages and so they
> > will see any malicious intent immediately, right ?
> 
> Right.
> > If it is not malicious it is just helping, and there is nothing wrong
> > with that.
> 
> But if it is non-massive, non-critical shouldn't the maintainer be notified?
> All I'm saying yes, via a pull-request.

This would be ideal, yes, but for very trivial and obviously correct
changes I do not see the strict need for that overhead.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Simo Sorce]

On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
> 
> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Well, I'd say this works great. There's maybe a hundred or two hundred
> > proven packagers and somehow none of them decide to mess up the kernel
> > any day. In fact, the commits which caused this thread are _correct_:
> > so far I haven't heard one word to the contrary. I don't see any point
> > in discussing hypotheticals.
> 
> You are telling me there hundreds of people that have complete
> control over all the packages in fedora with no boundaries???
> They can do anything they what??? Wow...


Steve, this is not really shocking.
Git has history, so you can always see anything that changes, and
maintainers are supposed to keep an eye on their packages and so they
will see any malicious intent immediately, right ?
If it is not malicious it is just helping, and there is nothing wrong
with that.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Mathieu Bridon]

On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
> On 12/08/2017 11:46 AM, Mathieu Bridon wrote:
> > You're blowing this way out of proportion, as if this was a
> > catastrophe. History shows that it isn't.
> 
> Maybe I am... Would not be the first time! ;-)
> 
> In last couple of months there were a couple of changes
> that were non-critical so I'm getting the feeling
> people are getting a bit embolden... which is worrisome.
> 
> Then on the other hand I get these pull-requests that
> work so well! 
> 
> So I just don't understand why for non-massive changes
> why is it not required to go through the pull-request
> process?

This wasn't a trivial change.

It certainly was trivial for each package it got applied to, but it got
applied to quite a few packages.

That's essentially a similar change to mass-rebuilds, just at a smaller
scale.

It was also announced properly on this list, enough time in advance, so
it shouldn't have taken you by surprise.

If you really want to insist on the maintainers's responsibilities,
start by reading announcements on this list.


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

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 11:52:21AM -0500, Steve Dickson wrote:
> 
> 
> On 12/08/2017 11:28 AM, Kalev Lember wrote:
> > On 12/08/2017 05:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >> On Fri, Dec 08, 2017 at 10:59:20AM -0500, Steve Dickson wrote:
> >>>
> >>>
> >>> On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  How would the overhead be lower? Instead of a single clean commit that
>  does what needs to be done you want the person doing this cleanup on a
>  hundred packages to send you a special message and wait while you make
>  the decision whether to allow a three line change or not? Please explain.
> >>> Who determines "needs to be done" Shouldn't the owner of the package be in
> >>> on the determination, with silents being acceptance after a certain amount
> >>> of time? I think so.
> >>
> >> This is completely infeasible to contact each maintainer individually
> >> when doing massive changes. The policy specifies that the mass change
> >> should be pre-announced, discussed, and announced on the mailing list.
> >> This procedure was followed, the changes are simple and correct.
> My apologies for not making myself clear... I understand the
> need to make massive changes... The problem I have is a single
> change is made because it "feels" right... Those changes need to
> go by the maintainer.
> 
> >>
> >>> Yes to your second question... For one reason... maintaining stability.
> >>> You give people the ability to change anything and everything they
> >>> want w/out any review... that is called instability... 
> >>
> >> No, those changes don't have any effect on the way that your package
> >> operates, they just change the reference from an obsolete name to
> >> one that actually exists. Without such changes we would have more
> >> and more obsolete cruft in packages. It's great that somebody is willing
> >> to spend their time keeping the distro tidy. Change, if done carefully,
> >> does not mean instability.
> > 
> > I wholeheartedly agree with Zbyszek here. Well said.
> I too agree WRT massive build and/or changes... but anything
> else need to go through them maintainer. 

Well, it _is_ a massive change: ignatenkobrain is removing references
to systemd-units. According to repoquery, in F26 there are 369
packages with R: systemd-units. I'd say that 369 qualifies as "mass".

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

Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[nicolas . mailhot]

Hi,

I am proposing for inclusion a macro set aimed at automating the packaging of 
forge-hosted projects.

— Packaging draft: 
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
— FPC ticket: https://pagure.io/packaging-committee/issue/719 (without the 
“hasdraft” tag because I don't know how to add it in pagure)
— fedora-rpm-macros RFE with the macro file: 
https://bugzilla.redhat.com/show_bug.cgi?id=1523779

What it does: conversion of a forge url, version, tag, commit set to the values 
expected in rpm specfiles, in optional rpm variables. Computation of the 
corresponding %{dist}.

Objective: centralize forge structure know-how in a single technical place, 
deprecate all the complex manual forge URL handling spread over many Fedora 
spec files, simplify packaging and spend time on more interesting stuff.

What's currently implemented: definitions for github.com and 
code.googlesource.com
(I didn't want to propose stuff I didn't use myself. Adding more definitions is 
trivial. The macros are in Lua which is change-friendly, no arcane rpm syntax 
knowledge is needed).

Please consult packaging draft for full information.

This is a spin-off of the work I'm currently doing on Go packaging, as Go is 
heavily forge-oriented. I took the time to extract the generic non-Go-specific 
forge knowledge in a separate macro file. The macros have been heavily tested 
on real-life Go projects with quite a lot of variance, on EL7 and rawhide. 
That's why they come with built-in error handling.

Regards,

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 12:33 PM, Adam Williamson wrote:
> On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
>> Then on the other hand I get these pull-requests that
>> work so well! 
>>
>> So I just don't understand why for non-massive changes
>> why is it not required to go through the pull-request
>> process?
> 
> There is a pedestrian reason, which is that the pull request system is
> very *new*. It's only been there a couple of months. So it's not
> surprising that all existing policies haven't been rewritten around it.
Fair enough... It is a very good system. 

> 
> But there are also the practical reasons others have given several
> times but you have just ignored in your multiple replies. Put yourself
> in the shoes of a provenpackager who needs to make corresponding
> changes to, say, 50 packages. All those changes need to go through
> before an important modernization/cleanup to another package can be
> completed, for instance.
> 
> Now you file 50 pull requests. And wait. And wait. And wait...
Guilty as charged... :-) 

This is a massive change... I do get that.. 

> 
> How long will it be before you can get the modernization/cleanup
> finished? You're going to be sitting there waiting for 50 people to
> respond to pull requests, and it's a racing certainty at least one of
> them just *won't*. In the mean time you'll be working on other things,
> and losing track. It just makes it much harder to get important stuff
> done. Fedora is a *distribution*, and a large part of being a
> distribution is some level of consistency in the way we provide
> software to people. It's *important* that we have a mechanism by which
> we can make a reasonable cut at having multiple packages, maintained by
> different people, do things the same way - and have the packages
> changed promptly when those policies change.
> 
> I wouldn't say this is an open-and-shut case, there are reasonable
> arguments in favor of using the PR process for changes, sometimes or
> always. But I agree with other folks that you're not doing yourself any
> favours by acting as if this policy is clearly insane and you're the
> only sane person in the room, and as if there had been some sort of
> major controversy or disaster when there hasn't. 
Sane person?? You are actually calling me a sane person!?? That's a first... ;-)

I just think its odd to have so many people that can changes so
much without any boundaries... I just didn't realize that was the case.

> Someone fixed up some
> dependencies in your package which you should've fixed yourself years
> ago. That's the sum total of what happened. Your git complaints don't
> seem to make sense to anyone else and you've refused to explain exactly
> what this special workflow you have is despite more than one person
> specifically asking you.
This time... but there has been other changes... 

> 
> Important note: I'm a proven packager. I make changes to other packages
> when I judge that it's appropriate to do so, under the policy.
> 
I think making these single changes via the PR system would be
the best policy.

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

Re: [Fedora-packaging] Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[Matthew Miller]

On Fri, Dec 08, 2017 at 07:03:48PM +0100, nicolas.mail...@laposte.net wrote:
> I am proposing for inclusion a macro set aimed at automating the packaging of 
> forge-hosted projects.

Could we be more specific about what "forges" are supported? I see
github and googlesource.com in the examples, but I think this is more
discoverable for people packaging if we call them out more clearly.

Also, is "forge" synonymous with "git hosting service" as used here?
https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services


Ah, here

> What's currently implemented: definitions for github.com and 
> code.googlesource.com

Could open-source solutions pagure.io and gitlab.com be added, please?

-- 
Matthew Miller

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

Re: [Fedora-packaging] Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[nicolas . mailhot]

De: "Matthew Miller"
On Fri, Dec 08, 2017 at 07:03:48PM +0100, nicolas.mail...@laposte.net wrote:
>> I am proposing for inclusion a macro set aimed at automating the packaging 
>> of forge-hosted projects.

> Also, is "forge" synonymous with "git hosting service" as used here?

Here a "forge" is pretty much anything that allows access to version/commit/tag 
archives on normalized paths, that can be deduced from project root URL on the 
"forge" + version/commit/tag/scm info.

>> What's currently implemented: definitions for github.com and 
>> code.googlesource.com

> Could open-source solutions pagure.io and gitlab.com be added, please?

Well I currently do not use those, so I wouldn't know what definitions to add :)

It takes maximum 5 min, for someone who knows the structure of a "forge" to add 
it to the macro, it's just a copy of an existing "if (forge == something) then" 
block, adaptation of the lua regexps to extract the correct variables from the 
URL path, and then use of the result in the inner if tag/version/commit block 
to set rpm variables

The hard part was to define a generic macro structure, with a packager-friendly 
API, sane rpm variable names, reasonable rule ordering and error handling.

Regards,

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

Re: What to I have to do....

[Matthias Runge]

On Fri, Dec 08, 2017 at 11:46:03AM -0500, Steve Dickson wrote:
> 
> 
> On 12/08/2017 11:21 AM, Charalampos Stratakis wrote:
> > The kernel is actually blacklisted from proven packager access, you can't 
> > make changes there.
> This is good to know... how do you get on that list? ;-) 
> > 
> > Apart from that though, I don't really see any reasons for creating this 
> > thread.
> > 
> > Proven packagers do trivial and non-trivial cleanups all the time. While I 
> > agree that a PR would be better,
> > when dealing with changes on a vast amount of packages that should be 
> > ideally done in a timely manner, waiting for a
> > timely response from every single maintainer of the respective packages is 
> > just not realistic.
> I understand the need to make massive changes... I no problem with that...
> The problem is random people are making non-critical, non-massive 
> changes because they "feel" its the right thing to do. Those
> changes should go through the maintainer. 

Now this has gone back and forth. The system worked more or less ok.
Maybe it is more about the changes (and communication) of a
specific provenpackager?

There has been a recent thread "stop messing with other people packages",
and Iwonder who the mentioned proven packager was in that case.

I had once a case, where even a bug was filed by the pp, the change
submitted and bug closed after. I was online and reading emails at
that time, but I didn't had the chance to react. I asked the pp to
wait for my reaction in a reasonable time before doing that again.

Unfortunately, some time later, the same proven packager changed
something else. It was just a cosmetic change, and he didn't even
try to contact me, neither via irc, nor email or bugzilla.

So, maybe this is just caused by the behaviour of a single person?

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

Re: What to I have to do....

[Florian Weimer]

On 12/08/2017 06:48 PM, Adam Williamson wrote:

On Fri, 2017-12-08 at 10:45 -0600, Michael Cronenworth wrote:

On 12/08/2017 10:40 AM, Steve Dickson wrote:

You are telling me there hundreds of people that have complete
control over all the packages in fedora with no boundaries???
They can do anything they what??? Wow...


Not really. There are a handful of packages that are protected. I tried to push 
a
grub2 update for a change that maintainers ignored for years. I couldn't create
updates in Bodhi and my rawhide build, although successful, was not properly 
signed
for release to the repos.


The whole boot chain is restricted in this way due to Secure Boot,
basically; we have to restrict who is allowed to build boot chain
packages to satisfy requirements of the Secure Boot signing program.


I'm not in any special Fedora group and I can build and tag glibc, so 
whatever protection is in place (if any is at all), it is very limited 
at best.


(While glibc is not itself part of the boot chain, it is part of its 
build process, and thus among of the trusted set of packages.)


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

Re: no updates since Monday

[Randy Barlow]

On 12/08/2017 09:25 AM, Chuck Anderson wrote:
> Does anyone know why there have been no updates or changes to any of
> the Fedora repos (including rawhide) since Monday?

It was due to the planned infrastructure datacenter move. I believe
updates went out today and things should be back to normal.



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

[Test-Announce] Proposal to CANCEL: 2017-12-11 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting tomorrow. I don't
think we have anything requiring discussion this week. If you're aware
of anything important we have to discuss this week, please do reply to
this mail and we can go ahead and run the meeting. Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Reminder: upcoming retirement of webkitgtk and webkitgtk3 packages

[Sérgio Basto]

On Thu, 2017-12-07 at 23:26 +, Sérgio Basto wrote:
> On Wed, 2017-12-06 at 16:19 -0800, Adam Williamson wrote:
> > On Thu, 2017-12-07 at 00:04 +, Sérgio Basto wrote:
> > > 
> > > hum Markdown plugin is build with GTK3 , the plus of GTK+ is
> > > confusing
> > > me 
> > 
> > GTK+ is the correct name of the project and the product. It is not
> > called GTK. "GTK+ 3" and "GTK 3" refer to the same thing, and "GTK+
> > 3"
> > is technically the correct name. (It was called GTK a long, long,
> > long
> > time ago and the + was added to indicate an OO rewrite, but that's
> > ancient history).
> 
> Thanks, I already can build geany-plugin-markdown with webkitgtk3-
> devel 

It is working with webkitgtk4 :) [1]

[1]
https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Rele
ases/build/685925/

Thank you Michael , btw about package naming IMHO webkitgtk4 should be
called webkit2gtk3 and for gtk4 webkit2gtk4
 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] 2017-12-11 @ 17:00 UTC - Fedora 28 Blocker Review Meeting

[Adam Williamson]

# F28 Blocker Review meeting
# Date: 2017-12-11
# Time: 17:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have two proposed blockers and one proposed freeze
exception for Fedora 28 Beta, and one proposed blocker for Fedora 28
Final, so let's have a quick review meeting on Monday.

If you have time over the weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F28 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Ambassadors] Re: Autumn Elections 2017 are cancelled

[Robert Mayr]

Il 08/dic/2017 12:39 AM, "Dominik 'Rathann' Mierzejewski" <
domi...@greysector.net> ha scritto:

On Thursday, 07 December 2017 at 18:54, Jan Kurik wrote:
> During the Autumn 2017 Election cycle we wanted to try a new approach
> in the way how Elections are organized [1]. Unfortunately, at the
> beginning of the Voting period we realized the new way does not work
> as expected [2] and even we tried to put some mitigation plan in place
> [3], we have not succeeded. To come up with some workable solution we
> have decided to cancel the currently running Autumn 2017 Elections and
> start it again in early January 2018. In upcoming days I will publish
> a schedule for the January 2018 Elections as well as more details on
> how we are going to organize it.

Who is "we" that "decided" to cancel the running elections? What were the
reasons for this "decision"? I object to this strongly. It doesn't look
like this "decision" was made through an open process as is the usual
Fedora way. I can't even find a Council ticket for this or a thread
in the council-discuss mailing list.

I'm afraid I'm losing confidence that the current Council is capable
of leading Fedora if they cannot even hold an election according to
the current documented rules without breaking them in more than one way.

I haven't checked if elections to the Council and Mindshare were
organized according to policy (maybe I should!), but with FESCo
elections, the following were broken:
1. Candidate nominations were accepted later than 3 days before
   the voting period started. This contradicts
   https://fedoraproject.org/wiki/FESCo_election_policy#Candidates
2. Candidates whose interviews weren't ready for publication before the
   start of the voting period were not disqualified. This contradicts
   https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

Due to not having enough (number of open seats + 25%) candidates on the
day before the voting period, the nomination period was extended by 3
days. Arguably, the extension should have happened 3 days earlier
and should have been made longer than 3 days because extending by 3 days
on the eve of the voting period start still doesn't give anyone a chance
to be nominated according to
https://fedoraproject.org/wiki/FESCo_election_policy#Candidates .
I'd have extended by at least a week, also due to infrastructure
instability this week. The interview readiness deadline was,
suprisingly, extended by a week, allowing candidates who couldn't be
bothered to write their interviews to be voted in anyway. Nothing was
said about disqualifying candidates who'd fail to publish their interviews
despite getting votes in the first few days of the elections.

Last but not least, I wonder why all elections are being cancelled
instead of just FESCo. This was not explained, either.

With sad regards,
Dominik
--
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
___
ambassadors mailing list -- ambassad...@lists.fedoraproject.org
To unsubscribe send an email to ambassadors-le...@lists.fedoraproject.org


It think you stated your opinion more than once now and I also know "we"
(Council) gave you all the reasons for any decision we took in public. We
wanted to try something new and it didn't work, it is not constructive at
all to continue with the same concerns neither by deleting interviews in
sign of protest.
I also think you know perfectly why all elections have been cancelled,
interviews were missing for several candidates and if we would have
cancelled just FESCo you probably would complain about the decision because
we treat bodies in different ways.
So, let's be constructive and eventually make proposals, we all are part of
a community, we are not politicians or either role, but want to have equal
elections with a smooth process.
If you have ideas to improve that (and I think you already did in some way)
we will and want to take that in consideration. We also have some new
tickets in Council pagure too about that.
Thanks.
Kind regards

==
Robert Mayr
(robyduck)
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

[Bug 1523893] New: perl-Log-Report-1.25 is available

[bugzilla]

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

Bug ID: 1523893
   Summary: perl-Log-Report-1.25 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Log-Report
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.25
Current version/release in rawhide: 1.23-1.fc28
URL: http://search.cpan.org/dist/Log-Report/

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

-- 
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 1512341] perl-Finance-Quote-1.47 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   ||perl-Finance-Quote-1.47-1.e
   ||l7



--- Comment #22 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1510220] perl-Finance-Quote-1.42 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.43-1.f |perl-Finance-Quote-1.43-1.f
   |c28 |c28
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   ||perl-Finance-Quote-1.47-1.e
   ||l7



--- Comment #47 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1509722] perl-Finance-Quote-1.40 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.41-1.f |perl-Finance-Quote-1.41-1.f
   |c28 |c28
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   ||perl-Finance-Quote-1.47-1.e
   ||l7



--- Comment #52 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1469031] Please update perl-Plack version

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Plack-1.0033-1.el7
 Resolution|--- |ERRATA
Last Closed||2017-12-08 22:28:50



--- Comment #8 from Fedora Update System  ---
perl-Plack-1.0033-1.el7 has been pushed to the Fedora EPEL 7 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
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 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Iterator-Simple-0.07-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-1aef2547f7

-- 
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 1522709] Upgrade perl-BibTeX-Parser to 1.01

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-BibTeX-Parser-1.01-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-65a2bcaaed

-- 
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 1522699] Upgrade perl-experimental to 0.019

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-experimental-0.019-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-120341939f

-- 
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 1523888] New: perl-libwww-perl-6.30 is available

[bugzilla]

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

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



Latest upstream release: 6.30
Current version/release in rawhide: 6.29-1.fc28
URL: http://search.cpan.org/dist/libwww-perl/

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

-- 
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 1523884] New: perl-DBIx-Simple-1.36 is available

[bugzilla]

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

Bug ID: 1523884
   Summary: perl-DBIx-Simple-1.36 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DBIx-Simple
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.36
Current version/release in rawhide: 1.35-19.fc27
URL: http://search.cpan.org/dist/DBIx-Simple/

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

-- 
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 1522699] Upgrade perl-experimental to 0.019

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-experimental-0.019-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-99702e925c

-- 
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 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-Iterator-Simple-0.07-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-b4277f16f9

-- 
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 1522709] Upgrade perl-BibTeX-Parser to 1.01

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-BibTeX-Parser-1.01-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-19c15a7e6e

-- 
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 1510220] perl-Finance-Quote-1.42 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.43-1.f |perl-Finance-Quote-1.43-1.f
   |c28 |c28
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   ||perl-Finance-Quote-1.47-1.f
   ||c25



--- Comment #48 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1509722] perl-Finance-Quote-1.40 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.41-1.f |perl-Finance-Quote-1.41-1.f
   |c28 |c28
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   ||perl-Finance-Quote-1.47-1.f
   ||c25



--- Comment #53 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1511240] perl-Finance-Quote-1.45 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   ||perl-Finance-Quote-1.47-1.f
   ||c25



--- Comment #31 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1006  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 768  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 350  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 248  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 245  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  80  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  78  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b8147c68   
openvpn-auth-ldap-2.0.3-15.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-71f816e116   
collectd-5.8.0-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-12e12a6bff   
borgbackup-1.1.3-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-08f3522912   
wordpress-4.9.1-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f58e92e860   
exim-4.89-4.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d704442ae7   
qpid-cpp-1.37.0-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-97efaab7e7   
tor-0.2.9.14-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f2055d3f62   
shellinabox-2.20-5.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-77cc9084cb   
nodejs-6.12.2-1.el7


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

MUMPS-5.1.2-2.el7
R-3.4.3-1.el7
SuperLU-5.2.0-5.el7
armadillo-8.300.0-1.el7
atop-2.3.0-6.el7
gajim-0.16.9-2.el7
gnome-shell-extension-disconnect-wifi-17-1.el7
google-droid-fonts-20120715-12.el7
gsmartcontrol-1.1.3-1.el7
hypre-2.11.2-2.el7
lcgdm-1.9.1-1.el7
libebur128-1.2.3-1.el7
meta-test-family-0.7.8-1.el7
mld2p4-2.1.0-6.el7
mlpack-2.2.5-2.el7
nbdkit-1.1.25-1.el7
nodejs-6.12.2-1.el7
pdc-client-1.8.0-4.el7
perl-EV-4.15-1.el7
petsc-3.8.1-3.el7
petsc4py-3.8.1-3.el7
pgdbf-0.6.2-2.el7
php-bartlett-PHP-CompatInfo-5.0.9-1.el7
php-phpmyadmin-sql-parser-4.2.4-1.el7
python-jsonmodels-2.2-1.el7
python-nbxmpp-0.6.1-1.el7
python-pymediainfo-2.2.0-1.el7
python-wikitcms-2.2.2-1.el7
relval-2.2.1-1.el7
shellinabox-2.20-5.el7
socket_wrapper-1.1.9-1.el7
spamassassin-iXhash2-2.05-12.el7
suricata-3.2.5-1.el7
tito-0.6.11-1.el7
tomcat-8.0.47-1.el7

Details about builds:



 MUMPS-5.1.2-2.el7 (FEDORA-EPEL-2017-e36735026b)
 A MUltifrontal Massively Parallel sparse direct Solver

Update Information:

- Related updates to several packages. - Super updated to 5.2.0 - hypre rebuilt
for superlu version bump - petsc version bump

References:

  [ 1 ] Bug #1498209 - superlu 5.2.0 on epel
https://bugzilla.redhat.com/show_bug.cgi?id=1498209




 R-3.4.3-1.el7 (FEDORA-EPEL-2017-cbd9d53432)
 A language for data analysis and graphics

Update Information:

R 3.4.3.




 SuperLU-5.2.0-5.el7 (FEDORA-EPEL-2017-e36735026b)
 Subroutines to solve sparse linear systems

Update Information:

- Related updates to several packages. - Super updated to 5.2.0 - hypre rebuilt
for superlu version bump - petsc version bump

References:

  [ 1 ] Bug #1498209 - superlu 5.2.0 on epel
https://bugzilla.redhat.com/show_bug.cgi?id=1498209




 armadillo-8.300.0-1.el7 (FEDORA-EPEL-2017-e36735026b)
 Fast C++ matrix library with syntax similar to MATLAB and Octave

Update Information:

- Related updates to several packages. - Super updated to 5.2.0 - hypre rebuilt
for superlu version bump - petsc version bump

[Bug 1408326] build perl-EV for EPEL7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #8 from Fedora Update System  ---
perl-EV-4.15-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f7e014081f

-- 
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 1510678] perl-Finance-Quote-1.44 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   ||perl-Finance-Quote-1.47-1.e
   ||l7



--- Comment #40 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1511240] perl-Finance-Quote-1.45 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   ||perl-Finance-Quote-1.47-1.e
   ||l7



--- Comment #30 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1510678] perl-Finance-Quote-1.44 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   ||perl-Finance-Quote-1.47-1.f
   ||c25



--- Comment #41 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1512341] perl-Finance-Quote-1.47 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c26 |c26
   |perl-Finance-Quote-1.47-1.f |perl-Finance-Quote-1.47-1.f
   |c27 |c27
   |perl-Finance-Quote-1.47-1.e |perl-Finance-Quote-1.47-1.e
   |l7  |l7
   ||perl-Finance-Quote-1.47-1.f
   ||c25



--- Comment #23 from Fedora Update System  ---
perl-Finance-Quote-1.47-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1515805] perl-Module-CoreList-5.20171120 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Module-CoreList-5.20171120-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1523894] perl-Protocol-WebSocket-0.22 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-Protocol-WebSocket-0.22-1.el7.src.rpm for
rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=23601769

-- 
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 1523894] perl-Protocol-WebSocket-0.22 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1365073
  --> https://bugzilla.redhat.com/attachment.cgi?id=1365073=edit
[patch] Update to 0.22 (#1523894)

-- 
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 1523894] New: perl-Protocol-WebSocket-0.22 is available

[bugzilla]

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

Bug ID: 1523894
   Summary: perl-Protocol-WebSocket-0.22 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Protocol-WebSocket
  Keywords: FutureFeature, Triaged
  Assignee: dd...@cpan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.22
Current version/release in rawhide: 0.21-1.fc28
URL: http://search.cpan.org/dist/Protocol-WebSocket/

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

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