-----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
There might be valid use-cases, but I'm not sure if they really are: %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
Thoughts? - -- - -Igor Gnatenko
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,
On Thu, 2018-02-08 at 16:20 +0000, 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 .
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
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.
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.
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,
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
-----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
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 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
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:
- 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
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
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.
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
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] https://research.redhat.com/powerlinux-openpower-development-hosting/
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
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 kevin.kofler@chello.at 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-leave@lists.fedoraproject.org
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
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_Maintainer...
Kind regards Till
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:
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.)
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.
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
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:
- 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.)
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.
- 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-leave@lists.fedoraproject.org
On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller mattdm@fedoraproject.org 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
On 02/09/2018 03:34 PM, Josh Boyer wrote:
On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller mattdm@fedoraproject.org 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:
- Rawhide, which doesn't go through bodhi
- 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 -
On Fri, Feb 9, 2018 at 9:22 AM, Panu Matilainen pmatilai@redhat.com 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 <pkgname>" 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.
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
Hello,
On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen pmatilai@redhat.com wrote:
On 02/09/2018 03:34 PM, Josh Boyer wrote:
On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller mattdm@fedoraproject.org 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:
- Rawhide, which doesn't go through bodhi
- 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-leave@lists.fedoraproject.org
Hello,
On Fri, Feb 9, 2018 at 10:57 PM, Michal Novotny clime@redhat.com wrote:
Hello,
On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen pmatilai@redhat.com wrote:
On 02/09/2018 03:34 PM, Josh Boyer wrote:
On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller mattdm@fedoraproject.org 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:
- Rawhide, which doesn't go through bodhi
- 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-leave@lists.fedoraproject.org
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.
On 09/02/18 16:53 +0000, 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 :-)
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:
- Rawhide, which doesn't go through bodhi
- 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).
On 02/09/2018 08:34 AM, Josh Boyer wrote:
On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller mattdm@fedoraproject.org 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.
- Rawhide, which doesn't go through bodhi
- 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.
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
On 13/02/18 01:00, 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-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.
On Tue, Feb 13, 2018 at 3:03 AM, J. Randall Owens < jrowens.fedora@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
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.
On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow bowlofeggs@fedoraproject.org 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
On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow bowlofeggs@fedoraproject.org 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
On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow bowlofeggs@fedoraproject.org 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
On Sun, Mar 11, 2018 at 10:01 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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 bowlofeggs@fedoraproject.org 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.
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 zbyszek@in.waw.pl 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 bowlofeggs@fedoraproject.org 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
On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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 zbyszek@in.waw.pl 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?
On Sun, Mar 11, 2018 at 2:21 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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 zbyszek@in.waw.pl 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?
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 nkadel@gmail.com wrote:
On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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 zbyszek@in.waw.pl 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
On Sun, Mar 11, 2018 at 3:58 PM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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 nkadel@gmail.com wrote:
On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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 zbyszek@in.waw.pl 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.
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 mattdm@fedoraproject.org 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
- Rawhide, which doesn't go through bodhi
- 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 NEWSLike 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 dcantrell@redhat.com Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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.
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).
On Tue, Feb 13, 2018 at 3:24 PM, Matthew Miller mattdm@fedoraproject.org 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
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,
On Wed, Feb 14, 2018 at 10:00:18AM +0100, nicolas.mailhot@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 wrote:
- 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
The changelog in the spec file could serve that purpose if we could get rid of all the "rebuilt" entries. I would rather write the release notes in the spec file than in a separate file. If the requirement for a new changelog entry for every build could be dropped, then the RPM changelog could become the release notes (although, if it would be called "%release_notes" instead of "%changelog", then it might help packagers understad what to write there).
A separate file doesn't in itself prevent merge conflicts, but dropping the "rebuilt" entries would make merge conflicts rarer.
Of course, if upstream provides a file with suitable release notes, then the spec should just refer to that, so that the packager doesn't have to copy and paste them.
Regarding the issue that started this thread: Users aren't expected to know about RPM macros, so presence of an RPM macro in the release notes would indicate that the packager has misunderstood what release notes should contain.
Björn Persson
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.
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
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.
-----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
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-leave@lists.fedoraproject.org
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-leave@lists.fedoraproject.org
-----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
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..
.. like this. Thanks!
Pavel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I've went and fixed 493 packages (listed below). If it broke something, please let me know. I checked diff briefly and don't think that I broke anything…
Maintainers by package: 389-console mreynolds nhosoi nkinder rmeggins 389-ds-base mreynolds nhosoi nkinder rmeggins FlightGear bellet GtkAda rombobeorn L-function pcpa MAKEDEV airlied clumens Macaulay2 rdieter tremble OpenTK churchyard PyPE moceap R-BSgenome.Celegans.UCSC.ce2 pingou R2spec pingou RdRand jhladky jtulak SDL_image jwrdegoede limb moezroy sdz SimGear bellet jwrdegoede spot abrt abrt-team jfilak jmilan mhabrnal mkutlak mmarusak msuchy acpica-tools ahs3 anjuta gnome-sig kalev limb moezroy rakesh apache-log4j-extras coolsvap gil moceap apmud dwmw2 apper kde-sig rdieter rhughes argus fab janfrode limb asm6809 linville asterisk itamarjp jsmith russellb atomic-devmode jlebon atop grover hobbes1069 limb attica jreznik kde-sig rdieter audiofile ajax alexl caillon caolanm gnome-sig johnp mschwendt rhughes rstrode ssp autofs iankent jmoyer automake kasal praiskup ttomecek aws landgraf rombobeorn b43-fwcutter linville beakerlib afri sopos beets maha mbaldessari bip adamwill bcl mmahut bitmap-fonts pnemade pravins blivet-gui m4rtink vtrefny bsp limb buildnumber-maven-plugin weli cabal-rpm petersen capstone drago01 rebus chemical-mime-data belegdol cjdns sdgathman clamav gnat janfrode mstevens nb pwouters robert sergiomb steve cloudy mmahut sergiopr cmst martinkg cobbler jimi kwizart orion shenson cockpit cockpit dperpeet martinpitt pvolpe stefw colord gnome-sig rhughes common-lisp-controller green compat-gtkhtml314 limb compiz-plugins-extra raveit65 compiz-plugins-main raveit65 cone moceap steve conman dsommers sharkcz tuxbrewr vda container-selinux dwalsh fkluknav jchaloup lsm5 runcom copr-backend clime frostyx msuchy copr-dist-git clime msuchy cqrlog hobbes1069 crda linville createrepo james lmacken packaging-team vmukhame cross-binutils dhowells lkundrak sharkcz crypto-policies lef nmav cups-filters jpopelka twaugh zdohnal custodia cheimes simo cyphesis bruno mpreisle darktable germano madko ohaessler dhcp-forwarder pwouters dietlibc limb djview4 terjeros djvulibre mkasik dmraid agk bmr cfeist iankent jwrdegoede kzak lvm-team mauelsha mbroz mcsontos mornfall pjones prajnoha twaugh zkabelac dnf-plugins-core dmach ignatenkobrain jmracek rpm-software-management-sig dolphin dvratil kde-sig dot2tex radford dovecot mhlavink dpkg kanarip sergiomb topdog dpm-dsi aalvarez andreamanzi ellert rocha simonm dput-ng suraia drgeo-doc brouhaha dt agk mbroz okozina ecryptfs-utils mhlavink raphgro sandeen elementary-xfce-icon-theme hannes elfutils aoliva fche jakub jankratochvil mjw pmachata roland ell sonkun elog tc01 emacs jgu jsynacek msekleta phracek emacs-lua timn eqp jcp etoys dsd gavin tuxbrewr evolution alexl caillon caolanm mbarnes mcrha rhughes rstrode ssp tpopela evolution-data-server alexl caillon caolanm johnp mbarnes mcrha rhughes rstrode ssp exaile cicku deji williamjmorenor fedora-logos alexl caillon caolanm johnp mbarnes rhughes rstrode spot ssp fedpkg ausil cqi lsedlar firewalld erig0 jpopelka twoerner flashrom dhendrix mrnuke peter robert flex kasal pfrankli flow-tools orion stingray forge-parent huwang mizdebsk weli fortune-firefly bruno foxtrotgps bubeck freefem++ cicku corsepiu itamarjp freeipa abbra ipa-maint jhrozek mkosek pvoborni rcritten simo tkrizek freeradius nkondras fts-monitoring aalvarez andreamanzi simonm gawk dkaspar gdb jankratochvil sergiodj genders dmlb2000 gentoo amigadave cicku thias geomview rdieter ghc petersen ghex dodji drago01 kalev gists firemanxbr glite-jobid-api-cpp valtri gnome-bluetooth hadess gnome-media orphan gnome-remote-desktop jadahl gnome-volume-manager orphan gnue-common ashawley gnupg bcl rdieter tmraz golang-github-cpuguy83-go-md2man fpokorny jchaloup lsm5 gold zaniyah gprbuild landgraf rombobeorn grub2 bcl pjones gstreamer alexl caillon caolanm company gnome-sig johnp mbarnes rhughes rstrode ssp wtaymans gstreamer-plugins-base alexl caillon caolanm company gnome-sig johnp mbarnes rhughes rstrode ssp wtaymans gstreamer1-vaapi farnz frafra kwizart moezroy wtaymans gtk2-engines alexl caillon caolanm gnome-sig johnp mbarnes mclasen rhughes rstrode ssp gtkhtml3 alexl caillon caolanm gnome-sig johnp mbarnes mcrha rhughes rstrode ssp gtksourceview2 gnome-sig mclasen rstrode guava huwang mizdebsk guile22 jdulaney mlichvar gzip branto jamartis kdudka pstodulk herqq jreznik hmaccalc nalin hsqldb fnasser jjohnstn mizdebsk httpcomponents-client jerboaa kdaniel mizdebsk msimacek httpcomponents-core jerboaa kdaniel mizdebsk msimacek httpry mhayden httrack cicku fale orphan hunspell-et caolanm hunt limb ibus-typing-booster anishpatil mfabian idm-console-framework mharmsen mreynolds nhosoi nkinder rmeggins iksemel jcollie volter indi-gphoto astro-sig lupinix initscripts dkaspar harald lnykryn zbyszek irma_configuration puiterwijk isl dhowells jakub iw drago01 linville ixpdimm_sw djbw jhli rutvijk jBCrypt sdz jansi-native goldmann mizdebsk msimacek java-1.8.0-openjdk dbhole jerboaa jvanek michalvala omajid java-service-wrapper arg gil lef mizdebsk msimacek javapackages-tools mizdebsk msimacek msrb jaxen mizdebsk jboss-ejb3-ext-api braoru gil lef jetty eclipse-sig kdaniel mizdebsk msimacek jfbterm mtasaka jpathwatch jcapik mizdebsk msimacek kakasi tagoh kchildlock vascom kcolorchooser jreznik kde-sig rdieter than kdbg karsten than kde-i18n kkofler rdieter than kde-runtime dvratil jgrulich jreznik kde-sig kkofler mbriza rdieter than kde-settings dvratil jgrulich jreznik kde-sig mbriza rdieter than kde-workspace dvratil jgrulich jreznik kde-sig mbriza rdieter than kdeartwork-extras orphan rdieter kdebase3 jreznik kkofler rdieter svahl than kdelibs dvratil jgrulich jreznik kde-sig kkofler rdieter than kdelibs3 jreznik kkofler rdieter than kdesrc-build brummbq jgrulich kdewebdev jreznik kde-sig kkofler rdieter than kdocker raphgro rdieter keepass mavit tpokorra keepassxc germano nonamedotc kexec-tools baoquan yangrr keyutils dhowells kf5-kcmutils dvratil jgrulich kde-sig rdieter than kf5-kded dvratil jgrulich kde-sig rdieter than kf5-ktexteditor dvratil jgrulich kde-sig rdieter than kinput2 tagoh kmenuedit kde-sig rdieter knot jvcelak pspacek pwouters tkrizek krecipes balajig8 kkofler lbrickbuster2 jwrdegoede libXi ajax alexl bentiss caillon caolanm glisse johnp mbarnes rhughes rstrode ssp whot libabigail dodji sinnykumari libblockdev sbueno vpodzime vtrefny libclaw lkundrak martinkg xavierb libdigidocpp anttix germano kalev libdvdread fkluknav hhorak itamarjp rathann rdieter libeXosip2 nucleo libgovirt teuf libgringotts aarem cwickert libjaylink jkastner mrnuke libkeepalive psutter libkomparediff2 jgrulich kde-sig kkofler rdieter than libmnl hushan libmongo-client czanik rsroka theinric libnfnetlink stingray libpagemap pholasek libqalculate deji nonamedotc rdieter libqb beekhof jpokorny libselinux dwalsh mgrepl pcmoore plautrba libsemanage dwalsh mgrepl pcmoore plautrba libsigc++ jwrdegoede limb libtaskotron mkrizek qa-tools-sig libtimezonemap dshea libunwind jsorensen kyle pmachata spot libverto-jsonrpc npmccallum libwacom bentiss hadess ofourdan whot liferea cheese eseyman tuxbrewr yaneti yselkowitz lightdm-gtk alt-gtk-de-sig besser82 cwickert leigh123linux raveit65 rdieter linkchecker cicku dchen mikep linux-firmware dwmw2 jforbes jwboyer kyle labbott linux_logo thias livecd-tools astokes bcl bruno huff katzj ngompa llvm ajax daveisfera dmalcolm ignatenkobrain jakub jistone kyle scottt siddharths tstellar llvm3.7 nalimilan orion lmarbles thias logcheck mrunge logjam spot logwatch frankcrawford herrold jsynacek lorax bcl clumens dcantrel dmach mgracik wwoods ltrace djdelorie law pmachata lua-sql timn lv tagoh lvm2 agk bmarzins bmr cfeist kzak lvm-team mauelsha mbroz mcsontos mornfall msnitzer pjones prajnoha zkabelac lz4 ignatenkobrain kumarpraveen pjp manaplus bruno maven akurtakov jamielinux mizdebsk msimacek msrb maven-assembly-plugin gil huwang jcapik mizdebsk msimacek maven-plugin-testing jcapik mizdebsk msimacek yyang mc jnovy kloczek slavazanko vda meiga rajeeshknambiar mercurial kiilerix nbecker pstodulk meshmagick bruno mgopen-fonts sarantis mhonarc jamatos tremble xavierb mingw-pango epienbro kalev rjones mirrorbrain averi mlocate mitr msekleta vpavlin mlpack rcurtin mock jcwillia mebrown msuchy mockito jerboaa omajid raphgro rfenkhuber rkennke mod_auth_openidc adelton jdennis puiterwijk mod_authnz_pam adelton mod_revocator kwright mharmsen mongo-cxx-driver mskalick tdawson mongodb hhorak jpacner maxamillion mskalick strobert tdawson moreutils ryansb slankes mtdev whot munge stevetraylen nbdkit rjones net-tools mruprich mruprich zdohnal netbeans-resolver moceap nethack fale lmacken tachoknight netplug jpopelka network-manager-applet bengal danw dcbw fgiudici jklimes lkundrak thaller newlisp ndowens nfs-utils bfields steved nled ctyler nmh bressers levined nodejs-less jamielinux mrunge nodejs-sig patches sgallagh nodejs-mime-db jsmith nodejs-sig nrpe hedenface herrold nb smooge swilkerson numactl pholasek nuttcp nmav rvokal objectweb-asm3 dwalluck fnasser mizdebsk msimacek obmenu mlichvar ocaml-camlimages bruno ocaml-curl dchen rjones ocaml-extlib rjones ocaml-lablgl dchen peter rjones ocaml-lablgtk amdunn dchen jtaylor rjones ocaml-perl4caml rjones office-runner baptistemm hguemar opencv hguemar hhorak jmlich jridky kwizart pkajaba sergiomb vjancik opendkim stevej opendmarc stevej openldap jsynacek mhonek rmeggins openmpi deji dledford jhladky orion origin maxamillion tdawson orpie bowlofeggs jaredwallace oscap-anaconda-addon vpodzime osm-gps-map jcollie jkastner lef osm2pgsql fab oxygen-fonts dvratil jgrulich kde-sig rdieter than pacman cicku zbyszek pam-u2f sjenning pam_afs_session ktdreyer papaki lgao paraview deji orion sagitter pbuilder sergiomb smani pcs cfeist idevat omular tojeline pdns mstevens ruben perl alexl caillon caolanm corsepiu iarnell jplesnik mbarnes ppisar psabata rhughes spot ssp perl-Algorithm-Annotate jplesnik ppisar perl-BSSolv jstribny perl-Boulder orion perl-Class-DBI-Plugin-Type spot perl-Convert-Binary-C alexlan jplesnik perl-Convert-UUlib robert perl-DBD-SQLite2 spot perl-DBIx-Class-EncodedColumn iarnell jplesnik perl-Goo-Canvas liangsuilong perl-HTML-Mason-PSGIHandler corsepiu perl-HTML-Quoted corsepiu perl-IO-Handle-Util corsepiu jplesnik jpo mmaslano ppisar perl-LWP-Protocol-http10 corsepiu perl-Net-SSH-Expect redragon perl-POE-Component-Client-Keepalive jehane jplesnik ppisar perl-Params-Util corsepiu laxathom perl-Plack corsepiu eseyman jpo ppisar perl-Unix-Statgrab cicku steve ttorling perl-namespace-clean jplesnik pghmcfc ppisar tremble permlib jjames php-pecl-imagick hubbitus phpMyAdmin remi robert pki-core edewata kwright mharmsen vakwetu pki-usgov-dod-cacerts spollei plague dcbw plexus-build-api huwang jcapik mizdebsk plymouth elad gnome-sig rstrode pngquant besser82 sergiomb po4a athimm sergiomb sharkcz portreserve twaugh postscriptbarcode mariobl orphan powermock dchen jerboaa lef msimacek neugens rkennke ppp jskarvad jsynacek msekleta thozza preload orphan procps-ng jrybar protobuf abbot ignatenkobrain mizdebsk peter psi ivanromanov slankes psi-plus ivanromanov psiconv huzaifas ptpd jondkent pbrobinson publican jfearn rlandmann pulseaudio jankratochvil lennart lkundrak rdieter wtaymans py3status gchamoul kubo pyjokes pbrobinson pwhalen pykickstart bcl clumens dcantrel jkonecny m4rtink rvykydal sbueno vponcova pylint bcl lupinix mrunge orion pypar bstinson deji pypy mcyprian mstuchli python-sig pyroom slankes sundaram python-HTMLgen jamatos python-acme elyscape itamarjp jhogarth nb noodles rbu python-afl mcyprian python-argcomplete dageek dbmacartney ignatenkobrain stevetraylen python-bash8 flepied python-cffi brouhaha jdulaney python-cotyledon apevec pkilambi python-docker carlwgeorge ttomecek python-docker-py lsm5 mstuchli ttomecek python-flask-httpauth jpena python-flask-wtf kumarpraveen pjp sundaram tflink python-flower jcline python-gammu laxathom sergiomb python-gencpp rmattes robotics-sig thofmann python-genlisp rmattes robotics-sig thofmann python-genpy rmattes robotics-sig thofmann python-gerritlib kashyapc python-gfm germano thm python-gitdb ignatenkobrain lsedlar python-glusterfs-api humble kkeithle ppai python-greenlet abbot ignatenkobrain kevin salimma terjeros python-kubernetes amoralej python-memcached apevec hguemar kevin sgallagh python-mlpy dhanesh95 python-ncclient ihrachyshka python-oasa limb python-openidc-client mohanboddu puiterwijk python-parsedatetime itamarjp mbaldessari python-pygraphviz zbyszek python-pymilter pwouters sdgathman python-pyswip thofmann python-responses germano python-sphinx-argparse aviso bcl lupinix python-tw2-core lmacken ralph python-txws infra-sig ralph python-virtualenvwrapper cstratak infra-sig python-wsgi_intercept apevec chandankumar python3 bkabrda churchyard cstratak ishcherb mcyprian pviktori rkuska tomspur torsava qdevelop moceap qdigidoc anttix germano kalev qpid-dispatch irina tross qt dvratil jreznik kasal kkofler rdieter than qt3 kkofler rdieter than qt5-qtbase jgrulich jreznik kde-sig rdieter than qt5-qtdeclarative jgrulich jreznik kde-sig rdieter than qt5-qtquickcontrols jgrulich jreznik kde-sig lkundrak rdieter than qtermwidget heliocastro lupinix lxqt-sig raphgro tieugene quagga balajig8 mruprich msekleta qucs chitlesh rblcheck moceap rcrpanel jjmcd rdopkg jruzicka recode zkota redis cicku flaper87 nathans remind orphan renrot andriy cra resource-agents beekhof cfeist dvossel lon oalbrigt rkhunter kevin nonamedotc wolfy rp-pppoe than rpm ffesti ignatenkobrain mjw packaging-team pmatilai pmoravco vmukhame rss-glx cheese rsync mruprich pavlix simo vvitek rubygem-charlock_holmes axilleas ktdreyer rubygem-memcache-client mmorsi rubygem-mixlib-cli jdunn rubygem-mixlib-config jdunn rubygem-mixlib-log jdunn rubygem-mongo tdawson vondruch rubygem-omniauth axilleas ruby-packagers-sig rubygem-rainbow jstribny pvalena samba abbra anoopcs asn gd jarrpa jlayton obnox simo samefile buc mschwendt scanssh moceap schroot zachcarter scim pwu selinux-policy dwalsh lvrabec mgrepl pcmoore plautrba serpentine orphan setroubleshoot dwalsh mgrepl pcmoore plautrba sfntly pnemade shorewall mbaldessari shunit2 hushan sjinn linville snake jlaska wwoods snapper agk ignatenkobrain lvm-team msnitzer okozina soprano jreznik kde-sig rdieter than sphinx-webtools averi spim mikep springlobby gilboa sqlcli larsks srcpd dfateyev sslh jhogarth storhaug jarrpa kkeithle subtitleeditor ankursinha mso sugar-colordeducto snavin sugar-pukllanapac callkalpa sugar-ruler callkalpa svgalib orion synapse mtasaka renich tonet666p synfig limb luya syslog-ng czanik jpo marcusk mrunge system-config-printer jpopelka twaugh zdohnal systemtap brolley drsmith2 fche jistone lberk mjw nathans scox smakarov wcohen sysusage frankcrawford targetcli grover teeworlds ignatenkobrain limb lkundrak ohaessler tftp jsynacek themonospot-base hman-it themonospot-console hman-it themonospot-plugin-avi hman-it themonospot-plugin-mkv hman-it tinymce kevin mrunge tkdnd tjikkun tomcat akurtakov coolsvap csutherl kdaniel van tpm2-tss javierm snits yunyings trac daveisfera fschwarz limb lmacken translate-toolkit cicku dwayne mmraka petersen tremulous-data pwalter ucblogo gemi uhd jskarvad unbound pavlix pemensik pwouters thozza urw-fonts dkaspar than utrac limb vboot-utils parasense vdr martinkg vpv vegastrike-data bruno jwrdegoede vegastrike-music bruno jwrdegoede verilator chitlesh scottt vhostmd rjones wavbreaker dmaley wiggle gospo linville wireshark huzaifas jlayton mruprich msehnout phatina steved xen jforbes myoung xfce4-taskmanager cwickert mikedep333 nonamedotc xflr5 smani xhtml2fo-style-xsl olea ovasik xmltool guidograzioli xmltooling bruno guidograzioli xmvn mizdebsk msimacek msrb xplayer-plparser alt-gtk-de-sig besser82 leigh123linux xrdp bojan itamarjp proski yast2-devtools besser82 ypbind hhorak mmuzila pkubat yubico-piv-tool jjelen yum james jbowes katzj packaging-team vmukhame
Packages by maintainer: aalvarez dpm-dsi fts-monitoring aarem libgringotts abbot protobuf python-greenlet abbra freeipa samba abrt-team abrt adamwill bip adelton mod_auth_openidc mod_authnz_pam afri beakerlib agk dmraid dt lvm2 snapper ahs3 acpica-tools airlied MAKEDEV ajax audiofile libXi llvm akurtakov maven tomcat alexl audiofile evolution evolution-data-server fedora-logos gstreamer gstreamer-plugins-base gtk2-engines gtkhtml3 libXi perl alexlan perl-Convert-Binary-C alt-gtk-de-sig lightdm-gtk xplayer-plparser amdunn ocaml-lablgtk amigadave gentoo amoralej python-kubernetes andreamanzi dpm-dsi fts-monitoring andriy renrot anishpatil ibus-typing-booster ankursinha subtitleeditor anoopcs samba anttix libdigidocpp qdigidoc aoliva elfutils apevec python-cotyledon python-memcached python-wsgi_intercept arg java-service-wrapper ashawley gnue-common asn samba astokes livecd-tools astro-sig indi-gphoto athimm po4a ausil fedpkg averi mirrorbrain sphinx-webtools aviso python-sphinx-argparse axilleas rubygem-charlock_holmes rubygem-omniauth balajig8 krecipes quagga baoquan kexec-tools baptistemm office-runner bcl bip gnupg grub2 livecd-tools lorax pykickstart pylint python-sphinx- argparse beekhof libqb resource-agents belegdol chemical-mime-data bellet FlightGear SimGear bengal network-manager-applet bentiss libXi libwacom besser82 lightdm-gtk pngquant xplayer-plparser yast2-devtools bfields nfs-utils bkabrda python3 bmarzins lvm2 bmr dmraid lvm2 bojan xrdp bowlofeggs orpie branto gzip braoru jboss-ejb3-ext-api bressers nmh brolley systemtap brouhaha drgeo-doc python-cffi brummbq kdesrc-build bruno cyphesis fortune-firefly livecd-tools manaplus meshmagick ocaml- camlimages vegastrike-data vegastrike-music xmltooling bstinson pypar bubeck foxtrotgps buc samefile caillon audiofile evolution evolution-data-server fedora-logos gstreamer gstreamer-plugins-base gtk2-engines gtkhtml3 libXi perl callkalpa sugar-pukllanapac sugar-ruler caolanm audiofile evolution evolution-data-server fedora-logos gstreamer gstreamer-plugins-base gtk2-engines gtkhtml3 hunspell-et libXi perl carlwgeorge python-docker cfeist dmraid lvm2 pcs resource-agents chandankumar python-wsgi_intercept cheese liferea rss-glx cheimes custodia chitlesh qucs verilator churchyard OpenTK python3 cicku exaile freefem++ gentoo httrack linkchecker pacman perl-Unix- Statgrab redis translate-toolkit clime copr-backend copr-dist-git clumens MAKEDEV lorax pykickstart cockpit cockpit company gstreamer gstreamer-plugins-base coolsvap apache-log4j-extras tomcat corsepiu freefem++ perl perl-HTML-Mason-PSGIHandler perl-HTML-Quoted perl-IO- Handle-Util perl-LWP-Protocol-http10 perl-Params-Util perl-Plack cqi fedpkg cra renrot cstratak python-virtualenvwrapper python3 csutherl tomcat ctyler nled cwickert libgringotts lightdm-gtk xfce4-taskmanager czanik libmongo-client syslog-ng dageek python-argcomplete danw network-manager-applet daveisfera llvm trac dbhole java-1.8.0-openjdk dbmacartney python-argcomplete dcantrel lorax pykickstart dcbw network-manager-applet plague dchen linkchecker ocaml-curl ocaml-lablgl ocaml-lablgtk powermock deji exaile libqalculate openmpi paraview pypar dfateyev srcpd dhanesh95 python-mlpy dhendrix flashrom dhowells cross-binutils isl keyutils djbw ixpdimm_sw djdelorie ltrace dkaspar gawk initscripts urw-fonts dledford openmpi dmach dnf-plugins-core lorax dmalcolm llvm dmaley wavbreaker dmlb2000 genders dodji ghex libabigail dperpeet cockpit drago01 capstone ghex iw drsmith2 systemtap dsd etoys dshea libtimezonemap dsommers conman dvossel resource-agents dvratil dolphin kde-runtime kde-settings kde-workspace kdelibs kf5-kcmutils kf5-kded kf5-ktexteditor oxygen-fonts qt dwalluck objectweb-asm3 dwalsh container-selinux libselinux libsemanage selinux-policy setroubleshoot dwayne translate-toolkit dwmw2 apmud linux-firmware eclipse-sig jetty edewata pki-core elad plymouth ellert dpm-dsi elyscape python-acme epienbro mingw-pango erig0 firewalld eseyman liferea perl-Plack fab argus osm2pgsql fale httrack nethack farnz gstreamer1-vaapi fche elfutils systemtap ffesti rpm fgiudici network-manager-applet firemanxbr gists fkluknav container-selinux libdvdread flaper87 redis flepied python-bash8 fnasser hsqldb objectweb-asm3 fpokorny golang-github-cpuguy83-go-md2man frafra gstreamer1-vaapi frankcrawford logwatch sysusage frostyx copr-backend fschwarz trac gavin etoys gchamoul py3status gd samba gemi ucblogo germano darktable keepassxc libdigidocpp python-gfm python-responses qdigidoc gil apache-log4j-extras java-service-wrapper jboss-ejb3-ext-api maven- assembly-plugin gilboa springlobby glisse libXi gnat clamav gnome-sig anjuta audiofile colord gstreamer gstreamer-plugins-base gtk2- engines gtkhtml3 gtksourceview2 plymouth goldmann jansi-native gospo wiggle green common-lisp-controller grover atop targetcli guidograzioli xmltool xmltooling hadess gnome-bluetooth libwacom hannes elementary-xfce-icon-theme harald initscripts hedenface nrpe heliocastro qtermwidget herrold logwatch nrpe hguemar office-runner opencv python-memcached hhorak libdvdread mongodb opencv ypbind hman-it themonospot-base themonospot-console themonospot-plugin-avi themonospot-plugin-mkv hobbes1069 atop cqrlog hubbitus php-pecl-imagick huff livecd-tools humble python-glusterfs-api hushan libmnl shunit2 huwang forge-parent guava maven-assembly-plugin plexus-build-api huzaifas psiconv wireshark iankent autofs dmraid iarnell perl perl-DBIx-Class-EncodedColumn idevat pcs ignatenkobrain dnf-plugins-core llvm lz4 protobuf python-argcomplete python- gitdb python-greenlet rpm snapper teeworlds ihrachyshka python-ncclient infra-sig python-txws python-virtualenvwrapper ipa-maint freeipa irina qpid-dispatch ishcherb python3 itamarjp asterisk freefem++ libdvdread python-acme python-parsedatetime xrdp ivanromanov psi psi-plus jadahl gnome-remote-desktop jakub elfutils isl llvm jamartis gzip jamatos mhonarc python-HTMLgen james createrepo yum jamielinux maven nodejs-less janfrode argus clamav jankratochvil elfutils gdb pulseaudio jaredwallace orpie jarrpa samba storhaug javierm tpm2-tss jbowes yum jcapik jpathwatch maven-assembly-plugin maven-plugin-testing plexus-build- api jchaloup container-selinux golang-github-cpuguy83-go-md2man jcline python-flower jcollie iksemel osm-gps-map jcp eqp jcwillia mock jdennis mod_auth_openidc jdulaney guile22 python-cffi jdunn rubygem-mixlib-cli rubygem-mixlib-config rubygem-mixlib-log jehane perl-POE-Component-Client-Keepalive jerboaa httpcomponents-client httpcomponents-core java-1.8.0-openjdk mockito powermock jfearn publican jfilak abrt jforbes linux-firmware xen jgrulich kde-runtime kde-settings kde-workspace kdelibs kdesrc-build kf5- kcmutils kf5-kded kf5-ktexteditor libkomparediff2 oxygen-fonts qt5-qtbase qt5- qtdeclarative qt5-qtquickcontrols jgu emacs jhladky RdRand openmpi jhli ixpdimm_sw jhogarth python-acme sslh jhrozek freeipa jimi cobbler jistone llvm systemtap jjames permlib jjelen yubico-piv-tool jjmcd rcrpanel jjohnstn hsqldb jkastner libjaylink osm-gps-map jklimes network-manager-applet jkonecny pykickstart jlaska snake jlayton samba wireshark jlebon atomic-devmode jmilan abrt jmlich opencv jmoyer autofs jmracek dnf-plugins-core jnovy mc johnp audiofile evolution-data-server fedora-logos gstreamer gstreamer- plugins-base gtk2-engines gtkhtml3 libXi jondkent ptpd jpacner mongodb jpena python-flask-httpauth jplesnik perl perl-Algorithm-Annotate perl-Convert-Binary-C perl-DBIx-Class- EncodedColumn perl-IO-Handle-Util perl-POE-Component-Client-Keepalive perl- namespace-clean jpo perl-IO-Handle-Util perl-Plack syslog-ng jpokorny libqb jpopelka cups-filters firewalld netplug system-config-printer jreznik attica herqq kcolorchooser kde-runtime kde-settings kde-workspace kdebase3 kdelibs kdelibs3 kdewebdev qt qt5-qtbase qt5-qtdeclarative qt5- qtquickcontrols soprano jridky opencv jruzicka rdopkg jrybar procps-ng jskarvad ppp uhd jsmith asterisk nodejs-mime-db jsorensen libunwind jstribny perl-BSSolv rubygem-rainbow jsynacek emacs logwatch openldap ppp tftp jtaylor ocaml-lablgtk jtulak RdRand jvanek java-1.8.0-openjdk jvcelak knot jwboyer linux-firmware jwrdegoede SDL_image SimGear dmraid lbrickbuster2 libsigc++ vegastrike-data vegastrike-music kalev anjuta ghex libdigidocpp mingw-pango qdigidoc kanarip dpkg karsten kdbg kasal automake flex qt kashyapc python-gerritlib katzj livecd-tools yum kdaniel httpcomponents-client httpcomponents-core jetty tomcat kde-sig apper attica dolphin kcolorchooser kde-runtime kde-settings kde- workspace kdelibs kdewebdev kf5-kcmutils kf5-kded kf5-ktexteditor kmenuedit libkomparediff2 oxygen-fonts qt5-qtbase qt5-qtdeclarative qt5-qtquickcontrols soprano kdudka gzip kevin python-greenlet python-memcached rkhunter tinymce kiilerix mercurial kkeithle python-glusterfs-api storhaug kkofler kde-i18n kde-runtime kdebase3 kdelibs kdelibs3 kdewebdev krecipes libkomparediff2 qt qt3 kloczek mc ktdreyer pam_afs_session rubygem-charlock_holmes kubo py3status kumarpraveen lz4 python-flask-wtf kwizart cobbler gstreamer1-vaapi opencv kwright mod_revocator pki-core kyle libunwind linux-firmware llvm kzak dmraid lvm2 labbott linux-firmware landgraf aws gprbuild larsks sqlcli law ltrace laxathom perl-Params-Util python-gammu lberk systemtap lef crypto-policies java-service-wrapper jboss-ejb3-ext-api osm-gps-map powermock leigh123linux lightdm-gtk xplayer-plparser lennart pulseaudio levined nmh lgao papaki liangsuilong perl-Goo-Canvas limb SDL_image anjuta argus atop bsp compat-gtkhtml314 dietlibc hunt libsigc++ python-oasa synfig teeworlds trac utrac linville asm6809 b43-fwcutter crda iw sjinn wiggle lkundrak cross-binutils libclaw network-manager-applet pulseaudio qt5- qtquickcontrols teeworlds lmacken createrepo nethack python-tw2-core trac lnykryn initscripts lon resource-agents lsedlar fedpkg python-gitdb lsm5 container-selinux golang-github-cpuguy83-go-md2man python-docker-py lupinix indi-gphoto pylint python-sphinx-argparse qtermwidget luya synfig lvm-team dmraid lvm2 snapper lvrabec selinux-policy lxqt-sig qtermwidget m4rtink blivet-gui pykickstart madko darktable maha beets marcusk syslog-ng mariobl postscriptbarcode martinkg cmst libclaw vdr martinpitt cockpit mauelsha dmraid lvm2 mavit keepass maxamillion mongodb origin mbaldessari beets python-parsedatetime shorewall mbarnes evolution evolution-data-server fedora-logos gstreamer gstreamer- plugins-base gtk2-engines gtkhtml3 libXi perl mbriza kde-runtime kde-settings kde-workspace mbroz dmraid dt lvm2 mclasen gtk2-engines gtksourceview2 mcrha evolution evolution-data-server gtkhtml3 mcsontos dmraid lvm2 mcyprian pypy python-afl python3 mebrown mock mfabian ibus-typing-booster mgracik lorax mgrepl libselinux libsemanage selinux-policy setroubleshoot mhabrnal abrt mharmsen idm-console-framework mod_revocator pki-core mhayden httpry mhlavink dovecot ecryptfs-utils mhonek openldap michalvala java-1.8.0-openjdk mikedep333 xfce4-taskmanager mikep linkchecker spim mitr mlocate mizdebsk forge-parent guava hsqldb httpcomponents-client httpcomponents-core jansi-native java-service-wrapper javapackages-tools jaxen jetty jpathwatch maven maven-assembly-plugin maven-plugin-testing objectweb-asm3 plexus-build- api protobuf xmvn mjw elfutils rpm systemtap mkasik djvulibre mkosek freeipa mkrizek libtaskotron mkutlak abrt mlichvar guile22 obmenu mmahut bip cloudy mmarusak abrt mmaslano perl-IO-Handle-Util mmorsi rubygem-memcache-client mmraka translate-toolkit mmuzila ypbind moceap PyPE apache-log4j-extras cone netbeans-resolver qdevelop rblcheck scanssh moezroy SDL_image anjuta gstreamer1-vaapi mohanboddu python-openidc-client mornfall dmraid lvm2 mpreisle cyphesis mreynolds 389-console 389-ds-base idm-console-framework mrnuke flashrom libjaylink mrunge logcheck nodejs-less pylint syslog-ng tinymce mruprich net-tools net-tools quagga rsync wireshark mschwendt audiofile samefile msehnout wireshark msekleta emacs mlocate ppp quagga msimacek httpcomponents-client httpcomponents-core jansi-native java-service- wrapper javapackages-tools jetty jpathwatch maven maven-assembly-plugin maven- plugin-testing objectweb-asm3 powermock xmvn mskalick mongo-cxx-driver mongodb msnitzer lvm2 snapper mso subtitleeditor msrb javapackages-tools maven xmvn mstevens clamav pdns mstuchli pypy python-docker-py msuchy abrt copr-backend copr-dist-git mock mtasaka jfbterm synapse myoung xen nalimilan llvm3.7 nalin hmaccalc nathans redis systemtap nb clamav nrpe python-acme nbecker mercurial ndowens newlisp neugens powermock ngompa livecd-tools nhosoi 389-console 389-ds-base idm-console-framework nkinder 389-console 389-ds-base idm-console-framework nkondras freeradius nmav crypto-policies nuttcp nodejs-sig nodejs-less nodejs-mime-db nonamedotc keepassxc libqalculate rkhunter xfce4-taskmanager noodles python-acme npmccallum libverto-jsonrpc nucleo libeXosip2 oalbrigt resource-agents obnox samba ofourdan libwacom ohaessler darktable teeworlds okozina dt snapper olea xhtml2fo-style-xsl omajid java-1.8.0-openjdk mockito omular pcs orion cobbler flow-tools llvm3.7 openmpi paraview perl-Boulder pylint svgalib orphan gnome-media gnome-volume-manager httrack kdeartwork-extras postscriptbarcode preload remind serpentine ovasik xhtml2fo-style-xsl packaging-team createrepo rpm yum parasense vboot-utils patches nodejs-less pavlix rsync unbound pbrobinson ptpd pyjokes pcmoore libselinux libsemanage selinux-policy setroubleshoot pcpa L-function pemensik unbound peter flashrom ocaml-lablgl protobuf petersen cabal-rpm ghc translate-toolkit pfrankli flex pghmcfc perl-namespace-clean phatina wireshark pholasek libpagemap numactl phracek emacs pingou R-BSgenome.Celegans.UCSC.ce2 R2spec pjones dmraid grub2 lvm2 pjp lz4 python-flask-wtf pkajaba opencv pkilambi python-cotyledon pkubat ypbind plautrba libselinux libsemanage selinux-policy setroubleshoot pmachata elfutils libunwind ltrace pmatilai rpm pmoravco rpm pnemade bitmap-fonts sfntly ppai python-glusterfs-api ppisar perl perl-Algorithm-Annotate perl-IO-Handle-Util perl-POE-Component- Client-Keepalive perl-Plack perl-namespace-clean praiskup automake prajnoha dmraid lvm2 pravins bitmap-fonts proski xrdp psabata perl pspacek knot pstodulk gzip mercurial psutter libkeepalive puiterwijk irma_configuration mod_auth_openidc python-openidc-client pvalena rubygem-rainbow pviktori python3 pvoborni freeipa pvolpe cockpit pwalter tremulous-data pwhalen pyjokes pwouters clamav dhcp-forwarder knot python-pymilter unbound pwu scim python-sig pypy qa-tools-sig libtaskotron radford dot2tex rajeeshknambiar meiga rakesh anjuta ralph python-tw2-core python-txws raphgro ecryptfs-utils kdocker mockito qtermwidget rathann libdvdread raveit65 compiz-plugins-extra compiz-plugins-main lightdm-gtk rbu python-acme rcritten freeipa rcurtin mlpack rdieter Macaulay2 apper attica geomview gnupg kcolorchooser kde-i18n kde- runtime kde-settings kde-workspace kdeartwork-extras kdebase3 kdelibs kdelibs3 kdewebdev kdocker kf5-kcmutils kf5-kded kf5-ktexteditor kmenuedit libdvdread libkomparediff2 libqalculate lightdm-gtk oxygen-fonts pulseaudio qt qt3 qt5- qtbase qt5-qtdeclarative qt5-qtquickcontrols soprano rebus capstone redragon perl-Net-SSH-Expect remi phpMyAdmin renich synapse rfenkhuber mockito rhughes apper audiofile colord evolution evolution-data-server fedora-logos gstreamer gstreamer-plugins-base gtk2-engines gtkhtml3 libXi perl rjones mingw-pango nbdkit ocaml-curl ocaml-extlib ocaml-lablgl ocaml- lablgtk ocaml-perl4caml vhostmd rkennke mockito powermock rkuska python3 rlandmann publican rmattes python-gencpp python-genlisp python-genpy rmeggins 389-console 389-ds-base idm-console-framework openldap robert clamav flashrom perl-Convert-UUlib phpMyAdmin robotics-sig python-gencpp python-genlisp python-genpy rocha dpm-dsi roland elfutils rombobeorn GtkAda aws gprbuild rpm-software-management-sig dnf-plugins-core rsroka libmongo-client rstrode audiofile evolution evolution-data-server fedora-logos gstreamer gstreamer-plugins-base gtk2-engines gtkhtml3 gtksourceview2 libXi plymouth ruben pdns ruby-packagers-sig rubygem-omniauth runcom container-selinux russellb asterisk rutvijk ixpdimm_sw rvokal nuttcp rvykydal pykickstart ryansb moreutils sagitter paraview salimma python-greenlet sandeen ecryptfs-utils sarantis mgopen-fonts sbueno libblockdev pykickstart scottt llvm verilator scox systemtap sdgathman cjdns python-pymilter sdz SDL_image jBCrypt sergiodj gdb sergiomb clamav dpkg opencv pbuilder pngquant po4a python-gammu sergiopr cloudy sgallagh nodejs-less python-memcached sharkcz conman cross-binutils po4a shenson cobbler siddharths llvm simo custodia freeipa rsync samba simonm dpm-dsi fts-monitoring sinnykumari libabigail sjenning pam-u2f slankes moreutils psi pyroom slavazanko mc smakarov systemtap smani pbuilder xflr5 smooge nrpe snavin sugar-colordeducto snits tpm2-tss sonkun ell sopos beakerlib spollei pki-usgov-dod-cacerts spot SimGear fedora-logos libunwind logjam perl perl-Class-DBI-Plugin- Type perl-DBD-SQLite2 ssp audiofile evolution evolution-data-server fedora-logos gstreamer gstreamer-plugins-base gtk2-engines gtkhtml3 libXi perl stefw cockpit steve clamav cone perl-Unix-Statgrab steved nfs-utils wireshark stevej opendkim opendmarc stevetraylen munge python-argcomplete stingray flow-tools libnfnetlink strobert mongodb sundaram pyroom python-flask-wtf suraia dput-ng svahl kdebase3 swilkerson nrpe tachoknight nethack tagoh kakasi kinput2 lv tc01 elog tdawson mongo-cxx-driver mongodb origin rubygem-mongo terjeros djview4 python-greenlet teuf libgovirt tflink python-flask-wtf thaller network-manager-applet than kcolorchooser kdbg kde-i18n kde-runtime kde-settings kde-workspace kdebase3 kdelibs kdelibs3 kdewebdev kf5-kcmutils kf5-kded kf5-ktexteditor libkomparediff2 oxygen-fonts qt qt3 qt5-qtbase qt5-qtdeclarative qt5- qtquickcontrols rp-pppoe soprano urw-fonts theinric libmongo-client thias gentoo linux_logo lmarbles thm python-gfm thofmann python-gencpp python-genlisp python-genpy python-pyswip thozza ppp unbound tieugene qtermwidget timn emacs-lua lua-sql tjikkun tkdnd tkrizek freeipa knot tmraz gnupg tojeline pcs tomspur python3 tonet666p synapse topdog dpkg torsava python3 tpokorra keepass tpopela evolution tremble Macaulay2 mhonarc perl-namespace-clean tross qpid-dispatch tstellar llvm ttomecek automake python-docker python-docker-py ttorling perl-Unix-Statgrab tuxbrewr conman etoys liferea twaugh cups-filters dmraid portreserve system-config-printer twoerner firewalld vakwetu pki-core valtri glite-jobid-api-cpp van tomcat vascom kchildlock vda conman mc vjancik opencv vmukhame createrepo rpm yum volter iksemel vondruch rubygem-mongo vpavlin mlocate vpodzime libblockdev oscap-anaconda-addon vponcova pykickstart vpv vdr vtrefny blivet-gui libblockdev vvitek rsync wcohen systemtap weli buildnumber-maven-plugin forge-parent whot libXi libwacom mtdev williamjmorenor exaile wolfy rkhunter wtaymans gstreamer gstreamer-plugins-base gstreamer1-vaapi pulseaudio wwoods lorax snake xavierb libclaw mhonarc yaneti liferea yangrr kexec-tools yselkowitz liferea yunyings tpm2-tss yyang maven-plugin-testing zachcarter schroot zaniyah gold zbyszek initscripts pacman python-pygraphviz zdohnal cups-filters net-tools system-config-printer zkabelac dmraid lvm2 zkota recode - -- - -Igor Gnatenko
On 02/09/2018 09:18 AM, Igor Gnatenko wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I've went and fixed 493 packages (listed below). If it broke something, please let me know. I checked diff briefly and don't think that I broke anything…
Did you ask FESCO? If not you, have abused your Fedora privileges, IMNSHO to play down a long unfixed *bug* in rpm.
zdohnal cups-filters net-tools system-config-printer
I checked system-config-printer and there are only '% ' and '%,' in changelog, which aren't rpm macros. Others are escaped in changelog, no need to fixing it.
-
Adam Williamson -
Björn Persson -
Daniel P. Berrangé -
David Cantrell -
David Malcolm -
David Sommerseth -
Igor Gnatenko -
J. Randall Owens -
John Florian -
Jonathan Wakely -
Josh Boyer -
Josh Boyer -
Kamil Dudka -
Kevin Kofler -
Matthew Miller -
Matěj Cepl -
Michal Novotny -
Michal Schorm -
Neal Gompa -
Nico Kadel-Garcia -
nicolas.mailhot＠laposte.net -
Panu Matilainen -
Pavel Raiskup -
Przemek Klosowski -
Ralf Corsepius -
Randy Barlow -
Rex Dieter -
Sérgio Basto -
Till Maas -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek -
Zdenek Dohnal