FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 05-28-2011, 11:49 PM
Tom Callaway
 
Default Changes to the Packaging Guidelines

Here is this week's change to the Fedora Packaging Guidelines:

---

The systemd guidelines on naming unit files have been amended to tell
packagers how to make compatibility symlinks for alternate service names
should their service have had a different name in the past.

http://fedoraproject.org/wiki/Packaging:Systemd#Naming

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to the Fedora Community, and all of the members of the FPC,
for assisting in drafting, refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
--
announce mailing list
announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/announce

!DSPAM:4de51dcc135711283930955!

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 07-20-2011, 02:47 PM
Tom Callaway
 
Default Changes to the Packaging Guidelines

Here are the latest changes to the Fedora Packaging Guidelines:

---

Some rpm versions pass pathnames to the automatic filtering macros, so a
section has been added to the guidelines to help packagers deal with it:

https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Pathnam es


---

For a while, Fedora considered mono packages to be
architecture-specific, and installed assemblies to %{_libdir}. However,
after discussions with upstream, we now consider mono packages to be
architecture (and platform) independent. This means that mono packages
should be correctly installed into the GAC in /usr/lib or installed into
/usr/lib/PACKAGENAME.

As a notable exception, any ELF binary libraries generated in a mono
package must be correctly installed into %{_libdir}, because these files
are architecture-specific.

Also, even though we consider mono packages to be architecture
independent, they must not be marked as "noarch". Although the
assemblies are the same, the files may differ due to strings referring
to the build architecture.

https://fedoraproject.org/wiki/Packaging:Mono#File_Locations

---

It was decided that gnome shell extension packages should have the
prefix gnome-shell-extension (with no "s" on the end).

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28gnome _shell_extensions.29

---

The section in the Fedora Packaging Guidelines concerning libexecdir has
been improved and expanded:

https://fedoraproject.org/wiki/Packaging:Guidelines#Libexecdir

---

The Fedora Java Packaging Guidelines have been updated to reflect the
latest macros for Maven 3.

https://fedoraproject.org/wiki/Packaging:Java

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Christian Krause, Aleksandar Kurtakov, Petr Pisar,
Stanislav Ochotnicky, and all of the members of the FPC, for assisting
in drafting, refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 09-22-2011, 05:06 PM
Tom Callaway
 
Default Changes to the Packaging Guidelines

Here are the latest changes to the Fedora Packaging Guidelines:

---

The section of the Packaging Guidelines regarding Compiler Flags has
been updated and improved, most notably, to document handling of PIE
enabled packages.

https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags

---

The prohibition against unnecessary explicit library requires has been
updated with an example of when explicit library requires are useful and
allowed. The example addresses packages that use features of a library
added after the library initially adopted its current SONAME.

https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires

---

An additional md5 implementation was added to the list of bundling
exceptions:

https://fedoraproject.org/w/index.php?title=Packaging:No_Bundled_Libraries&act ion=submit#Packages_granted_exceptions

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Kevin Fenzi, Adam Jackson, and all of the members of the
FPC, for assisting in drafting, refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-06-2012, 02:09 PM
Tom Callaway
 
Default Changes to the Packaging Guidelines

There have been quite a few approved changes to the Fedora Packaging
Guidelines since the previous announcement, but this is mostly because I
have not had time to actually apply the approved updates to the wiki
until recently. These updates actually were approved over a period of
several months. I will try harder to get updates written up and
announced in a more timely fashion going forward.

---

The Eclipse Plugin Packaging Guidelines were updated. The most major
change is the addition of a section discussing how to run the
reconciler. For the full updated guidelines see:
https://fedoraproject.org/wiki/Packaging:EclipsePlugins

---

t4k_common contains a forked copy of an older version of liblinebreak. A
temporary bundling exception has been granted until the t4k_common
upstream is able to port their code to use the newer system copy of
liblinebreak. The t4k_common package must include Provides:
bundled(liblinebreak) until the issue is resolved.

This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

Spring RTS includes a forked and bundled copy of Lua which has Spring
RTS specific patches applied, must link to streflop, and is configured
differently from stock Lua (most importantly it needs lua_Number to be a
float and not a double). Lua is particularly important because parts of
the game code may be written in it, which must yield exactly identical
results (also floating point operations!) on all platforms.

As a result, it has been granted a bundling exception for lua. The
Spring RTS package must include Provides: bundled(lua) = X.Y.Z (where
X.Y.Z is the base lua version), until the bundling issue is resolved (if
ever).

This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

A section has been added to the Guidelines that limits which package
manager repositories are allowed to be configured in Fedora. Additional
repository configuration files are allowed as documentation provided
that they are legally allowable by Fedora.

https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_of_Package_Mana gers

---

The MPI Guidelines have been clarified by adding this additional statement:

If the maintainer wishes for the environment module to load
automatically by use of a scriptlet in /etc/profile.d or by some other
mechanism, this MUST be done in a subpackage.

https://fedoraproject.org/wiki/Packaging:MPI

---

The Devel Packages section of the Packaging Guidelines has been
rewritten to be more comprehensive and clear:

https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

In addition, the ReviewGuidelines have been simplified to state simply
that Development files must be in a -devel package.

---

An exception was granted which permits the bundling of binutils
libraries, (most notably, libbfd, libcpu, libopcodes, and libdecnumber)
but only to packages which share the same upstream as binutils
(sourceware.org). This is because the libraries are developed by the
application authors as common functionality shared between several
applications. Being developers of both, they'll be intimately aware of
both issues that arise in the libraries and know how to port to newer
versions of the library as needed. Note that, at the moment, all of
these applications and libraries come from sourceware.org but not all of
them are used in binutils.

Packages leveraging this exception must add: Provides: bundled(binutils)
= %{snap}, where %{snap} is defined in the package as the date that the
binutils checkout was made, until the bundling issue is resolved (if ever).

This exception has been added to the list here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

The Packaging Guidelines section on Architecture Support has been
amended to clarify that all Fedora packages must successfully compile
and build into binary rpms on at least one supported primary
architecture, except where the package is useful only on a secondary
architecture (such as an architecture-specific boot utility, microcode
loader, or hardware configuration tool).

https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support

---

The "okjson" software has reluctantly been granted a bundling exception.
Packages which bundle okjson.rb must add: Provides: bundled(okjson),
until the bundling issue is resolved (if ever).

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

The section of the Packaging Guidelines covering /srv was amended to
include /opt and /usr/local. Specifically, the following sentence was added:

In addition, no Fedora package can have any files or directories
under /opt or /usr/local, as these directories are not permitted to
be used by Distributions in the FHS.

https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under _.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal

---

A new section has been added to the Fedora Packaging Guidelines
regarding Network Support. Specifically, if an application contains
native and stable support for both IPv4 and IPv6, and support for IPv6
does not negatively affect IPv4 then both must be enabled in the Fedora
package.

https://fedoraproject.org/wiki/Packaging:Guidelines#Networking_Support

---

As part of the /usrmove feature in Fedora 17, Fedora packages MUST NOT
place files or directories in the /bin, /sbin, /lib or /lib64
directories. Instead, the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64
directories must be used. Packages must assume that /bin, /sbin, /lib,
and /lib64 are symbolic links to the /usr/bin, /usr/sbin, /usr/lib, and
/usr/lib64 directories, respectively.

This is effective immediately for new packages, however, packagers are
not required to implement this change for distributions older than
Fedora 17.

https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout

---

A temporary bundling exception has been granted for libtdb_compat and
libccan, but only for samba4 packages. This exception will last until
F18 GA, or libtdb 2.x releases, whichever comes first.

Samba4 packages which bundle libtdb_compat or libccan must include
Provides: bundled(libtdb_compat) or Provides: bundled(libccan), until
the bundling issue(s) are resolved.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

A bundling exception has been granted for libreplace, but only if the
package in question shares the same upstream as samba. This is because
the libreplace library is developed by the application authors as common
functionality shared between several applications. Being developers of
both, they'll be intimately aware of both issues that arise in the
libraries and know how to port to newer versions of the library as needed.

Samba packages which bundle libreplace must include Provides:
bundled(libreplace), until the bundling issue is resolved (if ever).

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

The Pre-Release packages section was improved significantly, with the
intent of making it more clear through the use of specific examples in
tables.

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages

---

The Icon Tag in Desktop Files section in the Packaging Guidelines has
been amended to include a link to the scriptlets to refresh the icon cache.

https://fedoraproject.org/wiki/Packaging:Guidelines#Icon_tag_in_Desktop_Files

---

The Emacs Packaging Guidelines have been clarified and simplified, with
much unnecessary duplication removed.

https://fedoraproject.org/wiki/Packaging:Emacs

---

A new section containing tips and best practices for writing scriptlets
for Fedora packages has been added.

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Writing_scriptlets

---

The Guidelines section on Handling Locale Files has been updated to
reflect the additional functionality in %find_lang.

https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files

---

Ulrich Drepper's MD5 implementation, as found originally in gcc, was
added to the list of MD5 exception cases permitted for bundling exceptions.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

A link to the No Bundling Libraries page, which contains the steps
necessary to request a Bundling exception, has been added to the
"Bundling of multiple projects" section in the main Guidelines.

https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_of_multiple_projects

---

The section on File and Directory Ownership has been updated to reflect
the fact that while in most cases, it should not be necessary for
multiple packages to contain identical copies of the same file, if it is
necessary, multiple packages may contain identical copies of the same
file, as long as the following requirements are met:

* The packages sharing ownership of the identical files are built from a
single SRPM.

OR

* The packages sharing ownership of the identical files are not in a
dependency chain (e.g. if package A requires package B, they should not
both contain identical files, either A or B must own the common files,
but not both.)

In addition, identical files are defined as files which are always
identical in content, checksum, permissions, and location on the
filesystem in each package.

https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership

---

Announce Text:

A new section has been added to the PHP Guidelines, documenting the PHP
ZTS extension.

https://fedoraproject.org/wiki/Packaging:PHP#PHP_ZTS_extension

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Nick Clifton, Remi Collet, Frank R Dana Jr., Gilboa
Davara, Kevin Fenzi, Stephen Gallagher, Harald Hoyer, Jan Kratochvil,
Jussi Lehtola, Marcela Mašláňová, Panu Matilai, V*t Ondruch, Petr Pisar,
Michael Schwendt, Kay Sievers, Chris Tyler, Jonathan Underwood, Karel
Volný, Sami Wagiaalla, Christoph Wickert, and all of the members of the
FPC, for assisting in drafting, refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~tom
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-12-2012, 08:57 PM
Tom Callaway
 
Default Changes to the Packaging Guidelines

Here is the latest set of changes to the Fedora Packaging Guidelines:

---

A bundling exception for boost within Passenger was granted, due to the
intrusive nature of the forked changes, the efforts of the maintainer to
merge as many of them as possible into the upstream boost source tree,
and the visible efforts of the upstream to keep the bundled copy of
boost in sync with the current boost releases.

The package must also include a Requires: bundled(boost) = $VERSION
where $VERSION is the boost version being bundled.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_ex ceptions

---

Packages which have SysV initscripts that contain 'non-standard service
commands' (commands besides start, stop, reload, restart, or
try-restart) must convert those commands into standalone helper scripts.
Systemd does not support non-standard unit commands.

https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files

---

A section was added to the systemd Packaging Guidelines page with a link
to the Tmpfiles.d Packaging Guidelines page, since systemd uses Tmpfiles.d.

https://fedoraproject.org/wiki/Packaging:Systemd#Tmpfiles.d

---

The Ruby Packaging Guidelines were almost completely rewritten. If you
maintain ruby packages in Fedora, we advise that you review the new
guidelines.

https://fedoraproject.org/wiki/Packaging:Ruby

---

An informational note about Software Collection macros in Fedora
Packages was added:

https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros

---

The guidelines relating to PIE and Hardened Packages were updated. Now,
if your package meets the following critera you MUST enable the PIE
compiler flags:

* Your package is long running. This means it's likely to be started and
keep running until the machine is rebooted, not start on demand and quit
on idle.

* Your package has suid binaries, or binaries with capabilities.

* Your package runs as root.

https://fedoraproject.org/wiki/Packaging:Guidelines#PIE

---

Rules involving appropriate scripting within Fedora Package spec files
were added to the Guidelines:

https://fedoraproject.org/wiki/Packaging:Guidelines#Scripting_inside_of_spec_file s

---

The section in the systemd guidelines covering EnvironmentFiles and
support for /etc/sysconfig files was revised for clarification.

https://fedoraproject.org/wiki/Packaging:Systemd#EnvironmentFiles_and_support_for _.2Fetc.2Fsysconfig_files

---

The Ada Packaging Guidelines were updated for new rules on packaging
source files and updated macros.

https://fedoraproject.org/wiki/Packaging:Ada

---

The section of the Packaging Guidelines describing the "bootstrapping"
binary exception was amended for clarification:

https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions

---

The section of the Packaging Guidelines describing Duplication of system
libraries was amended to clarify the exceptions for Javascript and
parallel stacks.

https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_librari es

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Kevin Fenzi, Bohuslav Kabrda, Brett Lentz, Marcela
Mašláňová, Bill Nottingham, V*t Ondruch, Mamoru Tasaka, and all of the
members of the FPC, for assisting in drafting, refining, and passing
these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~tom
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-12-2012, 09:19 PM
Tom Lane
 
Default Changes to the Packaging Guidelines

Tom Callaway <tcallawa@redhat.com> writes:
> Here is the latest set of changes to the Fedora Packaging Guidelines:
> ---
> Packages which have SysV initscripts that contain 'non-standard service
> commands' (commands besides start, stop, reload, restart, or
> try-restart) must convert those commands into standalone helper scripts.
> Systemd does not support non-standard unit commands.

I was a bit surprised to read this, because in recent versions systemd's
service command supports nonstandard verbs just fine; it'll pass an
unrecognized verb through to the initscript, if there is one. Is that
functionality going to be removed again?

Background: after having done what the above text directs me to,
I had gotten beaten up over the fact that "service postgresql initdb"
no longer worked, and hence reinstituted a stub initscript that only
handles the nonstandard actions of the old one. Which works fine, or
at least it did as of last month when I last tried it. So now I'm in
violation of the guidelines for having tried to keep my users happy,
and I'm not happy, especially since the stated rationale is a falsehood.

regards, tom lane
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-13-2012, 02:58 PM
Tom Lane
 
Default Changes to the Packaging Guidelines

Tom Callaway <tcallawa@redhat.com> writes:
> On 04/12/2012 05:19 PM, Tom Lane wrote:
>> Background: after having done what the above text directs me to,
>> I had gotten beaten up over the fact that "service postgresql initdb"
>> no longer worked, and hence reinstituted a stub initscript that only
>> handles the nonstandard actions of the old one. Which works fine, or
>> at least it did as of last month when I last tried it. So now I'm in
>> violation of the guidelines for having tried to keep my users happy,
>> and I'm not happy, especially since the stated rationale is a falsehood.

> systemd doesn't understand non-standard commands. "service" passes
> through, but that was determined to be confusing.

> If you want to make an initscript stub, you can, but it needs to be in a
> separate subpackage, per the guidelines. We're trying not to have unit
> files and sysv initscripts in the same package, whether they're stubs or
> not.

Well, if it has to be in a new subpackage then I'm just going to drop it.
The entire rationale for the stub was to make things "just work" for
people who don't read the release notes. If it requires they install
a new subpackage they never heard of before, that would still require
reading the release notes, so it's not helpful. (Unless I was to make
postgresql-server require the new subpackage, but I'm sure that would
not be considered good packaging practice either ...)

regards, tom lane
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-13-2012, 03:47 PM
Tom Lane
 
Default Changes to the Packaging Guidelines

Bill Nottingham <notting@redhat.com> writes:
> Tom Callaway (tcallawa@redhat.com) said:
>> I understand what you're saying here. I think dropping the stub is the
>> best path forward here, along with making sure that the new "helper"
>> commands are in the release notes.

> My concern would be that we should likely standardize on a format/invocation
> for new helper commands wherever possible. Do we have existing ones outside
> of iptables at this point?

Postgresql has been using a "postgresql-setup" helper script since F16,
and the F16 release notes explain that instead of "service postgresql
foo" you should do "postgresql-setup foo". The two nonstandard actions
provided this way are "initdb" and "upgrade", both of which are for
database setup, hence the choice of script name. That choice probably
doesn't fit for other uses of nonstandard actions, though.

regards, tom lane
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-14-2012, 07:32 PM
Jeroen van Meeuwen
 
Default Changes to the Packaging Guidelines

On Thursday, April 12, 2012 04:57:29 PM Tom Callaway wrote:
> A bundling exception for boost within Passenger was granted, due to the
> intrusive nature of the forked changes, the efforts of the maintainer to
> merge as many of them as possible into the upstream boost source tree,
> and the visible efforts of the upstream to keep the bundled copy of
> boost in sync with the current boost releases.
>
> The package must also include a Requires: bundled(boost) = $VERSION
> where $VERSION is the boost version being bundled.
>
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_grant
> ed_exceptions
>

While I appreciate the work Brett Lentz has been putting in upstream, why does
this package have to be taken away from me?

I'm already facing a "thanks for your work but no thanks"[1].

I respectfully request Uncle Shadowman *not* be forcefully made the owner of
the package, and the reporter of the review request be granted ownership.

Kind regards,

Jeroen van Meeuwen

[1] https://bugzilla.redhat.com/show_bug.cgi?id=470696#c114

--
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-14-2012, 07:32 PM
Jeroen van Meeuwen
 
Default Changes to the Packaging Guidelines

On Thursday, April 12, 2012 04:57:29 PM Tom Callaway wrote:
> A bundling exception for boost within Passenger was granted, due to the
> intrusive nature of the forked changes, the efforts of the maintainer to
> merge as many of them as possible into the upstream boost source tree,
> and the visible efforts of the upstream to keep the bundled copy of
> boost in sync with the current boost releases.
>
> The package must also include a Requires: bundled(boost) = $VERSION
> where $VERSION is the boost version being bundled.
>
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_grant
> ed_exceptions
>

While I appreciate the work Brett Lentz has been putting in upstream, why does
this package have to be taken away from me?

I'm already facing a "thanks for your work but no thanks"[1].

I respectfully request Uncle Shadowman *not* be forcefully made the owner of
the package, and the reporter of the review request be granted ownership.

Kind regards,

Jeroen van Meeuwen

[1] https://bugzilla.redhat.com/show_bug.cgi?id=470696#c114

--
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 01:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org