Re: Escaping macros in %changelog

[Nico Kadel-Garcia]

On Sun, Mar 11, 2018 at 3:58 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Sun, Mar 11, 2018 at 02:22:49PM -0400, Nico Kadel-Garcia wrote:
>> On Sun, Mar 11, 2018 at 2:21 PM, Nico Kadel-Garcia  wrote:
>> > On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek
>> >  wrote:
>> >> On Sun, Mar 11, 2018 at 10:04:25AM -0400, Neal Gompa wrote:
>> >>> On Sun, Mar 11, 2018 at 10:01 AM, Zbigniew Jędrzejewski-Szmek
>> >>>  wrote:
>> >
>> >>> > I wanted to submit a PR for this, but I wasn't sure what the proper
>> >>> > location is. /usr/lib/rpm/redhat/macros (from redhat-rpm-config) or
>> >>> > /usr/lib/rpm/macros.d/macros.fedora (from fedora-rpm-macros)?
>> >>> >
>> >>>
>> >>> redhat-rpm-config is the right place. It belongs in 
>> >>> /usr/lib/rpm/redhat/macros.
>> >>
>> >> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/22
>> >
>> > So you're not actually adding a feature, as the pull request seems to
>> > describe. You're simply resetting the default from "0" to "numerical
>> > equivalent of 2 years", for all applications. Why not simply alter it
>> > for kernel.ll other packages unmodified?
>>
>> That came out somewhat garbled.
>>
>> Why not simply alter it for kernel.spec, and leave alone other
>> packages that may use the same macro?
> This seems to be misunderstanding. This has nothing to do with kernel.spec
> in particular. That PR trims _all_ changelogs, on purpose.

Ahh, that's more clear. I also saw the note and whitespace patch
mentioning "kernel-rpm-macros".  If I were writing such a change from
scratch, I'd set the log entry to say "Set default changelog retention
to 2 years", rather than "Trim changelog entries older than two
years", because the code is not actually in your patch. only the
change of the default entry. But it's not my package, I thought I'd
noticed an inconsistency that is nowhere near size of what I
understood to be a possible issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Zbigniew Jędrzejewski-Szmek]

On Sun, Mar 11, 2018 at 02:22:49PM -0400, Nico Kadel-Garcia wrote:
> On Sun, Mar 11, 2018 at 2:21 PM, Nico Kadel-Garcia  wrote:
> > On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek
> >  wrote:
> >> On Sun, Mar 11, 2018 at 10:04:25AM -0400, Neal Gompa wrote:
> >>> On Sun, Mar 11, 2018 at 10:01 AM, Zbigniew Jędrzejewski-Szmek
> >>>  wrote:
> >
> >>> > I wanted to submit a PR for this, but I wasn't sure what the proper
> >>> > location is. /usr/lib/rpm/redhat/macros (from redhat-rpm-config) or
> >>> > /usr/lib/rpm/macros.d/macros.fedora (from fedora-rpm-macros)?
> >>> >
> >>>
> >>> redhat-rpm-config is the right place. It belongs in 
> >>> /usr/lib/rpm/redhat/macros.
> >>
> >> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/22
> >
> > So you're not actually adding a feature, as the pull request seems to
> > describe. You're simply resetting the default from "0" to "numerical
> > equivalent of 2 years", for all applications. Why not simply alter it
> > for kernel.ll other packages unmodified?
> 
> That came out somewhat garbled.
> 
> Why not simply alter it for kernel.spec, and leave alone other
> packages that may use the same macro?
This seems to be misunderstanding. This has nothing to do with kernel.spec
in particular. That PR trims _all_ changelogs, on purpose.

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

Re: Escaping macros in %changelog

[Nico Kadel-Garcia]

On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Sun, Mar 11, 2018 at 10:04:25AM -0400, Neal Gompa wrote:
>> On Sun, Mar 11, 2018 at 10:01 AM, Zbigniew Jędrzejewski-Szmek
>>  wrote:

>> > I wanted to submit a PR for this, but I wasn't sure what the proper
>> > location is. /usr/lib/rpm/redhat/macros (from redhat-rpm-config) or
>> > /usr/lib/rpm/macros.d/macros.fedora (from fedora-rpm-macros)?
>> >
>>
>> redhat-rpm-config is the right place. It belongs in 
>> /usr/lib/rpm/redhat/macros.
>
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/22

So you're not actually adding a feature, as the pull request seems to
describe. You're simply resetting the default from "0" to "numerical
equivalent of 2 years", for all applications. Why not simply alter it
for kernel.ll other packages unmodified?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Nico Kadel-Garcia]

On Sun, Mar 11, 2018 at 2:21 PM, Nico Kadel-Garcia  wrote:
> On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> On Sun, Mar 11, 2018 at 10:04:25AM -0400, Neal Gompa wrote:
>>> On Sun, Mar 11, 2018 at 10:01 AM, Zbigniew Jędrzejewski-Szmek
>>>  wrote:
>
>>> > I wanted to submit a PR for this, but I wasn't sure what the proper
>>> > location is. /usr/lib/rpm/redhat/macros (from redhat-rpm-config) or
>>> > /usr/lib/rpm/macros.d/macros.fedora (from fedora-rpm-macros)?
>>> >
>>>
>>> redhat-rpm-config is the right place. It belongs in 
>>> /usr/lib/rpm/redhat/macros.
>>
>> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/22
>
> So you're not actually adding a feature, as the pull request seems to
> describe. You're simply resetting the default from "0" to "numerical
> equivalent of 2 years", for all applications. Why not simply alter it
> for kernel.ll other packages unmodified?

That came out somewhat garbled.

Why not simply alter it for kernel.spec, and leave alone other
packages that may use the same macro?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Zbigniew Jędrzejewski-Szmek]

On Sun, Mar 11, 2018 at 10:04:25AM -0400, Neal Gompa wrote:
> On Sun, Mar 11, 2018 at 10:01 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
> >> On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
> >>  wrote:
> >> > On 02/12/2018 08:00 PM, Michal Schorm wrote:
> >> >> The changelogs are long ass hell.
> >> >> What about keeping just 2 latest releases in it and deleting the rest?
> >> >> (It will be still kept in GIT history)
> >> >> 2 releases could be 2-
> >> >
> >> > I usually trim my changelogs to the last year of entries. It's kinda
> >> > arbitrary, but it does keep it from getting too insane and it's easy.
> >> >
> >> >
> >>
> >> What I don't get is why we don't just set RPM to trim the changelog
> >> automatically for the binary RPMs.
> >
> > I wanted to submit a PR for this, but I wasn't sure what the proper
> > location is. /usr/lib/rpm/redhat/macros (from redhat-rpm-config) or
> > /usr/lib/rpm/macros.d/macros.fedora (from fedora-rpm-macros)?
> >
> 
> redhat-rpm-config is the right place. It belongs in 
> /usr/lib/rpm/redhat/macros.

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/22

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

Re: Escaping macros in %changelog

[Neal Gompa]

On Sun, Mar 11, 2018 at 10:01 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
>> On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
>>  wrote:
>> > On 02/12/2018 08:00 PM, Michal Schorm wrote:
>> >> The changelogs are long ass hell.
>> >> What about keeping just 2 latest releases in it and deleting the rest?
>> >> (It will be still kept in GIT history)
>> >> 2 releases could be 2-
>> >
>> > I usually trim my changelogs to the last year of entries. It's kinda
>> > arbitrary, but it does keep it from getting too insane and it's easy.
>> >
>> >
>>
>> What I don't get is why we don't just set RPM to trim the changelog
>> automatically for the binary RPMs.
>
> I wanted to submit a PR for this, but I wasn't sure what the proper
> location is. /usr/lib/rpm/redhat/macros (from redhat-rpm-config) or
> /usr/lib/rpm/macros.d/macros.fedora (from fedora-rpm-macros)?
>

redhat-rpm-config is the right place. It belongs in /usr/lib/rpm/redhat/macros.



-- 
真実はいつも一つ！/ 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: Escaping macros in %changelog

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
> On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
>  wrote:
> > On 02/12/2018 08:00 PM, Michal Schorm wrote:
> >> The changelogs are long ass hell.
> >> What about keeping just 2 latest releases in it and deleting the rest?
> >> (It will be still kept in GIT history)
> >> 2 releases could be 2-
> >
> > I usually trim my changelogs to the last year of entries. It's kinda
> > arbitrary, but it does keep it from getting too insane and it's easy.
> >
> >
> 
> What I don't get is why we don't just set RPM to trim the changelog
> automatically for the binary RPMs.

I wanted to submit a PR for this, but I wasn't sure what the proper
location is. /usr/lib/rpm/redhat/macros (from redhat-rpm-config) or
/usr/lib/rpm/macros.d/macros.fedora (from fedora-rpm-macros)?

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

Re: Escaping macros in %changelog

[Michal Novotny]

Hello,

On Fri, Feb 9, 2018 at 10:57 PM, Michal Novotny  wrote:

> Hello,
>
> On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen 
> wrote:
>
>> On 02/09/2018 03:34 PM, Josh Boyer wrote:
>>
>>> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller 
>>> wrote:
>>>
 On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:

> It seems that a lot of people have %file, %check, %build, %whatsoever
> in their changelog section.
> Is there any reason I should not go and automatically escape them?
>

 This seems like a lot of churn. If we're going to do this, let's go big
 and get rid of RPM changelogs.

 When we have a package update, there are basically two different kinds
 of changelog information. Well, three.

 First, there's the upstream changelog. We don't generally do much with
 these except maybe package as %doc.

 Second, there's package maintainer changelogs. These are really
 redundant with the dist-git log. We don't really need this anymore.
 It's just a chore.

 Third, though, there's end-user information. Why should a user care
 *This* is redundant with bodhi update info, at least if packagers fill
 that out, and it often also duplicates upstream changelogs, *and* it
 often also covers things like "fixes CVE-' also carried the
 specfile changelog.

 This is neither most helpful for user *nor* ideal for packages. Why
 don't we drop changelogs entirely in favor of 1) using the dist-git
 logs for specfile maintainers and 2) providing the end-user information
 in a different way. This could be through specially formatted log lines
 going with the commit, or it could be simply in a standard separate
 file (`fedora.user-visible-changes`). Optionally, it could include both
 a high level end-user summary, and a detailed description for sysadmins
 and the curious.

 Wherever it lives, this would be read by Bodhi, so there's
 would be need to enter it more than once. And, perhaps a DNF plugin
 could be made to read and display this information for systems
 administrators.

>>>
>>> I fully support the removal of RPM changelogs.  However, you've missed
>>> two cases:
>>>
>>> 1) Rawhide, which doesn't go through bodhi
>>> 2) Fedora release upgrades, which don't go through bodhi
>>>
>>> Now, I would actually LOVE for Rawhide to go through bodhi but
>>> whatever.  The release -> release upgrade isn't really solvable that
>>> way though.
>>>
>>> Someone else suggested changelogs could be inserted during koji build
>>> time.  That would be interesting to look into.
>>>
>>
>> Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
>> rocket science we're talking about here if people are ready to give it a go.
>>
>
> I actually looked yesterday if I could make a PR for rpm implementing it
> but I couldn't really find a good way to do it. So I decided to implement it
> in `rpkg-client` (https://pagure.io/rpkg-client/branch/spec_preprocessor
> - basically a hack upon python-rpkg library) by spec preprocessing. So,
> with that development version of rpkg, you can have specs (or rather spec
> templates) like this in your Git project:
>
> Name:   {{{ git_name }}}
> Version:{{{ git_version }}}
> Release:1%{?dist}
> Summary:This is a test package.
>
> License:GPLv2+
> URL:https://someurl.org
>
> Source: {{{ make_source }}}
>
> %description
> This is a test package.
>
> %prep
> {{{ setup }}}
>
> {{{ git_change_log }}}
>
> rpkg will take that spec template and replace the {{{ ... }}} tags with
> standard output of the commands inside the braces (git_name, git_version,
> make_source, setup, git_change_log are all shell functions). Afterwards,
> the generated spec is used to e.g. create an srpm (done by `rpkg srpm`
> command).
>

I have implemented the idea here: https://pagure.io/rpkg-util/pull-request/7.
It is now under review. Please, join. Starting docs are here:
https://docs.pagure.org/rpkg-util/tutorials.html#spec-templates-from-scratch


>
> I haven't actually implemented the `git_change_log` function yet (nor the
> other functions except for `make_source`) like Igor did - currently it just
> always returns '%changelog' and that's it but I wanted to show this to
> possibly get some feedback.
>
> Thank you
> clime
>
>
>>
>> Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
>> already? Do you know what kind of hook they're using? Actually I think Suse
>> does this too so Fedora is probably again the last one to adopt this...
>>
>> - Panu -
>>
>> ___
>> 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: Escaping macros in %changelog

[Sérgio Basto]

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

Even less work with : 

fedpkg ci -c 


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

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

Release notes vs. Changelogs [was Re: Escaping macros in %changelog]

[Matthew Miller]

On Wed, Feb 14, 2018 at 10:00:18AM +0100, nicolas.mail...@laposte.net wrote:
> Actually, the problem is we're all talking about changelogs, when users ask 
> for release notes.
> That's not exactly the same thing.

Yes! Thanks, that puts nicely what I'm trying to say. Right now, the
git log is basically a (often poor, because it seems redudant with the
%changelog) changelog, the bodhi update info is release notes (when it
exists), and the %changelog is a weird mix.

I'd like to see us do one of:

1. Put real changelog info in the git log and have a separate standard
   fedora-package-release-notes.md (uh, or better name, but I bet that
   one doesn't have any conflicts!) which lives in dist-git (but not in
   the package) and gets fed into bodhi and whatever other tooling

2. Put both in git log but mark the release notes lines in some way so
   they can be extracted.

3. Or something else along these lines. The key parts are: reduce
   duplication and at the same time make the separation between release
   notes and changelog more clear so that both can be better.

-- 
Matthew Miller

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

Re: Escaping macros in %changelog

[John Florian]

On Tue, 2018-02-13 at 12:07 -0800, Adam Williamson wrote:
> On Mon, 2018-02-12 at 11:59 -0500, David Cantrell wrote:
> > The dist-git changelogs are mostly noise and I would prefer better
> > organized information about impacts to users and developers.  Like
> > tell
> > me what things changed in the new glibc package, not that the glibc
> > RPM
> > has been upgraded to the new release.  I can figure out that part
> > myself.
> 
> As an alternative perspective on this, I am *constantly* frustrated
> by
> the lack of detail in SCM commit messages, and would much prefer far
> more of it. I frequently find myself wanting to know exactly why
> someone did something seven years ago, and find it entirely
> impossible
> to answer the question from the information available.


Yes!  As a lifelong developer and user with the gray hair of "been
there, done that" I couldn't agree more with this sentiment.  SCM
messages are for developers, not users.  I want an SCM message to
briefly summary WHAT happened and then in detail WHY it happened.  The
changed code itself gives details of WHAT and if it's unclear it ought
have comments in the code, not the SCM message.  Users, on the other
hand, likely don't care about any of that, unless they too are a
developer.  Fine, they don't need anything else.  Plain, non-developer
users however, need to know HOW this impacts them and might appreciate
the WHY.

Beyond that, I really don't care how we get there.  But IMHO, that
should be the goal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[John Florian]

On Tue, 2018-02-13 at 15:33 -0500, Josh Boyer wrote:
> 
> The point is, we have LOTS of places where change information or
> discussion occurs.  We should try and have a canonical location for
> the *descriptive summary* of these changes/discussions.

This hit home.  Way back in the early 90s when I was new to Linux this
was one of the more frustrating things for me.  Mastering RHL (later
Fedora) was an exercise in knowing *where* to look and you can't even
know to look there until you become aware that there's yet one more
source.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[nicolas . mailhot]

Hi,

Actually, the problem is we're all talking about changelogs, when users ask for 
release notes.
That's not exactly the same thing.

Regards,

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

Re: Escaping macros in %changelog

[David Malcolm]

On Tue, 2018-02-13 at 12:07 -0800, Adam Williamson wrote:
> On Mon, 2018-02-12 at 11:59 -0500, David Cantrell wrote:
> > The dist-git changelogs are mostly noise and I would prefer better
> > organized information about impacts to users and developers.  Like
> > tell
> > me what things changed in the new glibc package, not that the glibc
> > RPM
> > has been upgraded to the new release.  I can figure out that part
> > myself.
> 
> As an alternative perspective on this, I am *constantly* frustrated
> by
> the lack of detail in SCM commit messages, and would much prefer far
> more of it. I frequently find myself wanting to know exactly why
> someone did something seven years ago, and find it entirely
> impossible
> to answer the question from the information available.

As well as %changelog, there's this wonderful other syntactical
construct in rpm spec files called a "comment" ;-)

Joking aside, and I haven't done much packaging in some time, but back
in the day I was always struck my how terse most specfiles seemed to
be, and I made a point of trying to properly comment mine.  I think
some of this may be the result of dealing with frustrating build
issues: "yes! it finally worked, commit it and move on!"

Specfiles are code, and IMHO ought to be commented, following the usual
best-practices for code comments.  If nothing else, a bug ID is way
better than nothing - or a URL to a discussion - but ideally summarize
the rationale for anything surprising in a comment.

It's not an obfuscated code competition.

Hope this is constructive
Dave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Josh Boyer]

On Tue, Feb 13, 2018 at 3:24 PM, Matthew Miller
 wrote:
> On Tue, Feb 13, 2018 at 12:07:27PM -0800, Adam Williamson wrote:
>> > The dist-git changelogs are mostly noise and I would prefer better
>> > organized information about impacts to users and developers.  Like tell
>> > me what things changed in the new glibc package, not that the glibc RPM
>> > has been upgraded to the new release.  I can figure out that part myself.
>> As an alternative perspective on this, I am *constantly* frustrated by
>> the lack of detail in SCM commit messages, and would much prefer far
>> more of it. I frequently find myself wanting to know exactly why
>> someone did something seven years ago, and find it entirely impossible
>> to answer the question from the information available.
>
> I think this is made worse by having three different changelogs in
> three different places (spec file, git, bodhi).

Or 4 if you include bugzilla, where a lot of discussion actually takes place.

Or 5 if you include upstream.

Or 6 if you include devel list posts talking about a general change
that is then done across packages but doesn't reference the original
thread anywhere in git, bugzilla, changelog, or bodhi.

The point is, we have LOTS of places where change information or
discussion occurs.  We should try and have a canonical location for
the *descriptive summary* of these changes/discussions.  I don't think
%changelog lends itself to that.  The git commit log is likely the
best place, but we have nothing to enforce good usage of it.

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

Re: Escaping macros in %changelog

[Matthew Miller]

On Tue, Feb 13, 2018 at 12:07:27PM -0800, Adam Williamson wrote:
> > The dist-git changelogs are mostly noise and I would prefer better
> > organized information about impacts to users and developers.  Like tell
> > me what things changed in the new glibc package, not that the glibc RPM
> > has been upgraded to the new release.  I can figure out that part myself.
> As an alternative perspective on this, I am *constantly* frustrated by
> the lack of detail in SCM commit messages, and would much prefer far
> more of it. I frequently find myself wanting to know exactly why
> someone did something seven years ago, and find it entirely impossible
> to answer the question from the information available.

I think this is made worse by having three different changelogs in
three different places (spec file, git, bodhi).



-- 
Matthew Miller

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

Re: Escaping macros in %changelog

[Adam Williamson]

On Mon, 2018-02-12 at 11:59 -0500, David Cantrell wrote:
> The dist-git changelogs are mostly noise and I would prefer better
> organized information about impacts to users and developers.  Like tell
> me what things changed in the new glibc package, not that the glibc RPM
> has been upgraded to the new release.  I can figure out that part myself.

As an alternative perspective on this, I am *constantly* frustrated by
the lack of detail in SCM commit messages, and would much prefer far
more of it. I frequently find myself wanting to know exactly why
someone did something seven years ago, and find it entirely impossible
to answer the question from the information available.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Daniel P . Berrangé]

On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
> On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
>  wrote:
> > On 02/12/2018 08:00 PM, Michal Schorm wrote:
> >> The changelogs are long ass hell.
> >> What about keeping just 2 latest releases in it and deleting the rest?
> >> (It will be still kept in GIT history)
> >> 2 releases could be 2-
> >
> > I usually trim my changelogs to the last year of entries. It's kinda
> > arbitrary, but it does keep it from getting too insane and it's easy.
> >
> >
> 
> What I don't get is why we don't just set RPM to trim the changelog
> automatically for the binary RPMs.
> 
> Mageia does this to keep the payload sizes sane:
> http://gitweb.mageia.org/software/rpm/rpm-setup/tree/macros.in#n22

That's good, but it is still worth trimming the actual changelogs too.
It is pointless accumulating 10 years worth of %changelog in the .spec
file in dist-git. Every time we branch rawhide, we should have something
that culls all changelogs from the specs in 'master' that are older
than 1 year.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Neal Gompa]

On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
 wrote:
> On 02/12/2018 08:00 PM, Michal Schorm wrote:
>> The changelogs are long ass hell.
>> What about keeping just 2 latest releases in it and deleting the rest?
>> (It will be still kept in GIT history)
>> 2 releases could be 2-
>
> I usually trim my changelogs to the last year of entries. It's kinda
> arbitrary, but it does keep it from getting too insane and it's easy.
>
>

What I don't get is why we don't just set RPM to trim the changelog
automatically for the binary RPMs.

Mageia does this to keep the payload sizes sane:
http://gitweb.mageia.org/software/rpm/rpm-setup/tree/macros.in#n22

-- 
真実はいつも一つ！/ 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: Escaping macros in %changelog

[Randy Barlow]

On 02/12/2018 08:00 PM, Michal Schorm wrote:
> The changelogs are long ass hell.
> What about keeping just 2 latest releases in it and deleting the rest?
> (It will be still kept in GIT history)
> 2 releases could be 2-

I usually trim my changelogs to the last year of entries. It's kinda
arbitrary, but it does keep it from getting too insane and it's easy.



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: Escaping macros in %changelog

[Till Maas]

On Sat, Feb 10, 2018 at 10:25:48PM +0100, David Sommerseth wrote:

> I personally find it abusing shared resources throwing builds at it which has
> not been tested first.  So I prefer to do local mockbuilds first, simply to
> lessen the load on shared resources.  I'm not saying I haven't tossed failing
> builds at koji, that has happened too.  But I generally try to avoid that as
> much as I can.

koji has enough ressources to allow for test builds. You can actually to
test-only builds (so-called stretch builds). IMHO the scarcer resource
is maintainer time, therefore I am all for using as much shared
resources as possible if it frees time for maintainers. See also:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

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

Re: Escaping macros in %changelog

[Pavel Raiskup]

On Monday, February 12, 2018 5:59:57 PM CET David Cantrell wrote:
> On 02/09/2018 08:34 AM, Josh Boyer wrote:
> > On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller  
> > wrote:
> >> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
> >>> It seems that a lot of people have %file, %check, %build, %whatsoever
> >>> in their changelog section.
> >>> Is there any reason I should not go and automatically escape them?
> >>
> >> This seems like a lot of churn. If we're going to do this, let's go big
> >> and get rid of RPM changelogs.
> >>
> >> When we have a package update, there are basically two different kinds
> >> of changelog information. Well, three.
> >>
> >> First, there's the upstream changelog. We don't generally do much with
> >> these except maybe package as %doc.
> >>
> >> Second, there's package maintainer changelogs. These are really
> >> redundant with the dist-git log. We don't really need this anymore.
> >> It's just a chore.
> >>
> >> Third, though, there's end-user information. Why should a user care
> >> *This* is redundant with bodhi update info, at least if packagers fill
> >> that out, and it often also duplicates upstream changelogs, *and* it
> >> often also covers things like "fixes CVE-' also carried the
> >> specfile changelog.
> >>
> >> This is neither most helpful for user *nor* ideal for packages. Why
> >> don't we drop changelogs entirely in favor of 1) using the dist-git
> >> logs for specfile maintainers and 2) providing the end-user information
> >> in a different way. This could be through specially formatted log lines
> >> going with the commit, or it could be simply in a standard separate
> >> file (`fedora.user-visible-changes`). Optionally, it could include both
> >> a high level end-user summary, and a detailed description for sysadmins
> >> and the curious.
> >>
> >> Wherever it lives, this would be read by Bodhi, so there's
> >> would be need to enter it more than once. And, perhaps a DNF plugin
> >> could be made to read and display this information for systems
> >> administrators.
> > 
> > I fully support the removal of RPM changelogs.  However, you've missed
> > two cases:
> 
> I will also add that I fully support removal of RPM changelogs.  To me
> it ends up being a very common merge conflict if you are trying to
> backport patches to previous branches and we could fix that by
> eliminating the changelogs entirely.

I don't support full removal.  If any automation goes into pipeline
regarding %changelogs, please let users the freedom to write the
%changelogs manually if they want.  Even if I'm not probably good at it,
I'm fine to write the %changelog entry, and resolve the merge conflicts
(in case of changelog it is matter of less then several seconds with meld,
similar to merge conflicts in Release tag).

As an example, see at GNU upstream repos (e.g. tar, automake, ..) how they
generate ChangeLog from git changelog (gitlog-to-changelog through `make
V=1 ChangeLog` command).  That really requires *a lot* of concentration
during writing git commit messages, and reviews.  Any mistake in commit
message requires another commit with "patch" for gitlog-to-changelog
output.

Yes, if we'll have good protection against mistakes (push-reject policy
for mis-formated git messages, so e.g. provenpackagers won't create patch
work for maintainers), it would be nice _option_ which I would love to
pick in many cases.

Pavel

> > 1) Rawhide, which doesn't go through bodhi
> > 2) Fedora release upgrades, which don't go through bodhi
> > 
> > Now, I would actually LOVE for Rawhide to go through bodhi but
> > whatever.  The release -> release upgrade isn't really solvable that
> > way though.
> > 
> > Someone else suggested changelogs could be inserted during koji build
> > time.  That would be interesting to look into.
> 
> The dist-git changelogs are mostly noise and I would prefer better
> organized information about impacts to users and developers.  Like tell
> me what things changed in the new glibc package, not that the glibc RPM
> has been upgraded to the new release.  I can figure out that part myself.
> 
> Many projects include a NEWS file which summarizes the major changes and
> fixes in a new release.  This is usually nicer to consume than
> changelogs.  Sometimes the summarized changes are in another file.
> Sometimes there's nothing like that.
> 
> Maybe we could mark the relevant changes for that release in the %files
> section.  Like:
> 
> %changes NEWS
> 
> Like a doc macro.  An 'rpm -q --changelog' would just pipe that file
> through the pager.  Or display the path or whatever.  If a package lacks
> a file like that, rpm -q --changelog could just return nothing.
> 
> This also leaves open the option for package maintainers to create their
> own summary files and package readmes, which could be expanded to
> explain specifics about that software on Fedora.
> 
> -- 
> David Cantrell 
> Red Hat, Inc. | Boston, MA | EST5EDT
> _

Re: Escaping macros in %changelog

[Michal Schorm]

On Tue, Feb 13, 2018 at 3:03 AM, J. Randall Owens <
jrowens.fed...@ghiapet.net> wrote:
>
> When you say 2 releases, are you talking about package or Fedora
> releases? I'd favour an approach of keeping all the changes since
> release, or since branching might be even better, or since the release
> before the package's release, myself. 2 package releases seems a bit curt.
>

I was thinking about 2 last package releases by upstream, that has been
packed into Fedora.
(So if fedora skipped some upstream release, still keeping 2 last upstream
release packed)

However It was just a thought in general, on how to have changelogs shorter.
I'm not sure if it would really work as good as I imagine.


--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[J. Randall Owens]

On 13/02/18 01:00, Michal Schorm wrote:
> 5)
> The changelogs are long ass hell.
> What about keeping just 2 latest releases in it and deleting the rest?
> (It will be still kept in GIT history)
> 2 releases could be 2-20 entries, depends of work done.
> But still it looks short enough for me.

When you say 2 releases, are you talking about package or Fedora
releases? I'd favour an approach of keeping all the changes since
release, or since branching might be even better, or since the release
before the package's release, myself. 2 package releases seems a bit curt.

-- 
J. Randall Owens | http://www.GhiaPet.net/



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: Escaping macros in %changelog

[Michal Schorm]

I don't think, removing the changelog entirely is a good idea. We do not
have suitable replacement.

1)
I agree with said. GIT commit messages should describe the work of
developer.
Thus messages like "typo fix" "revert of revert of merge of ..." "forgot to
add new-sources" are common, and should stay as they are. (Because they
well describe what changes has been made from developer / maintainer POV)

2)
Generating BODHI updates messages?
Definitelly +1 !
But with chance to still edit it by hand.

3)
What should be written to the changelog? IMHO the stuff that changed from
user POV.
So stuff like "update to NVR" "changelog can be found at URL" "CVEs fixed:
1, 2, 3, 4, ..." "bugs solved: RHBZ#1, 2, 3, 4, ..." "compiler optimization
for F22 disabled for PPC64le, because of bug XYZ"
And I don't see any other suitable place to add this.

4)
A research should be made first, about how do users use the changelogs.
If they do, I'd be cautious.

5)
The changelogs are long ass hell.
What about keeping just 2 latest releases in it and deleting the rest? (It
will be still kept in GIT history)
2 releases could be 2-20 entries, depends of work done.
But still it looks short enough for me.

6)
It should be part of the packaging guidelines - where should be written
what.
Probabbly not in a form of unbreakable rule, but rather information to the
packagers how to do it, and remind of things they shouldn't forget to write
down there.


--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[David Cantrell]

On 02/09/2018 08:34 AM, Josh Boyer wrote:
> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller  
> wrote:
>> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>>> It seems that a lot of people have %file, %check, %build, %whatsoever
>>> in their changelog section.
>>> Is there any reason I should not go and automatically escape them?
>>
>> This seems like a lot of churn. If we're going to do this, let's go big
>> and get rid of RPM changelogs.
>>
>> When we have a package update, there are basically two different kinds
>> of changelog information. Well, three.
>>
>> First, there's the upstream changelog. We don't generally do much with
>> these except maybe package as %doc.
>>
>> Second, there's package maintainer changelogs. These are really
>> redundant with the dist-git log. We don't really need this anymore.
>> It's just a chore.
>>
>> Third, though, there's end-user information. Why should a user care
>> *This* is redundant with bodhi update info, at least if packagers fill
>> that out, and it often also duplicates upstream changelogs, *and* it
>> often also covers things like "fixes CVE-' also carried the
>> specfile changelog.
>>
>> This is neither most helpful for user *nor* ideal for packages. Why
>> don't we drop changelogs entirely in favor of 1) using the dist-git
>> logs for specfile maintainers and 2) providing the end-user information
>> in a different way. This could be through specially formatted log lines
>> going with the commit, or it could be simply in a standard separate
>> file (`fedora.user-visible-changes`). Optionally, it could include both
>> a high level end-user summary, and a detailed description for sysadmins
>> and the curious.
>>
>> Wherever it lives, this would be read by Bodhi, so there's
>> would be need to enter it more than once. And, perhaps a DNF plugin
>> could be made to read and display this information for systems
>> administrators.
> 
> I fully support the removal of RPM changelogs.  However, you've missed
> two cases:

I will also add that I fully support removal of RPM changelogs.  To me
it ends up being a very common merge conflict if you are trying to
backport patches to previous branches and we could fix that by
eliminating the changelogs entirely.

> 1) Rawhide, which doesn't go through bodhi
> 2) Fedora release upgrades, which don't go through bodhi
> 
> Now, I would actually LOVE for Rawhide to go through bodhi but
> whatever.  The release -> release upgrade isn't really solvable that
> way though.
> 
> Someone else suggested changelogs could be inserted during koji build
> time.  That would be interesting to look into.

The dist-git changelogs are mostly noise and I would prefer better
organized information about impacts to users and developers.  Like tell
me what things changed in the new glibc package, not that the glibc RPM
has been upgraded to the new release.  I can figure out that part myself.

Many projects include a NEWS file which summarizes the major changes and
fixes in a new release.  This is usually nicer to consume than
changelogs.  Sometimes the summarized changes are in another file.
Sometimes there's nothing like that.

Maybe we could mark the relevant changes for that release in the %files
section.  Like:

%changes NEWS

Like a doc macro.  An 'rpm -q --changelog' would just pipe that file
through the pager.  Or display the path or whatever.  If a package lacks
a file like that, rpm -q --changelog could just return nothing.

This also leaves open the option for package maintainers to create their
own summary files and package readmes, which could be expanded to
explain specifics about that software on Fedora.

-- 
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: Escaping macros in %changelog

[Matthew Miller]

On Fri, Feb 09, 2018 at 08:34:02AM -0500, Josh Boyer wrote:
> > Wherever it lives, this would be read by Bodhi, so there's
> > would be need to enter it more than once. And, perhaps a DNF plugin
> > could be made to read and display this information for systems
> > administrators.
> 
> I fully support the removal of RPM changelogs.  However, you've missed
> two cases:
> 
> 1) Rawhide, which doesn't go through bodhi
> 2) Fedora release upgrades, which don't go through bodhi

I'm actually suggesting something different: write the user-focused
changelog in one place when updating the package, and have bodhi read
that and use it for its description (making the bodhi step less work).


-- 
Matthew Miller

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

Re: Escaping macros in %changelog

[Matthew Miller]

On Fri, Feb 09, 2018 at 08:12:43AM +0100, Igor Gnatenko wrote:
> * Many times people put some useless messages in there, so we
> probably don't want to convert old history to git-based changelogs
> and have point where we ask people to start writing useful commit
> messages.

There are lots of useless messages in many changelogs, too.


> * No easy way to map changelogs with versions and releases in
> package. Imagine that you pushed commit with update, then realised
> that it doesn't build and reverted. What should be in changelog?

I think we *need* separate changelog streams -- the packager one (with
all the messiness) and a user-focused one. This could either be a
separate file or some kind of standard we agree on for special lines in
the git changelog. (In that case, we could have a tool to extract those
lines, and it could understand to remove user messages found in
reverted commits.)

I'm not sure it's super-useful to inject them into the RPM itself.
Better, I think, to put it in /usr/share/doc somewhere or something.
That makes the metadata more lightweight (what percentage of
/var/lib/rpm/Packages is changelog text)? 


-- 
Matthew Miller

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

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Michael Schwendt]

On Thu, 8 Feb 2018 18:39:19 +0100, Petr Stodulka wrote:

> > The following:
> > %files
> > /some/directory/
> > 
> > is equivalent to:
> > %files
> > %dir /some/directory
> > /some/directory/*
> > 
> > 
> > There's nothing wrong here.
> > 
> >   
> 
> Exactly. IMHO, use of %dir macro for "top" pkg directories is more clean 
> solution, but
> doesn't matter in case the rpm is packaged correctly.

That makes no sense, if you restrict yourself to a "top" directory.
It could be a huge tree with lots of subdirectories. How would you
package it then? With explicit %dir everywhere? Or with %dir only for
the "top" directory?

Including complete directory trees with

  /foo/bar/

is fine and clean and is an advertised solution for many years.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Michael Schwendt]

On Thu, 8 Feb 2018 18:09:25 +, Tomasz Kłoczko wrote:

> I'm sure that in the past it was difference here :|

You are mistaken about that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[David Sommerseth]

On 10/02/18 12:54, Kevin Kofler wrote:
> David Sommerseth wrote:
>> I doubt Koji was primarily built for "does this work?"-builds.  It exists
>> to build proper packages targeting Fedora repositories.
> 
> But that is the point, to build a proper package:
> 
> do {
>   try build;
> } while (!build succeeded);
> 
> and the output is a working package.

We agree on the goal.  But we have different views on the path to the goal.

I personally find it abusing shared resources throwing builds at it which has
not been tested first.  So I prefer to do local mockbuilds first, simply to
lessen the load on shared resources.  I'm not saying I haven't tossed failing
builds at koji, that has happened too.  But I generally try to avoid that as
much as I can.

>> To me this is backwards and is lacking some logic.  If you push things
>> which does not build properly, you also waste a build.
> 
> That is a build attempt that would have had to happen anyway. Otherwise, how 
> do I know that it doesn't build.
> 
> The point is, the above optimized loop needs n build attempts. What you 
> propose doing needs n+1 build attempts to get the exact same package.

True.  But my n+1 approach also wouldn't add litter to the git commit history
with noise.  I use the same approach when doing development too;  I always try
to avoid committing anything which hasn't been tested first, as I simply find
it nasty to have commits not building (which again makes bisecting harder) ...
But I'll agree that development and package maintenance are not the same thing
- even though they carry similarities


-- 
kind regards,

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

Re: Escaping macros in %changelog

[Michal Novotny]

I must agree with Kevin that taking every single commit message and putting
it into changelog without further tweaking
might just produce lots of redundant and not really desired lines in the
output. But I think something still can be done.
When you invoke `rpkg tag` (the same goes for `fedpkg tag`), it brings up
an editing window where you can edit a tag
message. So we could generate the commit messages into this window where
the user could edit them.
The {{{ git_change_log }}} (or just {{{ git_changelog }}}) macro would then
use exactly those tag messages
(for each tag) to generate the final change log into the spec file.

On Sat, Feb 10, 2018 at 12:54 PM, Kevin Kofler 
wrote:

> David Sommerseth wrote:
> > I doubt Koji was primarily built for "does this work?"-builds.  It exists
> > to build proper packages targeting Fedora repositories.
>
> But that is the point, to build a proper package:
>
> do {
>   try build;
> } while (!build succeeded);
>
> and the output is a working package.
>
> > To me this is backwards and is lacking some logic.  If you push things
> > which does not build properly, you also waste a build.
>
> That is a build attempt that would have had to happen anyway. Otherwise,
> how
> do I know that it doesn't build.
>
> The point is, the above optimized loop needs n build attempts. What you
> propose doing needs n+1 build attempts to get the exact same package.
>
> Kevin Kofler
> ___
> 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: Escaping macros in %changelog

[Kevin Kofler]

David Sommerseth wrote:
> I doubt Koji was primarily built for "does this work?"-builds.  It exists
> to build proper packages targeting Fedora repositories.

But that is the point, to build a proper package:

do {
  try build;
} while (!build succeeded);

and the output is a working package.

> To me this is backwards and is lacking some logic.  If you push things
> which does not build properly, you also waste a build.

That is a build attempt that would have had to happen anyway. Otherwise, how 
do I know that it doesn't build.

The point is, the above optimized loop needs n build attempts. What you 
propose doing needs n+1 build attempts to get the exact same package.

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

Re: Escaping macros in %changelog

[David Sommerseth]

On 09/02/18 23:46, Kevin Kofler wrote:
> David Sommerseth wrote:
>> Doesn't 'fedpkg mockbuild' resolve those test builds?  To my knowledge,
>> this is fairly close to what koji does under the hood.  Then you'll have
>> everything tested locally, git tree can be cleaned up and be in a
>> reasonable shape before being pushed out.
> 
> I'm surely not going to build those packages on my computer, that's what we 
> have Koji for!

I doubt Koji was primarily built for "does this work?"-builds.  It exists to
build proper packages targeting Fedora repositories.

>> If you want to make koji run the build, you can also use 'fedpkg build
>> --scratch' and provide an SRPM (generated by 'fedpkg srpm').  This
>> shouldn't need to be git pushed either to work.
> 
> Then I have to waste a build (which wastes my time and Koji's resources) 
> because I'll have to build the last attempt (the one that ends up 
> succeeding) again as an official build later. It also takes extra time to 
> build and upload the SRPM compared to letting Koji compose it from dist-git, 
> which for a large package like qt5-qtwebengine is not negligible either. (I 
> have only so much upload speed on this asymmetric cable broadband 
> connection.)

To me this is backwards and is lacking some logic.  If you push things which
does not build properly, you also waste a build.

And if your build works but there are other non-critical typos, you still
waste a build when you correct that.

Testing builds is critical to ensure your .spec file is properly setup.  If it
happens locally or in a pre-built SRPM sent to koji, is not really that
important.  Here people use what is most convenient to them.

To avoid bandwidth issues I know people (including myself) uses external hosts
with a decent Internet link (you might even get access to some free resources,
especially if targeting special platforms - like the Open Power Hub if doing
POWER8 related stuff [1]).  Use sshfs or similar approaches to a remote server
which is used to update a .spec file from your local host and then use ssh on
that host and do the heavy-lifting there directly.  The bandwidth for a ssh
connection is negligible compared to uploading large srpm packages.  Plus the
koji upload goes fairly fast.

Or you could get a more reasonable and decent Internet connection at home/work
with a better bandwidth.

To me these complaints sounds more like insisting on not adopting to the
reality.  Getting all your expectations covered and expect the Fedora tooling
around to adopt to your expectations just sounds backwards to me.


[1] 

-- 
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: Escaping macros in %changelog

[Kevin Kofler]

David Sommerseth wrote:
> Doesn't 'fedpkg mockbuild' resolve those test builds?  To my knowledge,
> this is fairly close to what koji does under the hood.  Then you'll have
> everything tested locally, git tree can be cleaned up and be in a
> reasonable shape before being pushed out.

I'm surely not going to build those packages on my computer, that's what we 
have Koji for!

> If you want to make koji run the build, you can also use 'fedpkg build
> --scratch' and provide an SRPM (generated by 'fedpkg srpm').  This
> shouldn't need to be git pushed either to work.

Then I have to waste a build (which wastes my time and Koji's resources) 
because I'll have to build the last attempt (the one that ends up 
succeeding) again as an official build later. It also takes extra time to 
build and upload the SRPM compared to letting Koji compose it from dist-git, 
which for a large package like qt5-qtwebengine is not negligible either. (I 
have only so much upload speed on this asymmetric cable broadband 
connection.)

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

Re: Escaping macros in %changelog

[David Sommerseth]

On 09/02/18 23:09, Kevin Kofler wrote:
> Kamil Dudka wrote:
>> Would not it be then better to work on this in a staging branch and rework
>> those commits before they are pushed to a production branch?  I am myself
>> not interested in going through commits like "fix a typo", "forgot to bump
>> release", "add missing BR", "revert the previous revert", etc.
> 
> I have to push them to the right branch so I can build them. Then if it 
> builds, it's fine, but if it's broken, I fix it and try again.

Hi Kevin,

Doesn't 'fedpkg mockbuild' resolve those test builds?  To my knowledge, this
is fairly close to what koji does under the hood.  Then you'll have everything
tested locally, git tree can be cleaned up and be in a reasonable shape before
being pushed out.

If you want to make koji run the build, you can also use 'fedpkg build
--scratch' and provide an SRPM (generated by 'fedpkg srpm').  This shouldn't
need to be git pushed either to work.


Just my 2 cents.


-- 
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: Escaping macros in %changelog

[Kevin Kofler]

Neal Gompa wrote:
> Mageia, OpenMandriva, and PLD all generate their changelogs from the
> source control system.
[snip]
> SUSE uses the Open Build Service VCS export to changes files which are
> converted into changelog entries at package build time.

All these distros have in common that their changelogs are A LOT less 
readable than ours.

> But yeah, Fedora is once again a laggard. This seems to be a recurring
> trend, and one I'm not particularly pleased about.

Autogenerating RPM changelogs from the SCM has been proposed over and over 
again multiple times. It was always shot down because it just doesn't work. 
Not adopting some particular bad idea does not make us laggards. Can we 
please stop beating this dead horse again and again?

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

Re: Escaping macros in %changelog

[Kevin Kofler]

Kamil Dudka wrote:
> Would not it be then better to work on this in a staging branch and rework
> those commits before they are pushed to a production branch?  I am myself
> not interested in going through commits like "fix a typo", "forgot to bump
> release", "add missing BR", "revert the previous revert", etc.

I have to push them to the right branch so I can build them. Then if it 
builds, it's fine, but if it's broken, I fix it and try again.

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

Re: Escaping macros in %changelog

[Michal Novotny]

Hello,

On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen  wrote:

> On 02/09/2018 03:34 PM, Josh Boyer wrote:
>
>> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller 
>> wrote:
>>
>>> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>>>
 It seems that a lot of people have %file, %check, %build, %whatsoever
 in their changelog section.
 Is there any reason I should not go and automatically escape them?

>>>
>>> This seems like a lot of churn. If we're going to do this, let's go big
>>> and get rid of RPM changelogs.
>>>
>>> When we have a package update, there are basically two different kinds
>>> of changelog information. Well, three.
>>>
>>> First, there's the upstream changelog. We don't generally do much with
>>> these except maybe package as %doc.
>>>
>>> Second, there's package maintainer changelogs. These are really
>>> redundant with the dist-git log. We don't really need this anymore.
>>> It's just a chore.
>>>
>>> Third, though, there's end-user information. Why should a user care
>>> *This* is redundant with bodhi update info, at least if packagers fill
>>> that out, and it often also duplicates upstream changelogs, *and* it
>>> often also covers things like "fixes CVE-' also carried the
>>> specfile changelog.
>>>
>>> This is neither most helpful for user *nor* ideal for packages. Why
>>> don't we drop changelogs entirely in favor of 1) using the dist-git
>>> logs for specfile maintainers and 2) providing the end-user information
>>> in a different way. This could be through specially formatted log lines
>>> going with the commit, or it could be simply in a standard separate
>>> file (`fedora.user-visible-changes`). Optionally, it could include both
>>> a high level end-user summary, and a detailed description for sysadmins
>>> and the curious.
>>>
>>> Wherever it lives, this would be read by Bodhi, so there's
>>> would be need to enter it more than once. And, perhaps a DNF plugin
>>> could be made to read and display this information for systems
>>> administrators.
>>>
>>
>> I fully support the removal of RPM changelogs.  However, you've missed
>> two cases:
>>
>> 1) Rawhide, which doesn't go through bodhi
>> 2) Fedora release upgrades, which don't go through bodhi
>>
>> Now, I would actually LOVE for Rawhide to go through bodhi but
>> whatever.  The release -> release upgrade isn't really solvable that
>> way though.
>>
>> Someone else suggested changelogs could be inserted during koji build
>> time.  That would be interesting to look into.
>>
>
> Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
> rocket science we're talking about here if people are ready to give it a go.
>

I actually looked yesterday if I could make a PR for rpm implementing it
but I couldn't really find a good way to do it. So I decided to implement it
in `rpkg-client` (https://pagure.io/rpkg-client/branch/spec_preprocessor -
basically a hack upon python-rpkg library) by spec preprocessing. So,
with that development version of rpkg, you can have specs (or rather spec
templates) like this in your Git project:

Name:   {{{ git_name }}}
Version:{{{ git_version }}}
Release:1%{?dist}
Summary:This is a test package.

License:GPLv2+
URL:https://someurl.org

Source: {{{ make_source }}}

%description
This is a test package.

%prep
{{{ setup }}}

{{{ git_change_log }}}

rpkg will take that spec template and replace the {{{ ... }}} tags with
standard output of the commands inside the braces (git_name, git_version,
make_source, setup, git_change_log are all shell functions). Afterwards,
the generated spec is used to e.g. create an srpm (done by `rpkg srpm`
command).

I haven't actually implemented the `git_change_log` function yet (nor the
other functions except for `make_source`) like Igor did - currently it just
always returns '%changelog' and that's it but I wanted to show this to
possibly get some feedback.

Thank you
clime


>
> Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
> already? Do you know what kind of hook they're using? Actually I think Suse
> does this too so Fedora is probably again the last one to adopt this...
>
> - Panu -
>
> ___
> 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: Escaping macros in %changelog

[Jonathan Wakely]

On 09/02/18 16:53 +, Jonathan Wakely wrote:

On 09/02/18 08:34 -0500, Josh Boyer wrote:

Someone else suggested changelogs could be inserted during koji build
time.  That would be interesting to look into.


If a koji build page just showed the Git commit logs since the last
build that could be far more useful than showing hundreds of lines of
the %changelog from the spec file. I could hit 'End' on my keyboard to
jump to the bottom of a koji page to see the changes.

Try finding the changelog entry for the new build here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1029927

The bottom of the page shows a change from "Tue May 06 2003" (not very
relevant to a recent koji build) and the top of the page shows
hundreds of RPMs that I need to scroll past before the changelog
starts.


But a #changelog anchor would also solve that specific problem :-)

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

Re: Escaping macros in %changelog

[Jonathan Wakely]

On 09/02/18 08:34 -0500, Josh Boyer wrote:

Someone else suggested changelogs could be inserted during koji build
time.  That would be interesting to look into.


If a koji build page just showed the Git commit logs since the last
build that could be far more useful than showing hundreds of lines of
the %changelog from the spec file. I could hit 'End' on my keyboard to
jump to the bottom of a koji page to see the changes.

Try finding the changelog entry for the new build here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1029927

The bottom of the page shows a change from "Tue May 06 2003" (not very
relevant to a recent koji build) and the top of the page shows
hundreds of RPMs that I need to scroll past before the changelog
starts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-02-08 at 13:32 -0500, Matthew Miller wrote:
> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
> > It seems that a lot of people have %file, %check, %build, %whatsoever
> > in their changelog section.
> > Is there any reason I should not go and automatically escape them?
> 
> This seems like a lot of churn. If we're going to do this, let's go big
> and get rid of RPM changelogs. 
> 
> When we have a package update, there are basically two different kinds
> of changelog information. Well, three.
> 
> First, there's the upstream changelog. We don't generally do much with
> these except maybe package as %doc.
> 
> Second, there's package maintainer changelogs. These are really
> redundant with the dist-git log. We don't really need this anymore.
> It's just a chore.

So I've spent a bit of time and created git-rpm-changelog[0]. RFEs, Issues and
PRs are very welcome 😉

Once I will get it working very fast and reliable, I will try to make it part
of packaging process.. Somehow...


[0] https://github.com/ignatenkobrain/git-rpm-changelog
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9y3sACgkQaVcUvRu8
X0xDTxAAuJYSQFA8sIsFoLytUWyEca13z4dWFutsLA14T93/nRkH7/6sf92hqzDt
2ZEWDU3uS8GKe4Xi9t4Obcv9EAbC5ynx4Iu/fHUE83AEiySX8ihndeRyzKhW3zqB
ic/FUjJ5R9sdPMbc4m8LeAasOKgux3KxE57bcfJ5f6KpofVGn1aDZ35sKegox+5G
ZKlfTvutDRgiPjdrlFJEI83DVAqortpO7w4+Wip8JZqvd2EKuMwM34ZxW7S5KsSl
7v+QagenAGqc+hNVKfA9TPl1I8HCgppIphvJ+arS+rNiMJ1ACo4z2hvUx9jr8h7q
e8r26QtcL3U3Ccz/hlzzsWMDYjd195EPjWT4TOU3+t19rsIyuHlqLZUE+H9HVlFk
6cQhsXgsSEDjqrlxyZxh8czzhB5M7emN6I5KhrovHlnq7fzzq/WXF4irNBePmbSk
Tr7AlpGOhBbgrYexjK7xlMzguUvhE5kHHV8zU8pfNRT4F37jnwAezcKzbF7r4jkk
jrL/TxrUEh4N/l/R2JowWeuj17XXsgurNY+JWmu0jPqZtu+78I1AsPnTFjK3Dhwb
v+79osXQr2et9BKBr+APCnaGXaI/lNTfdPFLJVWAHBIvILjtPXbtSkxaDWnbmKxf
yqyGJqUNX8pJEzu+ghDKHDW19WO8PLkM77lQaPV9bZkqQoigxFE=
=5YnU
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Neal Gompa]

On Fri, Feb 9, 2018 at 9:22 AM, Panu Matilainen  wrote:
>
>
> Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
> rocket science we're talking about here if people are ready to give it a go.
>
> Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
> already? Do you know what kind of hook they're using? Actually I think Suse
> does this too so Fedora is probably again the last one to adopt this...
>

Mageia, OpenMandriva, and PLD all generate their changelogs from the
source control system.

Mageia does it with SVN, while OpenMandriva and PLD do it from Git.

Mageia's build system calls "mgarepo rpmlog " and appends it
to the spec file just before starting the package build. mgarepo has a
number of rules for excluding messages from generated changelog
entries, which is how they don't look extremely awful.

OpenMandriva's build system (ABF) does something similar, though it's
been switched off for a while due to it being somewhat slow (they
don't have a lot of build system resources anymore). I'm not aware of
the exact process used by PLD, but they do something similar.

SUSE uses the Open Build Service VCS export to changes files which are
converted into changelog entries at package build time. The changes
files are managed independently, so the function more or less like how
ours does, but some packages also dynamically generate changes entries
based on source VCS information (some openSUSE developed packages have
changes generated from upstream project Git information, for example).

When using a VCS for generating changelogs, you need to enforce some
rules for how to omit or include entries.

In our case, we'd probably want a rule that would make such a thing
actually include the commit message and omit them otherwise, since
unlike the other distributions, we can't rewrite our commit messages
(because Koji builds are tightly associated with commit messages). SVN
disassociates revision from revision message, and OMV and PLD let you
rewrite commits freely. We'd also need a way to "correct" generated
entries when they have errors in them.

But yeah, Fedora is once again a laggard. This seems to be a recurring
trend, and one I'm not particularly pleased about.

-- 
真実はいつも一つ！/ 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: Escaping macros in %changelog

[Panu Matilainen]

On 02/09/2018 03:34 PM, Josh Boyer wrote:

On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller  wrote:

On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:

It seems that a lot of people have %file, %check, %build, %whatsoever
in their changelog section.
Is there any reason I should not go and automatically escape them?


This seems like a lot of churn. If we're going to do this, let's go big
and get rid of RPM changelogs.

When we have a package update, there are basically two different kinds
of changelog information. Well, three.

First, there's the upstream changelog. We don't generally do much with
these except maybe package as %doc.

Second, there's package maintainer changelogs. These are really
redundant with the dist-git log. We don't really need this anymore.
It's just a chore.

Third, though, there's end-user information. Why should a user care
*This* is redundant with bodhi update info, at least if packagers fill
that out, and it often also duplicates upstream changelogs, *and* it
often also covers things like "fixes CVE-' also carried the
specfile changelog.

This is neither most helpful for user *nor* ideal for packages. Why
don't we drop changelogs entirely in favor of 1) using the dist-git
logs for specfile maintainers and 2) providing the end-user information
in a different way. This could be through specially formatted log lines
going with the commit, or it could be simply in a standard separate
file (`fedora.user-visible-changes`). Optionally, it could include both
a high level end-user summary, and a detailed description for sysadmins
and the curious.

Wherever it lives, this would be read by Bodhi, so there's
would be need to enter it more than once. And, perhaps a DNF plugin
could be made to read and display this information for systems
administrators.


I fully support the removal of RPM changelogs.  However, you've missed
two cases:

1) Rawhide, which doesn't go through bodhi
2) Fedora release upgrades, which don't go through bodhi

Now, I would actually LOVE for Rawhide to go through bodhi but
whatever.  The release -> release upgrade isn't really solvable that
way though.

Someone else suggested changelogs could be inserted during koji build
time.  That would be interesting to look into.


Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly 
rocket science we're talking about here if people are ready to give it a go.


Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM 
already? Do you know what kind of hook they're using? Actually I think 
Suse does this too so Fedora is probably again the last one to adopt this...


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

Re: Escaping macros in %changelog

[Josh Boyer]

On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller  wrote:
> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>> It seems that a lot of people have %file, %check, %build, %whatsoever
>> in their changelog section.
>> Is there any reason I should not go and automatically escape them?
>
> This seems like a lot of churn. If we're going to do this, let's go big
> and get rid of RPM changelogs.
>
> When we have a package update, there are basically two different kinds
> of changelog information. Well, three.
>
> First, there's the upstream changelog. We don't generally do much with
> these except maybe package as %doc.
>
> Second, there's package maintainer changelogs. These are really
> redundant with the dist-git log. We don't really need this anymore.
> It's just a chore.
>
> Third, though, there's end-user information. Why should a user care
> *This* is redundant with bodhi update info, at least if packagers fill
> that out, and it often also duplicates upstream changelogs, *and* it
> often also covers things like "fixes CVE-' also carried the
> specfile changelog.
>
> This is neither most helpful for user *nor* ideal for packages. Why
> don't we drop changelogs entirely in favor of 1) using the dist-git
> logs for specfile maintainers and 2) providing the end-user information
> in a different way. This could be through specially formatted log lines
> going with the commit, or it could be simply in a standard separate
> file (`fedora.user-visible-changes`). Optionally, it could include both
> a high level end-user summary, and a detailed description for sysadmins
> and the curious.
>
> Wherever it lives, this would be read by Bodhi, so there's
> would be need to enter it more than once. And, perhaps a DNF plugin
> could be made to read and display this information for systems
> administrators.

I fully support the removal of RPM changelogs.  However, you've missed
two cases:

1) Rawhide, which doesn't go through bodhi
2) Fedora release upgrades, which don't go through bodhi

Now, I would actually LOVE for Rawhide to go through bodhi but
whatever.  The release -> release upgrade isn't really solvable that
way though.

Someone else suggested changelogs could be inserted during koji build
time.  That would be interesting to look into.

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

Re: Escaping macros in %changelog

[Vít Ondruch]

Dne 9.2.2018 v 09:21 Kevin Kofler napsal(a):
> Matthew Miller wrote:
>> Second, there's package maintainer changelogs. These are really
>> redundant with the dist-git log. We don't really need this anymore.
>> It's just a chore.
> My %changelog entries are not identical to the dist-git commit messages:
>
> 1. It often takes me several git commits to make a new EVR that builds.
>Also, typos in commit messages cannot be fixed. (Both of those issues
>could be solved if we were to allow force pushes to dist-git, but that
>would open a much bigger can of worms, as you certainly know.)
>
> 2. Most of my git commit messages are of the form:
>
>one-line summary
>
>full copy&paste of the RPM changelog entry, including the line with date,
>author and EVR.
>
>(The only ones that deviate from that format are followup fixup commits
>as per point 1.) If you are going to generate RPM changelogs from those
>commit messages, they will look really messy, with the date-author-EVR
>line duplicated.
>
> 3. Some of my commit messages contain additional notes that are not intended
>for the package changelog. (Typically a full paragraph of explanatory
>text.)
>
> Thus, I think autogenerating the %changelog from dist-git commit messages 
> would degrade its quality a lot, at least for my packages.

This doesn't mean it could not work. There are, for example, well
established [skip ci] marks [1] used to skip CI for minor changes. We
could have something similar such as [skip changelog], or something of
opposite meaning to include just some specific part of commit message.

In the end it would save you at least the "full copy&paste of the RPM
changelog entry, including the line with date,   author and EVR." work.

BTW I assume you know "fedpkg clog" and "git commit -F clog" to save you
copy&pasting ;)

Vít


[1] https://www.google.cz/search?q=skip+ci

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

Re: Escaping macros in %changelog

[Kamil Dudka]

On Friday, February 9, 2018 9:21:27 AM CET Kevin Kofler wrote:
> Matthew Miller wrote:
> 
> > Second, there's package maintainer changelogs. These are really
> > redundant with the dist-git log. We don't really need this anymore.
> > It's just a chore.
> 
> 
> My %changelog entries are not identical to the dist-git commit messages:
> 
> 1. It often takes me several git commits to make a new EVR that builds.

Would not it be then better to work on this in a staging branch and rework 
those commits before they are pushed to a production branch?  I am myself
not interested in going through commits like "fix a typo", "forgot to bump 
release", "add missing BR", "revert the previous revert", etc.

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

Re: Escaping macros in %changelog

[Pavel Raiskup]

On Friday, February 9, 2018 9:25:33 AM CET Igor Gnatenko wrote:
> On Fri, 2018-02-09 at 08:57 +0100, Pavel Raiskup wrote:
> > On Thursday, February 8, 2018 5:02:10 PM CET Igor Gnatenko wrote:
> > > Hello everyone,
> > >
> > > It seems that a lot of people have %file, %check, %build, %whatsoever in
> > > their
> > > changelog section.
> > >
> > > Is there any reason I should not go and automatically escape them?
> >
> > There's IMO no good reason why you should.
> >
> > I wouldn't use proven packager rights if the package builds fine.  Fill a
> > pull request if anything.
> 
> Then I have doubts that %changelog means anything

It means something but it is not that important to not ship such package.

> because whoever uses rpm -- changelog would see unexpanded macro so if
> you had %autosetup -p1 in there, users would see real commands
> instead... And also it might break in some cases which requires
> maintainer intervention.

I only said why I wouldn't use _my_ provenpackager powers for innocent
issues.

> Also I don't see reason why I should send PR for ~500 packages where most of 
> it
> won't be merged ever. And this will create much more problems for me to track
> this issue rather than just going and fixing all of them.

Though it only delayed (lowered priority of) the real solution ...

> > E.g. server-side git hook refusing commits "adding typos" into changelog
> > would solve it once and forever.  If you were able to implement some
> > systematic change like this then I would excuse the walk across all the
> > spec files to fix old issues..
> 
> https://pagure.io/releng/issue/7300

.. like this.  Thanks!

Pavel


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

Re: Escaping macros in %changelog

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2018-02-09 at 08:57 +0100, Pavel Raiskup wrote:
> On Thursday, February 8, 2018 5:02:10 PM CET Igor Gnatenko wrote:
> > Hello everyone,
> > 
> > It seems that a lot of people have %file, %check, %build, %whatsoever in
> > their
> > changelog section.
> > 
> > Is there any reason I should not go and automatically escape them?
> 
> There's IMO no good reason why you should.
> 
> I wouldn't use proven packager rights if the package builds fine.  Fill a
> pull request if anything.

Then I have doubts that %changelog means anything because whoever uses rpm --
changelog would see unexpanded macro so if you had %autosetup -p1 in there,
users would see real commands instead... And also it might break in some cases
which requires maintainer intervention.

Also I don't see reason why I should send PR for ~500 packages where most of it
won't be merged ever. And this will create much more problems for me to track
this issue rather than just going and fixing all of them.

> One could admit that fixing similar typos (white space issues, spelling
> issues, changelog date issues, ...) is OK if you are touching the spec
> file anyway because of some real problems, but even then you make the
> patch less readable - and thus you raise chances that something get's
> overlooked.  So I wouldn't do that.
> 
> > %check → %%check
> > %build → %%build
> > %whatsoever → %%whatsoever
> > 
> > There might be valid use-cases, but I'm not sure if they really are:
> > %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
> > 
> > Thoughts?
> 
> E.g. server-side git hook refusing commits "adding typos" into changelog
> would solve it once and forever.  If you were able to implement some
> systematic change like this then I would excuse the walk across all the
> spec files to fix old issues..

https://pagure.io/releng/issue/7300
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9Wv0ACgkQaVcUvRu8
X0wgEg/+K6D6X+LtU6WG9wO2uLl8vhx0KjxhHGMKJmp6Fwd6OZ1ZsIXd0su0veuA
CuGRxu6nphmGPg5ElwR+J1jdz4hBK/Hwqju1XZNNCgg56vLrA8OPVFzLlKoBPfqF
YDYfkh91AouECRdowwCeLfUS6pgOFZSlhdptrEusxSBcToL9HtwIf3AtOpUmIi+c
mBZ4TBWmt+4ik12tLR4Up7+n5a/dichEOx3Loq7RFPEOfjvBhudU/MZpn1b0Kf/P
vN8ocKoKbMvuHotHvBvp/j4BhsTIphvXr7Yg7DFItOTu18wfE+xr0DjWr3RZjxjF
bUIUJX4V9SRZHBBHJ6e4lwmifHtOLTlW/wW0d7pQvDKduw5ek0D0Bm/y5I/FEHwa
moY73GB7iQzIUMXOa12X1UyCnPvn3yw1WcBB/90QxovrAfAfYaPgKZmenVqwMapL
B4PKPHnbH2VqkFheZgBifixCL0ENSj35K+xgowQTkWJ1/0ZCXT+U1ihQh951zYF3
Jb7lSKJSVMvp96HgR8vYBQQL34sYM7/cL1/N0BMis3NFjPc0DYbMuVRp0pbuRs0/
XT04F/lTvYBRUbW5wBgY5ss/+kiVVTZLmRaoJXBEbf1fh79d3il5O7oHugYhbCBn
+U927O5rR38EdERBV7BofY1kmoQE9nrki4ZWX3PAyc1muUCvxZM=
=greE
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[nicolas . mailhot]

De: "Przemek Klosowski"

Hi,

> Many environments (corporate, government) actually require keeping track 
> of this stuff, so addressing it would help the acceptance of Fedora and 
> Redhat in such environments

Then have Koji or Bohdi insert accurate changelogs at build time. Can't be less 
reliable than the current crap (though it was useful to drag rpm in UTF-8 land).

Regards,

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

Re: Escaping macros in %changelog

[Kevin Kofler]

Matthew Miller wrote:
> Second, there's package maintainer changelogs. These are really
> redundant with the dist-git log. We don't really need this anymore.
> It's just a chore.

My %changelog entries are not identical to the dist-git commit messages:

1. It often takes me several git commits to make a new EVR that builds.
   Also, typos in commit messages cannot be fixed. (Both of those issues
   could be solved if we were to allow force pushes to dist-git, but that
   would open a much bigger can of worms, as you certainly know.)

2. Most of my git commit messages are of the form:

   one-line summary

   full copy&paste of the RPM changelog entry, including the line with date,
   author and EVR.

   (The only ones that deviate from that format are followup fixup commits
   as per point 1.) If you are going to generate RPM changelogs from those
   commit messages, they will look really messy, with the date-author-EVR
   line duplicated.

3. Some of my commit messages contain additional notes that are not intended
   for the package changelog. (Typically a full paragraph of explanatory
   text.)

Thus, I think autogenerating the %changelog from dist-git commit messages 
would degrade its quality a lot, at least for my packages.

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

Re: Escaping macros in %changelog

[Pavel Raiskup]

On Thursday, February 8, 2018 5:02:10 PM CET Igor Gnatenko wrote:
> Hello everyone,
> 
> It seems that a lot of people have %file, %check, %build, %whatsoever in their
> changelog section.
> 
> Is there any reason I should not go and automatically escape them?

There's IMO no good reason why you should.

I wouldn't use proven packager rights if the package builds fine.  Fill a
pull request if anything.

One could admit that fixing similar typos (white space issues, spelling
issues, changelog date issues, ...) is OK if you are touching the spec
file anyway because of some real problems, but even then you make the
patch less readable - and thus you raise chances that something get's
overlooked.  So I wouldn't do that.

> %check → %%check
> %build → %%build
> %whatsoever → %%whatsoever
> 
> There might be valid use-cases, but I'm not sure if they really are:
> %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
> 
> Thoughts?

E.g. server-side git hook refusing commits "adding typos" into changelog
would solve it once and forever.  If you were able to implement some
systematic change like this then I would excuse the walk across all the
spec files to fix old issues..

Pavel

> --
> -Igor Gnatenko
> ___
> 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: Escaping macros in %changelog

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-02-08 at 13:32 -0500, Matthew Miller wrote:
> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
> > It seems that a lot of people have %file, %check, %build, %whatsoever
> > in their changelog section.
> > Is there any reason I should not go and automatically escape them?
> 
> This seems like a lot of churn. If we're going to do this, let's go big
> and get rid of RPM changelogs. 
> 
> When we have a package update, there are basically two different kinds
> of changelog information. Well, three.
> 
> First, there's the upstream changelog. We don't generally do much with
> these except maybe package as %doc.
> 
> Second, there's package maintainer changelogs. These are really
> redundant with the dist-git log. We don't really need this anymore.
> It's just a chore.
> 
> Third, though, there's end-user information. Why should a user care
> *This* is redundant with bodhi update info, at least if packagers fill
> that out, and it often also duplicates upstream changelogs, *and* it
> often also covers things like "fixes CVE-' also carried the
> specfile changelog.
> 
> This is neither most helpful for user *nor* ideal for packages. Why
> don't we drop changelogs entirely in favor of 1) using the dist-git
> logs for specfile maintainers and 2) providing the end-user information
> in a different way. This could be through specially formatted log lines
> going with the commit, or it could be simply in a standard separate
> file (`fedora.user-visible-changes`). Optionally, it could include both
> a high level end-user summary, and a detailed description for sysadmins
> and the curious.
> 
> Wherever it lives, this would be read by Bodhi, so there's
> would be need to enter it more than once. And, perhaps a DNF plugin
> could be made to read and display this information for systems
> administrators.

While I totally agree with what you've said, there are some problems with
generating changelogs from git.

* Many times people put some useless messages in there, so we probably don't
want to convert old history to git-based changelogs and have point where we ask
people to start writing useful commit messages.
* No easy way to map changelogs with versions and releases in package. Imagine
that you pushed commit with update, then realised that it doesn't build and
reverted. What should be in changelog?

I would **love** to switch to git-based changelogs, but we need to work on
defining how exactly it should behave and find way how to get there (it will
involve release engineering at least). Would be nice if you would describe step
by step workflow you would like to see 😉

In meanwhile, unescaped macros in %changelog create problems because they do
expand.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9SesACgkQaVcUvRu8
X0wPGQ/9E6PRloCCF3q945AVt+saxen2PG+ehvRRjUTPK2tmmQQDf5NzaGsVowF3
/RYwxNpCeiBUgy2mz0/3lfkRSGhvM6km5hT370LdTec0WE85Fd0MUWiYt8uPoL8q
bUxDKpJl6H7gcEFslztP0Ou2W85RWUfGGOux03IZQdjssxDF+bCUX17VrHWaieFA
o1u7Q/jFT6nYGA4F+hHOYF8eFzG7nT64ScJTXL/uJeHTiwT6pBWUm6yCKpl539tl
2+jozmKA/7GcuHopT7QaV51hlJ5nDy+mcAGhjRmYVxm5OIxAxICkegcKCL2FTbsm
BKx70jrd4gb5ScsVUBGUTXgf9BUbUdXwMV2iCrLDiSyDSkOE9kooBifR4lLj7Asf
/eldClCnOkcNeEzapfFvu6T3YDZaG6sVm64UcZ5UdfsJ+44HPE9MygCaicprnRdL
HO8eSQwq7GDYL2i+XZWgXzon3w77u3DBMGYUxOz1tTTTBNiD/mr8EAqxC2gUsxfQ
tCk8NjROmo0d0kqBGr7Fu1ltjVrB0rGx4CRlU/84O/Rt6G53ZWJ/s4+fa/QnhBCz
FzVg/aOPc8+CZX6g+vXr5RJ5lo/oKErzT5hI29eev9oUOJulhA0zc04C9pa7X3tV
9tU6DRsjKLeth9u+ecyH+SOwwfMS8XGVZZ6b2hkFfMOAqqMTWps=
=GWlO
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Zdenek Dohnal]

On 02/08/2018 05:02 PM, Igor Gnatenko wrote:
> Hello everyone,
>
> It seems that a lot of people have %file, %check, %build, %whatsoever
> in their
> changelog section.
>
> Is there any reason I should not go and automatically escape them?
>
> %check → %%check
> %build → %%build
> %whatsoever → %%whatsoever
>
> There might be valid use-cases, but I'm not sure if they really are:
> %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
>
>
> Thoughts?

+1 for me, go ahead :)

> ___ > devel mailing list -- 
> devel@lists.fedoraproject.org > To unsubscribe
send an email to devel-le...@lists.fedoraproject.org
-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C



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: Escaping macros in %changelog

[Matěj Cepl]

On 2018-02-08, 18:32 GMT, Matthew Miller wrote:
> This seems like a lot of churn. If we're going to do this, 
> let's go big and get rid of RPM changelogs. 

+1

Matej
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
How fleeting are all human passions compared to the massive
continuity of ducks.
  -- Dorothy L. Sayers: Gaudy Night
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Przemek Klosowski]

On 02/08/2018 01:32 PM, Matthew Miller wrote:

This seems like a lot of churn. If we're going to do this, let's go big
and get rid of RPM changelogs.

When we have a package update, there are basically two different kinds
of changelog information. Well, three.
[...]
Third, though, there's end-user information. [..]*and*  it
often also covers things like "fixes CVE-' also carried the
specfile changelog.
This is very useful in my opinion. I know that it's not a consistent 
policy driven technology, but rather a sort of a kindness extended by 
consciencious packagers, but it's a great way to correlate specific CVE 
issues to the update stream. Without it, there's no clear way to find 
out if the system is vulnerable or not---the software versions aren't 
necessarily sufficient because of backports, and require manual checking 
to find out when a fix is being included.


Many environments (corporate, government) actually require keeping track 
of this stuff, so addressing it would help the acceptance of Fedora and 
Redhat in such environments
rpm -q --changelog mypackage | grep CVE is really useful in such 
circumstances.


Having said that, the informality of the current setup makes it a little 
haphazard:  I know that not all CVEs are being mentioned--and if they 
are, they don't always mention specific audit information like the BZ 
entries, software revisions etc.


This is neither most helpful for user*nor*  ideal for packages. Why
don't we drop changelogs entirely in favor of 1) using the dist-git
logs for specfile maintainers and 2) providing the end-user information
in a different way. This could be through specially formatted log lines
going with the commit, or it could be simply in a standard separate
file (`fedora.user-visible-changes`). Optionally, it could include both
a high level end-user summary, and a detailed description for sysadmins
and the curious.
I don't like the idea of a separate file; I'd like to preserve and maybe 
codify the security fix info in package metadata. If not changelog, then 
whatevern replaces it should mention the CVEs  in a complete and 
organized way, i.e. the packaging rules should require mentioning CVEs 
and linking them to problem reports and specific patches that address them.



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

Re: Escaping macros in %changelog

[Matthew Miller]

On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
> It seems that a lot of people have %file, %check, %build, %whatsoever
> in their changelog section.
> Is there any reason I should not go and automatically escape them?

This seems like a lot of churn. If we're going to do this, let's go big
and get rid of RPM changelogs. 

When we have a package update, there are basically two different kinds
of changelog information. Well, three.

First, there's the upstream changelog. We don't generally do much with
these except maybe package as %doc.

Second, there's package maintainer changelogs. These are really
redundant with the dist-git log. We don't really need this anymore.
It's just a chore.

Third, though, there's end-user information. Why should a user care
*This* is redundant with bodhi update info, at least if packagers fill
that out, and it often also duplicates upstream changelogs, *and* it
often also covers things like "fixes CVE-' also carried the
specfile changelog.

This is neither most helpful for user *nor* ideal for packages. Why
don't we drop changelogs entirely in favor of 1) using the dist-git
logs for specfile maintainers and 2) providing the end-user information
in a different way. This could be through specially formatted log lines
going with the commit, or it could be simply in a standard separate
file (`fedora.user-visible-changes`). Optionally, it could include both
a high level end-user summary, and a detailed description for sysadmins
and the curious.

Wherever it lives, this would be read by Bodhi, so there's
would be need to enter it more than once. And, perhaps a DNF plugin
could be made to read and display this information for systems
administrators.





-- 
Matthew Miller

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

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Tomasz Kłoczko]

On 8 February 2018 at 17:39, Petr Stodulka  wrote:
[..]

> > There's nothing wrong here.
> >
> >
>
> Exactly. IMHO, use of %dir macro for "top" pkg directories is more clean
> solution, but
> doesn't matter in case the rpm is packaged correctly.
>

I'm sure that in the past it was difference here :|
And I'm sure that I found few specs where it was some issue wen /$ was used.

If I'll not back with some exact examples packages/specs (which I saw in
last 2-3 weeks)  in next few days it will mean that I was wrong :/

Nevertheless I found many directories not owned by any packages on my
system as result of many upgrades.
There are few common causes of such issues:

- example gluster.spec: does owns many directories %{_libdir}/glusterfs and
by this on each upgrade to the next version is
left %{_libdir}/glusterfs/ with many empty directories inside.
Other case is that set of dependencies between subpackages are not correct
and by delete some packages ordering them during remove using dependencies
there are left some empty directories

- example libiscis.spec: sometimes it is bug in spec and exact directory is
not included in %files (not added %{_libdir}/iscis
  BTW there are two iscsi client libraries in distribution and libiscsi
moves clashing library to %{_libdir}/iscis

Probably here is more common cases when after upgrade there is left some
not deleted files or directories.

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: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-02-08 at 16:56 +, Tomasz Kłoczko wrote:
> BTW some massively occurring errors in really big number Fedora of specs.
> 
> Looks like many people don't know that %files entry like:
> 
> /some/directory/
> 
> does not include /some/directory into package but all files and
> subdirectories which are in /some/directory.

This is not true.

/foo/bar is same as /foo/bar/ with one caveat: /foo/bar/ will fail if "bar" is
a file and not a directory.

> What it is causing such mistake everyone can check by executing

No, this is caused by different mispackaging.

> $ (for i in /usr/{lib64,exec,share}; do find $i -name \*; done) 2>&1 |
> xargs rpm -qf |grep "is not owned by any package"

Yes, this is a problem and you better to report bugs instead of dumping this
here.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp8jdkACgkQaVcUvRu8
X0weJg//W5VMwRVH50A9pEQe39EdGJW+HN6jCOp6V0m6NeLyGVj01+WVXtc5X89k
z+OAwiB06l/jDbdjY6VdYfnn8Z2XBvwqyRPlRpOLrffJTuthZOk53l8LFUM6Lf9C
q6MREhl3a1sdtWPzdF2IeDNlCwGa9Eu/dsMcgVuiWi0lpfec4ADXz/kYbD8PtccS
6CyRSZjZOh7fY5xBZReMgc18qTKoo5ZR1nG0cPMfeyE8uGEOOMd0ewsKLucKXv8J
lVriDuU7e2YajnJnYAByIxJqmpIRALaQbsAcLin8uSkkHBNlY1wZsyYL2egJM1bI
XiUei/8xN/TFA3yOtu60JGfSVczJbfdSrQzNABOK9pPR3Rv9XdZTPW2QVIvjKO12
bKw2uq98n8MFszCqyw+31dpN4U5rtyDyoXhBGiBpqKORjYDG1ax8CkrfF79IR67Q
F+taFyZfa8hTQU9vn0EMLs0B/JqioMJ+/muiaNddZ/bAk30fl7cg0yPftWA4WgY1
e4Na7IXQQRbjHhdSSAST3Fqr8y2K77w40BHhR8aSWotDHhkOcdQzVObV3T/CCsqn
re8kCnqTP+YcXvN+CS0Za/6cfHq9mNipyT9xSHOK1ENN14CbmJgtnBLoftYXCrPU
vRli/1pLlPAsI5PsNwnKzee3kBnkD2eQv6aZKdh0r7s/xlRDP+k=
=lugv
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Petr Stodulka]

On 8.2.2018 18:33, Neal Gompa wrote:
> On Thu, Feb 8, 2018 at 11:56 AM, Tomasz Kłoczko
>  wrote:
>> BTW some massively occurring errors in really big number Fedora of specs.
>>
>> Looks like many people don't know that %files entry like:
>>
>> /some/directory/
>>
>> does not include /some/directory into package but all files and
>> subdirectories which are in /some/directory.
>>
> 
> It in fact does.
> 
> The following:
> %files
> /some/directory/
> 
> is equivalent to:
> %files
> %dir /some/directory
> /some/directory/*
> 
> 
> There's nothing wrong here.
> 
> 

Exactly. IMHO, use of %dir macro for "top" pkg directories is more clean 
solution, but
doesn't matter in case the rpm is packaged correctly.

-- 
Petr Stodulka
Core Services (In-place upgrades and migrations)
IRC nicks: pstodulk, skytak
Red Hat



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: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Neal Gompa]

On Thu, Feb 8, 2018 at 11:56 AM, Tomasz Kłoczko
 wrote:
> BTW some massively occurring errors in really big number Fedora of specs.
>
> Looks like many people don't know that %files entry like:
>
> /some/directory/
>
> does not include /some/directory into package but all files and
> subdirectories which are in /some/directory.
>

It in fact does.

The following:
%files
/some/directory/

is equivalent to:
%files
%dir /some/directory
/some/directory/*


There's nothing wrong here.


-- 
真実はいつも一つ！/ 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: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Jerry James]

On Thu, Feb 8, 2018 at 9:56 AM, Tomasz Kłoczko  wrote:
> Looks like many people don't know that %files entry like:
>
> /some/directory/
>
> does not include /some/directory into package but all files and
> subdirectories which are in /some/directory.

That is incorrect.  For example, the polyml spec file contains this in %files:

%{_libdir}/polyml/

And on my x86_64 Fedora 27 box:

$ rpm -qf /usr/lib64/polyml
polyml-5.7.1-1.fc27.x86_64

The trailing slash doesn't matter.  I use it as a visual reminder that
the %files entry is a directory, not a file.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Tomasz Kłoczko]

BTW some massively occurring errors in really big number Fedora of specs.

Looks like many people don't know that %files entry like:

/some/directory/

does not include /some/directory into package but all files and
subdirectories which are in /some/directory.

This is in how many specs such lines are used:

[tkloczko@domek SPECS.fedora]$ grep ^%\{.*\/$ * | grep -v __ | awk -F\.
'{print $1}' | uniq| wc -l
4827

There is

[tkloczko@domek SPECS.fedora]$ grep ^%\{.*\/$ * | grep -v __ | wc -l
17762

such entries in all fedora spec files.

What it is causing such mistake everyone can check by executing

$ (for i in /usr/{lib64,exec,share}; do find $i -name \*; done) 2>&1 |
xargs rpm -qf |grep "is not owned by any package"

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: Escaping macros in %changelog

[Rex Dieter]

Igor Gnatenko wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hello everyone,
> 
> It seems that a lot of people have %file, %check, %build, %whatsoever in
> their changelog section.
> 
> Is there any reason I should not go and automatically escape them?
> 
> %check → %%check
> %build → %%build
> %whatsoever → %%whatsoever

+1 , escape

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

Re: Escaping macros in %changelog

[Sérgio Basto]

On Thu, 2018-02-08 at 16:20 +, Sérgio Basto wrote:
> On Thu, 2018-02-08 at 17:02 +0100, Igor Gnatenko wrote:
> > Hello everyone,
> > 
> > It seems that a lot of people have %file, %check, %build,
> > %whatsoever
> > in their
> > changelog section.
> > 
> > Is there any reason I should not go and automatically escape them?
> > 
> > %check → %%check
> > %build → %%build
> > %whatsoever → %%whatsoever
> > 
> > There might be valid use-cases, but I'm not sure if they really
> > are:
> > %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
> > 
> > 
> > Thoughts?
> 
> I already though a lot about this, my last decision was remove
> %instead add another one . 
> 
> %{_localstatedir}/ft/ → {_localstatedir}/ft/

Also some people make the mistake of comment %setup with #%setup 
which is not correct , setup will still running . #setup is the correct
way of comment out , i.e % have a lot of power so I though would be
better remove then . 


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

Re: Escaping macros in %changelog

[Sérgio Basto]

On Thu, 2018-02-08 at 17:02 +0100, Igor Gnatenko wrote:
> Hello everyone,
> 
> It seems that a lot of people have %file, %check, %build, %whatsoever
> in their
> changelog section.
> 
> Is there any reason I should not go and automatically escape them?
> 
> %check → %%check
> %build → %%build
> %whatsoever → %%whatsoever
> 
> There might be valid use-cases, but I'm not sure if they really are:
> %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
> 
> 
> Thoughts?

I already though a lot about this, my last decision was remove %instead add 
another one . 

%{_localstatedir}/ft/ → {_localstatedir}/ft/


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