I find patching rubygems (for CVEs) a pain in the ass because of the
packaging guideline requirement to have the rubygem package's Source0 be
the actual gem.
I'd much rather work from tarballs.
Jeroen van Meeuwen
needs an update (it's read-only).
The section about "Inaccessible Directories" applies only to RPM < 22.214.171.124
according to information on fedora-devel-list, and that means Fedora < 9
if the information is correct. At least since Fedora 10, RPM sets a sane
default umask, so unowned directories are created with mode 0755.
Much progress has been made on packaging related pages with regards to
the wiki cleanup. This involves better use of categories, archiving
old pages, and renaming pages for better search results. The detailed
task list is at
I have three TODO items that I would appreciate some help with.
1. Spread the word to use the new naming and categories.
2. Let me know if there are any major changes that need to be done (so
I don't repeat the mistakes with future page changes)
3. Look over the list of renaming changes for the protected Packaging
pages. I finished up adding categories last night and am a bit cross
eyed looking at it so general proofreading would also be helpful. This
is in with wikirename.git repo and named Packaging.psv
Here's the high level structure that Toshio and put together last night:
*Category:Packaging (containing mostly subcategories and few if any
Inside Packaging you can find (among others):
Category:Packaging best practices (this one replaces an old
guidelines and policy category)
Inside Packaging committee you can find:
Category:Packaging guidelines - holding the Packaging: namespace pages
Category:Packaging guidelines drafts - holding the drafts (in the
Main: namespace) in progress and a sub category of archived drafts
Category:Packaging meeting logs - Meeting logs which will be in the
Category:Packaging meeting minutes - Meeting minutes which will be in
the Meeting: namespace
I have already renamed the Package Maintainers pages. Any that I
missed are probably recent additions but I will keep looking and
assist anyone who has questions.
I have renamed most of the Packaging guidelines drafts. The rest will
be archived or renamed within the next week. Feel free to take care
of your own pages.
We are still hoping to get the scripts worked out so that the pages in
Packaging: can be changed by wikibot. [Failing that, I am willing to
do it manually if given access or someone already with access will
need to manually make the changes.]
Susan Lauber, (RHCX, RHCA, RHCSS)
Lauber System Solutions, Inc.
gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974
This is kind of a two part question. I have a package up for review
that, per the author, is dual licensed GPL and Artistic. Only GPL is
accepted in Fedora.
Do I specify my License as just GPLv2+ or do I indicate it's dual
licensed even though Artistic is not allowed in Fedora?
Also, there was a bit of confusion on the licensing status of this
particular package. The PKG-INFO file indicates "Artistic" as the
license, but also lists GPL -- I think this is just a side effect of
one of the two licenses needing to be listed as "primary" on the pypi
page. Note the License field there and then the Categories field.
I was able to contact the author, and he has indicated to me via email
that this package should indeed be dual licensed under GPL and
Artistic. This leads me to wonder a couple of things:
- Is the PKG-INFO as indicated above sufficient to demonstrate the
dual licensed nature of this package?
- If it's not, would including the email from the author as part of
the documentation be adequate?
- Failing that, is the only way to get the author to release a new
version of the package including license information and/or
updatin the pypi entry?
I am now trying to review on bug 483498, then I got a question.
# repoquery --repoid=koji-11 --whatprovides '/usr/share/gnome-background-properties/*' | sort | uniq
# repoquery --repoid=koji-11 --whatprovides '/usr/share/gnome-background-properties' | sort | uniq
My question is: which package should own %_datadir/gnome-background-properties?
- As the name of this directory shows something related to GNOME, maybe one component
of GNOME should own this directory. However in that case forcing these packages
to have "Requires" for the GNOME component due to this ownership issue seems
- Or maybe filesystem (even if "gnome" appears on this directory name)?
Any comments appreciated.