Greetings Fedora People,
I want to end my active contributions to fedora, so there are going to be some
apps that need love soon. We are talking about following stuff:
kde-plasma-publictransport -- Public Transport plasma applet ( master f21 f20
kdesrc-build -- A tool to allow you to easily build KDE from its source
repositories ( master f21 f20 f19 )
kwooty -- A friendly nzb usenet binary download application ( master f21 f20
owncloud -- Private file sync and share server ( master f21 f20 f19 el6 )
php-channel-dropbox-php -- Adds the Dropbox-PHP channel to PEAR ( master f21
f20 f19 el6 )
php-cloudfiles -- PHP API for the Cloud Files storage system ( f20 f19 el6 )
php-dropbox-php-Dropbox -- Library for integrating dropbox with PHP ( master
f21 f20 f19 el6 )
php-opencloud -- PHP SDK for OpenStack/Rackspace APIs ( master f21 f20 el6 )
php-phpass -- Portable password hashing framework for use in PHP applications
( master f21 f20 f19 el6 )
php-when -- Date/Calendar recursion library for PHP ( master f21 f20 f19 el6 )
semantik -- mind mapping tool ( master f21 f20 f19 )
unison240 -- Multi-master File synchronization tool ( master f21 f20 f19 )
If you are interested in any of these, feel free to contact me or send acls
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.