I was looking briefly into packaging some Puppet modules, and I was
curious if anyone else has gone down this road.
I'm mainly interested in the Puppetlabs modules,
http://forge.puppetlabs.com/users/puppetlabs , since I imagine these
will have the widest user base, although I'm not an expert on Puppet
Module culture :)
Does anyone have suggestions for package naming conventions? It looks
like the upstream modules include the creators' names as part of the
package names, which strikes me as a little verbose from the
perspective of Fedora packaging.
Most of you aware regarding liberation license problem we are facing from
long time. Looks like time came when we can get rid of it.
Google has recently released google-croscore fonts.
- These are from same vendor ascendar with OFL license and more glyph
coverage than existing liberation.
- Existing shape in liberation and same as croscore since from the
- Use base of croscore fonts and apply enhancements available in
liberation and call new entity liberation 2.0
1. Liberation license issues will get resolved
2. Liberation user community will get enhanced fonts. i.e. more language
Need help from legal for doing licensing stuff, dunno how we can crack
licensing of Liberation SansNarrow.
The Fedora ARM team is pleased to announce that the Fedora 17 GA release
for ARM is now available for download from:
The GA release includes prebuilt images for Versatile Express (QEMU), Trimslice,
Beagleboard xM, Pandaboard, Kirkwood Plugs, Highbank and iMX based hardware platforms.
Please visit the announcement page for additional information and links to specific
We invite you to download the Fedora 17 GA release and provide your valuable input
to the Fedora ARM team. Please join us on the IRC in #fedora-arm on Freenode or
send feedback and comments to the ARM mailing list.
On behalf of the Fedora ARM team,
it seems to be the right time to do an unification/reorganization of
Oracle (Berkeley) DB packages in rawhide. The current situation is that
there are three of them:
compat-db - shipping old libdbs for compatibility (4.5,4.6 and 4.7)
db4 - shipping latest 4.x libdb series (4.8)
libdb - shipping latest libdb release (5.3)
What I'm planning to do is getting rid of db4 package. But before that
I want to clean-up compat-db for a bit.
After fiddling a bit with repoquery nothing seems to be dependent on
libdb-4.5 so if there are no objections I want to remove it.
There was only one package dependent on 4.6 (squidGuard) because it
had compilation problems with 4.7. This package is now built against
5.3 with no problem so 4.6 could go away from compat-db as well.
Only one package (pam_abl-0:0.2.3-8.fc12) was dependent on 4.7
in Fedora 17 but it's already rebuilt in rawhide so 4.7 can go away as
So the plan is:
1) remove 4.5, 4.6 and 4.7 from compat-db
2) put 4.8 to compat-db
3) make db4 a dead package
(db4 package name is not very descriptive any more as we have
The reason I'm sending this to fedora-devel is that I'm unable to
reveal dlopen() or similar deps in packages so if your package
requires older libdb I plan to remove and can not be rebuilt against
newer libdb then please speak up!
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá,
kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl.
--- Jan Werich
Ok, I guess this topic has been brought up before, but I think some
things changed recently that would warrant seriously considering adding
a default caching name server in fedora installs.
There are at least 2 situations where it is needed, and they are common
or will be common enough.
The 2 use cases for which a properly configurable and dynamically
changeable caching DNA name server would be really useful are:
- DNSSEC verification
- Clients using VPNs into private networks.
The first case is already in the works, and the reason it needs a
caching DNS name server is the complexity of dealing with DNSSEC
verification. I won't spend time on that except for saying this effort
should be part of a unified solution.
The second case is what is really hurting me.
I have my own DNS server at home that resolves address only for my
private network, and forwards any other request.
When I connect to my employer VPN however I need to use their DNS server
to resolve their internal machines, the same happens to pretty much any
other VPN service I have used. Also I do not need to route all DNS
traffic in the VPN for all web sites, mostly for performance reasons,
but also for privacy reasons.
This could be easily solved if we have a caching DNS server that can be
dynamically change to forward DNS requests to the proper DNS server only
for the private domains they provide.
A good name caching server would forward all .redhat.com DNs request top
the DNS addresses provided by the VPN connection, all my .home addresses
to my local DNS server (provided by dhcp) and perhaps all other
addresses to a configurable 'default DNS server'.
Of course for this to work properly we need some level of integration
between Network Manager and the DNS caching server so that the dynamic
configurations can be pushed in/out when the related networks come
Simo Sorce * Red Hat, Inc * New York
We have assorted init scripts that have historically defined custom actions.
Given that this is an unbounded set, it is impossible to handle them
natively in systemd. However, they're usually part of administrators muscle
Better late than never (and thanks to Michal Schmidt), I've added support to
/sbin/service for running legacy actions if specified.
HOW TO IMPLEMENT IN YOUR PACKAGE
For each legacy option (such as "xyzzy") supported by your init script (such
as "frobozz"), package an executable script named:
If this file exists and is executable, then when an administrator runs:
/sbin/service frobozz xyzzy
this file will be executed, to do whatever. This file can be a symlink
somewhere else, or even a compiled executable if you really desire.
1) A legacy action of this sort should print to stderr the preferred way to
accomplish the task, if one is supported.
2) Don't package a legacy action for new scripts or actions that were not
supported by the prior init script; this is intended for compatibility with
existing scripts and/or administrator brains.
3) Don't package
or we will hurt you. (And /sbin/service will likely be changed to ignore
these actions if this becomes a problem.)
WHEN THIS WILL LAND
It's in initscripts git now, will package shortly for F18/F17/F16.