Call for testers for FMN
by Pierre-Yves Chibon
Dear all,
Pkgdb2 is now running for a little over two months. It seems that most of you
like it which is appreciated :)
However, one of the annoyance from Pkgdb1 has not disapeared. Pkgdb2 sends you
an email for each action you do.
So if you request 3 ACLs on two packages, you receive six emails.
This is a pretty annoying feature but looks like you have grown accustomed to it
as not many people complained of this behavior :)
However, pkgdb2 was not meant to do this¹.
Pkgdb2 is meant to rely on fedmsg and the new Fedora Notifications (FMN) system
for its notifications.
FMN is already deployed and running, however, it was not advertised too much
so as to give us the time to adjust and optimize it where needed.
Today, we would like to ask more people to register/test it.
The big plan (wrt pkgdb2) is basically:
* Have more people test FMN
* Fix bugs/optimize
* Create an account on FMN for all the packagers that do not have one already
* Turn off email notification on pkgdb
* Automatically create FMN accounts for users added to the packager group
There are several advantages to FMN, among them:
* a central place to get/manage your notifications for all the Fedora systems
(bodhi, badges, pkgdb...)
* the possibility to choose which notifications to get where, for example
- IRC notification upon successful build on koji
- Email notification for failed build on koji
- Some day, push to android devices
* the possibility to send the notifications as batch, for example:
- wait 10 minutes after the first pkgdb action and then send me all the pkgdb
notifications
This way if someone asks for 3 ACLs on 2 packages within 10 minutes, you
will only receive one notification
* from an infrastructure developer point of view: less code duplication
So please, register on FMN:
https://apps.fedoraproject.org/notifications/
Test it and open bug tickets and RFEs here:
https://github.com/fedora-infra/fmn/issues
Thanks for your help,
The #fedora-apps team
¹ The emailing part was even added per request from Seneca when they looked
at pkgdb2
9 years, 8 months
Self Introduction / Contributing a package to Fedora
by Derek Pressnall
I have a question about contributing a package to Fedora. Is it common for
the author of an open source package to act as package maintainer? Or is
it better to have someone else be the package maintainer (who is more
experienced with the Fedora build processes)? I'm the author of a backup
utility which fills a niche between tools based on rsync, and the
heavy-weight full featured backup tools, which I think would be a good fit
for a typical Fedora user. I already have an SRPM available on the Github
project site (www.snebu.com), but it may need a bit more work to get it in
line with the Fedora build system. I've also been reading through the
package maintainer guidelines, and am willing to go through the process
too, if needed. I have already created my Fedora and Bugzilla accounts,
and will spin up Koji this weekend to play with.
Thanks,
--Derek
9 years, 8 months
packages seeking new owner
by Gregor Tätzner
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
f19 )
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
f19 )
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
right away.
Cheers,
Greg
9 years, 8 months
Add Gparted into Live's
by Álvaro Castillo
Dear Fedora Team,
I pray to God. Could Fedora live have CD/DVD/USB Gparted by default?
Could add Gparted please?
9 years, 8 months
Assistance with a dlopen bug...
by Kevin Fenzi
Greetings.
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
either:
Traceback (most recent call last):
File "/usr/bin/calibre", line 20, in <module>
sys.exit(main())
File "/usr/lib64/calibre/calibre/gui2/main.py", line 458, in main
gui_debug=gui_debug)
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? :)
kevin
9 years, 8 months
the tragedy of Fedora Live USB conversion and what we can do about it
by Kamil Paral
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):
https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=cs&i...
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):
http://www.zive.cz/uploadedfiles/38598240.png
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?
Some ideas:
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:
http://www.zive.cz/uploadedfiles/38598240.png
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.
9 years, 8 months
The GNU C Library will be rebased in F21 to match glibc 2.20.
by Carlos O'Donell
Fedora,
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:
http://fedoraproject.org/wiki/Changes/GLIBC220
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.
Cheers,
Carlos.
9 years, 8 months
Schedule for Thursday's FPC Meeting (2014-07-31 16:00 UTC)
by James Antill
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
irc.freenode.net.
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
------------------new day----------------------
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:
https://fedorahosted.org/fpc/report/12
= Followups =
(approval and retirement sections already passed, /opt exception passed,
basename passed)
#topic #339 software collections in Fedora
.fpc 339
https://fedorahosted.org/fpc/ticket/339
(comment #16 is the current winner)
#topic #341 How to replace "docker" package with an entirely
different package of the same name?
.fpc 341
https://fedorahosted.org/fpc/ticket/341
#topic #382 Go Packaging Guidelines Draft
.fpc 382
https://fedorahosted.org/fpc/ticket/382
(waiting on fesco)
#topic #442 Please recommend usage of new sysusers.d/ facility to
register system users
.fpc 442
https://fedorahosted.org/fpc/ticket/442
(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
.fpc 444
https://fedorahosted.org/fpc/ticket/444
= New business =
#topic #447 Bundling exception for axmail
.fpc 447
https://fedorahosted.org/fpc/ticket/447
#topic #448 Copylib exception for fastlz
.fpc 448
https://fedorahosted.org/fpc/ticket/448
#topic #449 Bundle lib exception, json-c on php-pecl-jsonc
.fpc 449
https://fedorahosted.org/fpc/ticket/449
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://fedorahosted.org/fpc/report/12
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.
9 years, 8 months
rubygem-syntax license revised from 'Public Domain' to 'BSD'
by Vít Ondruch
Dear all,
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.
Regards,
Vít
9 years, 8 months
