GPG verification in SPECs
by Till Maas
Hi,
upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at
https://build.opensuse.org/package/show/Base:System/gpg-offline
They allow to use a keyring and detached signature as additional source
in SPECs to get both verified. Since gpg-offline's upstream is willing
to create a proper release to allow easy packaging for Fedora, I wonder
if I will find any obstacles when I package it. The packaging guidelines
allow packaging RPM macros, therefore this should be fine.
Also I am interested whether there are better options available.
Regards
Till
10 years, 6 months
bodhi client question
by Joachim Backes
Dear bodhi/koji specialists,
perhaps, this is a dumb question:
sometimes after having filed a BZ, I get some email like
-----------------------------------------------------------
Package xxxxx-4.1.0.0-4.beta1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xxxxx-4.1.0.0-4.beta1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-9971/xxxxx-4.1.0.0-4....
------------------------------------------------------------
*My question:* if xxxxx consists of a lot of packages, and I'm only
needing some few of them (libreoffice is a good example), how then can I
automatically download only those packages installed on my site?
The usage of "bodhi -D xxxxx....." will download *all* and not only the
locally installed pkgs.
Kind regards
Joachim Backes
--
Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.4-302.fc19.x86_64
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
https://www-user.rhrk.uni-kl.de/~backes
10 years, 6 months
Non-responsive maintainer: Dodji Seketeli
by Darryl L. Pierce
BZ#848774
This bug is nearly a year old, requesting that package offlineimap be
upgraded to what was then the latest release (6.5.4, now it is
6.5.5-rc2). There has been no response from the maintainer.
I posted a bug comment on 01 July asking for something from the package
maintainer and received no word.
I don't want to take over the package, but would like either the primary
or else a co-maintainer to upgrade the package as it has bugs that have
been fixed since 6.5.2 (the currently packaged release).
--
Darryl L. Pierce <mcpierce(a)gmail.com>
http://mcpierce.multiply.com/
"What do you care what people think, Mr. Feynman?"
10 years, 7 months
Rawhide tree now includes install images
by Kevin Fenzi
Greetings.
After consulting with various teams, release engineering has re-enabled
rawhide composes to create install images again. These images were
dropped as part of the 'no frozen rawhide' proposal several years ago.
This allows users to use the latest boot.iso or pxe images to install
rawhide instances or point to rawhide as a install-able tree.
kevin
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 7 months
rpmbuild --buildarch equivalent?
by Juerg Haefliger
Hi,
A long time ago rpmbuild used to have an option --buildarch to
override the arch detection. What is its equivalent nowadays? Sorry,
couldn't figure it out so far.
Thanks
...Juerg
10 years, 7 months
F20 System Wide Change: Web Assets
by Jaroslav Reznik
= Proposed System Wide Change: Web Assets =
https://fedoraproject.org/wiki/Changes/Web_Assets
Change owner(s): T.C. Hollingsworth <tchollingsworth(a)gmail.com>
Traditionally, Fedora has been pushing bits from its various servers to
people's browsers in an ad-hoc fashion, and issues surrounding JavaScript have
been swept under the rug. This change proposal provides a simple framework for
shipping static web content and a way forward to treat JavaScript more closely
to other code in the distribution.
== Detailed description ==
A standard directory (/usr/share/assets) for static bits that are intended to
be delivered to web browsers, such as CSS Frameworks, UI libraries, etc. will
be introduced. HTTP daemons in the distribution should make this directory
available publicly as /assets.
Additionally, a standard directory (/usr/share/javascript) for JavaScript
code, which may be used in browsers or server-side by applications such as
nodejs or rubygem-execjs will also be introduced.
Finally, new packaging guidelines [1] will provide instructions for making
proper use of these new directories.
== Scope ==
=== The web-assets RPM ===
A web-assets package will be introduced. A preliminary SRPM is available
here. [2]
The web-assets-filesystem subpackage will be provided, which contains the
following directories:
* /usr/share/assets
* /usr/share/javascript
Additionally the following symlinks will be provided:
* /usr/share/javascript -> /usr/share/assets/javascript
* /usr/share/fonts -> /usr/share/assets/fonts (so any Fedora font package can
be used as a web font)
A web-assets-devel subpackage will be provided that provides macros like
%{_assetdir} and other conveniences described in the proposed guidelines.
A web-assets-httpd package will make the web assets directory available at
http://server/assets/.
=== redhat-rpm-config ===
We can trivially [3] automatically version the virtual Provides required by
the static inclusion section [4] of the new guidelines, but the macro would
need to live in redhat-rpm-config to work right in koji without conditional
inclusion, which results in terrible syntax like %{?js_includes: %js_includes
foopackage} due to RPM's restrictions regarding macros that accept arguments.
=== httpd ===
httpd may want to add Requires: web-assets-httpd (or ship the configuration
itself, though it was suggested that it would be better seperate [5]) to make
the assets directory available unconditionally by default. This will simplify
packaging. (We really would prefer that JavaScript libraries not depend on
httpd, as they could be used by Node.js or Ruby.)
=== JavaScript packagers ===
Some longstanding reviews (like jquery) can now be completed with clear
guidelines, paving the way for web applications to start being migrating to
using proper dependencies instead of bundling.
All web applications currently in the distribution should be examined for
bundled JavaScript, which should be packaged separately.
=== Web application packagers ===
Web applications can migrate to new JavaScript/Web Asset packages as they
become available.
There are a lot of potentially affected packages. There's no hope of fixing
them all in one release cycle, and even the dependency chain for jQuery, a big
ticket package, could take several months to get reviewed and imported.
Therefore, this Change proposal just seeks FESCo/FPC approval for a start to
unravelling this madness. This will be a long transition, and will probably
make the systemd transition look like a day in the park.
=== Foreign languages ===
Many foreign languages support JavaScript, like Ruby via rubygem-execjs or
Java via rhino. Several of them already depend on existing JavaScript library
packages (virtually all node.js-related ones) and will need to be modified to
conform to the new locations specified by the guidelines.
=== Node.js ===
Several node packages ship JavaScript for the browser and will need to be
modified to conform to the new guidelines.
=== FPC ===
The Fedora Packaging Committee will need to consider and approve drafts
pertaining to Web Assets [6] and JavaScript [7].
=== FPC/FESCo ===
FPC/FESCo may or may not want to consider a firm date for sunsetting the
bundled JavaScript exception and requiring all new packages to meet the new
guidelines.
[1] https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/Web_Assets
[2] http://patches.fedorapeople.org/web-assets/web-assets-1-1.fc19.src.rpm
[3] https://gist.github.com/tchollingsworth/6007074#file-macros-web-assets-L4...
[4] User:Patches/PackagingDrafts/Web_Assets##Static_Inclusion_of_Libraries
[5] https://lists.fedoraproject.org/pipermail/packaging/2013-July/009313.html
[6] User:Patches/PackagingDrafts/Web Assets
[7] User:Patches/PackagingDrafts/JavaScript
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 8 months
F20 Self Contained Change: Apache OpenOffice
by Jaroslav Reznik
= Proposed Self Contained Change: Apache OpenOffice =
https://fedoraproject.org/wiki/Changes/ApacheOpenOffice
Change owner(s): Andrea Pescetti <pescetti(a)apache.org>
Add Apache OpenOffice [1], the free productivity suite, to Fedora.
== Detailed description ==
Apache OpenOffice (formerly OpenOffice.org) is an extremely popular free and open-
source office software suite.
Donated by Oracle to the Apache Software Foundation in 2011, it is now
developed and supported by a thriving community; it graduated from the Apache
Incubator in October 2012 and it is now an Apache Top-Level Project.
Apache OpenOffice 4.0, due in the last decade of July 2013, is a major update.
The two new versions (3.4.0 and 3.4.1) released in 2012 under the Apache
guidance totalled 60 million downloads so far, not counting mirrors.
To be clear, this proposal is about merely adding Apache OpenOffice: it doesn't
affect existing office suites included in Fedora and it doesn't require that
Apache OpenOffice is made the default office suite in Fedora.
== Scope ==
Proposal owners:
Packaging is the main issue here. The default OpenOffice build process produces
RPM packages, but there are major changes to be done to obtain a set of RPM
packages and matching SRPMs suitable for inclusion in Fedora.
Version 4.0 produces packages based on the current product name: this allows
to avoid name clashes with older versions of OpenOffice.
The OpenOffice sources have been updated to allow a clean build with the default
tools shipped with Fedora 19.
The change is isolated, except some possible packaging overlap with LibreOffice,
see below.
Other developers:
This issue was widely discussed for Fedora 19 too (the feature was then
postponed to Fedora 20 since OpenOffice 4.0 was rescheduled to be released after
Fedora 19).
The /usr/bin/soffice and /usr/bin/unopkg executables/symlinks are still a
problem since (in the Fedora packages) they would conflict between LibreOffice
and Apache OpenOffice: it is recommended to fix it in the LibreOffice packages too.
As discussed on the mailing lists, applications that programmatically spawn an
OpenOffice/LibreOffice process may benefit of the "soffice" symlink when they need to
locate an OpenOffice/LibreOffice installation. On the other hand, the current
upstream LibreOffice packages do not rely on a "soffice" symlink.
Anyway, some coordination will be needed, as already envisaged by FESCo for
Fedora 19, to ensure a smooth user experience. The impact on the system as a
whole is believed to be limited enough for this change not to be considered a
"system-wide change".
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
[1] http://openoffice.org/
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 8 months
F20 Self Contained Change: Ruby on Rails 4.0
by Jaroslav Reznik
= Proposed Self Contained Change: Ruby on Rails 4.0 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0
Change owner(s): Vít Ondruch <vondruch(a)redhat.com>, Josef Stříbný
<jstribny(a)redhat.com>, ruby-sig(a)lists.fedoraproject.org
Ruby on Rails 4.0 is the latest version of well know web framework written in
Ruby.
== Detailed description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with
it. Therefore the whole Ruby on Rails stack should be updated from 3.2 in
Fedora 19 to 4.0 (latest version) in Fedora 20. This will ensure that all the
Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on
Rails.
== Scope ==
Proposal owners:
* The whole Rails stack has to be updated
* New additional gems will have to be packaged
* Some dependencies of the Rails stack will need update
For the list, see [1]
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
[1] https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0#Scope
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 8 months
Self Introduction
by Peter Hanecak
Hello,
I've been asked by Luya Tshimbalanga <luya(a)fedoraproject.org> to
maintain the gimp-separate+ package for official Fedora project so that
it can be included in Design Suite Livemedia.
Having read some introductory information, I would now like to introduce
myself with few short facts:
- I'm using Linux (at start Red Hat, later Fedora) since roughly 1997.
- To ease the maintenance of my systems, I'm creating RPM packages "just
for myself" since 1998 - this one seems to be the oldest one:
http://hany.sk/~hany/RPM/doors1/jserv-doc-0.9.11-2.i386.html
- I'm supporter of Free and Open Source Software and small-scale
contributor, more recently broadening it with participation in Open Data
initiatives.
- Now, Luya's invite finally pushed me to come closer to the Fedora project.
- I'm earning a living by doing software development and related
consulting work.
- I'm married with two children.
I'm looking forward for future cooperation. And I would also like to
thank in advance to all which will help me to get through initial stages
of first package submission
(https://bugzilla.redhat.com/show_bug.cgi?id=913289).
Sincerely
Peter
--
Peter Hanecak <hany(a)hany.sk>
http://hany.sk/~hany/
GnuPG: http://hany.sk/~hany/gpg/E4C349E3.txt
10 years, 8 months