I'm seeing a fun crash of the calibre application in rawhide. I'm not
fully sure when it started, but I'm not sure how to track it down
Traceback (most recent call last):
File "/usr/bin/calibre", line 20, in <module>
File "/usr/lib64/calibre/calibre/gui2/main.py", line 458, in main
File "/usr/lib64/calibre/calibre/gui2/main.py", line 320, in run_gui
from calibre.gui2.ui import Main
File "/usr/lib64/calibre/calibre/gui2/ui.py", line 26, in <module>
from calibre.db.legacy import LibraryDatabase
File "/usr/lib64/calibre/calibre/db/legacy.py", line 17, in <module>
from calibre.db.backend import DB
File "/usr/lib64/calibre/calibre/db/backend.py", line 31, in <module>
from calibre.utils.magick.draw import save_cover_data_to
File "/usr/lib64/calibre/calibre/utils/magick/__init__.py", line 14, in <module>
raise RuntimeError('Failed to load ImageMagick: '+_merr)
RuntimeError: Failed to load ImageMagick: dlopen: cannot load any more
object with static TLS
ImageMagick hasn't changed recently at all, so I think it's something in it's dep tree,
but not really sure how to go about finding it.
Anyone have clever ideas? :)
It's a well-known fact in our circles that third-party USB conversion tools (like UNetbootin or Universal USB Installer) can't create Fedora Live USB correctly. Unfortunately, it is not well known among our users (I see it very often on test list, IRC, or local fedora.cz website/forums) and even journalists. This is an article that was published yesterday showcasing difficulties of Fedora installation process (translated from Czech by google translate):
The purpose of that article is to highlight the fact that Linux has made a lot of progress in the last years, but the results are still a bit like a Russian roulette. Fedora, in this case, is shown as the negative example. The website itself is not known for high quality articles here in CZ, but they are quite popular and have a large reader base. They are mainly Windows-focused, but with the recent advancement of Linux on all fronts (mainly in gaming), they're clearly willing to provide more Linux coverage - and they picked Fedora as their second option right after Ubuntu, which is great. Provided they're able to install it in the first place...
The result of Live USB boot attempt is often this (from the article):
I wonder, is there something we can do to improve the situation?
* We have no control over third-party USB conversion tools.
* Even if we file bug reports, they are often ignored (Adam Williamson said he tried to communicate with UNetbootin, unsuccessfully).
* Third-party USB installers fail for many distributions, like OpenSUSE <http://en.opensuse.org/SDB:Live_USB_stick> or Arch <https://wiki.archlinux.org/index.php/USB_Flash_Installation_Media#Using_U...>.
* Still, they are hugely popular, because Ubuntu and its derivatives dominate the market and those tools usually work fine for them.
* The users simply don't know that those tools shouldn't be used, and some others should be used instead.
I don't known the technical details about USB conversion process, but maybe we could collectively think of some changes that would improve the current state at least a bit?
1. First and foremost, we should obviously consider whether we can make some compose changes that would make the image more compatible with third-party USB installers. That's very technical, but I hope relevant people could provide some comments here.
2. Second, we could make USB conversion instructions more visible on our pages. If you look at http://fedoraproject.org/, there's a big Download Now! button, which gives you the ISO, but you'll never encounter any suggestions what to do with it. That's only available at http://fedoraproject.org/en/get-fedora#desktops in the right column (which is nice and quite visible, I think). Could we provide the same information on the front page?
3. Third, if everything goes wrong and you end up in a dracut shell, could we at least advise our users what went wrong and what to do with it? Because the current output is very scary and very hard to decipher by a general user:
So what if we detected that we failed to find a partition having "Fedora-Live" in its name (thus most probably an incorrectly created LiveUSB), and in that case printed out something like this?
* It seems Fedora Live image could not have been accessed. This often happens *
* when Live USB media is incorrectly created by a third-party USB installer. *
* Please refer to official documentation on fedoraproject.org for proper *
* instructions. *
(native speakers will surely make it sound better)
This would help our users a lot to understand what's wrong and how to fix it. Also, it would be much easier to google out the problem. If we included the same text on our LiveUSB instructions page <https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB>, it could receive a very good position in online search results.
So, what do you think? From my experience, the inability to boot USB is very common and I'd even say it's one of the major problems why new users walk away from Fedora. Because, understand, they don't even know something is wrong on their end. That scary dracut error looks like a problem in Fedora, and therefore often their conclusion is "Fedora is so broken it can't even boot". If we try to mitigate the problem at least with clear explanations, we will not only discourage less users, but also decrease the number of negative reviews by journalists.
This is a reminder that the glibc team will be rebasing
glibc in F21 to match glibc 2.20.
The plan remains largely as was written here:
Only glibc 2.20 has ABI guarantees, and therefore we
will move to 2.20 before F21 goes to GA to ensure that
F21 has a strong ABI guarantee.
I expect this to be the process forever going forward:
* Rawhide tracks glibc master.
* Fedora release is branched from Rawhide.
* glibc release is made upstream.
* Fedora branch is rebased on glibc upstream release
to include ABI guarantees.
* Fedora release goes GA.
The changes in the rebase should be minor since we've
been tracking master the whole time.
Following is the list of topics that will be discussed in the FPC
meeting Thursday at YYYY-MM-DD 16:00 UTC in #fedora-meeting-1 on
Local time information (via. rktime):
2014-07-31 09:00 Thu US/Pacific PDT
2014-07-31 12:00 Thu US/Eastern EDT
2014-07-31 16:00 Thu UTC <-
2014-07-31 17:00 Thu Europe/London BST
2014-07-31 18:00 Thu Europe/Paris CEST
2014-07-31 18:00 Thu Europe/Berlin CEST
2014-07-31 21:30 Thu Asia/Calcutta IST
2014-08-01 00:00 Fri Asia/Singapore SGT
2014-08-01 00:00 Fri Asia/Hong_Kong HKT
2014-08-01 01:00 Fri Asia/Tokyo JST
2014-08-01 02:00 Fri Australia/Brisbane EST
Links to all tickets below can be found at:
= Followups =
(approval and retirement sections already passed, /opt exception passed,
#topic #339 software collections in Fedora
(comment #16 is the current winner)
#topic #341 How to replace "docker" package with an entirely
different package of the same name?
#topic #382 Go Packaging Guidelines Draft
(waiting on fesco)
#topic #442 Please recommend usage of new sysusers.d/ facility to
register system users
(more votes needed, or defer to FESCO?)
#topic #444 Officially recommend to releng that SCLs be placed in
separate packages rather than separate branches in git
= New business =
#topic #447 Bundling exception for axmail
#topic #448 Copylib exception for fastlz
#topic #449 Bundle lib exception, json-c on php-pecl-jsonc
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
I have updated rubygem-syntax from version 1.0.0 to version 1.2.0. The
gem used to be accompanied by email discussion, which claimed the
license to be 'Public Domain'. However, the library was picked up by
different upstream and now it ships under BSD license.
-----BEGIN PGP SIGNED MESSAGE-----
Some people have already heard about the new Security Team making the rounds on BZ trying to clean up vulnerabilities that still linger within our OS. Until today I've not said much as I was waiting to see how successful we'd be at trying to remedy some of these situations. Turns out I had nothing to fear. So with that I formally announce the Security Team to Fedora and open the doors to all that are interested.
== What are we doing? ==
The Security Team's mission is to assist packagers in closing security vulnerabilities. Once alerted to a vulnerability on a package, the security team can help work with upstream to obtain a patch or a new release of a package. Once we have a patch or a new release we attach it to the vulnerability bug and work with packagers to get the fix pushed.
== How bad is the problem now? ==
As of a few days ago we had 566 open vulnerability tickets that cover both Fedora and EPEL. The breakdown of those bugs by severity looks like this:
* Critical: 3
* Important: 69
* Moderate: 366
* Low: 128
The good thing is that few of these vulnerabilities are considered "bad" (critical and important). There are likely bugs in there that no longer apply since the packages have been upgraded but the tickets never got closed. Also, a package that is in both Fedora and EPEL will get a ticket for each so from a pure numbers standpoint there are duplicates in those stats.
== How many people have signed up for the team? ==
Over twenty so far.
== How can I join/get involved/learn more about the project? ==
Go look at our wiki page, which is still being developed but does contain some basic information on the team. We also have a listserv and an IRC channel where we hang out.
 #fedora-security-team on irc.freenode.net
- -- Eric
Eric "Sparks" Christensen
sparks(a)fedoraproject.org - sparks(a)redhat.com
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
devel-announce mailing list