packaging September 2009

packaging@lists.fedoraproject.org

35 participants
22 discussions

Ocaml sub-package issue
by Orion Poplawski 08 Oct '09

08 Oct '09

I package plplot which ships bindings for oodles of languages, among them perl and ocaml. The ocaml packaging guidelines suggest: %global _use_internal_dependency_generator 0 %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh %global __find_provides /usr/lib/rpm/ocaml-find-provides.sh to add the required ocaml Requires/Provides. However, this breaks the automatic perl (and other?) generation for the perl sub-package. How should this be handled? Is there a way to add the ocaml-find-requires/provides to the normal list of providers? Shouldn't this be done automatically by the build system? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

4 9

Package Guildelines / Review Guidelines: .la archives must/should not contradiction
by Till Maas 01 Oct '09

01 Oct '09

Hiyas, I just noticed that the packaging guidelines say the .la archives should not be included but the review guidelienes say that they must not included: https://fedoraproject.org/wiki/Packaging:Guidelines#StaticLibraries https://fedoraproject.org/wiki/Packaging:ReviewGuidelines I stumbled up this because the Merge Review of apr cannot be finished with clarification of this: https://bugzilla.redhat.com/show_bug.cgi?id=225253 Regards Till

3 2

packaging a command line app to have action / servicemenu in filemanagers
by Development discussions related to Fedora 30 Sep '09

30 Sep '09

Hi, my pre-reviewer [1] noted that I didn't run desktop-file-install on a .desktop file I am installing. However, the app isn't actually a gui app, therefore the must rule doesn't apply. What the .desktop file does achieve is adding an "extract tnef archive" menu item to files where the mime-type matches tnef. The unwanted sideeffect of doing this is that gnome places an icon for the program into the Application menu. This icon is useless; it runs a script to run the app, without an input parameter, and hence does nothing (well, that 'nothing' might need to be double checked). Is it acceptable to add a desktop file to achieve this ? Is there someway to indicate to the desktop program that the menu entry shouldn't be shown ? Does using desktop-file-x any use on .desktop files that aren't intended to become part of the menus ? DaveT. [1] https://bugzilla.redhat.com/show_bug.cgi?id=522920

3 3

Exemption for bundling local copy of system library?
by Michel Alexandre Salim 29 Sep '09

29 Sep '09

Hi, Oolite <http://oolite.org> is currently undergoing review, and a stumbling block is in its use of its own copy of libjs. An upstream developer is participating in the review and has a clear explanation for the rationale: https://bugzilla.redhat.com/show_bug.cgi?id=459211 libjs is not exposed to any network interfaces, so the risk is probably quite low -- the alternative is to wait until xulrunner 2.0 is released (the previous stable version has problems in its scripting mechanism and most third-party add-ons for Oolite do not work on it anymore. Would it be alright in this case to bundle libjs? PS the "no bundled libraries" draft (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does not clearly indicate which mailing list is to be used Thanks, -- Michel Alexandre Salim

3 4

Problem with creating RPM for screenlets
by Tareq Al Jurf 28 Sep '09

28 Sep '09

does this "python setup.py bdist_rpm"create packages correctly? i'm trying to create a package for screenlets from a tar.bz file and what version of python does fedora 12 have? -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf(a)fedoraproject.org

2 1

Explicit "Requires" should (usually) be arch-specific
by Braden McDaniel 16 Sep '09

16 Sep '09

Since apparently a requirement for "foo" can be satisfied by any available architecture for which a "foo" is available, "Requires" that do not specify the architecture are unsafe for multilib systems (unless the dependency really can be satisfied by any architecture--which does not strike me as the most common case). I think this bears mentioning in https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires And I think the example there needs to add the architecture to be correct. -- Braden McDaniel <braden(a)endoframe.com>

5 14

cleanup RPM Tags in Packaging Guidelines
by Till Maas 16 Sep '09

16 Sep '09

Hiyas, currently the RPM Tags section in the Packaging Guidelines[0] contains a blacklist of some RPM Tags: * Packager * Vendor * Copyright * PreReq Except for the Copyright tag, they all should not be used. I want to propose to change this to to a whitelist of RPM Tags that are allowed to be used and mention only explanations about their substitutions or reasons why they must not be used in the Guidelines. As the previous sentence implicates, I also want to change it to forbid these tags completely (must not) or there should be some information added, when it is ok to use them in Fedora. E.g. when is it ok to use PreReq or Packager in the Spec? The guidelines do not answer this question, therefore it would be easier to just forbid these tags for easier understanding of the guidelines. If there is a reason to use these tags in the future, the guidelines can be adapted anyways. The reason why I spotted this, is because a spec posted for review does contain a tag called "Distribution" and the Guidelines do not provide any guidance about how to proceed. I assume that it must not be used either. Regards Till [0] https://fedoraproject.org/wiki/Packaging/Guidelines#Tags

2 2

EPEL + Fortran guideline
by Susi Lehtola 16 Sep '09

16 Sep '09

Hi, it just occurred to me that there is no %{_fmoddir} in EPEL. What should we do about that? Define the %{_fmoddir} macro in every package that needs it, make some wrapper package or what? -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

1 0

What does one do when a package maintainer is unresponsive ?
by steve 16 Sep '09

16 Sep '09

Hi, What is the course of action to be followed if a package maintainer appears to be unresponsive ? Specifically, I speak of the usb_modeswitch package, for which there has been an update-to-latest-upstream request pending for sometime now ... https://bugzilla.redhat.com/buglist.cgi?component=usb_modeswitch&product=Fe… In the BZ that I submitted[1], I even offered to co-maintain or take over ownership of this package in case the package maintainer is hard pressed for time, without receiving any response. I would like to see this bz fixed before I can start pester^Whelping out on BZ 515412 [2], which is causing me a lot of inconvenience. cheers, - steve [1] https://bugzilla.redhat.com/show_bug.cgi?id=519332 [2] https://bugzilla.redhat.com/show_bug.cgi?id=515412 -- random non tech spiel: http://lonetwin.blogspot.com/ tech randomness: http://lonehacks.blogspot.com/ what i'm stumbling into: http://lonetwin.stumbleupon.com/

2 2

Re: Common Voicedata Packaging Guidelines
by Toshio Kuratomi 15 Sep '09

15 Sep '09

CC'ing fedora-packaging since there's no need for us to just talk about these things between ourselves. On 09/10/2009 12:44 AM, Ding-Yi Chen wrote: > 於三，2009-09-09 於 11:10 -0700，Toshio Kuratomi 提到： >> Greetings, >> >> I'm one of the other members of the Fedora Packaging Committee and we >> had some more questions about CommonVoiceData: >> >> https://fedoraproject.org/wiki/PackagingDrafts/CommonVoiceData >> >> 1) Who uses the data? (answered: just gcin) >> 2) Who uses the db? >> 3) Do we need a standard for this or is it just going to be used by > gcin? > > If that data is only for gcin, I would have just contacted gcin's > maintainer and include it as a sub-package of gcin. > > I do plan use the voice data with ibus and couple of others. > I also plan to pack other voice data, such as : > 1. Ekho http://e-guidedog.sourceforge.net/ekho.php > 2. http://espeak.sourceforge.net/ > > Hmm, do you mean that there must be sufficient amount of relative > packages to push this proposal? I can pack those voice-data, if that is > mandatory. > There does not need to be a large amount of voice data packages. I'm mainly wondering what is happening with the db. If there are several packages that use the db, then it seems like there needs to be some coordination among those projects to do so. >> 4) If a standard, who would be best to make a standard for this stuff? >> 4b) If no idea, do you think freedesktop would be a common meeting >> ground for the participants? > > I haven't though that way. I would gladly move the issue to freedeskop > if discussing there is more appreciate. > It may be. Usually the Fedora Guidelines are written to tell packagers how to deal with a standard that originated elsewhere (FHS, .desktop file handling, etc). If we're just talking about where on the filesystem the data files shold be placed and how the packages should be named, then Fedora Guidelines can cover it immediately (via the FHS and package naming being a distro-specific standard). It's the usage of the database that seems a bit odd to be originating in Fedora rather than some distro-agnostic, upstream location. >> 5) If not a standard, what does gcin do with this db? > It is merely an example usage for the voice data. > So -- what's the plan for using the db? >> Implementation >> 1) What package owns the db on the filesystem? > Actually the package: voicedata owns the db. > The packing voicedata is in on the way. > Okay. So the packages that contain voicedata need to Require(XXX): voicedata where XXX are the scriptlets that update the db. >> 2) Scriptlets need to account for upgrade/removal/install -- See >> https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Syntax >> >> https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Scriptlet_Orderi… > > Thanks for pointing out the "upgrade" requirement. I think I covered > install/uninstall script in the sample spec file. > >> 3) What's this db created during the %build? We noticed that there's >> sqlite3 commands in %build but the db created there isn't installed. >> -Toshio >> > > Thanks for telling me this. > I will fix the proposal and spec if you think the common voicedata idea > still belong to fedora packaging guideline. No problem. We'll definitely want something written up in the Guidelines. I'm just not sure yet what the purpose of all the parts in the draft is and whether there needs to be cross-distro, cross-upstream-project consensus to make these effective. -Toshio

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging September 2009