Feedback on documentation
by Bruno Wolff III
I am a new packager following:
http://fedoraproject.org/wiki/PackageMaintainers/Join
And read the following note:
Running ssh-add before doing any cvs operations is a very good idea. It will save you from having to type your key password for every operation. You only have to run ssh-add once per session, it will remember it until you log out or reboot. If "ssh-add" reports "Could not open a connection to your authentication agent.", start a new shell under it using "exec ssh-agent bash".
However I was never asked for a password. I assume that my Fedora cert
is just being picked up. Did I do something odd or is this note out of date?
14 years, 9 months
/srv usage
by Philippe Makowski
Hi,
I would like to know if there is any rule about using /srv ?
Firebird package need a place to store databases files, and reading
the FHS rules, it seems that it is the right place for that instead of
/var/lib
14 years, 9 months
Version name for prerelease when upstream used date based versions
by Bruno Wolff III
I am looking a the suggested version name for a prerelease when upstream
uses dates for their versions.
I am close to having a package (colossus) ready, but one sticking point is
that upstream is probably a week or two away from putting up a new public
build (essentially a snapshot they want to recommend to general users). The
code has changed a lot since their last public release, so that a snapshot
now is really much more of a prerelease package than a post release. Some
things have changed from the last public build to make it more suitable
for packaging in Fedora, so packaging that version isn't very practical.
Upstream is considering changing to more normal version names, but probably
won't make such a change before the next public build.
I could hold off on putting the package into rawhide until after they
make the next public build making the issue moot. (I wasn't going to put
the package into a released version of Fedora until then in any case.)
I could also use a current date for the version of the package, but that
won't correspond to any actual release made by the upstream. I could also
use the date of the last public build even though the code has diverged
since then. (I am not sure if the interface has changed much since then
since for my own use I have been running current svn check outs for over
a year and don't use the public build versions.)
14 years, 9 months
Fwd: Python package distribution standards
by Jon Stanley
If you are interested in Python packaging standards and not subscribed
to the distributions list (where cross-distro collaboration happens),
now would be a good time to do so :)
---------- Forwarded message ----------
From: Ben Finney <ben+freedesktop(a)benfinney.id.au>
Date: Tue, Jul 7, 2009 at 9:21 AM
Subject: Python package distribution standards
To: distributions(a)lists.freedesktop.org
Cc: Distutils-Sig(a)python.org
Howdy all,
I'm cross-posting between the Python distutils discussion forum and the
Freedesktop distributions discussion forum. If you think any OS-specific
discussion forums need to be involved, please ask a representative to
join one or more of these forums so the discussion doesn't get too
attenuated.
For a number of weeks now, the Python package distribution standards
have been undergoing intensive scrutiny in the wake of much face-to-face
discussion at Pycon 2009. Many goals are being juggled in an attempt to
get a beneficial result for everyone affected by these standards.
The discussion has reached a point of some “open questions”
<URL:http://article.gmane.org/gmane.comp.python.devel/105237> on the
current draft of PEP 376 <URL:http://www.python.org/dev/peps/pep-0376/>,
which has re-raised the issue of how Python distribution standards could
be improved with regard to OS distribution packaging requirements.
I've made a case for metadata that would be beneficial to OS packagers
<URL:http://thread.gmane.org/gmane.comp.python.devel/105237/focus=105270>,
but I am not very cognizant of the needs of specific OS packaging
systems. We need input from others who know and care about how Python
packages should fit into specific operating system package management
systems.
If you feel you have constructive input on how Python's package
distribution metadata can be improved for the needs of OS packagers
(along with other needs being targeted by such metadata), please read
the standards drafts, join this discussion, and weigh in now while the
topic is hot.
--
\ “The industrial system is profoundly dependent on commercial |
`\ television and could not exist in its present form without it.” |
_o__) —John Kenneth Galbraith, _The New Industrial State_, 1967 |
Ben Finney
_______________________________________________
Distributions mailing list
Distributions(a)lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/distributions
14 years, 9 months
Should Scintilla be package as a shared library ?
by Remi Collet
Hi,
http://www.scintilla.org/ is a free source code editing component.
Upstream provides only a makefile for a static library.
Of course, it's quite easy to create a shared library, but without
versionning as upstream doesn't handle this.
At least scite (in fedora repo) use this library, but probably other
projects (I have no way to detect this).
I'm working in MySQL Workbench, which also use it (and some other
bundled libraries, as curl, boost, ..., more easy to remove)
What sould I do ?
- package scintilla as a shared lib
(this will imply rebuilding all applications on scintilla update and
probably issue with applications using different version)
or
- package MySQL Workbench with the bundled scintilla
(the simple solution, but against good pratices)
Thanks for your comment on this.
Remi.
14 years, 9 months
License reference for additional, non-essential example files of a package
by Federico Hernandez
Hi!
The upstream project has some additional, non essential files (in this case
vim syntax files which the upstream project "make install"s under the
docdir). How should these reference to a license information? Do they have
to include a license information? I ask as Bram Moolenaar has asked the
upstream project to not have any license reference in the syntax files (the
upstream project has submitted them to be included in the vim distribution).
Would a reference to the license in a corresponding README file be enough?
/Federico
14 years, 9 months
Re: About my proposal of moving the stage to expand gem files
by Jeroen van Meeuwen
On Sat, 04 Jul 2009 02:32:49 +0900, Mamoru Tasaka
<mtasaka(a)ioa.s.u-tokyo.ac.jp> wrote:
> Hello, all:
>
> Two weeks ago I wrote the proposal to move the stage to expand
> rubygem files from %install to %prep as:
>
> https://www.redhat.com/archives/fedora-packaging/2009-June/msg00069.html
> https://fedoraproject.org/wiki/PackagingDrafts/Gem_expand_stage_change
>
> I would appreciate it if you would write some opinion for my proposal
> on fedora-packaging mailing list.
>
In my opinion, the guidelines requiring the use of the .gem instead of the
.zip/.tar.gz is the root cause of the problem.
If only we are allowed to use the .zip/.tar.gz, then in most cases we could
extract the .zip/.tar.gz in %prep, apply patches in %prep, build the .gem
in %build (if needed), do additional compiling in %build, and properly
install in %install.
I've never really understood the requirement to use the .gem anyway, so
maybe that's what I'm missing.
--Jeroen
14 years, 9 months
