Exchanging reviews.
by Peter Lemenkov
Hello.
I've got a couple of packages to review - both builds fine in Koji
(and one passes all the tests - other doesn't have tests
unfortunately):
* https://bugzilla.redhat.com/823105 - erlang-riak_control - Admin UI for Riak
* https://bugzilla.redhat.com/841766 - erlang-riak_search - Full-text
search engine based on Riak
if someone has stalled review requests then I'm willing to start
reviewing them in exchange for these ones.
--
With best regards, Peter Lemenkov.
11 years, 8 months
retiring Pimlico suite of apps (contacts / dates / tasks)
by Peter Robinson
Hi All,
The pimlico suite of apps originally designed for phones but useful
standalone have been dead upstream for quite some time and with the
restructuring of evolution are often breaking. Upstream gnome now has
standalone Contacts and Calendar apps with a Tasks app planned and
there's others that also substitute such as GTG.
So unless anyone explicitly wants to maintain them I'll kill them off
in the next couple of days. If you're interested get in touch.
Peter
11 years, 8 months
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, 8 months
Re: [Fontconfig] Heads up: Droid fonts update in Rawhide
by Nicolas Mailhot
Le Jeu 26 juillet 2012 09:32, Akira TAGOH a écrit :
> Well, I see what Nicolas wants to do here. since Japanese characters
> on Unicode's CJK Unified Ideographs is a subset of Chinese characters,
> I think he wanted to avoid picking Droid Sans Japanese up for Chinese
> anyway.
Ideally, I'd like the target="scan" lang-specific rules to generate a form
of simulated locl table. I know the current rules I use don't do that, but
I guess they are a sort of RFE on my part :)
I think Droid is a good showcase of the dead-end
selecting-lang-by-font-name is : if we don't hide the various
lang-specific droid names to the user, it only takes two or three
droid-like families to make font selection totally unusable in most apps.
Best regards,
--
Nicolas Mailhot
11 years, 8 months
[ACTION REQUIRED v3] Retiring packages for F-18
by Bill Nottingham
Before we branch for Fedora 18, as is custom, we will block currently
orphaned packages and packages that have failed to build since Fedora 16.
The following packages are currently orphaned, or fail to build. If
you have a need for one of these packages, please pick them up.
If no one claims any of these packages, they will be blocked before
we branch for Fedora 18. That is currently scheduled to happen on
or around August 7th.
Note that if you're receiving this mail directly, it's because you are
a co-maintainer of one of these packages. Please work with your
comaintainers to take up maintenance.
Package archmage (orphan)
Package boolstuff (orphan)
Package cmucl (orphan)
comaintained by: green
Package drupal6-video (orphan)
Package eclipse-m2m-qvtoml (fails to build)
Package fillmore-lombard (fails to build)
comaintained by: salimma
Package gant (fails to build)
Package genus2reduction (orphan)
Package globalplatform (orphan)
Package gpshell (orphan)
Package gtkmm-utils (orphan)
Package gtkpod (orphan)
Package hamster-applet (orphan)
Package hartke-aurulent-sans-fonts (orphan)
Package healpix (fails to build)
Package json (orphan)
Package k12linux-quick-start-guide (orphan)
Package kadu (fails to build)
comaintained by: gajownik radekl
Package libcrystalhd (fails to build)
comaintained by: kwizart
Package libgtkhotkey (orphan)
Package libhid (fails to build)
Package libqttracker (fails to build)
comaintained by: jreznik
Package libsoup22 (orphan)
Package natus (fails to build)
Package ncpfs (orphan)
Package ntfs-config (fails to build)
Package nvi (orphan)
Package perl-Nagios-Plugin-Beanstalk (orphan)
Package pfqueue (orphan)
Package pino (fails to build)
Package polyester (orphan)
Package polyester3 (orphan)
Package python-batchhttp (orphan)
Package python-chm (orphan)
Package python-pywt (fails to build)
Package python-remoteobjects (orphan)
Package python-typepad (orphan)
Package qtparted (fails to build)
Package selenium-remote-control (fails to build)
Package torque (orphan)
Package typepad-motion (orphan)
Package upstart (orphan)
Package winwrangler (orphan)
List of deps left behind by packages which are orphaned or fail to build:
Removing: healpix
skyviewer requires chealpix-devel = 2.13a-2.fc14
skyviewer requires libchealpix.so
Removing: libgtkhotkey
synapse requires libgtkhotkey.so.1
Removing: libsoup22
libopensync-plugin-syncml requires libsoup22-devel = 2.2.105-9.fc15
libsyncml requires libsoup-2.2.so.8
libsyncml requires libsoup22-devel = 2.2.105-9.fc15
Removing: ncpfs
hydra requires libncp.so.2.3
hydra requires ncpfs-devel = 2.2.6-17.fc18
hydra requires libncp.so.2.3(NCPFS.2.2.0.17)
hydra requires libncp.so.2.3(NCPFS_2.2.0.19)
hydra requires libncp.so.2.3(NCPFS_2.2.1)
medusa requires libncp.so.2.3
medusa requires ncpfs-devel = 2.2.6-17.fc18
medusa requires libncp.so.2.3(NCPFS.2.2.0.17)
medusa requires libncp.so.2.3(NCPFS_2.2.0.19)
medusa requires libncp.so.2.3(NCPFS_2.2.1)
Removing: python-batchhttp
django-typepad requires python-batchhttp = 1.1-5.fc18
Removing: python-chm
chm2pdf requires python-chm = 0.8.4-12.fc18
Removing: python-remoteobjects
django-typepad requires python-remoteobjects = 1.1-5.fc18
Removing: python-typepad
django-typepad requires python-typepad = 1.1.2-5.fc18
Removing: selenium-remote-control
perl-Alien-SeleniumRC requires selenium-server = 1.0.3-8.20100318svn.fc15
Removing: torque
pbstop requires torque-client = 3.0.4-1.fc17
pdsh requires torque-devel = 3.0.4-1.fc17
pdsh-mod-torque requires torque = 3.0.4-1.fc17
pdsh-mod-torque requires libtorque.so.2
perl-PBS requires libtorque.so.2
perl-PBS requires libtorque-devel = 3.0.4-1.fc17
python-pbs requires torque-devel = 3.0.4-1.fc17
python-pbs requires libtorque.so.2
python3-pbs requires libtorque.so.2
Removing: upstart
clamav-milter-upstart requires /sbin/initctl
clamav-scanner-upstart requires /sbin/initctl
dhcp-forwarder-upstart requires /sbin/initctl
ip-sentinel-upstart requires /sbin/initctl
milter-greylist-upstart requires /sbin/initctl
tor-upstart requires /sbin/initctl
The script that generated this page can be found at
https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py
There you can also report bugs and RFEs.
11 years, 9 months
F17 updates broke anaconda PNG image handling
by Jos Vos
Hi,
While an anaconda/systemd problem is being worked on (bug #841822),
now my next problem when making new F17 spins including all updates:
anaconda can't display PNG images anymore.
For all images it tries to open (and all these images do exist),
it gives an error like:
17:47:31,122 ERR anaconda: unable to read anaconda_header.png: Couldn't recognize the image file format for file '/usr/share/anaconda/pixmaps/anaconda_header.png'
Looking at the anaconda code, this error seems to be generated by
getPixbuf() in /usr/lib64/python2.7/site-packages/pyanaconda/gui.py,
when it does a gtk.gdk.pixbuf_new_from_file(fn).
Any suggestion on what could be causing this?
Thx,
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
11 years, 9 months
A preupgrade adventure - F16 to F17
by Martin Langhoff
Just an informational anecdote. My main dev machine is a vanilla
Lenovo X220 laptop, running an up-to-date F16. At OLPC, we are damned
close to *shipping* a F17-based distro on our XO laptops, so I thought
it'd be good to update.
Worried about /usr move, I decided to DTRT: use preupgrade.
First, preupgrade completely hides grubby errors, and tells you
everthing's peachy. This cannot be a feature. I managed to hit a few
grubby errors, and without the debug output from preupgrade-cli
showing the grubby command it's running, I'd still be scratching my
head...
So grub configs were not being updated, for two reasons
- My machine does not have /boot/grub/grub.cfg, it has grub.conf
instead, so I hit BZ#841976 . Unsure why these conffiles are changing
names, this was a fresh F16 install back when F16 was new.
- Added the missing grub.cfg, grubby segfaults (BZ#841979). Ummpf!
- The preupgrade wikipage helpfully provides instructions to edit
grub.conf by hand. Completely wrong instructions. You don't want the
/boot prefix there. You don't want "savedefault". You probably want to
ensure you see the menu.
I am no expert on what params the preupgrade initrd _really_ needs,
but things did not move forward until I fixed it up and added the
params that preupgrade was giving to the failing grubby.
- And there I hit BZ#813973 - preupgrade (anaconda) garbles the URL
so you only get 404s.
The adventure continues, but at thistime I am under the impression
that preupgrade gets far less testing and polish than yum upgrades.
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
11 years, 9 months