Replacing grubby with grub2-mkconfig in kernel install process
by Ben Rosser
In Fedora 17, when you install grub2 and generate a fresh config file, that
config is produced by grub2-mkconfig. However, when you install a kernel
update, the kernel's entry is added to the grub2 boot menu by grubby.
This produces messy grub boot menus. The entries added by grubby read
something like "Fedora (%kernel_version)". grub2-mkconfig, on the other
hand, only displays one "Fedora Linux" boot option and places the other
kernels and their recovery mode environments in a submenu called "Advanced
Options".
Now, I never really liked seeing three kernels on the main menu to begin
with, and I think the new grub2 approach of hiding the other kernels in a
submenu is nice. But then as soon as I start installing updates the submenu
becomes incomplete (and eventually useless, as the new kernels won't be
listed there) and the grubby options take over the menu.
It seems to me that we should make the boot menu more consistent somehow. I
feel like the simplest solution is just to run grub2-mkconfig at every
kernel update, and stop using grubby for this. Then everything would look
consistent- the "Fedora Linux" boot option would have the latest kernel
and all kernels would always be listed under the submenu. (As far as I
know, this would just be a change to the kernel specfile, right?).
Alternatively, if Fedora does want boot menus that look like the ones
produced by grubby, then the grub2 default configuration should be changed
to reflect that, so the boot menu will always look consistent.
I should add that I did see a reference to possibly replacing grubby with a
"grub-updconf" (though I'm not aware of such a program) on the wiki-
http://fedoraproject.org/wiki/Features/Grub2 - so possibly there are
already plans for this?
Ben
11 years, 9 months
PyXML package - deprecate it?
by Roman Rakus
Hi all,
looks like PyXML package is deprecated since python itself provides xml
mechanisms.
When you look deeper,
python's xml provides:
"dom", "parsers", "sax", "etree"
and PyXML provides:
'dom', 'marshal', 'parsers', 'sax', 'schema', 'utils', 'xpath', 'xslt'
So, PyXML duplicates dom, parsers and sax (and looks like python's is in
better shape). Is any package using marshall, schema or any other not in
python itself?
Deprecate PyXML or just remove duplicated parts?
RR
11 years, 9 months
packaging puppet modules
by Ken Dreyer
I was looking briefly into packaging some Puppet modules, and I was
curious if anyone else has gone down this road.
http://forge.puppetlabs.com/
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.
- Ken
11 years, 9 months
Liberation 2.0 font development plan based on croscore fonts.
by pravin.d.s＠gmail.com
Hi All,
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
same vendor.
Plan:
- Use base of croscore fonts and apply enhancements available in
liberation and call new entity liberation 2.0
Advantage:
1. Liberation license issues will get resolved
2. Liberation user community will get enhanced fonts. i.e. more language
coverage.
Need help from legal for doing licensing stuff, dunno how we can crack
licensing of Liberation SansNarrow.
Regards,
Pravin Satpute
11 years, 9 months
Fedora 17 ARM GA Release
by Paul Whalen
The Fedora ARM team is pleased to announce that the Fedora 17 GA release
for ARM is now available for download from:
http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images/
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
hardware images:
http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_GA
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,
Paul
11 years, 9 months
gutenprint update in rawhide, soname bump
by Jiri Popelka
Hi
I built gutenprint 5.2.8 in rawhide.
This introduces a soname bump (libgutenprint.so.2 to .3).
These packages (owners CCed) need rebuilding:
cinepaint
photoprint
--
Jiri
11 years, 9 months
Pidgin 2.10.4
by Heiko Adams
Hi there,
can anyone start building pidgin 2.10.4, which is a security update
since the package maintainer seems to be unresponsive?
--
Grüße aus Coburg
Ulrike, Leon Jan und Heiko
11 years, 9 months
upcoming libdb/db4/compat-db reorganization
by Jindrich Novy
Hi all,
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
well.
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
libdb-5.3 ...)
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!
Thanks,
Jindrich
--
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
11 years, 9 months
default DNS caching name server on Fedora ?
by Simo Sorce
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
up/down.
Discuss.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
11 years, 9 months
