Re: Removal of BuildRoot

[Vít Ondruch]

Dne 19.2.2018 v 15:30 Randy Barlow napsal(a):
> On 02/19/2018 06:19 AM, Vít Ondruch wrote:
>> The problem with Bodhi is that we don't use Bodhi for Rawhide where
>> majority of work should be done.
> There is an infrastructure hackathon in April where we hope to discuss a
> way to enable Bodhi for Rawhide so it can gate updates based on
> automated tests.
>
>

Cool! Good to hear that.


V.



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

Re: Removal of BuildRoot

[Neal Gompa]

On Mon, Feb 19, 2018 at 11:30 AM, Pierre-Yves Chibon
 wrote:
> On Mon, Feb 19, 2018 at 09:06:17AM -0500, Neal Gompa wrote:
>> failed tests do not show up
>> on the main page (probably was not considered because of how poorly
>> the test information fetching goes).
>
> I guess you're referring to the:
> `Tests Passed` under the `Test Gating Status` on the right hand side menu of
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-d7644a98e0
> or maybe the
> `Tests Waiting` under the same section at the same place in
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-e452cb1e69
>
> Or do you have something else in mind?
>

Those are fine and dandy, but I'm referring to when there are *any*
failed tests, their rows that show up under the "Automated Tests" tab
should also show up at the top of the "Details" tab, under a "Failed
Tests" section.

That way people can see them up front, click on them to see details,
and it's much more obvious why an update is being blocked.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Pierre-Yves Chibon]

On Mon, Feb 19, 2018 at 09:06:17AM -0500, Neal Gompa wrote:
> failed tests do not show up
> on the main page (probably was not considered because of how poorly
> the test information fetching goes).

I guess you're referring to the:
`Tests Passed` under the `Test Gating Status` on the right hand side menu of
https://bodhi.fedoraproject.org/updates/FEDORA-2018-d7644a98e0
or maybe the
`Tests Waiting` under the same section at the same place in
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e452cb1e69

Or do you have something else in mind?


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

Re: Removal of BuildRoot

[Randy Barlow]

On 02/17/2018 02:30 AM, Pierre-Yves Chibon wrote:
> Rpmlint can be configured using the --rpmlintconf/-r option or by setting a
> .rpmlint file in the working directory

There's an open RFE to get taskotron to use such a file, though it
hasn't yet been suggested that it use the same path as fedpkg:

https://pagure.io/taskotron/task-rpmlint/issue/5

I can't log in to Pagure right now for some reason, so I can't make that
suggestion, but hopefully I'll remember to once that gets fixed ☺



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

Re: Removal of BuildRoot

[Randy Barlow]

On 02/19/2018 06:19 AM, Vít Ondruch wrote:
> The problem with Bodhi is that we don't use Bodhi for Rawhide where
> majority of work should be done.

There is an infrastructure hackathon in April where we hope to discuss a
way to enable Bodhi for Rawhide so it can gate updates based on
automated tests.



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

Re: Removal of BuildRoot

[Petr Viktorin]

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


Yeah, well, I definitely agree that's how it should be done, but... did 
you see the script that handles the automatic pull requests? (If not, 
the first half is here: https://pagure.io/python-fixrequires, and the 
second half -- merging -- is not yet automated.)


Pagure's API around automatically creating and administering Pull 
Requests is, not yet useful enough. Selenium kinda works as a 
workaround. But I wouldn't recommend it, unless one of your goals is to 
find the issues, so this can eventually become the preferred workflow. 
(See e.g. https://pagure.io/pagure/issue/2803)


(Disclaimer: I'm not the one actually doing the work, I just heard the 
complaints...)



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


tl;dr: It's possible, people are slowly working on it, but it's not 
generally usable yet.



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

Re: Removal of BuildRoot

[Neal Gompa]

On Mon, Feb 19, 2018 at 6:19 AM, Vít Ondruch  wrote:
>
>
> Dne 17.2.2018 v 14:01 Neal Gompa napsal(a):
>> On Fri, Feb 16, 2018 at 4:24 PM, Jason L Tibbitts III  
>> wrote:
 "NG" == Neal Gompa  writes:
>>> NG> As upstream for rpmlint, I do not believe anyone cares at all about
>>> NG> rpmlint in Fedora.
>>>
>>> We seemingly care so little for it that the rpmlint status appears on
>>> every bodhi update.
>>>
>>> I did spend some time trying to make rpmlint better ages ago and kind of
>>> got blocked by the restriction that it (at the time) had to conform to
>>> whatever RHEL4 wanted.  But that was obviously a long time ago.
>>>
>>> NG> Until we can fail builds on rpmlint errors (as both Mageia and
>>> NG> openSUSE do), it's pointless to consider rpmlint as something that
>>> NG> ensures things stay clean and sane.
>>>
>>> If you can tolerate no false positives from rpmlint then there must be a
>>> pile of things it doesn't look at.  I always saw it as a useful advisory
>>> tool but have difficulty imagining that you could gate off of it.
>>>
>>> What I did was hack my local setup (which does auto-rpmlint directly
>>> within vim) to accept magic comments to tell it to stop complaining
>>> about certain things.  I recall suggesting that upstream a long time ago
>>> but not having much luck.  But again, we're talking over a decade here.
>>>
>> The problem with Bodhi
>
> The problem with Bodhi is that we don't use Bodhi for Rawhide where
> majority of work should be done.
>
>

Bodhi is too slow and too heavy for this. Before even thinking about
doing this, fix Bodhi first. For the majority of my updates, I can't
even *get* the check information, as it gets stuck fetching. Update
merging into releases takes too long, and failed tests do not show up
on the main page (probably was not considered because of how poorly
the test information fetching goes).

I still disagree with Bodhi gating Rawhide, but if you're going to
make things more difficult on people, at least fix it so Bodhi
provides some value consistently.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Vít Ondruch]

Dne 17.2.2018 v 14:01 Neal Gompa napsal(a):
> On Fri, Feb 16, 2018 at 4:24 PM, Jason L Tibbitts III  
> wrote:
>>> "NG" == Neal Gompa  writes:
>> NG> As upstream for rpmlint, I do not believe anyone cares at all about
>> NG> rpmlint in Fedora.
>>
>> We seemingly care so little for it that the rpmlint status appears on
>> every bodhi update.
>>
>> I did spend some time trying to make rpmlint better ages ago and kind of
>> got blocked by the restriction that it (at the time) had to conform to
>> whatever RHEL4 wanted.  But that was obviously a long time ago.
>>
>> NG> Until we can fail builds on rpmlint errors (as both Mageia and
>> NG> openSUSE do), it's pointless to consider rpmlint as something that
>> NG> ensures things stay clean and sane.
>>
>> If you can tolerate no false positives from rpmlint then there must be a
>> pile of things it doesn't look at.  I always saw it as a useful advisory
>> tool but have difficulty imagining that you could gate off of it.
>>
>> What I did was hack my local setup (which does auto-rpmlint directly
>> within vim) to accept magic comments to tell it to stop complaining
>> about certain things.  I recall suggesting that upstream a long time ago
>> but not having much luck.  But again, we're talking over a decade here.
>>
> The problem with Bodhi

The problem with Bodhi is that we don't use Bodhi for Rawhide where
majority of work should be done.


Vít


>  is that it's too late. By that point the build
> has been submitted, it's gone through all the steps involved in
> submitting updates, and to make matters worse, *all* test results are
> now hidden from people by default. It took me a while to figure out
> where the test results had gone after the change occurred. I honestly
> thought we had given up on those things initially. I've always felt
> that some of those tests should be happening post-build, not
> post-update submission. Failing builds on "obviously bad" packages
> makes for a bigger incentive to improve packaging.
>
> As for toleration of false positives, that's more of a sign that we
> don't quite have a well-tuned configuration and maybe there are some
> checks in rpmlint itself that need to be tweaked. In both Mageia and
> openSUSE, we have rpmlint policy packages that define the checks, the
> "scores", and the threshold in which it is bad enough to make
> something be rejected. The reason for this is because we want to block
> packages that are "obviously wrong" from being accepted by the build
> system. It's really the only way to make people consider improving
> their packaging. Everyone has tried nicer ways, and it doesn't work.
>
> And in both Mageia and openSUSE's case, you can define
> .rpmlintrc files that are picked up by the build system to
> ignore issues that are obvious false positives. Yes, this could be
> abused, and perhaps we shouldn't do that. But if you want packaging to
> improve, you need a way for people to reliably determine what they're
> doing is "good" or "bad". Right now, we don't have that, and my
> personal feeling is that if I spend the effort in doing so, it would
> be wasted because it wouldn't result in any improvement.
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Panu Matilainen]

On 02/16/2018 02:36 PM, Tomasz Kłoczko wrote:
On 16 February 2018 at 11:21, Panu Matilainen > wrote:

[..]

Not everybody runs rpmlint for everything they produce, on the
contrary I suspect it's fairly small percentage of packagers out
there that do. If rpm itself doesn't directly complain about such
things they'll simply never get cleaned up.


And this is why for example calling rpmlint should be one of the pre 
steps done by koji on sending build request.


People building packages on koji are an even smaller percentage because 
that's limited to the Fedora/EPEL ecosystem.


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

Re: Removal of BuildRoot

[Athos Ribeiro]

On Sun, Feb 18, 2018 at 09:13:22AM +0100, Pierre-Yves Chibon wrote:
> On Sat, Feb 17, 2018 at 10:37:08PM -0500, Neal Gompa wrote:
> > On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III  
> > wrote:
> > >> "DS" == David Sommerseth  writes:
> > >
> > > DS> False positives are also easily filtered out by adding .rpmlint to
> > > DS> the dist-git repository.
> > >
> > > Which is an absolutely terrible name for that.  Really.  Why would
> > > anyone at all ever think it is a good idea to _hide_ the file that
> > > controls that?
> > >
> > 
> > I agree. What do we need to do to change this to .rpmlintrc?
> 
> A pull-request to fedpkg or rpkg sounds like a good start :)

https://pagure.io/rpkg/pull-request/293

-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Tomasz Kłoczko]

On 18 February 2018 at 18:06, Stephen John Smoogen  wrote:
[..]
>> I think that you are not fully aware what you've just done.
>
> Actually I am fully aware. I have been agreeing with parts of what you
> have written but you keep thinking I am attacking you because I don't
> agree with everything you have written. Then you keep interpreting
> everything I say as some sort of agenda.

It is really sad to see a comment ignoring almost all technical
argumenta and main analogy with how kernel tree is maintained.
Instead, you are focusing *only* on one (first) sentence commenting
what do you think that I'm thinking.
Plase stop doing this and try to focus on the subject.

I can only say that you completely missed my point.
Please read my reply one more time and try to not think about who
wrote this reply, or at least try to read this reply without first
sentence.

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

Re: Removal of BuildRoot

[Stephen John Smoogen]

On 18 February 2018 at 00:46, Tomasz Kłoczko  wrote:
> On 16 February 2018 at 15:50, Stephen John Smoogen  wrote:
> [..]
>>
>> Even before EPEL-5 was EOL, very little of Fedora would compile out of
>>
>> the box and required massive amounts of %if and other hacks to even
>> try to compile from a rawhide spec file.
>>
>> If someone wanted to keep compiling for EL-5 they should branch the
>> code themselves and maintain it as such versus trying to keep the
>> cruft in the main tree. I believe that is what arbitrary branching is
>> for.
>
>
> I think that you are not fully aware what you've just done.

Actually I am fully aware. I have been agreeing with parts of what you
have written but you keep thinking I am attacking you because I don't
agree with everything you have written. Then you keep interpreting
everything I say as some sort of agenda.

The part that you are not getting though is that even if I agree with
you on parts makes it that it will happen any time soon. Fedora is not
a centrally ruled organization. It is a collection of people doing
what they want and bringing what they want to the OS. They will follow
guidelines and rules to a point and only after they have each
convinced themselves that the rule/guideline makes sense to them. Any
time someone tries to make people do things even if it is in their
best interest, it causes a majority of members to get their backs up,
fight, and ignore the solution.

That is the part I have disagreed with you on. The idea that somehow
you can enforce a large change like this even if you did all the
changes yourself. People would revert them and route around them in
ways that may make the original problem worse. If you want to get
something done, you have to build group consensus and you have to show
what you want multiple times even if you think the 49th time should
have been enough. And show is not usually in words. It is in having
specs and tools which help people see why it fixes a problem. And
finally you have to realize that there will always be a thousand
corner cases which will trump a central rule for some reason and need
case by case exceptions.

This is all I am going to be saying on this.

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

Re: Removal of BuildRoot

[Pierre-Yves Chibon]

On Sat, Feb 17, 2018 at 10:37:08PM -0500, Neal Gompa wrote:
> On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III  
> wrote:
> >> "DS" == David Sommerseth  writes:
> >
> > DS> False positives are also easily filtered out by adding .rpmlint to
> > DS> the dist-git repository.
> >
> > Which is an absolutely terrible name for that.  Really.  Why would
> > anyone at all ever think it is a good idea to _hide_ the file that
> > controls that?
> >
> 
> I agree. What do we need to do to change this to .rpmlintrc?

A pull-request to fedpkg or rpkg sounds like a good start :)


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

Re: Removal of BuildRoot

[Tomasz Kłoczko]

On 16 February 2018 at 15:50, Stephen John Smoogen  wrote:
[..]

> Even before EPEL-5 was EOL, very little of Fedora would compile out of
>
the box and required massive amounts of %if and other hacks to even
> try to compile from a rawhide spec file.
>
> If someone wanted to keep compiling for EL-5 they should branch the
> code themselves and maintain it as such versus trying to keep the
> cruft in the main tree. I believe that is what arbitrary branching is
> for.
>

I think that you are not fully aware what you've just done.
You just delivered *golden argument* on why EL{6,7} changes/tweaks should
be not be kept as %ifed part of the spec on master branch.

Than you very much because you succeeded on what I've been failing so far
here!!! :D

I can only repeat yet another time that only way solving whole class of
issues like those with EL*/EPEL is NOT keeping EL{6,7} relevant changes on
rawhide master branch!
If at least one person will checkout exact older Fedora branch, do
necessary updates, test it (somehow) and will be using such updated package
it is absolute minimum guarantee that such updates may be working correct.

At the moment each package has per Fedora version branches and some of the
packages el{6,7} branches.
It is hard to understand why it is in this case such duality that on master
are integrated changes relevant to el{6,7} or older Fedora on master.
What looks like handy from point of view single package maintainer creates
whole chaos on master branch and moving forward all changes in this point
with descent speed is only by this harder and harder from point of view of
Fedora as distribution
In other words .. what looks like useful feature on single package scale is
really UNACCEPTABLE on whole distro level.

If someone still has some doubts about necessary changes just ask
yourselves what would happen if Linus would be accepting in his kernel git
repo #ifdefed parts which will be used on older kernels? such #ifdefed
parts does not make any sense as whole tree is in EXACT kernel version!!!
-> such parts never would be tested!!!
Isn't it?

Because kernel has similar number of objects (text files) as Fedora, and
needs to be maintained *as consistent set*, it delivers working example
where some future Fedora changes should go.
Some package maintainers must as well step down on Earth to spot that what
they are doing *has bigger context*.
Why? Because it is only LOGICAL way of keeping everything as *working and
consistent set*.

Q: What generally happens with Linux kernel tree when Linus releases new
non-rc main kernel version?
A: Whole tree is cloned and maintained separately by people who at least
are using exact kernel version.

EXACTLY the same methodology should be applied in case of the Fedora.
In both cases (kernel and fedora) general methodology is determined quite
frankly by VCS tooling which in both cases is git.
With proper separations will be possible to remove INSTANTLY tons of
%ifings from rawhide specs which will make all specs *way more readable*
and NOT affected by any changes in older Fedoras or EL*.
Simpler form/shorter specs -> lower possibility of mistakes and lower
effort on understand what is done in exact spec.
It lowers energy barrier on introduce large scale changes (if they will be
needed) as well on any branches.

Q.E.D.

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

Re: Removal of BuildRoot

[Neal Gompa]

On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III  wrote:
>> "DS" == David Sommerseth  writes:
>
> DS> False positives are also easily filtered out by adding .rpmlint to
> DS> the dist-git repository.
>
> Which is an absolutely terrible name for that.  Really.  Why would
> anyone at all ever think it is a good idea to _hide_ the file that
> controls that?
>

I agree. What do we need to do to change this to .rpmlintrc?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Luya Tshimbalanga]

On 2018-02-15 04:44 PM, Jason L Tibbitts III wrote:
>> "LT" == Luya Tshimbalanga  writes:
> LT> When you get a chance, would you also update the spec guideline as
> LT> well?
>
> Which spec guideline did you mean?  If you were referring to the
> packaging guidelines, they have said that BuildRoot: should not be used
> since 2016:
>
> The BuildRoot: tag, Group: tag, and %clean section SHOULD NOT be used.
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
>
>  - J<

Thank you for the update, I missed that part. In that case, the
fedora-package needs to update as well as rpmdev-newspec command still
uses "rm -fr %{buildroot}" line.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net



0xD8A2609A.asc
Description: application/pgp-keys


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

Re: Removal of BuildRoot

[Randy Barlow]

On 02/17/2018 11:37 AM, Neal Gompa wrote:
> When tests have failures or
> warnings, they are _not_ featured on the update page itself.

The test tab shows the counts of passing, warning, and failing tests,
once they finish loading.



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

Re: Removal of BuildRoot

[Tomasz Kłoczko]

On 16 February 2018 at 12:43, Tom Hughes  wrote:

> On 16/02/18 12:36, Tomasz Kłoczko wrote:
>
>> On 16 February 2018 at 11:21, Panu Matilainen > > wrote:
>> [..]
>>
>> Not everybody runs rpmlint for everything they produce, on the
>> contrary I suspect it's fairly small percentage of packagers out
>> there that do. If rpm itself doesn't directly complain about such
>> things they'll simply never get cleaned up.
>>
>>
>> And this is why for example calling rpmlint should be one of the pre
>> steps done by koji on sending build request.
>> It would be good to perform at least one time a month rpmlint test across
>> all packages, and if it anything wrong automatically should be created git
>> issue or bugzilla ticket.
>>
>
> Well rpmlint would need to be made a lot better first. The rate of
> false positives at the moment is enormous.
>

With such approach always will be chicken and egg problem because rpmlint
will be not improving because it will be not used, and it will be not
improving because it will not widely used.
It is necessary to cut this loop somewhere, and if it will be added in
whole pipeline of the Fedora processes single change in rpmlint will
automatically expose some number of packages with some issues.
I'm 100% sure that even current rpmlint will expose some number of specs
which needs to be cleaned up.

"Not everybody runs rpmlint"

If everybody will be using rpmlint it will start improving .. as same as
"build it and they will come".

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

Re: Removal of BuildRoot

[Jason L Tibbitts III]

> "NG" == Neal Gompa  writes:

NG> What do you want it to be?

What the other distros use seems far better to me.  Alternately, just
"rpmlintrc".

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

Re: Removal of BuildRoot

[Neal Gompa]

On Sat, Feb 17, 2018 at 11:14 AM, Jason L Tibbitts III
 wrote:
>> "NG" == Neal Gompa  writes:
>
> NG> The problem with Bodhi is that it's too late.
>
> I don't disagree, but you've switched up your argument.  You made the
> statement that Fedora doesn't care about rpmlint so there's no point in
> improving it.  People do care, and rpmlint is featured in an important
> place in an important application.  It could even be used for gating,
> except that it gives far too many false positives.
>

You mentioned Bodhi, so I mentioned that where it happens is not
helpful. I could have also brought up the general attitude I encounter
from people in the mailing list and on IRC that rpmlint is useless and
its warnings and errors can be ignored, but that's not solvable
without making it a centerpiece in the package build process.

I would argue that the way Bodhi shows the update checks is actually
indicating that they're _not_ important. They're hidden away, and many
times, clicking on that tab will give you nothing but an endless
loading screen, which indicates that there's been no priority to
ensuring the test data is always accessible, anyway. It is _not_ front
and center in mock or koji builds. When tests have failures or
warnings, they are _not_ featured on the update page itself. They are
still hidden away.

Again, making the rpmlint policy that approximates Fedora packaging
guidelines is possible, but I don't think it'd be used.

> NG> And in both Mageia and openSUSE's case, you can define
> NG> .rpmlintrc files that are picked up by the build system
> NG> to ignore issues that are obvious false positives.
>
> And of course we have that, too, but it's not used in as many places.
> I would definitely want to get the name changed from the terrible
> ".rpmlint" before that happens, though.
>

What do you want it to be?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Jason L Tibbitts III]

> "NG" == Neal Gompa  writes:

NG> The problem with Bodhi is that it's too late.

I don't disagree, but you've switched up your argument.  You made the
statement that Fedora doesn't care about rpmlint so there's no point in
improving it.  People do care, and rpmlint is featured in an important
place in an important application.  It could even be used for gating,
except that it gives far too many false positives.

NG> And in both Mageia and openSUSE's case, you can define
NG> .rpmlintrc files that are picked up by the build system
NG> to ignore issues that are obvious false positives.

And of course we have that, too, but it's not used in as many places.
I would definitely want to get the name changed from the terrible
".rpmlint" before that happens, though.

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

Re: Removal of BuildRoot

[Jonny Heggheim]

On 02/13/2018 11:05 PM, Igor Gnatenko wrote:
> Just a small heads up, BuildRoot tag is not needed since RHEL6 (which
> is oldest
> supported one nowadays, it's been year or so after EL5 retirement). And we
> don't support EL5 anymore, so...
>
> I wanted to send this heads up before I actually did that, but I hit
> "enter"
> button too early.
>
> Anyway, this is straitghtforward change, so no one should notice anything
> (apart from one commit with, hopefully, useful description in their
> repositories) 😉

Thanks! I fully support changes like this.

Jonny




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

Re: Removal of BuildRoot

[Neal Gompa]

On Fri, Feb 16, 2018 at 4:24 PM, Jason L Tibbitts III  wrote:
>> "NG" == Neal Gompa  writes:
>
> NG> As upstream for rpmlint, I do not believe anyone cares at all about
> NG> rpmlint in Fedora.
>
> We seemingly care so little for it that the rpmlint status appears on
> every bodhi update.
>
> I did spend some time trying to make rpmlint better ages ago and kind of
> got blocked by the restriction that it (at the time) had to conform to
> whatever RHEL4 wanted.  But that was obviously a long time ago.
>
> NG> Until we can fail builds on rpmlint errors (as both Mageia and
> NG> openSUSE do), it's pointless to consider rpmlint as something that
> NG> ensures things stay clean and sane.
>
> If you can tolerate no false positives from rpmlint then there must be a
> pile of things it doesn't look at.  I always saw it as a useful advisory
> tool but have difficulty imagining that you could gate off of it.
>
> What I did was hack my local setup (which does auto-rpmlint directly
> within vim) to accept magic comments to tell it to stop complaining
> about certain things.  I recall suggesting that upstream a long time ago
> but not having much luck.  But again, we're talking over a decade here.
>

The problem with Bodhi is that it's too late. By that point the build
has been submitted, it's gone through all the steps involved in
submitting updates, and to make matters worse, *all* test results are
now hidden from people by default. It took me a while to figure out
where the test results had gone after the change occurred. I honestly
thought we had given up on those things initially. I've always felt
that some of those tests should be happening post-build, not
post-update submission. Failing builds on "obviously bad" packages
makes for a bigger incentive to improve packaging.

As for toleration of false positives, that's more of a sign that we
don't quite have a well-tuned configuration and maybe there are some
checks in rpmlint itself that need to be tweaked. In both Mageia and
openSUSE, we have rpmlint policy packages that define the checks, the
"scores", and the threshold in which it is bad enough to make
something be rejected. The reason for this is because we want to block
packages that are "obviously wrong" from being accepted by the build
system. It's really the only way to make people consider improving
their packaging. Everyone has tried nicer ways, and it doesn't work.

And in both Mageia and openSUSE's case, you can define
.rpmlintrc files that are picked up by the build system to
ignore issues that are obvious false positives. Yes, this could be
abused, and perhaps we shouldn't do that. But if you want packaging to
improve, you need a way for people to reliably determine what they're
doing is "good" or "bad". Right now, we don't have that, and my
personal feeling is that if I spend the effort in doing so, it would
be wasted because it wouldn't result in any improvement.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Pavel Raiskup]

On Friday, February 16, 2018 7:48:17 PM CET Tom Hughes wrote:
> On 16/02/18 18:26, David Sommerseth wrote:
> 
> > But my "worst" example was probably the openvpn package I'm now in charge 
> > for
> > (and I am a core upstream developer for that project as well).  But it 
> > didn't
> > take that much efforts to iron out most of those issues.  False positives 
> > are
> > also easily filtered out by adding .rpmlint to the dist-git repository.
> 
> I suspect approximately nobody knows that you can create such a file
> because as far as I can tell it's not well documented.
> 
> Even now having googled a bit I haven't managed to find anything telling
> me what I can put in it.

If I'm not wrong, rpmlint doesn't *itself* accept that file:
https://github.com/rpm-software-management/rpmlint/issues/125

Pavel


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

Re: Removal of BuildRoot

[Pierre-Yves Chibon]

On Fri, Feb 16, 2018 at 06:48:17PM +, Tom Hughes wrote:
> On 16/02/18 18:26, David Sommerseth wrote:
> 
> > But my "worst" example was probably the openvpn package I'm now in charge 
> > for
> > (and I am a core upstream developer for that project as well).  But it 
> > didn't
> > take that much efforts to iron out most of those issues.  False positives 
> > are
> > also easily filtered out by adding .rpmlint to the dist-git repository.
> 
> I suspect approximately nobody knows that you can create such a file
> because as far as I can tell it's not well documented.

$ fedpkg lint --help
usage: fedpkg lint [-h] [--info] [--rpmlintconf RPMLINTCONF]

Rpmlint can be configured using the --rpmlintconf/-r option or by setting a
.rpmlint file in the working directory

optional arguments:
  -h, --helpshow this help message and exit
  --info, -iDisplay explanations for reported messages
  --rpmlintconf RPMLINTCONF, -r RPMLINTCONF
Use a specific configuration file for rpmlint
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Jason L Tibbitts III]

> "DS" == David Sommerseth  writes:

DS> False positives are also easily filtered out by adding .rpmlint to
DS> the dist-git repository.

Which is an absolutely terrible name for that.  Really.  Why would
anyone at all ever think it is a good idea to _hide_ the file that
controls that?

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

Re: Removal of BuildRoot

[Jason L Tibbitts III]

> "NG" == Neal Gompa  writes:

NG> As upstream for rpmlint, I do not believe anyone cares at all about
NG> rpmlint in Fedora.

We seemingly care so little for it that the rpmlint status appears on
every bodhi update.

I did spend some time trying to make rpmlint better ages ago and kind of
got blocked by the restriction that it (at the time) had to conform to
whatever RHEL4 wanted.  But that was obviously a long time ago.

NG> Until we can fail builds on rpmlint errors (as both Mageia and
NG> openSUSE do), it's pointless to consider rpmlint as something that
NG> ensures things stay clean and sane.

If you can tolerate no false positives from rpmlint then there must be a
pile of things it doesn't look at.  I always saw it as a useful advisory
tool but have difficulty imagining that you could gate off of it.

What I did was hack my local setup (which does auto-rpmlint directly
within vim) to accept magic comments to tell it to stop complaining
about certain things.  I recall suggesting that upstream a long time ago
but not having much luck.  But again, we're talking over a decade here.

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

Re: Removal of BuildRoot

[Jason L Tibbitts III]

> "NK" == Nico Kadel-Garcia  writes:

NK> While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete.

epel-rpm-macros set up the default buildroot value for EPEL5 and thus
rendered the BuildRoot: tag unnecessary well before that release went
EOL.

But even without that it still doesn't matter; if you want to take a
Fedora spec and build it on EL5, you'll have more to worry about than
whether you need a BuildRoot: tag.  We can't avoid cleaning things up
because someone, somewhere might one day want to take a Fedora spec
unaltered and build it on RHEL5.  If that were a valid argument, then
why not RHEL4?  We had EPEL there, too (and like EL5 we celebrated when
it went EOL).

NK> Are there any EPEL tools that are identical to the upstream Fedora
NK> releases, that might still use any of htese for legacy environments?

Those old spec files are still checked into git.  You can get the old
spec if you want to and build it if that's really what you want.

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

Re: Removal of BuildRoot

[David Sommerseth]

On 16/02/18 19:48, Tom Hughes wrote:
> On 16/02/18 18:26, David Sommerseth wrote:
> 
>> But my "worst" example was probably the openvpn package I'm now in charge for
>> (and I am a core upstream developer for that project as well).  But it didn't
>> take that much efforts to iron out most of those issues.  False positives are
>> also easily filtered out by adding .rpmlint to the dist-git repository.
> 
> I suspect approximately nobody knows that you can create such a file
> because as far as I can tell it's not well documented.
> 
> Even now having googled a bit I haven't managed to find anything telling
> me what I can put in it.

Have a look here: /usr/share/doc/rpmlint*/config.example


-- 
kind regards,

David Sommerseth



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

Re: Removal of BuildRoot

[Tom Hughes]

On 16/02/18 18:26, David Sommerseth wrote:


But my "worst" example was probably the openvpn package I'm now in charge for
(and I am a core upstream developer for that project as well).  But it didn't
take that much efforts to iron out most of those issues.  False positives are
also easily filtered out by adding .rpmlint to the dist-git repository.


I suspect approximately nobody knows that you can create such a file
because as far as I can tell it's not well documented.

Even now having googled a bit I haven't managed to find anything telling
me what I can put in it.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[David Sommerseth]

On 16/02/18 17:21, Martin Kolman wrote:
> On Fri, 2018-02-16 at 10:52 -0500, Neal Gompa wrote:
[...snip...]
>> As upstream for rpmlint, I do not believe anyone cares at all about
>> rpmlint in Fedora. One more warning or error won't mean anything. From
>> time to time, I have considered making a proper rpmlint policy for
>> Fedora, but I always decide not to because it's clear that that people
>> don't care about it and ignore it.
>
> I think this is more or less a chicken and egg problem - rpmlint output is
> currently so insanely bad and useless that
> most people indeed ignore it. So arguably if the output was better more
> people would likely use it.

I certainly might be a weird guy with odd perspectives  or I'm haven't
touched packages which has had so enormous issues with rpmlint it didn't make
sense to fix it.  Or I'm lacking good enough experience (I've not been
maintaining that many Fedora packages).

But my "worst" example was probably the openvpn package I'm now in charge for
(and I am a core upstream developer for that project as well).  But it didn't
take that much efforts to iron out most of those issues.  False positives are
also easily filtered out by adding .rpmlint to the dist-git repository.

If anyone have examples of those really nasty rpmlint reports ... that would
be far more valuable to this discussion than just claiming it is "insanely bad
and useless".  And since we have the attention of the rpmlint maintainer,
perhaps there would be a better chance to figure out how to report those
issues in a better way - or remove what isn't truly an issue.


-- 
kind regards,

David Sommerseth



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

Re: Removal of BuildRoot

[Matěj Cepl]

On 2018-02-16, 12:36 GMT, Tomasz Kłoczko wrote:
> And this is why for example calling rpmlint should be one of 
> the pre steps done by koji on sending build request. It would 
> be good to perform at least one time a month rpmlint test 
> across all packages, and if it anything wrong automatically 
> should be created git issue or bugzilla ticket.

All that would be awesome (or even blocking Koji build on 
rpmlint errors), but rpmlint then have to be substantially 
better: I am not sure I met a real life package which would be 
completely silent (no warnings, no errors) on fedpkg lint.

It would be actually nice, if we could get there, but 
unfortunately it seems to me we are far from this goal yet (if 
anybody has that goal).

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Every developer’s hunt for the best editor ends up with Vim,
Emacs or a management position.
  -- Rolf Bjaanes
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Martin Kolman]

On Fri, 2018-02-16 at 10:52 -0500, Neal Gompa wrote:
> On Thu, Feb 15, 2018 at 11:19 AM, Jonathan Wakely
>  wrote:
> > On 15/02/18 11:10 -0500, David Cantrell wrote:
> > > 
> > > On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
> > > > 
> > > > On 15/02/18 08:46 -0500, David Cantrell wrote:
> > > > > 
> > > > > First, I actually don't care if this change is made or not.  My 
> > > > > personal
> > > > > opinion is that it's a nice-to-have cleanup that will probably not 
> > > > > cause
> > > > > problems, but you never know with that many packages.  So that's why I
> > > > > feel it should be approached using pull requests.  We have that
> > > > > functionality now thanks to Pagure, which is something we *never* had 
> > > > > in
> > > > > dist-cvs or the former git system.  Is that tedious?  Yeah, it is.  
> > > > > But
> > > > > pushing a change like that across many packages will not necessarily
> > > > > explain to package maintainers why that was done.  If packages have 
> > > > > not
> > > > > been cleaned up in that amount of time and things are still building, 
> > > > > I
> > > > > question the urgency of the change.  Pull requests give package
> > > > > maintainers an opportunity to be part of this change.  Others have
> > > > > pointed this out too.  Otherwise things like this will likely continue
> > > > > happening and package maintainers will overwhelming remain in the dark
> > > > > about what changes should be made in spec files.
> > > > 
> > > > 
> > > > What's the real benefit to getting each maintainer to remove the tag
> > > > themselves via a pull request? After they get the pull request and
> > > > understand the motivation they now know about something that should
> > > > not be in their spec files. Is it really necessary for them to know a
> > > > negative? Should they also remember a list of other tags that
> > > > shouldn't be in there, or should we just remove the cruft, make sure
> > > > the docs, examples and templates don't have those tags, and move on?
> > > > 
> > > > Remaining in the dark about a tag that has no meaning doesn't seem
> > > > harmful.
> > > 
> > > 
> > > My thinking there is that the PR serves as a way to communicate this
> > > change to package maintainers who have been copying existing spec files
> > > and templates to make new packages.  Concern was mentioned that package
> > > maintainers keep using this tag when they don't need to, so the message
> > > has not been received.  I think a PR serves as a good way to communicate
> > > that to maintainers.
> > 
> > 
> > So remove it from all our specs and templates and let it be forgotten.
> > 
> > People keep copying it from existing specs because nobody has done the
> > work of removing all the existing uses before now.
> > 
> > Once it's gone we can make rpmlint warn about it, so it doesn't keep
> > coming back.
> > 
> 
> As upstream for rpmlint, I do not believe anyone cares at all about
> rpmlint in Fedora. One more warning or error won't mean anything. From
> time to time, I have considered making a proper rpmlint policy for
> Fedora, but I always decide not to because it's clear that that people
> don't care about it and ignore it.
I think this is more or less a chicken and egg problem - rpmlint output is 
currently so insanely bad and useless that
most people indeed ignore it. So arguably if the output was better more people 
would likely use it.

> 
> Until we can fail builds on rpmlint errors (as both Mageia and
> openSUSE do), it's pointless to consider rpmlint as something that
> ensures things stay clean and sane.
> 
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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: Removal of BuildRoot

[Neal Gompa]

On Thu, Feb 15, 2018 at 11:19 AM, Jonathan Wakely
 wrote:
> On 15/02/18 11:10 -0500, David Cantrell wrote:
>>
>> On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
>>>
>>> On 15/02/18 08:46 -0500, David Cantrell wrote:

 First, I actually don't care if this change is made or not.  My personal
 opinion is that it's a nice-to-have cleanup that will probably not cause
 problems, but you never know with that many packages.  So that's why I
 feel it should be approached using pull requests.  We have that
 functionality now thanks to Pagure, which is something we *never* had in
 dist-cvs or the former git system.  Is that tedious?  Yeah, it is.  But
 pushing a change like that across many packages will not necessarily
 explain to package maintainers why that was done.  If packages have not
 been cleaned up in that amount of time and things are still building, I
 question the urgency of the change.  Pull requests give package
 maintainers an opportunity to be part of this change.  Others have
 pointed this out too.  Otherwise things like this will likely continue
 happening and package maintainers will overwhelming remain in the dark
 about what changes should be made in spec files.
>>>
>>>
>>> What's the real benefit to getting each maintainer to remove the tag
>>> themselves via a pull request? After they get the pull request and
>>> understand the motivation they now know about something that should
>>> not be in their spec files. Is it really necessary for them to know a
>>> negative? Should they also remember a list of other tags that
>>> shouldn't be in there, or should we just remove the cruft, make sure
>>> the docs, examples and templates don't have those tags, and move on?
>>>
>>> Remaining in the dark about a tag that has no meaning doesn't seem
>>> harmful.
>>
>>
>> My thinking there is that the PR serves as a way to communicate this
>> change to package maintainers who have been copying existing spec files
>> and templates to make new packages.  Concern was mentioned that package
>> maintainers keep using this tag when they don't need to, so the message
>> has not been received.  I think a PR serves as a good way to communicate
>> that to maintainers.
>
>
> So remove it from all our specs and templates and let it be forgotten.
>
> People keep copying it from existing specs because nobody has done the
> work of removing all the existing uses before now.
>
> Once it's gone we can make rpmlint warn about it, so it doesn't keep
> coming back.
>

As upstream for rpmlint, I do not believe anyone cares at all about
rpmlint in Fedora. One more warning or error won't mean anything. From
time to time, I have considered making a proper rpmlint policy for
Fedora, but I always decide not to because it's clear that that people
don't care about it and ignore it.

Until we can fail builds on rpmlint errors (as both Mageia and
openSUSE do), it's pointless to consider rpmlint as something that
ensures things stay clean and sane.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Stephen John Smoogen]

On 16 February 2018 at 03:14, Nico Kadel-Garcia  wrote:
> On Thu, Feb 15, 2018 at 7:44 PM, Jason L Tibbitts III  
> wrote:
>>> "LT" == Luya Tshimbalanga  writes:
>>
>> LT> When you get a chance, would you also update the spec guideline as
>> LT> well?
>>
>> Which spec guideline did you mean?  If you were referring to the
>> packaging guidelines, they have said that BuildRoot: should not be used
>> since 2016:
>>
>> The BuildRoot: tag, Group: tag, and %clean section SHOULD NOT be used.
>>
>> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
>>
>>  - J<
>
> While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. Are
> there any EPEL tools that are identical to the upstream Fedora
> releases, that might still use any of htese for legacy environments?

Speaking with my EPSCO hat on.

EPEL-5 was End of Lifed when RHEL-5 was considered end of normal life.
As such it was archived to /pub/archives/epel and koji will no longer
compose builds for it. Keeping EPEL-5 in the main SRPMs is the
equivalent of keeping Fedora 6 in main spec files.

Even before EPEL-5 was EOL, very little of Fedora would compile out of
the box and required massive amounts of %if and other hacks to even
try to compile from a rawhide spec file.

If someone wanted to keep compiling for EL-5 they should branch the
code themselves and maintain it as such versus trying to keep the
cruft in the main tree. I believe that is what arbitrary branching is
for.


> ___
> 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: Removal of BuildRoot

[Kevin Fenzi]

On 02/16/2018 12:14 AM, Nico Kadel-Garcia wrote:
> On Thu, Feb 15, 2018 at 7:44 PM, Jason L Tibbitts III  
> wrote:
>>> "LT" == Luya Tshimbalanga  writes:
>>
>> LT> When you get a chance, would you also update the spec guideline as
>> LT> well?
>>
>> Which spec guideline did you mean?  If you were referring to the
>> packaging guidelines, they have said that BuildRoot: should not be used
>> since 2016:
>>
>> The BuildRoot: tag, Group: tag, and %clean section SHOULD NOT be used.
>>
>> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
>>
>>  - J<
> 
> While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. Are
> there any EPEL tools that are identical to the upstream Fedora
> releases, that might still use any of htese for legacy environments?

Yes it does.

https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/DWVJYIYVQ4SPF77HAQUAIIMHHDDIDECG/

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: Removal of BuildRoot

[nicolas . mailhot]

> I don't follow. How else (other than manual download) do you get your
> sources other than by spectool? Surely if you download them manually
> you would notice any URL change?

You can have an old source copy in Sources (downloaded manually of by spectool) 
but by the time you finish QA and start Fedora inclusion process the origin 
website restructured and the Source URL is no longer good.

And many people check the URL still exists, but not that the returned filename 
has not changed (and lastly you have the hash)

That's one of the many reasons I had to write %forgemeta (it's available in 
devel, use it, test it report problems!)
 
Regards,

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

Re: Removal of BuildRoot

[Pierre-Yves Chibon]

On Fri, Feb 16, 2018 at 12:11:12PM +, Tomasz Kłoczko wrote:
>On 15 February 2018 at 09:17, Paul Howarth  wrote:
>[..]
> 
>  Same here. Whilst I don't mind this change, as it stands I'm getting no
>  notifications when the packages I maintain are changed by other people,
>  and that's supposed to be one of the safeguards against potential
>  errors by provenpackagers.
> 
>Looks like here it is some technical glitch .. :-/

Yes, there is a bug: https://github.com/fedora-infra/fmn/issues/275

>I'm not 100% sure how it is here with current default git settings but
>looks like package maintainers have not enabled watch settings on git
>repos which they own or to which they have RW access.

You're confusing the mechanism present on src.fp.o that is entirely opt-in and
replaces the old watchcommits and watchbugzilla flags from pkgdb with the
notifications that are automatically set for all packagers via FMN and which do
include notifications about all and every commits done to packages they maintain
(and which currently seems to have a bug).


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

Re: Removal of BuildRoot

[Richard Shaw]

On Fri, Feb 16, 2018 at 7:22 AM, Tom Hughes  wrote:

> On 16/02/18 13:13, Richard Shaw wrote:
>
> I think it would be better to have fedpkg run rpmlint on "fedpkg build".
>> It can be informative only. At least then it would not require the
>> maintainer to run rpmlint themselves.
>>
>
> Please no. See above about ridiculous noise.


Less noise that doing it on commit :)


One thing I started doing was ALWAYS using spectool to download the new
>> sources for an update before doing a fedpkg upload-sources. I found that
>> the download links moved from time to time with some upstreams. That way I
>> know my source URL is good.
>>
>
> I don't follow. How else (other than manual download) do you get your
> sources other than by spectool? Surely if you download them manually
> you would notice any URL change?
>

I get notifications for most of my packages which provide download links
which you can easily do "curl -LO " which is what I used to do.

Even better would be to be able to tell fedpkg to go download the source
directly instead of me downloading it and then uploading it.


>
> And it's fedpkg new-sources, not upload-sources ;-)


Ehh.. I went from memory after only one cup of coffee :)

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

Re: Removal of BuildRoot

[Tom Hughes]

On 16/02/18 13:13, Richard Shaw wrote:

I think it would be better to have fedpkg run rpmlint on "fedpkg build". 
It can be informative only. At least then it would not require the 
maintainer to run rpmlint themselves.


Please no. See above about ridiculous noise.

One thing I started doing was ALWAYS using spectool to download the new 
sources for an update before doing a fedpkg upload-sources. I found that 
the download links moved from time to time with some upstreams. That way 
I know my source URL is good.


I don't follow. How else (other than manual download) do you get your
sources other than by spectool? Surely if you download them manually
you would notice any URL change?

And it's fedpkg new-sources, not upload-sources ;-)

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Richard Shaw]

On Fri, Feb 16, 2018 at 6:43 AM, Tom Hughes  wrote:

> On 16/02/18 12:36, Tomasz Kłoczko wrote:
>
>> On 16 February 2018 at 11:21, Panu Matilainen > > wrote:
>> [..]
>>
>> Not everybody runs rpmlint for everything they produce, on the
>> contrary I suspect it's fairly small percentage of packagers out
>> there that do. If rpm itself doesn't directly complain about such
>> things they'll simply never get cleaned up.
>>
>>
>> And this is why for example calling rpmlint should be one of the pre
>> steps done by koji on sending build request.
>> It would be good to perform at least one time a month rpmlint test across
>> all packages, and if it anything wrong automatically should be created git
>> issue or bugzilla ticket.
>>
>
> Well rpmlint would need to be made a lot better first. The rate of
> false positives at the moment is enormous.
>
> In fact pretty much any non-trivial package has rpmlint warnings
> which are no problem at all, even if only spellcheck issues.


I think it would be better to have fedpkg run rpmlint on "fedpkg build". It
can be informative only. At least then it would not require the maintainer
to run rpmlint themselves.

One thing I started doing was ALWAYS using spectool to download the new
sources for an update before doing a fedpkg upload-sources. I found that
the download links moved from time to time with some upstreams. That way I
know my source URL is good.

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

Re: Removal of BuildRoot

[Tom Hughes]

On 16/02/18 12:36, Tomasz Kłoczko wrote:
On 16 February 2018 at 11:21, Panu Matilainen > wrote:

[..]

Not everybody runs rpmlint for everything they produce, on the
contrary I suspect it's fairly small percentage of packagers out
there that do. If rpm itself doesn't directly complain about such
things they'll simply never get cleaned up.


And this is why for example calling rpmlint should be one of the pre 
steps done by koji on sending build request.
It would be good to perform at least one time a month rpmlint test 
across all packages, and if it anything wrong automatically should be 
created git issue or bugzilla ticket.


Well rpmlint would need to be made a lot better first. The rate of
false positives at the moment is enormous.

In fact pretty much any non-trivial package has rpmlint warnings
which are no problem at all, even if only spellcheck issues.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Tomasz Kłoczko]

On 16 February 2018 at 11:21, Panu Matilainen  wrote:
[..]

> Not everybody runs rpmlint for everything they produce, on the contrary I
> suspect it's fairly small percentage of packagers out there that do. If rpm
> itself doesn't directly complain about such things they'll simply never get
> cleaned up.


And this is why for example calling rpmlint should be one of the pre steps
done by koji on sending build request.
It would be good to perform at least one time a month rpmlint test across
all packages, and if it anything wrong automatically should be created git
issue or bugzilla ticket.

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

Re: Removal of BuildRoot

[Matthew Miller]

On Fri, Feb 16, 2018 at 03:14:43AM -0500, Nico Kadel-Garcia wrote:
> While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. Are
> there any EPEL tools that are identical to the upstream Fedora
> releases, that might still use any of htese for legacy environments?

FWIW EPEL 5 systems checking for updates dropped significantly with
RHEL 5 EOL -- cut down to half or so, but still at about the same level
as the number of people running F25 still. (Less than F26 or F27.)

-- 
Matthew Miller

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

Re: Removal of BuildRoot

[Tomasz Kłoczko]

On 15 February 2018 at 09:17, Paul Howarth  wrote:
[..]

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

Looks like here it is some technical glitch .. :-/
I'm not 100% sure how it is here with current default git settings but
looks like package maintainers have not enabled watch settings on git repos
which they own or to which they have RW access.
If it is true I think that repo watch should be *by default enabled for all
main and secondary maintainers* and it would be good if someone will
execute some oneliner to enable such watches on all git repos on all git
accounts with RW access to exact git repo.
Lack of enabled watches seems is only reasons why some git PRs are not
handled by package maintainers ASAP.

Just check do you have enabled watch on your package git repo (web page
upper right corner -> small icon with eye -> Watch issues, PRs, and
Commits).

Another part of default settings should be what is in bugzilla.
IMO any changes about git repos maintainers should be AUTOMATICALLY
propagated to bugzilla as well.

I think that it would be good introduce policy stripping down RW git repo
access if someone will have disabled watch for some period (half year?)
and/or if email address registered in FAS settings will be rejecting send
email for some period of time (half year and/or +10 rejects?).
I have impression that many FAS accounts are already dead. Every 2-3 months
is done all packages mass rebuild so within half year will be at least 2-3
opportunities to check email communication with every package maintainer
which have RW access to +1 git repo.
Performing such check about disabled watch enough long time or not updated
email address one time a week and publishing list of repos which could be
taken over by other active maintainers could allow keep as much as possible
packages in healthy state.

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

Re: Removal of BuildRoot

[David Sommerseth]

On 16/02/18 09:14, Nico Kadel-Garcia wrote:
> On Thu, Feb 15, 2018 at 7:44 PM, Jason L Tibbitts III  
> wrote:
[...snip...]
> While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. Are
> there any EPEL tools that are identical to the upstream Fedora
> releases, that might still use any of htese for legacy environments?

Perhaps a silly and ignorant question  but is it still possible to send
builds to EPEL 5 repositories?  I thought that option got closed long ago,
together with RHEL 5 reaching EOL.


-- 
kind regards,

David Sommerseth



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

Re: Removal of BuildRoot

[Yanko Kaneti]

On Fri, 2018-02-16 at 13:21 +0200, Panu Matilainen wrote:
> On 02/16/2018 12:54 PM, Michael Schroeder wrote:
> > On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote:
> > > Actually, inspired by this thread, rpm will start at least warning about
> > > BuildRoot tag in the next release or so.
> > > 
> > > The reason for silently ignoring all this time was to allow spec sharing
> > > between old and new rpm versions, but I guess the time has come to bury it
> > > for good.
> > 
> > Please do not code packaging policies into rpm, that's what tools
> > like rpmlint are for.
> 
> I don't see long, long since obsoleted rpm tag being packaging policy 
> but a technical rpm matter.
> 
> Not everybody runs rpmlint for everything they produce, on the contrary 
> I suspect it's fairly small percentage of packagers out there that do. 
> If rpm itself doesn't directly complain about such things they'll simply 
> never get cleaned up.

...if only we could collectively decide to write less guidelines and
more rationales for rules enforced by tools... One can always dream.

In this particular case IMHO it would've been perfectly acceptable for
koji to start bombing on builds with specs containing BuildRoot

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

Re: Removal of BuildRoot

[Panu Matilainen]

On 02/16/2018 12:54 PM, Michael Schroeder wrote:

On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote:

Actually, inspired by this thread, rpm will start at least warning about
BuildRoot tag in the next release or so.

The reason for silently ignoring all this time was to allow spec sharing
between old and new rpm versions, but I guess the time has come to bury it
for good.


Please do not code packaging policies into rpm, that's what tools
like rpmlint are for.


I don't see long, long since obsoleted rpm tag being packaging policy 
but a technical rpm matter.


Not everybody runs rpmlint for everything they produce, on the contrary 
I suspect it's fairly small percentage of packagers out there that do. 
If rpm itself doesn't directly complain about such things they'll simply 
never get cleaned up.


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

Re: Removal of BuildRoot

[Michael Schroeder]

On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote:
> Actually, inspired by this thread, rpm will start at least warning about
> BuildRoot tag in the next release or so.
> 
> The reason for silently ignoring all this time was to allow spec sharing
> between old and new rpm versions, but I guess the time has come to bury it
> for good.

Please do not code packaging policies into rpm, that's what tools
like rpmlint are for.

Thanks,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX GmbH,   GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Panu Matilainen]

On 02/15/2018 06:19 PM, Jonathan Wakely wrote:

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

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

On 15/02/18 08:46 -0500, David Cantrell wrote:
First, I actually don't care if this change is made or not.  My 
personal
opinion is that it's a nice-to-have cleanup that will probably not 
cause

problems, but you never know with that many packages.  So that's why I
feel it should be approached using pull requests.  We have that
functionality now thanks to Pagure, which is something we *never* 
had in

dist-cvs or the former git system.  Is that tedious?  Yeah, it is.  But
pushing a change like that across many packages will not necessarily
explain to package maintainers why that was done.  If packages have not
been cleaned up in that amount of time and things are still building, I
question the urgency of the change.  Pull requests give package
maintainers an opportunity to be part of this change.  Others have
pointed this out too.  Otherwise things like this will likely continue
happening and package maintainers will overwhelming remain in the dark
about what changes should be made in spec files.


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

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


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


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

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

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


Actually, inspired by this thread, rpm will start at least warning about 
BuildRoot tag in the next release or so.


The reason for silently ignoring all this time was to allow spec sharing 
between old and new rpm versions, but I guess the time has come to bury 
it for good.


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

Re: Removal of BuildRoot

[Dan Horák]

On Fri, 16 Feb 2018 09:19:54 +0100
Pavel Raiskup  wrote:

> On Wednesday, February 14, 2018 5:44:57 PM CET Remi Collet wrote:
> > Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
> > > Just a small heads up, ...
> > 
> > As I said on IRC
> > 
> > - waste of time
> > - waste of energy
> > - absolutely no value
> > 
> > And
> > 
> > - abuse proven packager privileges
> 
> Agreed, and it is also non-systematic approach again, which only beats
> commit statistics ;-) right?  It is equivalent to setup a bot/UI which
> goes and periodically fixes repos.  Much nicer approach would be if
> you invented a way so packagers won't do the same mistakes again, so
> we don't have to do the cleanups all over again.

git hooks can be the solution, they can warn the maintainer, they can
disallow commit, they can remove the cruft ...


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

Re: Removal of BuildRoot

[Tomasz Kłoczko]

On 14 February 2018 at 16:44, Remi Collet  wrote:

> Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
> > Just a small heads up, ...
>
>
> As I said on IRC
>
> - waste of time
> - waste of energy
> - absolutely no value
>
> And
>
> - abuse proven packager privileges
>

Cutting the tail of some legacy stuff is never kind of abuse.
Not every Fedora packager has full up-to-date knowledge about how spec
files should be written and many people on preparing own changes are
peaking on other specs as examples. As such people will be able to find
some non-empty set of specs with some contradicting patterns only this will
be always source of confusion.

Such mass change is about keeping everything in sane form and up-to-date
condition.
However NOT cutting such tails IS abusive.

There is no ANY *rational* reasons why such legacy stuff should be kept on
Fedora master branch spec files.

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

Re: Removal of BuildRoot

[Pavel Raiskup]

On Wednesday, February 14, 2018 5:44:57 PM CET Remi Collet wrote:
> Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
> > Just a small heads up, ...
> 
> As I said on IRC
> 
> - waste of time
> - waste of energy
> - absolutely no value
> 
> And
> 
> - abuse proven packager privileges

Agreed, and it is also non-systematic approach again, which only beats
commit statistics ;-) right?  It is equivalent to setup a bot/UI which
goes and periodically fixes repos.  Much nicer approach would be if you
invented a way so packagers won't do the same mistakes again, so we don't
have to do the cleanups all over again.

Pavel


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

Re: Removal of BuildRoot

[Nico Kadel-Garcia]

On Thu, Feb 15, 2018 at 7:44 PM, Jason L Tibbitts III  wrote:
>> "LT" == Luya Tshimbalanga  writes:
>
> LT> When you get a chance, would you also update the spec guideline as
> LT> well?
>
> Which spec guideline did you mean?  If you were referring to the
> packaging guidelines, they have said that BuildRoot: should not be used
> since 2016:
>
> The BuildRoot: tag, Group: tag, and %clean section SHOULD NOT be used.
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
>
>  - J<

While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. Are
there any EPEL tools that are identical to the upstream Fedora
releases, that might still use any of htese for legacy environments?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Jason L Tibbitts III]

> "LT" == Luya Tshimbalanga  writes:

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

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

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

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

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

Re: Removal of BuildRoot

[Jonathan Wakely]

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

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

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

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


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

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


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


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

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

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

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

Re: Removal of BuildRoot

[David Cantrell]

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

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

Thanks,

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

Re: Removal of BuildRoot

[Luya Tshimbalanga]

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



0xD8A2609A.asc
Description: application/pgp-keys


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

Re: Removal of BuildRoot

[Jonathan Wakely]

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

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


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

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


I recognize the work is difficult and time consuming.


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

Re: Removal of BuildRoot

[Jonathan Wakely]

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

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


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

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


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


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

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


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


Do we have the resources to do that?


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

Re: Removal of BuildRoot

[Miro Hrončok]

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


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


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

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

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

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


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

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

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


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

Re: Removal of BuildRoot

[Randy Barlow]

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

There is an open issue about this:

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



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

Re: Removal of BuildRoot

[David Cantrell]

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

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

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

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

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

Thanks,

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

Re: Removal of BuildRoot

[David Cantrell]

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

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

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

I recognize the work is difficult and time consuming.

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

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

Re: Removal of BuildRoot

[Rex Dieter]

Michal Novotny wrote:

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

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

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

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

Re: Removal of BuildRoot

[Michal Novotny]

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

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

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


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

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

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

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


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

Re: Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

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

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

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

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

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

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

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

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

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

Re: Removal of BuildRoot

[Paul Howarth]

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

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

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

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

Re: Removal of BuildRoot

[Michal Novotny]

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

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

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

clime

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

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

Re: Removal of BuildRoot

[Panu Matilainen]

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

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

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

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

- abuse proven packager privileges

+1

+1


Please, read policy[0] once more.


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

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

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

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

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


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

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


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


For deitys sake.

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

Re: Removal of BuildRoot

[Miroslav Suchý]

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

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

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

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


Miroslav



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

Re: Removal of BuildRoot

[Panu Matilainen]

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

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

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

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

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

Just a small heads up, ...



As I said on IRC

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

And

- abuse proven packager privileges



+1


Ralf, Remi, David,

Please, read policy[0] once more.


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

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

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

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

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


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



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

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

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


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

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


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


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

Re: Removal of BuildRoot

[Vít Ondruch]

Dne 15.2.2018 v 07:55 Remi Collet napsal(a):
> Le 15/02/2018 à 07:47, Igor Gnatenko a écrit :
>> On Wed, 2018-02-14 at 14:06 -0500, Rob Crittenden wrote:
>>> nicolas.mail...@laposte.net wrote:
 Hi,

 Thank you for cleaning up the cruft in the repository !

 Regards,

>>> Agreed. I'm usually pretty anal about others touching packages I
>>> maintain without at least a heads-up but in this case it doesn't bother
>>> me. I guess particularly since he didn't spin up a build or poke the
>>> n-v-r so reverting it if I really hated it or it broke something would
>>> be trivially easy.
>>> As an aside, it might be nice though to be able to watch a package and
>>> get automated notifications when things change. I don't maintain that
>>> many packages though. I'd imagine that for some this could be rather
>>> onerous, but I had no idea these changed were applied until I went and
>>> looked.
>> It is possible with fedmsg which we use. You can set notifications in special
>> webservice[0] (although I find settings in it counter-intuitive). Simplest 
>> one
>> is to set up notifications on all packages you maintain.
> Sadly, commit notifications does NOT work for months
> (works for old packages, not for newly imported one)

It does not work at all. I did not get any notification about mass
rebuild changes what so ever. No build notifications, no commit
notifications, anything ...

V.

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

Re: Removal of BuildRoot

[Remi Collet]

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

Sadly, commit notifications does NOT work for months
(works for old packages, not for newly imported one)


Remi

> 
> 
> [0] https://apps.fedoraproject.org/notifications
> ___
> 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: Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-02-14 at 14:06 -0500, Rob Crittenden wrote:
> nicolas.mail...@laposte.net wrote:
> > Hi,
> > 
> > Thank you for cleaning up the cruft in the repository !
> > 
> > Regards,
> > 
> 
> Agreed. I'm usually pretty anal about others touching packages I
> maintain without at least a heads-up but in this case it doesn't bother
> me. I guess particularly since he didn't spin up a build or poke the
> n-v-r so reverting it if I really hated it or it broke something would
> be trivially easy.
> 
> As an aside, it might be nice though to be able to watch a package and
> get automated notifications when things change. I don't maintain that
> many packages though. I'd imagine that for some this could be rather
> onerous, but I had no idea these changed were applied until I went and
> looked.

It is possible with fedmsg which we use. You can set notifications in special
webservice[0] (although I find settings in it counter-intuitive). Simplest one
is to set up notifications on all packages you maintain.


[0] https://apps.fedoraproject.org/notifications
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqFLPsACgkQaVcUvRu8
X0wKAg/8CLwC1EubCyRYj5LCZfOToxMs3gU0uWQE81RYRRiFlgmMzs5Hw4H6K8XC
/Urix1yIGyPxBF79r/6sKoQsyhQpGDDZG6RmnYmilDWBC1JytjkN9UhnIc/lbyTP
+/gokc8+R1cPWEKXfHtW9dkJ6xvytcgEckr5Us/6psRxGL0WFbk6wv0UmSfMDDDA
hZY0blFfgRhmwOAIKe+1w6I4VMOBbwvAehZDvHIX0rhYd2UDfEvbK4SUzepd5tKk
7FWjdkufoFKYOIsAlnOuTQZ7WUXN6H4kGUaCY7q/ScXwsmew/mG9OWaDFf7fyKOf
eFo02xZpmSKHGgUMQiZigPp2tMpgTWmDwj95ykblf212hDGVLmEdz1+zL+OXNgBU
D1MxOE7wWSGtEHjCkEdyD6v+LWSfCKGBKe6prXZoXMh2U0VBfISFh6adqw209uuL
5U1IdylFLlr518adoPL0vm96sg/EF/96soeGjeqmJQ5cTHtLun1Kjv+jICEftJcI
rX0FX4YHjZTLJDlwQymcVxp2GcQI1OiM3lubgVE69lLI1pkjxazBNSvkUy5nKOWJ
SYhvUT3A+VXDEt1WGl7vjMHMjlOiHFbyDRoyOCByFR4M63wd4/APRq7rVcrKocJj
oL+VzX5Mw5aXeBRJaut/6qAh6S6nvX2cSysIthp7sYoIhyURhIQ=
=P48f
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[David Cantrell]

On 02/14/2018 02:41 PM, Igor Gnatenko wrote:
> On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
>> On 02/14/2018 11:44 AM, Remi Collet wrote:
>>> Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
 Just a small heads up, ...
>>>
>>>
>>> As I said on IRC
>>>
>>> - waste of time
>>> - waste of energy
>>> - absolutely no value
>>>
>>> And
>>>
>>> - abuse proven packager privileges
> 
>> +1
> 
> Ralf, Remi, David,
> 
> Please, read policy[0] once more.
> 
>> Sometimes there are situations where it's simply a lot easier to fix stuff
> directly in Git than via bugzilla and the proper maintainers. So much easier
> that we should leave this path open. These situations shouldn't arise that
> often. Some examples of situations were bypassing the proper maintained is
> considered fine: 
>> […]
>> * small fixes or adjustments for new or modified packaging 
> guidelines can be done directly in Git after being announced some days 
> in advance.
> 
> I just missed waiting for few days (kinda intentionally), because it would not
> help anyone and will just disturb maintainers to do the actual work whereas it
> doesn't make any sense because cleanup is automated.
> 
> 
> [0] 
> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Mino
> r.2C_general_or_cleanup_changes
> 

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

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

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

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

Re: Removal of BuildRoot

[Orion Poplawski]

On 02/13/2018 03:05 PM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is oldest
supported one nowadays, it's been year or so after EL5 retirement). And we
don't support EL5 anymore, so...

I wanted to send this heads up before I actually did that, but I hit "enter"
button too early.

Anyway, this is straitghtforward change, so no one should notice anything
(apart from one commit with, hopefully, useful description in their
repositories) 😉


Thanks for your work cleaning up spec files.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
> On 02/14/2018 11:44 AM, Remi Collet wrote:
> > Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
> > > Just a small heads up, ...
> > 
> > 
> > As I said on IRC
> > 
> > - waste of time
> > - waste of energy
> > - absolutely no value
> > 
> > And
> > 
> > - abuse proven packager privileges
> 
> +1

Ralf, Remi, David,

Please, read policy[0] once more.

> Sometimes there are situations where it's simply a lot easier to fix stuff
directly in Git than via bugzilla and the proper maintainers. So much easier
that we should leave this path open. These situations shouldn't arise that
often. Some examples of situations were bypassing the proper maintained is
considered fine: 
> […]
> * small fixes or adjustments for new or modified packaging 
guidelines can be done directly in Git after being announced some days 
in advance.

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


[0] https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Mino
r.2C_general_or_cleanup_changes
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqEkNsACgkQaVcUvRu8
X0ynChAAi6ysL7vNKx/iOlXR8QwgeYPrGUls1wDcf+Pfk5TG5KnCHPD2Z1Ze5hOV
4m1LQXjG0uljIzRX0WjRQijCFgUgk8l5EEdy/bUNIocdPU4eUrTOkGW1ZUbs5XB7
5qkmllsn8EaYWf3FN1WeN198qh1cepCJkhyldTz/nzWWJQ3Shx1XjGboBPzHeDFP
NaAuOV7brE5S3yoXmRNbk1SVchqlt16KzLDkWZ0F0yvGlc2yThjeib8WRA8oKB4b
XqNnZGPHGbSvlRI/AbJGcn4G2/Fqiu9RG+0j223zAOXIU3xNrdgW/Rac2q27+TZt
sZLC7M3fq+lmGdZTU056v+DW3r7YaIuhxwVt+FotzxR5ax4SIN42nc9ufH35eq2M
9wNdGmT4ZzB2KZ+RJHWeIDn5VL3fxx2zZyboKCYlYXjhY5qm6KAL+pKN9QGiU6It
dVtm+GoosiN574tZU6chzeIAL2ysehK0xAo8xBuXRF/Jn7ERjpFAUj9dJxVMvRdF
f5Rdn2le88YQBNOoLAJSBJlCe5ONGYqSbUKySMZFcKkS/B4vk13H5tswKhOUDjtM
2N3fBwNEl+he+4SB1KEKEV70w5/Jdcze0UUlvnQRS8IDb7Mf4GrqqFkGC4D7CqWr
OESCudSLz0mrtIZ9YBd6bJJt924AhaUQnyPTZFsVb3SnZ+quxVM=
=hbS8
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Chuck Anderson]

On Tue, Feb 13, 2018 at 11:05:28PM +0100, Igor Gnatenko wrote:
> Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is 
> oldest
> supported one nowadays, it's been year or so after EL5 retirement). And we
> don't support EL5 anymore, so...
> 
> I wanted to send this heads up before I actually did that, but I hit "enter"
> button too early.
> 
> Anyway, this is straitghtforward change, so no one should notice anything
> (apart from one commit with, hopefully, useful description in their
> repositories) 😉
> -- 
> -Igor Gnatenko

FWIW, I support your efforts with this, so thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[David Cantrell]

On 02/14/2018 11:44 AM, Remi Collet wrote:
> Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
>> Just a small heads up, ...
> 
> 
> As I said on IRC
> 
> - waste of time
> - waste of energy
> - absolutely no value
> 
> And
> 
> - abuse proven packager privileges

+1

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

Re: Removal of BuildRoot

[Rob Crittenden]

nicolas.mail...@laposte.net wrote:
> Hi,
> 
> Thank you for cleaning up the cruft in the repository !
> 
> Regards,
> 

Agreed. I'm usually pretty anal about others touching packages I
maintain without at least a heads-up but in this case it doesn't bother
me. I guess particularly since he didn't spin up a build or poke the
n-v-r so reverting it if I really hated it or it broke something would
be trivially easy.

As an aside, it might be nice though to be able to watch a package and
get automated notifications when things change. I don't maintain that
many packages though. I'd imagine that for some this could be rather
onerous, but I had no idea these changed were applied until I went and
looked.

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

Re: Removal of BuildRoot

[Kevin Fenzi]

On 02/13/2018 02:05 PM, Igor Gnatenko wrote:
> Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is 
> oldest
> supported one nowadays, it's been year or so after EL5 retirement). And we
> don't support EL5 anymore, so...
> 
> I wanted to send this heads up before I actually did that, but I hit "enter"
> button too early.
> 
> Anyway, this is straitghtforward change, so no one should notice anything
> (apart from one commit with, hopefully, useful description in their
> repositories) 😉

Thanks for making these simple cleanup changes.

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: Removal of BuildRoot

[nicolas . mailhot]

Hi,

Thank you for cleaning up the cruft in the repository !

Regards,

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

Re: Removal of BuildRoot

[Ralf Corsepius]

IMO, bikesheding and stylishness with any actual usefulness.

If you really want to enforce this, make it a feature request for f30 
and have FESCO vote on it.


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

Re: Removal of BuildRoot

[Remi Collet]

Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
> Just a small heads up, ...


As I said on IRC

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

And

- abuse proven packager privileges


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

Re: Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-02-14 at 16:17 +, Michael J Gruber wrote:
> No, that commit description was not helpful as it did not explain why you see
> a need to exert your proven packager privileges, nor the fact that this is a
> mass change. I had to go around and look for you and some info about your
> commit.

You see, I assume that you you are average packager and you don't know that
BuildRoot definition was needed last in EL5, do you expect other average
maintainers to know this?

> Frankly, I hate it when I notice that someone is stepping on my toes in
> packages that I maintain without even trying to contact me. We have pull-
> requests for exactly that purpose now - communication right where it belongs,
> open and transparent.

Do you think it's reasonable to ask person to open 2.000+ Pull Requests and
track all of them which just remove one single line?

> As for the change itself - those legacy spec features are neither necessary
> nor harmful. No need for urgent action at all.

It's fine as long as people actually remove them. But the reality is different
- - no one is removing old cruft from spec files which is accumulating there for
ages (try to grep specs for `0%{?rhel} < 4`.

They are actually harmful in a sense that when new people come they look at
existing spec files and copy them over and over.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqEZY8ACgkQaVcUvRu8
X0zNLA//WG9vGnJ45cKes3zT2fU1XIqb+ULgBF7gsCaFXIZyOYEySLtKgQayz812
N9fLQyU96U9HwGTNy4fm3Kg/wIbxuQnAAs6iMHqFJGM1xRpKwhcnAK4T41OVJ8j3
ukOC4RfiovU9ypGBQkBLvfHTZl3nA9ZjscSmGKSynY9tbWn1XKmXlK1ALdr/7HsL
EYjlhRq9j4dUih9UgNtm1JEv0nb6P8UEXzKtQk9GAt3bAL0e4Faok/Nc3dqBHgQu
3nCOpJ17awqAA92xOolW3nuCIngqtDERuOHeyqg9t5pAgMNGAmXCOf1pbT+RHYqT
MZHUd8kT25l5yDuvidaqEX+gST6SfK2ZBmzlEWjw5lMYJuCh1E05aeODQmtMnrRt
uHWMr7Zqv5hvkGMtFNbt+G0B1KujLAWqrNTR3zIhPKTpFJEAczacHEsfgaOxMQaC
cA86Nsh/HGBILKX4lcD5ByYMoKBpy4o19hKV89qqCOXDiBr8PpVhdVIUxSGEQsHZ
lID6+fXefu9nwv8kAD0IQf/D+PbnmstwlzG2VDb45/lpf284HJsVA/oCy9tRnitN
Mk8E2l1NDvGpmbvMVAVPA1T1zxEZjdZ1zUBFgOSvghuSRs5uV/Fy9KKw0ALMK/yd
P3kMb9QdTl1c6/XDFg/3WqdIpSnhZnMUaUKDEoq1Id8WxDISBQE=
=gZN6
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Michael J Gruber]

No, that commit description was not helpful as it did not explain why you see a 
need to exert your proven packager privileges, nor the fact that this is a mass 
change. I had to go around and look for you and some info about your commit.

Frankly, I hate it when I notice that someone is stepping on my toes in 
packages that I maintain without even trying to contact me. We have 
pull-requests for exactly that purpose now - communication right where it 
belongs, open and transparent.

As for the change itself - those legacy spec features are neither necessary nor 
harmful. No need for urgent action at all. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is oldest
supported one nowadays, it's been year or so after EL5 retirement). And we
don't support EL5 anymore, so...

I wanted to send this heads up before I actually did that, but I hit "enter"
button too early.

Anyway, this is straitghtforward change, so no one should notice anything
(apart from one commit with, hopefully, useful description in their
repositories) 😉
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqDYSgACgkQaVcUvRu8
X0yzGw//R1CxLUKv24mETURYToIg3QTPWGOU1X6nOg0zBmT17AVCYOWr559+FYN3
WSgNwaVgO5iOkr2PufX7Zx8n7N0LitAKFr9zF/eV2kaSd2+NyHgKLL8uKDQtXVvQ
GWLISIP+BC/W0u+kuGXvBFF4Olp3wrUnB6+Jxb4EI70UbQsyJN+mI7wnbnnW+AWJ
OIV4gtsx1nXxD5XxjqHJEIkzXaFpnZxQ5EE0FNT1lwE5SJo9eSArqM/1M2i/dK0W
/85jAteSg8PEVMRMhGq/nLWIE8FCFk9r872SEbMFQZrlCw25Ykax5ef/I26T00ev
l+rcCMOHobGabxSf1QJV2YvUUnirDuTBHhyUPIfGPlSykc3AcyJY0C/XThnhUmwf
cnr66gOsZEAqGs4fpoUJ3akXcdrC3G3+04GmShdP/7fYnxmmCNxtQ1u/ZPxqz605
/rDI0SH9fywZuP0DX2Xk6YgCLrschIZ5W8+jajmJ9DbU3TdKkueLTKrfZgXiPz+d
dUsjUzp/+bVdeM0MvWRibxYjijBzSPGfi5lv0HPN9gg8884MRAEHFcMqHPkcEnC8
SPkhgT8YmFu6sVtmY0/Wb+SGYm/etlj/g5QhqTy0HyoGZEpD8+eJw91aW/rWsLIh
5d738JfsLUoOpl/iFGxc1MdyNSPNayRi5vaTbkn5vBd7nLR22IA=
=EhRC
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org