Packages which use the BuildRoot: directive

The Packaging Guidelines indicate that BuildRoot: should not be used in
Fedora specfiles.

The BuildRoot: tag has not been required since RHEL6 and was also not
required in EPEL5 (due to some magic in epel-rpm-macros). It has not
been needed in any Fedora release since at least Fedora 12.

It has already been removed from most packages due to previous efforts
but it lingers in a few (91, to be exact). Additionally, a few packages
(24) employ an odd construct like the following:

%{?el5:BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)}

which was always unnecessary and now is completely pointless because we
can't build for el5 in any case. And one does this odd bit:

%{?!buildroot:BuildRoot: %_tmppath/buildroot-%name-%version-%release}

Which is also pointless in Fedora (and is using an unsafe value which
was never allowed in Fedora or EPEL). I found all of these with a
simple grep for '^(%{?.*)?BuildRoot:' but I did add a find-buildroot
script to <a href="" title=""></a>

The usual lists are below. Feel free to fix your packages if you like;
there should be no need to rebuild. I will wait a few days and then fix
up the instances which remain.

Maintainers by package:
NLopt besser82
binutils aoliva jakub jankratochvil law nickc
carbon-c-relay piotrp
clamsmtp gnat
cmconvert pcfe
cmockery2 lpabon
cocot ueno
cracklib nalin tmraz
crash crash
cross-binutils dhowells lkundrak sharkcz
ctags than
cyrus-sasl jjelen plautrba
dbh fabiand limb
dev86 jnovy lkundrak
dfish jkaluza
dmlite adev andreamanzi gbitzes okeeble rocha
dmlite-plugins-s3 adev andreamanzi okeeble rocha
dpm-dsi andreamanzi ellert okeeble rocha simonm
dreamweb besser82
dspam gnat
dtach lon
edg-mkgridmap andreamanzi gbitzes
eject orphan
exim dwmw2 jskarvad tremble
exim-doc dwmw2 tremble
fgrun bellet
fido besser82 cdamian rfenkhuber
fprobe-ulog stingray
freecolor dfateyev
freetiger besser82
fuseiso orphan
gdb jankratochvil sergiodj
gdesklets-goodweather orphan
genchemlab limb
glibc64 codonell jakub
gmic berrange cheese
gofer jortel
gt5 szpak
inetvis orphan
inn ovasik rathann s4504kr
iperf somlo strobert
ipmiutil arcress
irssi-xmpp lbazan maha
isomaster limb szpak
jcommon-serializer caolanm
jfsutils fcami itamarjp
jnettop wolfy
lcgdm-dav adev andreamanzi gbitzes okeeble rocha
libasr dfateyev
libjoedog besser82 cdamian rfenkhuber
liblayout caolanm
liblinear besser82
libmatchbox cwickert dwalsh
libwhirlpool dfateyev
litmus aalvarez jorton rocha
lpairs szpak
matchbox-window-manager cwickert dwalsh
mhash limb spot
mingw-qwt rjones sailer
mrxvt mtasaka
msr-tools gbailey
mtools dkaspar
nagios-plugins-fts andreamanzi simonm
nagios-plugins-lcgdm adev andreamanzi gbitzes rocha
nxtrc dwrobel
orage kevin nonamedotc
pan adalloz pmkovar
pards orphan
parted bcl
passwd fkluknav jkucera mitr tmraz
patch twaugh
pentaho-reporting-flow-engine caolanm
perl-Array-Unique dfateyev
perl-Encode-Detect ralston
perl-File-Tempdir dfateyev
perl-Sys-Virt berrange jplesnik steve
perl-Tie-Cache dfateyev
perl-Time-ParseDate dfateyev ppisar xavierb
perl-enum dfateyev
publican-fedora immanetize rlandmann zoglesby
publican-genome orphan
publican-jboss rlandmann
pymssql swilkerson
python-sphinx-theme-flask besser82
python-sphinxcontrib-cheeseshop besser82
python3-dns aviso
radial mkasik
rear gdha
rubygem-narray besser82
rubygem-rspec-longrun besser82
salt dmurphy18 herlo terminalmage
sendmail jskarvad olysonek
shadow-utils pvrabec tmraz
shogun-data besser82 lupinix
singularity bbockelm dwd loveshack
spamprobe strobert
squid hno jsteffan luhliarik pavlix thozza
srcpd dfateyev
strace ldv vda
subscription-manager awood bkearney csnyder
sudo jvymazal kzak mattdm mildew rsroka tosykora
syslinux pjones
system-switch-displaymanager than
tcl-mysqltcl renep
textcat besser82
tgif mtasaka tremble
tkgate tnorth
ucx andreyma
udpcast lzap rjones
vxl ignatenkobrain mrceresa
webattery orphan
words kzak
wsdlpull denisarnaud
xfwm4-themes kevin nonamedotc
xrdhttpvoms andreamanzi okeeble
xscreensaver dchen lkundrak mtasaka

Packages by maintainer:
aalvarez litmus
adalloz pan
adev dmlite dmlite-plugins-s3 lcgdm-dav nagios-plugins-lcgdm
andreamanzi dmlite dmlite-plugins-s3 dpm-dsi edg-mkgridmap lcgdm-dav nagios-plugins-fts nagios-plugins-lcgdm xrdhttpvoms
andreyma ucx
aoliva binutils
arcress ipmiutil
aviso python3-dns
awood subscription-manager
bbockelm singularity
bcl parted
bellet fgrun
berrange gmic perl-Sys-Virt
besser82 NLopt dreamweb fido freetiger libjoedog liblinear python-sphinx-theme-flask python-sphinxcontrib-cheeseshop rubygem-narray rubygem-rspec-longrun shogun-data textcat
bkearney subscription-manager
caolanm jcommon-serializer liblayout pentaho-reporting-flow-engine
cdamian fido libjoedog
cheese gmic
codonell glibc64
crash crash
csnyder subscription-manager
cwickert libmatchbox matchbox-window-manager
dchen xscreensaver
denisarnaud wsdlpull
dfateyev freecolor libasr libwhirlpool perl-Array-Unique perl-File-Tempdir perl-Tie-Cache perl-Time-ParseDate perl-enum srcpd
dhowells cross-binutils
dkaspar mtools
dmurphy18 salt
dwalsh libmatchbox matchbox-window-manager
dwd singularity
dwmw2 exim exim-doc
dwrobel nxtrc
ellert dpm-dsi
fabiand dbh
fcami jfsutils
fkluknav passwd
gbailey msr-tools
gbitzes dmlite edg-mkgridmap lcgdm-dav nagios-plugins-lcgdm
gdha rear
gnat clamsmtp dspam
herlo salt
hno squid
ignatenkobrain vxl
immanetize publican-fedora
itamarjp jfsutils
jakub binutils glibc64
jankratochvil binutils gdb
jjelen cyrus-sasl
jkaluza dfish
jkucera passwd
jnovy dev86
jortel gofer
jorton litmus
jplesnik perl-Sys-Virt
jskarvad exim sendmail
jsteffan squid
jvymazal sudo
kevin orage xfwm4-themes
kzak sudo words
law binutils
lbazan irssi-xmpp
ldv strace
limb dbh genchemlab isomaster mhash
lkundrak cross-binutils dev86 xscreensaver
lon dtach
loveshack singularity
lpabon cmockery2
luhliarik squid
lupinix shogun-data
lzap udpcast
maha irssi-xmpp
mattdm sudo
mildew sudo
mitr passwd
mkasik radial
mrceresa vxl
mtasaka mrxvt tgif xscreensaver
nalin cracklib
nickc binutils
nonamedotc orage xfwm4-themes
okeeble dmlite dmlite-plugins-s3 dpm-dsi lcgdm-dav xrdhttpvoms
olysonek sendmail
orphan eject fuseiso gdesklets-goodweather inetvis pards publican-genome webattery
ovasik inn
pavlix squid
pcfe cmconvert
piotrp carbon-c-relay
pjones syslinux
plautrba cyrus-sasl
pmkovar pan
ppisar perl-Time-ParseDate
pvrabec shadow-utils
ralston perl-Encode-Detect
rathann inn
renep tcl-mysqltcl
rfenkhuber fido libjoedog
rjones mingw-qwt udpcast
rlandmann publican-fedora publican-jboss
rocha dmlite dmlite-plugins-s3 dpm-dsi lcgdm-dav litmus nagios-plugins-lcgdm
rsroka sudo
s4504kr inn
sailer mingw-qwt
sergiodj gdb
sharkcz cross-binutils
simonm dpm-dsi nagios-plugins-fts
somlo iperf
spot mhash
steve perl-Sys-Virt
stingray fprobe-ulog
strobert iperf spamprobe
swilkerson pymssql
szpak gt5 isomaster lpairs
terminalmage salt
than ctags system-switch-displaymanager
thozza squid
tmraz cracklib passwd shadow-utils
tnorth tkgate
tosykora sudo
tremble exim exim-doc tgif
twaugh patch
ueno cocot
vda strace
wolfy jnettop
xavierb perl-Time-ParseDate
zoglesby publican-fedora


Re: Packages which use the BuildRoot: directive

By Jason L Tibbitts III at 07/10/2018 - 20:27

Unfortunately it seems that many of these packages have had the
BuildRoot tags _added back in_ after previously having them removed. A
number of the commits even delete existing changelog entries, a sure
sign that someone is just copying the specfile from some outside source.

As a reminder, the Fedora's git repository is the canonical location for
Fedora's spec files. Simply overwriting what is in git with a file
copied from some external source is not permitted by the Fedora
packaging guidelines:
<a href="" title=""></a>

- J<

Re: Packages which use the BuildRoot: directive

By Josh Boyer at 07/11/2018 - 09:56

On Tue, Jul 10, 2018 at 8:27 PM Jason L Tibbitts III < ... at math dot> wrote:
That's impossible to enforce and unrealistic. We can say that as much
as we'd like, but there is nothing we can do to prevent people from
syncing from elsewhere. Having it in the guidelines seems to give a
false sense of security.


Re: Packages which use the BuildRoot: directive

By Jason L Tibbitts III at 07/11/2018 - 10:40

JB> That's impossible to enforce and unrealistic.

I will go as far as "it's somewhat difficult to enforce and idealistic",
but no further.

JB> We can say that as much as we'd like, but there is nothing we can do
JB> to prevent people from syncing from elsewhere.

There are lots of things we can't completely prevent, but that doesn't
mean we shouldn't have rules against them.

JB> Having it in the guidelines seems to give a false sense of security.

I don't understand how a guideline would ever give any "sense of
security". What would you expect a guideline to secure against?
They say what you are and aren't supposed to do, and not much more.

It's not much different than a code of conduct. If there's anything
that's "impossible to enforce and unrealistic", it's that. But we
certainly shouldn't get rid of a "be nice to each other" rule just
because such a rule would give someone a false sense of security that
they can post to a mailing list without getting nasty emails (as recent
threads on the subject of specfile cleanups have shown).

And certainly we can work to enforce this particular rule. It's not
hard to watch for commits which delete, say, the mass rebuild changelog
entries or reintroduce one of these recently removed tags and then alert
someone when necessary. That work is already in progress. It's would
technically be even easier to do that check in a git hook and simply
refuse to accept the push, if we really wanted to go that far.

- J<

Re: Packages which use the BuildRoot: directive

By Josh Boyer at 07/11/2018 - 10:52

On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III < ... at math dot> wrote:
OK. I'll go further and say it's actively antagonistic to people that
want to maintain spec files in a common location across a variety of
distributions. It seems more reasonable to have a guideline that
requires people to put a comment in the spec file if it is maintained
outside of Fedora and point to the proper location to file issues
against. That doesn't prevent people in the Fedora project from
making changes in dist-git and it'd certainly be way more helpful in
the long run to get the issue corrected upstream so we don't keep
having the same import issues over and over.

Yet people are surprised when they aren't followed, which is what I
meant by a false sense of security. "The guidelines say this so it
must be true!", yet the guideline is unrealistic.

Heh, that's fair. I think the analogy conflates two very different
things though. CoC is for human behavior norms, which are wide and
varied. Packaging guidelines tend to be more concrete, focused around
technology and less open to interpretation. They say "guidelines" but
if they aren't followed people treat them as rules and require
exceptions and exclusions.

I know you said this for argumentation's sake, but you're just proving
my two points above. All of that makes participating in Fedora
harder, for little benefit outside of sticking to a guideline that
doesn't make sense. You and I are going to likely disagree on this
point, and that's OK.

And I think the mass rebuild changelogs are unnecessary and convey no
valuable information, so *shrug*.


Re: Packages which use the BuildRoot: directive

By Igor Gnatenko at 07/11/2018 - 11:57

On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer < ... at fedoraproject dot org>

I will disagree with this (and I also think there was an FPC ticket about
Do you expect automated tooling to go to upstream and file PRs? People can
maintain their specs wherever they want, but they should be prepared that
Fedora will change their specs and they should not overwrite such changes.

It's not only changelogs, people keep re-adding BuildRoot and %clean
People keep overriding changes we've done in Fedora when they import from

Fedora dist-git is canonical location for spec files. They are supposed to
in Fedora buildsystem and work there. No one is going to understand whole
spec file just to make some fix in Fedora. Fullstop here.

Re: Packages which use the BuildRoot: directive

By Josh Boyer at 07/11/2018 - 12:16

On Wed, Jul 11, 2018 at 11:58 AM Igor Gnatenko
< ... at fedoraproject dot org> wrote:
I'd expect automated tooling to skip such packages based on a keyword
or control file in dist-git.

I said that as well. What you're missing is the part where people
tell the actual maintainers something changed.

Because nobody is communicating with upstream and fixing it there. In
some cases it'll be met with a shrug (like changelogs). In many, it
might actually result in upstream making a similar fix.

This is a human problem that the existing tools and guidelines aren't
going to solve. So we can either adjust the tools and guidelines to
actually be helpful to humans, or we can continue to stare at our
navels and pretend having these things written down is going to fix
the issues you're highlighting. I'd rather have a compromise that
works on collaboration. In reality, I expect nothing to change here
and we'll have this conversation again down the road.


Re: Packages which use the BuildRoot: directive

By Simo Sorce at 07/12/2018 - 07:11

On Wed, 2018-07-11 at 12:16 -0400, Josh Boyer wrote:
Isn't tooling in our dist-git commit hooks or push hooks that simply
reject commits that remove changelogs or re-add unwanted sections the
way to go here ?

But tools can solve, for example they can lint spec files in git hooks
and reject pushes that break lint.

Well said.


Re: Packages which use the BuildRoot: directive

By Kevin Kofler at 07/12/2018 - 07:26

Simo Sorce wrote:
Removing changelog entries is necessary to bring diverged branches back into
sync. I always destroy the branch changelog in favor of the Rawhide one if I
sync a new version from Rawhide to the branch. (Then I merge both ways, so
that the branches become fast-forwardable again.)

Kevin Kofler

Re: Packages which use the BuildRoot: directive

By Ben Rosser at 07/11/2018 - 13:39

On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer < ... at fedoraproject dot org> wrote:
What is "upstream", though? Some repository the packager uses to hold
the spec files? The actual upstream project that's being packaged?
Some other distribution's package repository? Presumably the people
doing automated cleanups would need to know this information, somehow.

And if an automated cleanup involves hundreds or thousands of
packages, is it realistic to have the person doing that cleanup look
up and contact various different upstreams manually for all of these?
Doesn't this make it harder, not easier, to do automated package

We have been telling people for a while now that they don't "own"
their packages. Making it easier for people to maintain their packages
outside of dist-git and (effectively) ignore changes from
proven-packagers seems to take us in the opposite direction.

If this is really something that's necessary, maybe it would be good
to require someone's approval (FESCo? FPC?) to maintain a package
outside of Fedora dist-git. Then at least the number of such packages
could be hopefully kept low.

Ben Rosser

Re: Packages which use the BuildRoot: directive

By Ken Dreyer at 07/12/2018 - 13:24

On Wed, Jul 11, 2018 at 11:39 AM, Ben Rosser <rosser. ... at gmail dot com> wrote:
I don't think I agree with the messaging that people don't "own" their
packages. I get the point that people should be open to other
contributors changing things, like the original context of this
thread. On the other hand, people don't take pride in work if they
don't "own" it :) We want to bring more contributors into Fedora, and
there's an element of pride in becoming a package maintainer that's a
good community incentive.

- Ken

Re: Packages which use the BuildRoot: directive

By Kevin Fenzi at 07/13/2018 - 17:53

On 07/12/2018 10:24 AM, Ken Dreyer wrote:
Well, I think people can still take pride in being good points of
contact or caretakers of the package for the Fedora community (and they
should, without packagers we would be no where!).

To my mind at least "own" implies a ability to do whatever you want with
your "property" and be upset/mad/disgruntled when someone else does
something with it, where 'caretaker' or 'point of contact' makes it more
clear that you are just trying to keep this package working and happy
for the others and when someone changes it you should be happy for the

All that said, people who maintain their specs elsewhere are doing so,
and we have no good way of forbidding it, so we should probably stop
pretending we do.


Re: Packages which use the BuildRoot: directive

By Josh Boyer at 07/11/2018 - 15:42

On Wed, Jul 11, 2018 at 1:40 PM Ben Rosser <rosser. ... at gmail dot com> wrote:
No, I said automated cleanups should skip such packages. If people
doing them were really interested, they could lookup the info in the
file or file a bug, or have their script file a bug because the
package was skipped.


I disagree. "Ownership" within Fedora is one aspect we've tried to
address, but we're pretending that Fedora "owns" the code base which
is a falsity. There are many more people involved and in this
specific kind of situation, pretending there aren't is just odd.

That's a thing that could be done, but I'm skeptical it will help much
without the other things.


Re: Packages which use the BuildRoot: directive

By Ben Rosser at 07/11/2018 - 16:33

On Wed, Jul 11, 2018 at 3:42 PM, Josh Boyer < ... at fedoraproject dot org> wrote:
Only if you consider packaging metadata to be part of "the code base".
I guess that's the crux of the issue, some people want to treat it
this way and others don't.

Fedora's attitude, at least officially, has hitherto been that
"packaging metadata" is managed downstream by packagers as a group. I
struggle to see why "upstream author considers the package spec part
of their upstream project and does not want other Fedora packagers to
touch it without going through upstream" is all that different from
"downstream packager considers spec they wrote to be their private
project and does not want other Fedora packagers to touch it without
going through them".

That being said, you are right that people are ignoring the existing
guidelines, and so maybe something should be changed.

Sure, this would be in addition to having some metadata on the package
to indicate external management. I am just suggesting that we
shouldn't let packagers do this themselves; some external body or
person should need to sign off on it first.

And as Matthew said, perhaps a requirement for approving this
arrangement could be that the packager in question agrees to respect
changes in dist-git (or automatically opened Pagure pull requests, or
whatever) made by other people?

Ben Rosser

Re: Packages which use the BuildRoot: directive

By Kevin Kofler at 07/11/2018 - 17:50

Ben Rosser wrote:
Packaging metadata has no business being part of the upstream code. Even for
code bases where I am both the upstream developer and the downstream
packager, experience has taught me to keep them separate.

The main issue with including the specfile in the upstream repository is
release timing: The right time to update the downstream package is
immediately AFTER the upstream release. (Before that, you don't even have a
valid Source URL to point to.) But then if you need to change the specfile
for whatever reason, the tarball will contain an outdated specfile (unless
you respin it in place, which is heavily frowned upon). Hence, a tarball
should NEVER contain the specfile.

I keep my specfiles for official Fedora packages in Fedora dist-git, and any
other specfiles in dedicated specfile repositories, but NEVER in the
upstream source tree. The only case where there is only one repository is
packages that are so trivial that there is no source tarball at all, e.g.,
kannolo-release. But those are technically downstream-only packages, not
upstream-only packages.

Kevin Kofler

Re: Packages which use the BuildRoot: directive

By Kevin Fenzi at 07/11/2018 - 15:47

On 07/11/2018 10:39 AM, Ben Rosser wrote:
Yep. I think most commonly it's the upstream project being packaged.

Sadly it would indeed.

The problem here is there's competing interests here and Fedora has
limited leverage. On the one hand it makes automated changes harder,
which I think is a bad thing, but on the other hand some upstreams want
to manage their spec file in the same scm that they manage the project
in so they can easily make changes when upstream does so.

The guidelines currently say:

<a href="" title=""></a>

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

I think this guideline is bad and counterproduuctive, since many
packages clearly ignore it. So what do we do? Take the package away from
(most likely) upstream developers? Tell them no no no very sternly so
they can ignore us?

How about adopting a convention for these spec files? A way to identify
them and provide a channel of communication for changes? A comment with
# Canonicalspec: https//
# ChangesPR: ...path to pr interface
# ChangesTicket: ...path to just filing a ticket about changes?

Alternately we could look at something in pagure/
to mark them somehow, or try and identify them and make a README.spec
file for each of them or soemthing.

Barring that, I think we will just continue to have people make changes
and them get overwritten.


Re: Packages which use the BuildRoot: directive

By Emmanuel Seyman at 07/11/2018 - 18:38

* Kevin Fenzi [11/07/2018 12:47] :
Does this include changes that were made for security reasons (disabling
a compile-time option, doing a dangerous chown/chmod call, ...)?
If so, I'm not very comfortable with this (and yes, I realize that this
is the current mode of operation).


Re: Packages which use the BuildRoot: directive

By Kevin Fenzi at 07/13/2018 - 17:44

On 07/11/2018 03:38 PM, Emmanuel Seyman wrote:
Sure, it would be any changes that are made to the Fedora spec vs the
upstream one. Hopefully someone realizes when this happens and works to
get the upstream spec updated as well, but I suspect there are cases
where it's not.


Re: Packages which use the BuildRoot: directive

By Zbigniew =?utf-... at 07/11/2018 - 18:11

On Wed, Jul 11, 2018 at 12:47:40PM -0700, Kevin Fenzi wrote:

Re: Packages which use the BuildRoot: directive

By =?UTF-8?B?TWlyb... at 07/12/2018 - 10:45

On 12.7.2018 00:11, Zbigniew Jędrzejewski-Szmek wrote:
I second that. When we mass filled PRs with python2 related changes it
was always a Red Hat maintained software, where people were basically
telling us: "no, we won't accept your PR here, we maintain the specfile
somewhere else". It was very unpleasant experience and usually such
maintainers expects us to:

1) find their canonical spec file location and figure out what special
branch we need to apply the patch to

2) wait for a new release of their software to happen and specfile
changes be "backported" into Fedora (sometimes took months)

Some maintainers were kinder than others, taking the changes and
applying them in their god-knows-where mainained spec files. Some where not.

We don't need to make the rule less strict, we need to find a way to
enforce it. The current state (people ignoring this rule) makes
contributing to Fedora even harder than it already is.

Re: Packages which use the BuildRoot: directive

By Kevin Fenzi at 07/13/2018 - 17:47

I don't see that there is any way to enforce it. I suppose you could try
and have a hook to detect it, but it could well have false positives and
block legit commits.

Perhaps once we no longer use specs we can solve this. ;)


Re: Packages which use the BuildRoot: directive

By Panu Matilainen at 07/30/2018 - 09:48

On 07/14/2018 12:47 AM, Kevin Fenzi wrote:
We can always have rpm spit out warnings first and errors later on.

With RHEL 5 and its contemporaries EOL by now, turning Buildroot: into a
warning seems like an actual possibility. Finally.

Re: Packages which use the BuildRoot: directive

By R P Herrold at 07/12/2018 - 13:24

Are these Holy Writ, or just process, subject to amendment?

There is a principle:

Seek first to understand

before ** suggesting ** what one feels are helpful suggestions

It applies here

oh -- So forking, or adding (probably) unwanted
co-maintainers, or continuing to fight that entropy with
what are functionally an unknown number of 'provenpackagers'
co-maintainers, pushing unwanted 'fixes' in, is proposed?

and a peeve: NOT updating the changelog when literally
thousands of packages are re-factored? I know I always love
getting to play detective, when an encountered version does not
match a prior SRPM of the same NEVR

If being ignored bothers you, perhaps the problem is not them,
but your reaction at being ignored

Perhaps offer of the carrot rather than use of the stick is in
order. Maybe, just asking questions, and coming up with a
rubric to annotate within a non-parsed field in a .spec file
where 'upstream' is (as was suggested -- as was done with the
various side adjunct repos -- dag, RF, more, to accommodate
their tooling)

great -- using force always makes new friends ... NOT

What happened to the Four Fedora F's ?

'Always'? A fork of 'Spacewalk' just left because of the
non-public approach to road-map by Red Hat insiders, and simply
ignoring or not taking non @redhat commits. I spoke with Don
Vosburg of SUSE at a conference about his frustration with
having to do so just a week or two ago. He _wished_ the fork
was not required, but to maintain the their implementation,
which is productized as 'SUSE Manager', he had to get that
fixes in

See again, seeking to understand first before suggesting
prescriptions to the person ** volunteering ** to do work
which happens also to benefit the Fedoraproject

The project is a social voluntary organization -- driving
volunteers AWAY is trivially easy. I took heat in the CentOS
project for working to keep the Signal to Noise ratio high, at
the expense of intentionally (and by a rubric documented in
the CentOS wiki) removing people unwilling to play by that set
of rules. I'd do it the same way again tomorrow. But I knew
I was not being welcoming to all, as not all were welcome,
frankly. Immediate kick-bans of people using profanity,
racist content, etc, seem to be a win to me

Again, the location of the hurt feelings is not with the
remote maintainer. Examining ** why ** you feel that way is
in order. Perhaps an out of band discussion with the
recalcitrant offender is in order ;) Looking at my sent
folder, I see that I send 20 to 30 'off list' emails a month,
to get at the reasoning of another behind things I do not

I find that it is very unpleasant to encounter a auto-closed
bug, doing research as to an error, and knowing full well that
this close is saying:

This bug (and the current item I am researching) is
known, but we did not fix it, so we swept it under the rug.
Perhaps it will fix itself

At that point, I can solve my unhappiness by:

committing a local fix, and NOT upstreaming it
committing a local fix, and upstreaming it

Obviously one path is better than the other for 'improving the
breed' -- but if I have been filing ignored bugs, which
simply get auto-closed, it is easier to do less work

And, frankly, that is their choice to make, rather than yours,
unless you are proposing to excommunicate people from

"The beatings will continue until morale improves"


-- Russ herrold

Re: Packages which use the BuildRoot: directive

By Matthew Miller at 07/11/2018 - 14:12

On Wed, Jul 11, 2018 at 01:39:51PM -0400, Ben Rosser wrote:
Yeah, this argument seems pretty compelling to me. I think that if
people want to maintain an outside spec file, they *must* also respect
changes made to the primary one in dist-git.

Re: Packages which use the BuildRoot: directive

By Jason L Tibbitts III at 07/12/2018 - 16:54

MM> Yeah, this argument seems pretty compelling to me. I think that if
MM> people want to maintain an outside spec file, they *must* also
MM> respect changes made to the primary one in dist-git.

I took a break from this discussion, but I did want to point out that
the guideline itself does say pretty much exactly that:

"If some maintainers are also attempting to keep copies of a spec in an
outside repository, they MUST be prepared to merge changes made to the
spec in Fedora's repository, and MUST NOT overwrite those changes with a
copy from an external repository or using fedpkg import. "

We don't say that you can't maintain a copy externally, only that
Fedora's specfile is part of Fedora and that maintainers must expect
that Fedora will occasionally be modifying it. Surely it isn't too much
to ask that those modifications not be wiped out.

- J<

Re: Packages which use the BuildRoot: directive

By Josh Boyer at 07/11/2018 - 15:42

On Wed, Jul 11, 2018 at 2:13 PM Matthew Miller < ... at fedoraproject dot org> wrote:
It would be compelling if changing words on a wiki page somehow made
something easier. It doesn't, and instead we continue to assume
because we have a guideline everybody a) is aware of it and b)
immediately follows it.

Look, we can just stop now. People want to pretend we don't have
problems or that the guideline is a solution when it isn't. That's
OK. I've offered some suggestions on how to improve things, and
people don't agree because it theoretically causes them more work.
That's also OK. I'm not interested in debating it further when people
aren't even reading what I've written.


Re: Packages which use the BuildRoot: directive

By Zbigniew =?utf-... at 07/11/2018 - 15:50

On Wed, Jul 11, 2018 at 02:12:37PM -0400, Matthew Miller wrote:
Yes. Another reason against keeping the spec file somewhere else and
just syncing it into dist-git, is that it makes it significantly
harder for another maintainer to contribute, even a simple fix. We
must be prepared for other people to help with our packages when
we're on vacation or busy, and accept PRs in src.fp.o, and having
an external location for the spec file interferes with all of that.


Re: Packages which use the BuildRoot: directive

By Tomasz Torcz at 07/11/2018 - 13:12

On Wed, Jul 11, 2018 at 12:16:45PM -0400, Josh Boyer wrote:
`git pull` with tell them, `git diff` / `git show` will show the
details. Don't we expect maintainers to know basics of git?

The maintainers are supposed to communicate with upstreams.

Re: Packages which use the BuildRoot: directive

By Zbigniew =?utf-... at 07/10/2018 - 16:15

On Tue, Jul 10, 2018 at 03:03:56PM -0500, Jason L Tibbitts III wrote:
Thanks! It'll be nice to see BuildRoot finally gone.