if multilline baseurl is in yum repo files it's not working
I've just merged this: commit b55044c8862036782d14b41e5c77b32c2fea8823 Author: Richard Hughes <richard> Date: Sun Sep 18 16:07:23 2011 +0100 Support non-standard multiline repo files Yum supports multiline repo files in the format: [Fedora] name=Fedora baseurl=http://download1.fedoraproject.org/ http://download2.fedoraproject.org/ We need to parse the lines manually and make this acceptable to the GKeyFile parser. Resolves https://bugzilla.redhat.com/show_bug.cgi?id=739393 Can you please try git master and tell me if this fixes the bug please. Thanks.
still not working:-(
Can you attach the output of "zif repo-list -v" please with zif either from git master or from one of my rebuilt srpm please. Thanks.
i already send you all of my repo file so you can look into them. zif repo-list -v TI:10:41:56 using config /etc/zif/zif.conf TI:10:41:56 loading config file /etc/zif/zif.conf TI:10:41:56 override file does not exist Enabling offline mode as user unprivileged. Action: Getting repo list Action: Loading repository Percentage: 5 Percentage: 10 TI:10:41:56 setting store jpackage17-generic TI:10:41:56 setting store jpackage17-generic-non TI:10:41:56 setting store jpackage50-generic TI:10:41:56 setting store jpackage50-generic-non TI:10:41:56 setting store jpackage60-generic TI:10:41:56 setting store jpackage60-generic-non TI:10:41:56 setting store jpackage17-elX TI:10:41:56 setting store jpackage17-elX-non TI:10:41:56 setting store jpackage50-elX TI:10:41:56 setting store jpackage50-elX-non TI:10:41:56 setting store jpackage60-elX TI:10:41:56 setting store jpackage60-elX-non TI:10:41:56 setting store redhat-os TI:10:41:56 setting store redhat-os-i386 TI:10:41:56 setting store redhat-os-x86_64 TI:10:41:56 setting store redhat-updates TI:10:41:56 setting store redhat-updates-i386 TI:10:41:56 setting store redhat-updates-x86_64 TI:10:41:56 setting store adobe-linux Percentage: 11 TI:10:41:56 setting store google-earth Failed: failed to load repos: failed to get filename elrepo.repo: Key file contains line ' http://elrepo.reloumirrors.net/elrepo/el6/$basearch/' which is not a key-value pair, group, or comment
(In reply to comment #4) > i already send you all of my repo file so you can look into them. Okay, so I've already fixed yesterday with: commit b3503f57ed558ecadaa121a5a6f70c69d9525547 Author: Richard Hughes <richard> Date: Mon Sep 19 07:57:27 2011 +0100 Make the repo file parser more permissive to append any string with a whitespace prefix :100644 100644 e316226... 3ac8fcf... M data/tests/repos/multiline.repo :100644 100644 5f3524f... a4375fb... M libzif/zif-utils.c Can you try rebuilding and installing the package from http://people.freedesktop.org/~hughsient/fedora/15/SRPMS/ and retest please. I've added all your repo files and it seems to work for me with git master. Thanks.
still not working:-( zif install ddd Downloading [== ] <9%> repomd.xml Failed to download: failed to resolve in viduxos-extras-i386: failed to load metadata for viduxos-extras-i386: failed to download repomd.xml from baseurl: failed to get valid response for ftp://viduxos/download/mirror/viduxos/ise/extras/i386/repodata/repomd.xml: Cannot connect to destination it seems don't detect or understand $releasever
(In reply to comment #6) > it seems don't detect or understand $releasever No, it's the fact that it's FTP. libsoup doesn't understand FTP, so I've had to add support for that in: commit bab80cec569de43518a1f058d4738e4fbb1c4bdb Author: Richard Hughes <richard> Date: Tue Sep 20 11:48:10 2011 +0100 Use wget to download files from FTP servers FTP is a nasty protocol that libsoup doesn't support. For the few mirrors that do not redirect to 'http://' use a wget helper to retrieve the file. Doing this means we don't get any status completion, but there doesn't seem to be any other credible FTP library other than libcurl. If somebody ported the hacky wget code to use libcurl then that would be wonderful. Can you try again with either git master or by rebuilding zif-0.2.4-0.89.20110920git.fc16.src.rpm or newer. Thanks.
still not working:-( do you see the "ise" in stead of "$releasever" in the url??? [== ] <9%> primary.xml Failed to download: failed to resolve in viduxos-extras-i386: failed to load metadata for viduxos-extras-i386: failed to download repomd.xml from baseurl: failed to run wget: --2011-09-20 13:32:41-- ftp://viduxos/download/mirror/viduxos/ise/extras/i386/repodata/repomd.xml => “/var/cache/zif/x86_64/ise/viduxos-extras-i386/repomd.xml” Resolving viduxos... 192.168.209.1 Connecting to viduxos|192.168.209.1|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /download/mirror/viduxos/ise/extras/i386/repodata ... No such directory “download/mirror/viduxos/ise/extras/i386/repodata”.
(In reply to comment #8) > do you see the "ise" in stead of "$releasever" in the url??? What does "zif get-config-value releasever" print? What did you expect it to be? Richard.
zif get-config-value releasever Enabling offline mode as user unprivileged. releasever = 'ise': while i expect to be 6:-) as it's an rhel-6...
Ahh, I see the problem. Zif reads the /etc/redhat-release file to get the release version but yum uses the package version of the thing that provides redhat-release. I'll fix this now. Thanks, Richard.
you should have to read the output of: rpm -q --nosignature --qf "%{VERSION}" --whatprovides redhat-release because eg on centos etc there is no redhat-release packages!
Okay, I think I've fixed this with: commit 76ddb6ea871078a43192816df9913af26f590adc Author: Richard Hughes <richard> Date: Tue Sep 20 15:51:13 2011 +0100 Get the releasever from the version of the package that provides redhat-release Can you try again with either git master or by rebuilding zif-0.2.4-0.92.20110920git.fc16.src.rpm or newer. Thanks.
still not working:-( [root@buildsys ~]# rpm -q zif zif-0.2.4-0.94.20110920git.el6.x86_64 [root@buildsys ~]# zif get-config-value releasever No value for releasever [root@buildsys ~]# zif install ddd Checking [====== ] <20%> primary.xml (zif:22843): Zif-CRITICAL **: zif_object_array_add: assertion `object != NULL' failed The transaction failed: no packages compatible with x86_64
(In reply to comment #14) > [root@buildsys ~]# zif get-config-value releasever > No value for releasever I've just fixed this in master, thanks. > [root@buildsys ~]# zif install ddd > Checking [====== ] <20%> > primary.xml > (zif:22843): Zif-CRITICAL **: zif_object_array_add: assertion `object != NULL' > failed Ouch, that shouldn't happen. Can you set G_DEBUG=fatal_criticals and get a backtrace please? Thanks.
i hope you can see zif is very far away from working version. in the last few day just in bz i report about 5 different bug not to mention other bz... it's not a critic just to be correct. anyway. with this version: [root@buildsys ~]# gdb --args zif install ddd GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/zif...Reading symbols from /usr/lib/debug/usr/bin/zif.debug...done. done. (gdb) r Starting program: /usr/bin/zif install ddd [Thread debugging using libthread_db enabled] Checking [======================= ] <20%> primary.xml Zif-CRITICAL **: zif_object_array_add: assertion `object != NULL' failed aborting... Program received signal SIGABRT, Aborted. 0x00007ffff57be905 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-7.el6_0.x86_64 db4-4.7.25-16.el6.x86_64 elfutils-libelf-0.152-1.el6.x86_64 gamin-0.1.10-9.el6.x86_64 glib2-2.28.4-1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64 gnutls-2.8.5-4.el6.x86_64 gpgme-1.1.8-3.el6.x86_64 libacl-2.2.49-5.el6.x86_64 libarchive-2.8.3-2.el6.x86_64 libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.2.el6.x86_64 libgcc-4.4.5-6.el6.x86_64 libgcrypt-1.4.5-5.el6_1.2.x86_64 libgpg-error-1.7-3.el6.x86_64 libselinux-2.0.94-5.el6.x86_64 libsoup-2.28.2-1.el6_1.1.x86_64 libtasn1-2.3-3.el6.x86_64 libxml2-2.7.6-1.el6.x86_64 lua-5.1.4-4.1.el6.x86_64 nspr-4.8.7-1.el6.x86_64 nss-3.12.9-12.el6_1.x86_64 nss-softokn-3.12.9-3.el6.x86_64 nss-softokn-freebl-3.12.9-3.el6.x86_64 nss-util-3.12.9-1.el6.x86_64 openssl-1.0.0-10.el6_1.4.x86_64 popt-1.13-7.el6.x86_64 rpm-libs-4.8.0-16.el6.x86_64 sqlite-3.6.20-1.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-26.el6.x86_64 (gdb) bt #0 0x00007ffff57be905 in raise () from /lib64/libc.so.6 #1 0x00007ffff57c00e5 in abort () from /lib64/libc.so.6 #2 0x00007ffff61f7f4a in g_logv () from /lib64/libglib-2.0.so.0 #3 0x00007ffff61f7fe3 in g_log () from /lib64/libglib-2.0.so.0 #4 0x00007ffff7bb2e17 in _zif_package_array_filter_best_provide (transaction=0x3068810, store=<value optimized out>, depend=<value optimized out>, package=0x7fffffffde60, state=0x674880, error=0x7fffffffde68) at zif-transaction.c:1000 #5 zif_transaction_get_package_provide_from_store (transaction=0x3068810, store=<value optimized out>, depend=<value optimized out>, package=0x7fffffffde60, state=0x674880, error=0x7fffffffde68) at zif-transaction.c:1115 #6 0x00007ffff7bb3dd5 in zif_transaction_get_packages_provides_from_store_array (data=<value optimized out>, item=0x30597a0, error=<value optimized out>) at zif-transaction.c:1261 #7 zif_transaction_get_package_provide_from_store_array (data=<value optimized out>, item=0x30597a0, error=<value optimized out>) at zif-transaction.c:1323 #8 zif_transaction_resolve_install_depend (data=<value optimized out>, item=0x30597a0, error=<value optimized out>) at zif-transaction.c:1415 #9 zif_transaction_resolve_install_item (data=<value optimized out>, item=0x30597a0, error=<value optimized out>) at zif-transaction.c:1769 #10 0x00007ffff7bb56e5 in zif_transaction_resolve_loop (data=0x30a6b40, state=0x674980, error=0x7fffffffe4d0) at zif-transaction.c:2871 #11 0x00007ffff7bb883f in zif_transaction_resolve (transaction=<value optimized out>, state=0x674980, error=0x7fffffffe4d0) at zif-transaction.c:3123 #12 0x000000000040b2ce in zif_transaction_run (priv=0x618090, transaction=0x3068810, state=0x674780, error=0x7fffffffe4d0) at zif-main.c:2284 #13 0x000000000040bf5f in zif_cmd_install (priv=0x618090, values=<value optimized out>, error=0x7fffffffe4d0) at zif-main.c:2545 #14 0x0000000000408289 in main (argc=3, argv=0x7fffffffe648) at zif-main.c:6223
(In reply to comment #16) > i hope you can see zif is very far away from working version. in the last few > day just in bz i report about 5 different bug not to mention other bz... > it's not a critic just to be correct. Sure, I don't disagree. I wasn't the person who opened the feature page, but on the flip side, I've had more bugs reported and more new contributors in the last 4 days than the whole of 2010 and 2011 put together. > anyway. with this version: > #4 0x00007ffff7bb2e17 in _zif_package_array_filter_best_provide > (transaction=0x3068810, store=<value optimized out>, depend=<value optimized > out>, package=0x7fffffffde60, state=0x674880, > error=0x7fffffffde68) at zif-transaction.c:1000 Fixed, thanks: commit f0649d638462c9e7086a1b950881462681c66c98 Author: Richard Hughes <richard> Date: Wed Sep 21 17:07:48 2011 +0100 Don't assume a provide array has a best depend Resolves https://bugzilla.redhat.com/show_bug.cgi?id=739393#c16 I know it might seem a pain to report all these issues, but I really appreciate it from someone who at least knows what gdb and releasever are. Please keep the bugs coming :)
(In reply to comment #16) > i hope you can see zif is very far away from working version. in the last few > day just in bz i report about 5 different bug not to mention other bz... > it's not a critic just to be correct. As the one who created the feature page: my testing showed zif as ready for daily usage. The feature was intended for f17, which is more than 6 months away, and a lot can happen (mainly bug fixes) in this kind of time. Note that fesco agreed on not allowing zif by default for now, and if I understood correctly they won't allow it in the near future. (f17 is out of the question AFAIK, but they might change their minds for f18, who knows). Thank you for your bug reports. Zif got a lot of new users, attention bug reports and bug fixes in the last few days, mostly (IMO) due to the discussion the feature page led to. This kind of attention is exactly what a free software project need to get into shape quickly.
still not working, but now it's not crash:-) # zif install ddd Checking [======================= ] <20%> filelists.sqlite The transaction failed: Failed to filter newest: cannot compare xorg-x11-fonts-ISO8859-1-75dpi;7.2-9.1.el6;noarch;viduxos-os-i386 with google-chrome-beta;14.0.835.186-101821;x86_64;google-chrome
(In reply to comment #19) > still not working, but now it's not crash:-) > > # zif install ddd > Checking [======================= > ] <20%> > filelists.sqlite > The transaction failed: Failed to filter newest: cannot compare > xorg-x11-fonts-ISO8859-1-75dpi;7.2-9.1.el6;noarch;viduxos-os-i386 with > google-chrome-beta;14.0.835.186-101821;x86_64;google-chrome I've fixed this yesterday, can you retry please.
it'll be a hard run...: zif install ddd Calculating install[=================================== ] (20%) ddd-3.3.12-5.el6.i686 (viduxos-extras-i386) (zif:17838): Zif-WARNING **: unrecognized: ddd(x86-32)=repodata/filelists.sqlite.bz2 Segmentation fault gdb: (gdb) bt #0 0x00007ffff57d2a67 in vfprintf () from /lib64/libc.so.6 #1 0x00007ffff5889cfc in __vasprintf_chk () from /lib64/libc.so.6 #2 0x00007ffff6230aeb in g_vasprintf () from /lib64/libglib-2.0.so.0 #3 0x00007ffff620e420 in g_strdup_vprintf () from /lib64/libglib-2.0.so.0 #4 0x00007ffff61f6bb0 in g_logv () from /lib64/libglib-2.0.so.0 #5 0x00007ffff61f6fe3 in g_log () from /lib64/libglib-2.0.so.0 #6 0x00007ffff7b754ab in zif_depend_new_from_data (keys=<value optimized out>, values=0x2e67a78) at zif-depend.c:596 #7 0x00007ffff7b88c7f in zif_md_primary_sql_sqlite_depend_cb (data=<value optimized out>, argc=<value optimized out>, argv=<value optimized out>, col_name=<value optimized out>) at zif-md-primary-sql.c:575 #8 0x0000003140a59c8f in sqlite3_exec () from /usr/lib64/libsqlite3.so.0 #9 0x00007ffff7b88b4e in zif_md_primary_sql_get_depends (md=0x2e2d2c0, type=0x7ffff7bcb293 "provides", package=<value optimized out>, state=<value optimized out>, error=0x7fffffffdf88) at zif-md-primary-sql.c:837 #10 0x00007ffff7b9794b in zif_package_remote_ensure_data (pkg=0x2e3e430, type=ZIF_PACKAGE_ENSURE_TYPE_PROVIDES, state=0x674a80, error=0x7fffffffdf88) at zif-package-remote.c:592 #11 0x00007ffff7b90818 in zif_package_provides (package=0x2e3e430, depend=0x37fc320, satisfies=0x7fffffffdd28, state=0x674a80, error=<value optimized out>) at zif-package.c:564 #12 0x00007ffff7b942bf in zif_package_array_depend (array=0x2dfea40, depend=0x37fc320, best_depend=0x0, provides=0x7fffffffdd98, type=ZIF_PACKAGE_ENSURE_TYPE_PROVIDES, state=0x674a80, error=0x7fffffffdf88) at zif-package-array.c:790 #13 0x00007ffff7b94366 in zif_package_array_provide (array=<value optimized out>, depend=<value optimized out>, best_depend=<value optimized out>, results=<value optimized out>, state=<value optimized out>, error=<value optimized out>) at zif-package-array.c:879 #14 0x00007ffff7bb0fce in zif_transaction_get_package_provide_from_install (transaction=<value optimized out>, depend=<value optimized out>, package=0x7fffffffdea0, state=<value optimized out>, error=<value optimized out>) at zif-transaction.c:1297 #15 0x00007ffff7bb2ab8 in zif_transaction_resolve_install_depend (data=<value optimized out>, item=0x2e1d2c0, error=0x7fffffffdf88) at zif-transaction.c:1665 #16 zif_transaction_resolve_install_item (data=<value optimized out>, item=0x2e1d2c0, error=0x7fffffffdf88) at zif-transaction.c:2073 #17 0x00007ffff7bb4f35 in zif_transaction_resolve_loop (data=0x36c3ad0, state=0x674880, error=0x7fffffffe500) at zif-transaction.c:3195 #18 0x00007ffff7bb80e7 in zif_transaction_resolve (transaction=<value optimized out>, state=0x674880, error=0x7fffffffe500) at zif-transaction.c:3458 #19 0x000000000040b354 in zif_transaction_run (priv=0x618090, transaction=0x2e1a020, state=0x674280, error=0x7fffffffe500) at zif-main.c:2363 #20 0x000000000040bfbf in zif_cmd_install (priv=0x618090, values=<value optimized out>, error=0x7fffffffe500) at zif-main.c:2624 #21 0x00000000004082f1 in main (argc=3, argv=0x7fffffffe678) at zif-main.c:6492
(In reply to comment #21) > it'll be a hard run...: > > zif install ddd > Calculating install[=================================== > > ] (20%) > ddd-3.3.12-5.el6.i686 (viduxos-extras-i386) Have you got the repo file for viduxos-extras-i386 please. > (zif:17838): Zif-WARNING **: unrecognized: > ddd(x86-32)=repodata/filelists.sqlite.bz2 > Segmentation fault Wow, that's some pretty messed up bt. It's showing random stuff from other strings in the SQL return values. What happens if you run "sudo valgrind install ddd -n -v" -- can you post the full log please. Thanks.
(In reply to comment #22) > (In reply to comment #21) > > it'll be a hard run...: > > > > zif install ddd > > Calculating install[=================================== > > > > ] (20%) > > ddd-3.3.12-5.el6.i686 (viduxos-extras-i386) > > Have you got the repo file for viduxos-extras-i386 please. > > > (zif:17838): Zif-WARNING **: unrecognized: > > ddd(x86-32)=repodata/filelists.sqlite.bz2 > > Segmentation fault > > Wow, that's some pretty messed up bt. It's showing random stuff from other > strings in the SQL return values. > > What happens if you run "sudo valgrind install ddd -n -v" -- can you post the > full log please. Thanks. is it valgrind zif install ddd -n -v &>valgrind.out ?:-)
Created attachment 525327 [details] valgrind output
(In reply to comment #22) > (In reply to comment #21) > > it'll be a hard run...: > > > > zif install ddd > > Calculating install[=================================== > > > > ] (20%) > > ddd-3.3.12-5.el6.i686 (viduxos-extras-i386) > > Have you got the repo file for viduxos-extras-i386 please. what do you mean by repo? the the whole repo dir? or ... just a file or...?
(In reply to comment #25) > what do you mean by repo? the the whole repo dir? or ... just a file or...? The single .repo file. I'll try to setup my el6 VM to reproduce the problem. (In reply to comment #24) > Created attachment 525327 [details] > valgrind output That's really helpful, thanks. That's basically showing that sqlite isn't returning NULL terminated string arrays. It doesn't actually say in the sqlite docs that it promises to, and zif happened to rely on that feature. It seems that newer versions do it by default but older (el6...) ones do not. This commit should get you past the valgrind problems. Can you retry with a newer snapshot that includes: commit 988bf60f1052c78f5389a9063b075aebe4423eab Author: Richard Hughes <richard> Date: Wed Sep 28 13:35:00 2011 +0100 Do not assume that the char** arrays from SQLite are NULL terminated Resolves https://bugzilla.redhat.com/show_bug.cgi?id=739393#c24 If that still blows up, can I have the new "valgrind zif install ddd -n -v &>valgrind.out" again please. Thanks. Richard.
getting worse, nor even compile: CC libzif_la-zif-store-array.lo /bin/sh ../libtool --silent --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/libsoup-2.4 -I/usr/in clude/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I../libzif -I../libzif -I. -DZIF_COMPILATION -DG_LOG_DOMAIN=\"Zif\" -DLOCALSTATEDIR=\""/var"\" -DTOP_SRCDIR=\"".."\" -DPACKAG E_DATA_DIR=\""/usr/share"\" -DSYSCONFDIR=\""/etc"\" -DPACKAGE_LOCALE_DIR=\""/usr/share/locale"\" -Wall -Wcast-align -Wno-uninitialized -Wmissing-declarations -Wredundant-decls -Wpointer-arith -W cast-align -Wwrite-strings -Winit-self -Wreturn-type -Wformat-nonliteral -Wformat-security -Wmissing-include-dirs -Wmissing-format-attribute -Wsign-compare -Wtype-limits -Wuninitialized -Waggregat e-return -Wdeclaration-after-statement -Wshadow -Wno-strict-aliasing -Winline -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 - mtune=atom -fasynchronous-unwind-tables -c -o libzif_la-zif-store-array.lo `test -f 'zif-store-array.c' || echo './'`zif-store-array.c zif-state.c:82:23: error: glib-unix.h: No such file or directory zif-state.c: In function 'zif_state_cancel_on_signal': zif-state.c:1166: warning: implicit declaration of function 'g_unix_signal_add' make[3]: *** [libzif_la-zif-state.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory `/builddir/build/BUILD/zif-0.2.5/libzif' make[2]: Leaving directory `/builddir/build/BUILD/zif-0.2.5/libzif' make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/zif-0.2.5'
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.