Packaging guidelines for rubygems
by Jeroen van Meeuwen
Hi,
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.
Kind regards,
Jeroen van Meeuwen
-kanarip
15 years, 1 month
Wiki cleanup TODO
by Susan Lauber
Greetings,
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
https://fedoraproject.org/wiki/Docs_tasks_for_Packaging_Guide_and_related...
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
http://git.fedorahosted.org/git/wikirename.git?p=wikirename.git;a=blob_pl...
Here's the high level structure that Toshio and put together last night:
*Category:Packaging (containing mostly subcategories and few if any
pages) https://fedoraproject.org/wiki/Category:Packaging
Inside Packaging you can find (among others):
Category:Package Maintainers
https://fedoraproject.org/wiki/Category:Package_Maintainers
Category:Packages
Category:Packaging SIGs
Category:Packaging best practices (this one replaces an old
guidelines and policy category)
Category:Packaging committee
https://fedoraproject.org/wiki/Category:Packaging_committee
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
Meeting: namespace
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.]
Thanks,
Susan
--
Susan Lauber, (RHCX, RHCA, RHCSS)
Lauber System Solutions, Inc.
http://www.laubersolutions.com
gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974
15 years, 1 month
Dual licensing question...
by Ray Van Dolson
This is kind of a two part question. I have a package up for review[1]
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[2]. 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?
Guidance appreciated!
Ray
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=488407#c4
[2]: http://pypi.python.org/pypi/text_table/0.02
15 years, 1 month
Call for the owner of %_datadir/gnome-background-properties
by Mamoru Tasaka
Hello, all:
I am now trying to review on bug 483498, then I got a question.
Currently:
-----------------------------------------------------------------
# repoquery --repoid=koji-11 --whatprovides '/usr/share/gnome-background-properties/*' | sort | uniq
desktop-backgrounds-basic-0:9.0.0-7.noarch
desktop-backgrounds-waves-0:9.0.0-7.noarch
fedorainfinity-backgrounds-0:0.0.5-2.fc11.noarch
gears-backgrounds-0:0.0.1-3.fc11.noarch
gnome-backgrounds-0:2.24.0-4.fc11.noarch
invinxble-backgrounds-0:0.0.1-3.fc11.noarch
neon-backgrounds-0:0.0.1-3.fc11.noarch
solar-backgrounds-0:0.92.0-2.fc11.noarch
solar-backgrounds-extras-0:0.92.0-2.fc11.noarch
themes-backgrounds-gnome-0:0.5.1-2.fc11.noarch
# repoquery --repoid=koji-11 --whatprovides '/usr/share/gnome-background-properties' | sort | uniq
desktop-backgrounds-basic-0:9.0.0-7.noarch
fedorainfinity-backgrounds-0:0.0.5-2.fc11.noarch
gears-backgrounds-0:0.0.1-3.fc11.noarch
gnome-backgrounds-0:2.24.0-4.fc11.noarch
invinxble-backgrounds-0:0.0.1-3.fc11.noarch
neon-backgrounds-0:0.0.1-3.fc11.noarch
solar-backgrounds-0:0.92.0-2.fc11.noarch
-------------------------------------------------------------------
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
redundant.
- Or maybe filesystem (even if "gnome" appears on this directory name)?
Any comments appreciated.
Regards,
Mamoru
15 years, 1 month
