I'm packaging some themes for GNOME Shell, which are compatible with only
GNOME 3.4 (i.e. can be installed with success only on Fedora 17).
What do you think is the best way to act?
Can I submit the package to the F17 branch only, excluding everyone else
(also master, i.e. F19)?
Or is it better to add an explicit "Requires" (for e.g. GNOME Shell 3.4.x)
to the Spec files? In such case, is something like "Requires:
gnome-shell=3.4.*" allowed to specify all sub-releases belonging to the 3.4
Thanks in advance for your help.
> Rex Dieter wrote:
> I can understand your frustration, and that you and Dan had trouble
> communicating and working together.
> I don't accept it. Dan reacting poorly is a given, and something he
> (and I
> with him) are working on.
> I personally don't feel it helps taking your greivances public, as
> now Dan's
> perception of you (and now potentially others) will be colored as
I'm one of MATE Desktop upstream developers. I'm sorry for my intrusion
here, but I feel the need to write my opinion in this thread. We already
worked with a lot of distros maintainers and always worked happily with
them. We got problems with Dan only. He already insulted a lot of
developers, maintainers and reviewers. He dont know how to work with
other people, and specifically with free and open source projects
upstream authors. If he has issues, he demands a solution from upstream
devs without trying to help in any way, and if he dont receive answers,
he start to insult.
I'm really worried if he can maintain MATE desktop packages with his
way to cooperate with other people and upstream maintainers.
-----BEGIN PGP SIGNED MESSAGE-----
I'm a Perl developer / sys-admin working for the PacketFence open
source project which has strong RHEL roots.
A few months ago I've switched to Fedora as my desktop and I'm trying
to upstream some of our own packages to improve their quality and so
that everyone can benefit from having easy access to them.
I have one package looking for a sponsor:
Also I plan on updating the asciidoc package and do whatever is in my
way to ease PacketFence's integration into Fedora and RHEL with the
ultimate goal of `yum install packetfence`.
Finally I'm also a spare time FLOSS android developer working on
Tomdroid and several other little perl projects plus a father of
Olivier Bilodeau <olivier(a)bottomlesspit.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I just received about a dozen bugs like this:
On Tue, Aug 21, 2012 at 02:16:42PM +0000, bugzilla(a)redhat.com wrote:
> Summary: Introduce new systemd-rpm macros in watchdog spec file
> Fedora 18 changes the way how to work with services in spec files. It
> introduces new macros - %systemd_post, %systemd_preun and %systemd_postun;
> which replace scriptlets from Fedora 17 and older (see
I'm not objecting to getting the bug being filed or to the packaging change.
However, the person who is sending these bugs reports is
(a) in a much better position to change the packages because they
understand the problem and the solution, and (b) ought to take on this
work because that's part of whatever feature/cleanup/etc they are
proposing, instead of pushing part of that work off to everyone else.
Therefore, I think a better Bugzilla message would have been:
> Fedora 18 changes the way how to work with services in spec files.
> [etc as above]
> If you would like to make this change to your own package, you
> don't need to do anything now.
> If you would like the reporter to fix your package, please add
> a comment to this bug saying so within the next [2 weeks]. The
> reporter will take care of this fix for you and unless there are
> complications you won't need to do anything else.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd