Escaping macros in %changelog

[Igor Gnatenko]

-----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
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp8dIIACgkQaVcUvRu8
> X0zOaA//WIbQAPp0ZjyWEEVAOl3d0EsG6y2Pk38B2K2ubFY8SYzJzpaZdAv3Lkdz
> wJDA0rSdLrfNGRKzuEIpciGX03tCRSGENg6XeUT4mGjFPIsN467F0sC9RHkH5nWM
> 2H1weD4K1MeukqcvEWU8vJjyB+Wqd8qtFKGgpypp+d5jMh1ZOCeJbul4raRzQjGu
> mvIVI1Qvg9x/3ZdNKk1GQdBslVRZqq/r+QLubkFjq04abAW1E3Dr5rFnRN+fWhQ7
> E56UcuWxuJk21JG6LxRjNeDCMvqwHMZ44So1MqxIxGTPVHlucustNTnJwVFSLMEm
> j7iPN4o9PxKew786Pm0/ggw6b49Y1w4ElzdFX6sfzQG4tAWu5Pa10paqUZyn/4IR
> RpqQhOyhXjqv1DxN5z+CGvgZNps/CtIXTE9HNG1Gs1bi3taX4tHOh8bpXVlj+ocw
> +03Q67LrgFVaqYaKfxW1jgfuvCRWUu3mdz16tx0W5ZuMkDgsq9H6ByYcVR8v/4Ly
> W+jL/H6kYzzviCu6k+hlOGccw9PKuhN9Iwg2wmQ100QiKIU58SKlb27YqlmRDVLz
> 12jl1R9qzLwR9A+yDbkQqxABPKNvOdY4RPOoqMKVGb0ZRuwMsVDLofVYpcnCBfIB
> wd8Rs9Kj36PxOO+HrHXKF05qRy2hOYiniS4XncmqPiFitd8GPQ4=
> =rcey
> -----END PGP SIGNATURE-----

[Sérgio Basto]

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


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


Cheers,
-- 
Sérgio M. B.

[Sérgio Basto]

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 . 


-- 
Sérgio M. B.

[Rex Dieter]

Igor Gnatenko wrote:

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

-- rex

[Matthew Miller]

On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>  It seems that a lot of people have %file, %check, %build,
> %whatsoever
>  in their changelog section.
>  Is there any reason I should not go and automatically escape them? 
This seems like a lot of churn. If we're going to do this, let's go big
and get rid of RPM changelogs. 

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

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

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

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

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

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





-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Przemek Klosowski]

On 02/08/2018 01:32 PM, Matthew Miller wrote:
>  This seems like a lot of churn. If we're going to do this,
> let's go big
>  and get rid of RPM changelogs.
>
>  When we have a package update, there are basically two different kinds
>  of changelog information. Well, three.
>  [...]
>  Third, though, there's end-user information. [..]*and*  it
>  often also covers things like "fixes CVE-####' also carried the
>  specfile changelog. 
This is very useful in my opinion. I know that it's not a
consistent 
policy driven technology, but rather a sort of a kindness extended by 
consciencious packagers, but it's a great way to correlate specific CVE 
issues to the update stream. Without it, there's no clear way to find 
out if the system is vulnerable or not---the software versions aren't 
necessarily sufficient because of backports, and require manual checking 
to find out when a fix is being included.

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

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

[Matěj Cepl]

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

Matej
-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl(a)ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
How fleeting are all human passions compared to the massive
continuity of ducks.
  -- Dorothy L. Sayers: Gaudy Night

[Zdenek Dohnal]

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

>  _______________________________________________ > devel mailing
> list -- devel(a)lists.fedoraproject.org > To unsubscribe 
send an email to
devel-leave(a)lists.fedoraproject.org
-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C

[Igor Gnatenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

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

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

In meanwhile, unescaped macros in %changelog create problems because they do
expand.
- -- 
- -Igor Gnatenko
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9SesACgkQaVcUvRu8
> X0wPGQ/9E6PRloCCF3q945AVt+saxen2PG+ehvRRjUTPK2tmmQQDf5NzaGsVowF3
> /RYwxNpCeiBUgy2mz0/3lfkRSGhvM6km5hT370LdTec0WE85Fd0MUWiYt8uPoL8q
> bUxDKpJl6H7gcEFslztP0Ou2W85RWUfGGOux03IZQdjssxDF+bCUX17VrHWaieFA
> o1u7Q/jFT6nYGA4F+hHOYF8eFzG7nT64ScJTXL/uJeHTiwT6pBWUm6yCKpl539tl
> 2+jozmKA/7GcuHopT7QaV51hlJ5nDy+mcAGhjRmYVxm5OIxAxICkegcKCL2FTbsm
> BKx70jrd4gb5ScsVUBGUTXgf9BUbUdXwMV2iCrLDiSyDSkOE9kooBifR4lLj7Asf
> /eldClCnOkcNeEzapfFvu6T3YDZaG6sVm64UcZ5UdfsJ+44HPE9MygCaicprnRdL
> HO8eSQwq7GDYL2i+XZWgXzon3w77u3DBMGYUxOz1tTTTBNiD/mr8EAqxC2gUsxfQ
> tCk8NjROmo0d0kqBGr7Fu1ltjVrB0rGx4CRlU/84O/Rt6G53ZWJ/s4+fa/QnhBCz
> FzVg/aOPc8+CZX6g+vXr5RJ5lo/oKErzT5hI29eev9oUOJulhA0zc04C9pa7X3tV
> 9tU6DRsjKLeth9u+ecyH+SOwwfMS8XGVZZ6b2hkFfMOAqqMTWps=
> =GWlO
> -----END PGP SIGNATURE-----

[Pavel Raiskup]

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

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

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

>  %check → %%check
>  %build → %%build
>  %whatsoever → %%whatsoever
>  
>  There might be valid use-cases, but I'm not sure if they really are:
>  %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
>  
>  Thoughts? 
E.g. server-side git hook refusing commits "adding typos" into changelog
would solve it once and forever.  If you were able to implement some
systematic change like this then I would excuse the walk across all the
spec files to fix old issues..

Pavel

>  --
>  -Igor Gnatenko
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[HEADS UP] Mass-macro-escape in %changelog (was: Escaping macros in %changelog)

[Igor Gnatenko]

-----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
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9WTgACgkQaVcUvRu8
> X0zsxA//XUfG2A+hbtNTCsgAXRkGpvKbfHZTucp4fq6ofwVih+2GcoxThiuXHHeW
> BNRadzLukWXH9+Cp1Urkrj1y9CjpacEP6zqspJ72De3ZL8jSfF9zoNsejpZAHZmG
> sQNbs8GTjgTBzXp+p5D9uInEJ+H2quEDzmFG3WyTPSrbbS2034GdyDtcYtkWPgeE
> JVcsxFhKsWQ8Pbh18S381ObOdn6JsWUN/Ov1pPDORg7GxLcC4gbycv7PyeZN+dsr
> VYRgQGFuokxbo2wRbGeg7RmUQwLTg/hqSmWC7EAFh5lPuOu5TKYB4KGlkzDNeDZO
> 3bdaMjsBmJfqgYP6QVoTL1U1PwJQb+E6oolVfOMBnFWnIQUxbyU1uk0xAINH2CfL
> u7y3CyCaCv/h+IdZEWfzTqnpNIvNNVjhP/p9+RGaAS6MT2+5LD9Mx/4tAv9ctIxP
> SPUFfoUF23oyfyCFl+JCWkdTeJsjtcMzaEB/JRIQKFiPsYo50ukvZ+7GcMwDwxMR
> dH14JRqnF2vU0WfpshUuABvdnMtiZbL0iycCNpsCQ2JBzYykAr9FqoVLlT1QROBy
> JPNRuAv7E/Fjkd84uBocz4fuSvJk0UgB3STvwKhn77o2MH0rHfCsAVXQJ0UGUnPV
> 6q1tjqgfC3aCTWtI9o54dc/RiSjeW2o4V3xQox+YwbhCjsiUtWQ=
> =1w8t
> -----END PGP SIGNATURE-----

[Kevin Kofler]

Matthew Miller wrote:
>  Second, there's package maintainer changelogs. These are really
>  redundant with the dist-git log. We don't really need this anymore.
>  It's just a chore. 
My %changelog entries are not identical to the dist-git commit messages:

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

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

   one-line summary

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

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

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

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

        Kevin Kofler

De: "Przemek Klosowski"

Hi,

>  Many environments (corporate, government) actually require keeping
> track 
>  of this stuff, so addressing it would help the acceptance of Fedora and 
>  Redhat in such environments 
Then have Koji or Bohdi insert accurate changelogs at build time. Can't be less
reliable than the current crap (though it was useful to drag rpm in UTF-8 land).

Regards,

-- 
Nicolas Mailhot

[Igor Gnatenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, 2018-02-09 at 08:57 +0100, Pavel Raiskup wrote:
>  On Thursday, February 8, 2018 5:02:10 PM CET Igor Gnatenko wrote:
>  > Hello everyone,
>  > 
>  > It seems that a lot of people have %file, %check, %build, %whatsoever in
>  > their
>  > changelog section.
>  > 
>  > Is there any reason I should not go and automatically escape them?
>  
>  There's IMO no good reason why you should.
>  
>  I wouldn't use proven packager rights if the package builds fine.  Fill a
>  pull request if anything. 
Then I have doubts that %changelog means anything because whoever uses rpm --
changelog would see unexpanded macro so if you had %autosetup -p1 in there,
users would see real commands instead... And also it might break in some cases
which requires maintainer intervention.

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

>  One could admit that fixing similar typos (white space issues,
> spelling
>  issues, changelog date issues, ...) is OK if you are touching the spec
>  file anyway because of some real problems, but even then you make the
>  patch less readable - and thus you raise chances that something get's
>  overlooked.  So I wouldn't do that.
>  
>  > %check → %%check
>  > %build → %%build
>  > %whatsoever → %%whatsoever
>  > 
>  > There might be valid use-cases, but I'm not sure if they really are:
>  > %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
>  > 
>  > Thoughts?
>  
>  E.g. server-side git hook refusing commits "adding typos" into changelog
>  would solve it once and forever.  If you were able to implement some
>  systematic change like this then I would excuse the walk across all the
>  spec files to fix old issues.. 
https://pagure.io/releng/issue/7300
- -- 
- -Igor Gnatenko
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9Wv0ACgkQaVcUvRu8
> X0wgEg/+K6D6X+LtU6WG9wO2uLl8vhx0KjxhHGMKJmp6Fwd6OZ1ZsIXd0su0veuA
> CuGRxu6nphmGPg5ElwR+J1jdz4hBK/Hwqju1XZNNCgg56vLrA8OPVFzLlKoBPfqF
> YDYfkh91AouECRdowwCeLfUS6pgOFZSlhdptrEusxSBcToL9HtwIf3AtOpUmIi+c
> mBZ4TBWmt+4ik12tLR4Up7+n5a/dichEOx3Loq7RFPEOfjvBhudU/MZpn1b0Kf/P
> vN8ocKoKbMvuHotHvBvp/j4BhsTIphvXr7Yg7DFItOTu18wfE+xr0DjWr3RZjxjF
> bUIUJX4V9SRZHBBHJ6e4lwmifHtOLTlW/wW0d7pQvDKduw5ek0D0Bm/y5I/FEHwa
> moY73GB7iQzIUMXOa12X1UyCnPvn3yw1WcBB/90QxovrAfAfYaPgKZmenVqwMapL
> B4PKPHnbH2VqkFheZgBifixCL0ENSj35K+xgowQTkWJ1/0ZCXT+U1ihQh951zYF3
> Jb7lSKJSVMvp96HgR8vYBQQL34sYM7/cL1/N0BMis3NFjPc0DYbMuVRp0pbuRs0/
> XT04F/lTvYBRUbW5wBgY5ss/+kiVVTZLmRaoJXBEbf1fh79d3il5O7oHugYhbCBn
> +U927O5rR38EdERBV7BofY1kmoQE9nrki4ZWX3PAyc1muUCvxZM=
> =greE
> -----END PGP SIGNATURE-----

[Pavel Raiskup]

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

>  because whoever uses rpm -- changelog would see unexpanded macro so
> if
>  you had %autosetup -p1 in there, users would see real commands
>  instead... And also it might break in some cases which requires
>  maintainer intervention. 
I only said why I wouldn't use _my_ provenpackager powers for innocent
issues.

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

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

Pavel

[HEADS UP] Mass-macro-escape in %changelog

[Ralf Corsepius]

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.

[HEADS UP] Mass-macro-escape in %changelog

[Zdenek Dohnal]

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

-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C

[Kamil Dudka]

On Friday, February 9, 2018 9:21:27 AM CET Kevin Kofler wrote:
>  Matthew Miller wrote:
>  
>  > Second, there's package maintainer changelogs. These are really
>  > redundant with the dist-git log. We don't really need this anymore.
>  > It's just a chore.
>  
>  
>  My %changelog entries are not identical to the dist-git commit messages:
>  
>  1. It often takes me several git commits to make a new EVR that builds. 
Would not it be then better to work on this in a staging branch and rework 
those commits before they are pushed to a production branch?  I am myself
not interested in going through commits like "fix a typo", "forgot to bump

release", "add missing BR", "revert the previous revert", etc.

Kamil

[Vít Ondruch]

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

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

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

Vít


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

[Josh Boyer]

On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; 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

[Panu Matilainen]

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

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

	- Panu -

[Neal Gompa]

On Fri, Feb 9, 2018 at 9:22 AM, Panu Matilainen <pmatilai(a)redhat.com&gt; 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.

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Igor Gnatenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

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


[0] https://github.com/ignatenkobrain/git-rpm-changelog
- -- 
- -Igor Gnatenko
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9y3sACgkQaVcUvRu8
> X0xDTxAAuJYSQFA8sIsFoLytUWyEca13z4dWFutsLA14T93/nRkH7/6sf92hqzDt
> 2ZEWDU3uS8GKe4Xi9t4Obcv9EAbC5ynx4Iu/fHUE83AEiySX8ihndeRyzKhW3zqB
> ic/FUjJ5R9sdPMbc4m8LeAasOKgux3KxE57bcfJ5f6KpofVGn1aDZ35sKegox+5G
> ZKlfTvutDRgiPjdrlFJEI83DVAqortpO7w4+Wip8JZqvd2EKuMwM34ZxW7S5KsSl
> 7v+QagenAGqc+hNVKfA9TPl1I8HCgppIphvJ+arS+rNiMJ1ACo4z2hvUx9jr8h7q
> e8r26QtcL3U3Ccz/hlzzsWMDYjd195EPjWT4TOU3+t19rsIyuHlqLZUE+H9HVlFk
> 6cQhsXgsSEDjqrlxyZxh8czzhB5M7emN6I5KhrovHlnq7fzzq/WXF4irNBePmbSk
> Tr7AlpGOhBbgrYexjK7xlMzguUvhE5kHHV8zU8pfNRT4F37jnwAezcKzbF7r4jkk
> jrL/TxrUEh4N/l/R2JowWeuj17XXsgurNY+JWmu0jPqZtu+78I1AsPnTFjK3Dhwb
> v+79osXQr2et9BKBr+APCnaGXaI/lNTfdPFLJVWAHBIvILjtPXbtSkxaDWnbmKxf
> yqyGJqUNX8pJEzu+ghDKHDW19WO8PLkM77lQaPV9bZkqQoigxFE=
> =5YnU
> -----END PGP SIGNATURE-----

[Jonathan Wakely]

On 09/02/18 08:34 -0500, Josh Boyer wrote:
> Someone else suggested changelogs could be inserted during koji build
> time.  That would be interesting to look into. 
If a koji build page just showed the Git commit logs since the last
build that could be far more useful than showing hundreds of lines of
the %changelog from the spec file. I could hit 'End' on my keyboard to
jump to the bottom of a koji page to see the changes.

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

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

[Jonathan Wakely]

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

[Michal Novotny]

Hello,

On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen <pmatilai(a)redhat.com&gt; wrote:

>  On 02/09/2018 03:34 PM, Josh Boyer wrote:
>
> > On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
> > wrote:
> >
> >> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
> >>
> >>> It seems that a lot of people have %file, %check, %build, %whatsoever
> >>> in their changelog section.
> >>> Is there any reason I should not go and automatically escape them?
> >>>
> >>
> >> This seems like a lot of churn. If we're going to do this, let's go big
> >> and get rid of RPM changelogs.
> >>
> >> When we have a package update, there are basically two different kinds
> >> of changelog information. Well, three.
> >>
> >> First, there's the upstream changelog. We don't generally do much with
> >> these except maybe package as %doc.
> >>
> >> Second, there's package maintainer changelogs. These are really
> >> redundant with the dist-git log. We don't really need this anymore.
> >> It's just a chore.
> >>
> >> Third, though, there's end-user information. Why should a user care
> >> *This* is redundant with bodhi update info, at least if packagers fill
> >> that out, and it often also duplicates upstream changelogs, *and* it
> >> often also covers things like "fixes CVE-####' also carried the
> >> specfile changelog.
> >>
> >> This is neither most helpful for user *nor* ideal for packages. Why
> >> don't we drop changelogs entirely in favor of 1) using the dist-git
> >> logs for specfile maintainers and 2) providing the end-user information
> >> in a different way. This could be through specially formatted log lines
> >> going with the commit, or it could be simply in a standard separate
> >> file (`fedora.user-visible-changes`). Optionally, it could include both
> >> a high level end-user summary, and a detailed description for sysadmins
> >> and the curious.
> >>
> >> Wherever it lives, this would be read by Bodhi, so there's
> >> would be need to enter it more than once. And, perhaps a DNF plugin
> >> could be made to read and display this information for systems
> >> administrators.
> >>
> >
> > I fully support the removal of RPM changelogs.  However, you've missed
> > two cases:
> >
> > 1) Rawhide, which doesn't go through bodhi
> > 2) Fedora release upgrades, which don't go through bodhi
> >
> > Now, I would actually LOVE for Rawhide to go through bodhi but
> > whatever.  The release -> release upgrade isn't really solvable that
> > way though.
> >
> > Someone else suggested changelogs could be inserted during koji build
> > time.  That would be interesting to look into.
> >
>
>  Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
>  rocket science we're talking about here if people are ready to give it a go.
>  
I actually looked yesterday if I could make a PR for rpm implementing it
but I couldn't really find a good way to do it. So I decided to implement it
in `rpkg-client` (https://pagure.io/rpkg-client/branch/spec_preprocessor -
basically a hack upon python-rpkg library) by spec preprocessing. So,
with that development version of rpkg, you can have specs (or rather spec
templates) like this in your Git project:

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

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

Source: {{{ make_source }}}

%description
This is a test package.

%prep
{{{ setup }}}

{{{ git_change_log }}}

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

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

Thank you
clime


>  Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
>  already? Do you know what kind of hook they're using? Actually I think Suse
>  does this too so Fedora is probably again the last one to adopt this...
>
>          - Panu -
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Kevin Kofler]

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

        Kevin Kofler

[Kevin Kofler]

Neal Gompa wrote:
>  Mageia, OpenMandriva, and PLD all generate their changelogs from the
>  source control system. 
[snip]
>  SUSE uses the Open Build Service VCS export to changes files which
> are
>  converted into changelog entries at package build time. 
All these distros have in common that their changelogs are A LOT less 
readable than ours.

>  But yeah, Fedora is once again a laggard. This seems to be a
> recurring
>  trend, and one I'm not particularly pleased about. 
Autogenerating RPM changelogs from the SCM has been proposed over and over 
again multiple times. It was always shot down because it just doesn't work. 
Not adopting some particular bad idea does not make us laggards. Can we 
please stop beating this dead horse again and again?

        Kevin Kofler

[David Sommerseth]

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

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

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


Just my 2 cents.


-- 
kind regards,

David Sommerseth

[Kevin Kofler]

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

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

        Kevin Kofler

[David Sommerseth]

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

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

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

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

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

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

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


[1] <https://research.redhat.com/powerlinux-openpower-development-hosting/>

-- 
kind regards,

David Sommerseth

[Kevin Kofler]

David Sommerseth wrote:
>  I doubt Koji was primarily built for "does this
> work?"-builds.  It exists
>  to build proper packages targeting Fedora repositories. 
But that is the point, to build a proper package:

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

and the output is a working package.

>  To me this is backwards and is lacking some logic.  If you push
> things
>  which does not build properly, you also waste a build. 
That is a build attempt that would have had to happen anyway. Otherwise, how 
do I know that it doesn't build.

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

        Kevin Kofler

[Michal Novotny]

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

On Sat, Feb 10, 2018 at 12:54 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[David Sommerseth]

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

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

> > To me this is backwards and is lacking some logic.  If you push
> things
> > which does not build properly, you also waste a build.
>  
>  That is a build attempt that would have had to happen anyway. Otherwise, how 
>  do I know that it doesn't build.
>  
>  The point is, the above optimized loop needs n build attempts. What you 
>  propose doing needs n+1 build attempts to get the exact same package. 
True.  But my n+1 approach also wouldn't add litter to the git commit history
with noise.  I use the same approach when doing development too;  I always try
to avoid committing anything which hasn't been tested first, as I simply find
it nasty to have commits not building (which again makes bisecting harder) ...
But I'll agree that development and package maintenance are not the same thing
- even though they carry similarities


-- 
kind regards,

David Sommerseth

[Matthew Miller]

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


>  * No easy way to map changelogs with versions and releases in
>  package. Imagine that you pushed commit with update, then realised
>  that it doesn't build and reverted. What should be in changelog? 
I think we *need* separate changelog streams -- the packager one (with
all the messiness) and a user-focused one. This could either be a
separate file or some kind of standard we agree on for special lines in
the git changelog. (In that case, we could have a tool to extract those
lines, and it could understand to remove user messages found in
reverted commits.)

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


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Fri, Feb 09, 2018 at 08:34:02AM -0500, Josh Boyer wrote:
>  > Wherever it lives, this would be read by Bodhi, so there's
>  > would be need to enter it more than once. And, perhaps a DNF plugin
>  > could be made to read and display this information for systems
>  > administrators.
>  
>  I fully support the removal of RPM changelogs.  However, you've missed
>  two cases:
>  
>  1) Rawhide, which doesn't go through bodhi
>  2) Fedora release upgrades, which don't go through bodhi 
I'm actually suggesting something different: write the user-focused
changelog in one place when updating the package, and have bodhi read
that and use it for its description (making the bodhi step less work).


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[David Cantrell]

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

>  1) Rawhide, which doesn't go through bodhi
>  2) Fedora release upgrades, which don't go through bodhi
>  
>  Now, I would actually LOVE for Rawhide to go through bodhi but
>  whatever.  The release -> release upgrade isn't really solvable that
>  way though.
>  
>  Someone else suggested changelogs could be inserted during koji build
>  time.  That would be interesting to look into. 
The dist-git changelogs are mostly noise and I would prefer better
organized information about impacts to users and developers.  Like tell
me what things changed in the new glibc package, not that the glibc RPM
has been upgraded to the new release.  I can figure out that part myself.

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

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

    %changes NEWS

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

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

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Michal Schorm]

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

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

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

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

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

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

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


--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

[J. Randall Owens]

On 13/02/18 01:00, Michal Schorm wrote:
>  5)
>  The changelogs are long ass hell.
>  What about keeping just 2 latest releases in it and deleting the rest?
>  (It will be still kept in GIT history)
>  2 releases could be 2-20 entries, depends of work done.
>  But still it looks short enough for me. 
When you say 2 releases, are you talking about package or Fedora
releases? I'd favour an approach of keeping all the changes since
release, or since branching might be even better, or since the release
before the package's release, myself. 2 package releases seems a bit curt.

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

[Michal Schorm]

On Tue, Feb 13, 2018 at 3:03 AM, J. Randall Owens <
jrowens.fedora(a)ghiapet.net&gt; 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

[Pavel Raiskup]

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

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

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

Pavel

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

[Till Maas]

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

>  I personally find it abusing shared resources throwing builds at it
> which has
>  not been tested first.  So I prefer to do local mockbuilds first, simply to
>  lessen the load on shared resources.  I'm not saying I haven't tossed failing
>  builds at koji, that has happened too.  But I generally try to avoid that as
>  much as I can. 
koji has enough ressources to allow for test builds. You can actually to
test-only builds (so-called stretch builds). IMHO the scarcer resource
is maintainer time, therefore I am all for using as much shared
resources as possible if it frees time for maintainers. See also:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintai...

Kind regards
Till

[Randy Barlow]

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

[Neal Gompa]

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

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

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Daniel P. Berrangé]

On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
>  On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
>  <bowlofeggs(a)fedoraproject.org&gt; wrote:
>  > On 02/12/2018 08:00 PM, Michal Schorm wrote:
>  >> The changelogs are long ass hell.
>  >> What about keeping just 2 latest releases in it and deleting the rest?
>  >> (It will be still kept in GIT history)
>  >> 2 releases could be 2-
>  >
>  > I usually trim my changelogs to the last year of entries. It's kinda
>  > arbitrary, but it does keep it from getting too insane and it's easy.
>  >
>  >
>  
>  What I don't get is why we don't just set RPM to trim the changelog
>  automatically for the binary RPMs.
>  
>  Mageia does this to keep the payload sizes sane:
>  http://gitweb.mageia.org/software/rpm/rpm-setup/tree/macros.in#n22 
That's good, but it is still worth trimming the actual changelogs too.
It is pointless accumulating 10 years worth of %changelog in the .spec
file in dist-git. Every time we branch rawhide, we should have something
that culls all changelogs from the specs in 'master' that are older
than 1 year.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Adam Williamson]

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

[Matthew Miller]

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



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Josh Boyer]

On Tue, Feb 13, 2018 at 3:24 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; 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

[David Malcolm]

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

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

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

It's not an obfuscated code competition.

Hope this is constructive
Dave

Hi,

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

Regards,

-- 
Nicolas Mailhot

[John Florian]

On Tue, 2018-02-13 at 15:33 -0500, Josh Boyer wrote:
>  
>  The point is, we have LOTS of places where change information or
>  discussion occurs.  We should try and have a canonical location for
>  the *descriptive summary* of these changes/discussions. 
This hit home.  Way back in the early 90s when I was new to Linux this
was one of the more frustrating things for me.  Mastering RHL (later
Fedora) was an exercise in knowing *where* to look and you can't even
know to look there until you become aware that there's yet one more
source.

[John Florian]

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

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

Beyond that, I really don't care how we get there.  But IMHO, that
should be the goal.

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

[Matthew Miller]

On Wed, Feb 14, 2018 at 10:00:18AM +0100, nicolas.mailhot(a)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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

Release notes vs. Changelogs

[Björn Persson]

Matthew Miller wrote:
>  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 
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

[Sérgio Basto]

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

    fedpkg ci -c 


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

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

[Michal Novotny]

Hello,

On Fri, Feb 9, 2018 at 10:57 PM, Michal Novotny <clime(a)redhat.com&gt; wrote:

>  Hello,
>
>  On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen <pmatilai(a)redhat.com&gt;
>  wrote:
>
> > On 02/09/2018 03:34 PM, Josh Boyer wrote:
> >
> >> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
> >> wrote:
> >>
> >>> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
> >>>
> >>>> It seems that a lot of people have %file, %check, %build, %whatsoever
> >>>> in their changelog section.
> >>>> Is there any reason I should not go and automatically escape them?
> >>>>
> >>>
> >>> This seems like a lot of churn. If we're going to do this, let's go
> big
> >>> and get rid of RPM changelogs.
> >>>
> >>> When we have a package update, there are basically two different kinds
> >>> of changelog information. Well, three.
> >>>
> >>> First, there's the upstream changelog. We don't generally do much
> with
> >>> these except maybe package as %doc.
> >>>
> >>> Second, there's package maintainer changelogs. These are really
> >>> redundant with the dist-git log. We don't really need this anymore.
> >>> It's just a chore.
> >>>
> >>> Third, though, there's end-user information. Why should a user care
> >>> *This* is redundant with bodhi update info, at least if packagers fill
> >>> that out, and it often also duplicates upstream changelogs, *and* it
> >>> often also covers things like "fixes CVE-####' also carried the
> >>> specfile changelog.
> >>>
> >>> This is neither most helpful for user *nor* ideal for packages. Why
> >>> don't we drop changelogs entirely in favor of 1) using the dist-git
> >>> logs for specfile maintainers and 2) providing the end-user information
> >>> in a different way. This could be through specially formatted log lines
> >>> going with the commit, or it could be simply in a standard separate
> >>> file (`fedora.user-visible-changes`). Optionally, it could include both
> >>> a high level end-user summary, and a detailed description for sysadmins
> >>> and the curious.
> >>>
> >>> Wherever it lives, this would be read by Bodhi, so there's
> >>> would be need to enter it more than once. And, perhaps a DNF plugin
> >>> could be made to read and display this information for systems
> >>> administrators.
> >>>
> >>
> >> I fully support the removal of RPM changelogs.  However, you've missed
> >> two cases:
> >>
> >> 1) Rawhide, which doesn't go through bodhi
> >> 2) Fedora release upgrades, which don't go through bodhi
> >>
> >> Now, I would actually LOVE for Rawhide to go through bodhi but
> >> whatever.  The release -> release upgrade isn't really solvable that
> >> way though.
> >>
> >> Someone else suggested changelogs could be inserted during koji build
> >> time.  That would be interesting to look into.
> >>
> >
> > Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
> > rocket science we're talking about here if people are ready to give it a go.
> >
>
>  I actually looked yesterday if I could make a PR for rpm implementing it
>  but I couldn't really find a good way to do it. So I decided to implement it
>  in `rpkg-client` (https://pagure.io/rpkg-client/branch/spec_preprocessor
>  - basically a hack upon python-rpkg library) by spec preprocessing. So,
>  with that development version of rpkg, you can have specs (or rather spec
>  templates) like this in your Git project:
>
>  Name:       {{{ git_name }}}
>  Version:    {{{ git_version }}}
>  Release:    1%{?dist}
>  Summary:    This is a test package.
>
>  License:    GPLv2+
>  URL:        https://someurl.org
>
>  Source: {{{ make_source }}}
>
>  %description
>  This is a test package.
>
>  %prep
>  {{{ setup }}}
>
>  {{{ git_change_log }}}
>
>  rpkg will take that spec template and replace the {{{ ... }}} tags with
>  standard output of the commands inside the braces (git_name, git_version,
>  make_source, setup, git_change_log are all shell functions). Afterwards,
>  the generated spec is used to e.g. create an srpm (done by `rpkg srpm`
>  command).
>  
I have implemented the idea here: https://pagure.io/rpkg-util/pull-request/7.
It is now under review. Please, join. Starting docs are here:
https://docs.pagure.org/rpkg-util/tutorials.html#spec-templates-from-scratch


>  I haven't actually implemented the `git_change_log` function yet (nor the
>  other functions except for `make_source`) like Igor did - currently it just
>  always returns '%changelog' and that's it but I wanted to show this to
>  possibly get some feedback.
>
>  Thank you
>  clime
>
>
> >
> > Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
> > already? Do you know what kind of hook they're using? Actually I think Suse
> > does this too so Fedora is probably again the last one to adopt this...
> >
> >         - Panu -
> >
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> >
>
>

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
>  On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
>  <bowlofeggs(a)fedoraproject.org&gt; 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

[Neal Gompa]

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



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Zbigniew Jędrzejewski-Szmek]

On Sun, Mar 11, 2018 at 10:04:25AM -0400, Neal Gompa wrote:
>  On Sun, Mar 11, 2018 at 10:01 AM, Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; 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(a)fedoraproject.org&gt; 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

[Nico Kadel-Garcia]

On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; 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(a)in.waw.pl&gt; 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?

[Nico Kadel-Garcia]

On Sun, Mar 11, 2018 at 2:21 PM, Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:
>  On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; 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(a)in.waw.pl&gt; 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?

[Zbigniew Jędrzejewski-Szmek]

On Sun, Mar 11, 2018 at 02:22:49PM -0400, Nico Kadel-Garcia wrote:
>  On Sun, Mar 11, 2018 at 2:21 PM, Nico Kadel-Garcia
> <nkadel(a)gmail.com&gt; wrote:
>  > On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek
>  > <zbyszek(a)in.waw.pl&gt; 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(a)in.waw.pl&gt; 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

[Nico Kadel-Garcia]

On Sun, Mar 11, 2018 at 3:58 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; 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(a)gmail.com&gt; wrote:
> > > On Sun, Mar 11, 2018 at 10:25 AM, Zbigniew Jędrzejewski-Szmek
> > > <zbyszek(a)in.waw.pl&gt; 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(a)in.waw.pl&gt; 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.