There was recently a thread on the Fedora ARM mailing list
about getting a Fedora ARM image into the official Docker Hub. That
discussion lead down the trail of how to best handle the naming for
all of this.
The current questions are either using Fedora's namespace and just
making a new image (using Fedora ARM as an example), this would be the
"FROM" line for a Dockerfile
Which would then contain all the standard tags for latest, rawhide, f22, etc.
Or alternatively, have each architecture maintain their own namespace
within the Hub which would look a little more like:
I'm personally a fan of the first option because it keeps things under
the Fedora umbrella and also allows for flexibility of aarch64, POWER,
etc as Docker supports more architectures. However the one thing I see
there that could be problematic is the possibility for users to be
confused if they don't search on the Docker Hub webUI and see the
associated documentation highlighting that the base image is for a
different architecture but instead just search from the docker command
line and end up with an image that won't run.
Looking forward to feedback on the topic.
 - https://lists.fedoraproject.org/pipermail/arm/2015-June/009526.html
= Proposed System Wide Change: jQuery =
Change owner(s): T.C. Hollingsworth <tchollingsworth at gmail dot com>
Traditionally, a copy of jQuery has been included with every web application that requires it. This change will migrate many of those applications to a shared system copy of jQuery. Both the 1.x branch of jQuery that supports Internet Explorer 6 and the 2.x branch of jQuery that only works with modern web browsers will be provided.
== Detailed Description ==
Traditionally, a copy of jQuery has been included with every web application that requires it. This change will migrate many of those applications to a shared system copy of jQuery.
The following packages are available in Fedora 21 and later and EPEL 6 and later:
* js-jquery - The latest version of the jQuery 2.x branch, suitable for web applications that are only compatible with modern web browsers that fully support modern web standards.
* js-jquery1 - The latest version of the jQuery 1.x branch, suitable for web applications that endeavor to be compatible with older web browsers such as Internet Explorer 6.
* js-jquery-migrate - The jQuery migrate plugin, which is a compatibility shim that enables web applications that depend on older versions of jQuery to work with the latest version, so that they can be ported away from old, unsupported jQuery versions that may potentially have security issues.
Some new packages are already beginning to use the system version of jQuery with little trouble, so for Fedora 23 we're going to open the doors to converting existing packages. We'll send announcements explaining how to unbundle existing packages. We'll also find all the packages we can that are bundling jQuery and inform maintainers about them, via e-mail only at this time. (We'll save the mass bug filing for F24 to allow maintainers to have a go at it voluntarily first. :-)
== Scope ==
* Migrating Web Applications
-- Web applications that depend on modern versions of jQuery will simply be ported to use the systemwide version instead,
-- Web applications that use older versions of jQuery (> 1.6.4 but <1.9) will be ported to use jquery-migrate and the systemwide version of jQuery. Packagers will be encouraged to work with upstream to migrate to the latest version of jQuery without jquery-migrate, since using this plugin re-enables misfeatures rightly removed from jQuery core that are XSS holes waiting to happen.
-- Maintainers of web applications that use extremely old versions of jQuery (< 1.6.4) will be strongly encouraged to work with upstream to migrate to the latest versions of jQuery and update their packages. However, current Fedora policy regarding bundled libraries permits these packages to be grandfathered in, so I am unable to force any action here.
-- Preliminary repoqueries have been performed to identify potentially affected packages, see the dependencies section for more details.
* Migrating documentation frameworks
-- Certain documentation frameworks, such as python-sphinx, ship copies of jQuery as well. These frameworks will be modified to use a symlink or other means so that they too can use the new systemwide versions.
* Release Engineering
-- No special attention required.
devel-announce mailing list
I would like to build lilypond for EPEL-7, but unfortunately it
requires texlive-metapost which we don't have in the RHEL-7
texlive. Now, the question is how to build just one subpackage
(or any required other subpackages) from the monstrosity which
the current texlive? Anybody any suggestions?
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
Ty zlý dávaj’ ty hodný pryč. // Those evil ones put away those good ones.
-- Magda Ceplová
On my Fedora 22 up to date (kernel 4.0.5-300.fc22.x86_64), when I
insert a SSD card I get this warning:
> giu 30 01:03:27 dodo.home.solinos.it kernel: mmc0: new high speed SDHC card at address 59b4
> giu 30 01:03:27 dodo.home.solinos.it kernel: Driver 'mmcblk' needs updating - please use bus_type methods
> giu 30 01:03:27 dodo.home.solinos.it kernel: mmcblk0: mmc0:59b4 00000 14.9 GiB
And after some time (dd if=img of=/dev/mmcblk0) I get many kernel error
> giu 30 01:32:14 dodo.home.solinos.it kernel: ------------[ cut here ]------------
> giu 30 01:32:14 dodo.home.solinos.it kernel: WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857 sdhci_send_command+0xa73/0xc50 [sd
> giu 30 01:32:14 dodo.home.solinos.it kernel: Modules linked in: mmc_block bnep bluetooth fuse xt_CHECKSUM iptable_mangle ipt_MASQUERAD
> giu 30 01:32:14 dodo.home.solinos.it kernel: parport_pc shpchp parport mei_me tpm mei dell_smo8800 nfsd auth_rpcgss nfs_acl lockd gra
> giu 30 01:32:14 dodo.home.solinos.it kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.0.5-300.fc22.x86_64 #1
> giu 30 01:32:14 dodo.home.solinos.it kernel: Hardware name: Dell Inc. Latitude E5520/03PH4G, BIOS A05 11/30/2011
> giu 30 01:32:14 dodo.home.solinos.it kernel: 0000000000000000 c244236c9fe8f15d ffff88022ec03d08 ffffffff817834f4
> giu 30 01:32:14 dodo.home.solinos.it kernel: 0000000000000000 0000000000000000 ffff88022ec03d48 ffffffff8109c66a
> giu 30 01:32:14 dodo.home.solinos.it kernel: ffff880224e7c4c0 ffff880224e7c4c0 ffff8801f12910f0 ffff8801f1291170
> giu 30 01:32:14 dodo.home.solinos.it kernel: Call Trace:
> giu 30 01:32:14 dodo.home.solinos.it kernel: <IRQ> [<ffffffff817834f4>] dump_stack+0x45/0x57
> giu 30 00:55:49 dodo.home.solinos.it kernel: DMA: Out of SW-IOMMU space for 65536 bytes at device 0000:09:00.1
> giu 30 00:55:49 dodo.home.solinos.it kernel: DMA: Out of SW-IOMMU space for 65536 bytes at device 0000:09:00.1
> giu 30 00:55:49 dodo.home.solinos.it kernel: ------------[ cut here ]------------
> giu 30 00:55:49 dodo.home.solinos.it kernel: WARNING: CPU: 0 PID: 10598 at drivers/mmc/host/sdhci.c:857 sdhci_send_command+0xa73/0xc50
> giu 30 00:55:49 dodo.home.solinos.it kernel: Modules linked in: uas usb_storage vfat fat mmc_block bnep bluetooth fuse xt_CHECKSUM ipt
> giu 30 00:55:49 dodo.home.solinos.it kernel: mei_me parport_pc wmi i2c_i801 mei tpm_tis parport tpm shpchp dell_smo8800 nfsd auth_rpc
> giu 30 00:55:49 dodo.home.solinos.it kernel: CPU: 0 PID: 10598 Comm: mmcqd/0 Tainted: G W 4.0.5-300.fc22.x86_64 #1
> giu 30 00:55:49 dodo.home.solinos.it kernel: Hardware name: Dell Inc. Latitude E5520/03PH4G, BIOS A05 11/30/2011
> giu 30 00:55:49 dodo.home.solinos.it kernel: 0000000000000000 00000000f78a99be ffff88022ec03d08 ffffffff817834f4
> giu 30 00:55:49 dodo.home.solinos.it kernel: 0000000000000000 0000000000000000 ffff88022ec03d48 ffffffff8109c66a
> giu 30 00:55:49 dodo.home.solinos.it kernel: ffff8802227de4c0 ffff8802227de4c0 ffff88021776b290 ffff88021776b310
> giu 30 00:55:49 dodo.home.solinos.it kernel: Call Trace:
The card written is unusable and I must reboot my notebook to use it
This problem is new for me (Update from f21 to 22), I have write with
this NB many card SD in the past.
If I usa another notebook with F21 the problem not happens and the card
is written good.
Some one have some suggest?
(inviato dal mio Linux Fedora 22 con Gnome 3.16)
Following up on the ABI checking topic raised in the "API Break
Detection" section near the end of the post
I'd like to summarize where we stand at the moment and what we plan do.
We discussed this topic on the #fedoral-devel IRC channel yesterday and
here is what stuck to my mind. Others are of course welcome to add what
I have forgotten and to correct me when I a wrong.
To start, we'd like to have an automated way to check the ABI
compatibility of binaries embedded in packages that are submitted to the
updates-testing repository. When an incompatible change is detected,
the package will be prevented from auto-increasing it's karma count. I
guess a manual intervention will then be required to increase the karma
or a new package version needs to be submitted again.
Under the hood, the current informal plan seems to be to come up with a
Taskotron checking task, which, for a given package named P, will
compare the ABIs of the binaries embedded in P against their
counterparts in the latest known stable version of P that is present in
the stable repository. The result of the comparison shall be a report
showing the ABI difference of the offending binaries, if those changes
are deemed harmful or possibly harmful, from an ABI compatibility
At this moment, we do have a command line tool named "abidiff" that
knows how to compare two shared library binaries and emits a report
about the differences in their ABI. That tool needs the debug info of
the binaries too. We are currently working on a tool named
"abipkgdiff" that takes two RPMs and compares the shared library
binaries. That tool should be ready enough (hopefully) in the coming
When the "abipkgdiff" command line tool is ready , I guess the plan is
to use it in a new Taskotron task that, when invoked on a given package,
gets the stable version of that package as well as the debuginfo
packages from koji, executes abipkgdiff to compare the package against
it's stable version and emits the resulting report.
So, that is the first "baby step" we talked about.
There are obviously going to be many other baby steps coming up, and
I'll write something about them a little bit later on this topic,
possibly in the wiki, rather. Needless to say, even the baby steps in
this note need to be refined, I guess we'll do that on the wiki some
where. But until then, I thought I'd drop this note to let you know
where we stand.
Thank you for reading so far.
: A change in a the ABI of a shared library is considered
"compatible", if an application linked with the older version of the
library is still going to function reliably when executed against the
newer version of the library, without being re-linked. Otherwise, the
ABI change is considered "incompatible".
: abidiff manual documentation can be consulted at
: abipkgdiff is being hacked on by Sinny Kumari in a branch of the
upstream libabigail git repo at
Hi dear developers,
after upgrading to tb-38.0.1, thunderbird-lightning-3.3-5.fc22.x86_64
has been obsoleted (as the formus are telling), but still the addons
manager of tb shows lightning as installed extension which can be
activated and removed.
Because I thougt that tb-lighning is now obsolete, I removed the
extension, but then I get rid totally from the calendars. So my
question: how t get the calendars running in TB without installing
lightning from the moz. extension pages?
Fedora release 22 (Twenty Two)
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
F23 is about to branch  and it's time we started thinking about what
we'd want to have a test day for. There are several changes accepted
already for F23, and more that have yet to be decided . You can find
the list here:
Please take some time and look through the list and see if there's
anything you'd be interested in testing - or if there's something you
think should get some testing that isn't in the ChangeSet!
For those of you not familiar with test days, a test day is an
online event aimed at testing a specific feature of an upcoming Fedora
Release. By utilizing IRC for organization/coordination and a Wiki
page for instructions and results, test days are easy to organize.
Anyone can request to host a test day or request that the QA team help
you out with the organization of the test day. A test day can be ran
for any feature or area of a distribution that focused testing would be
useful for. More information on test days can be found here:
To propose a test day, file a ticket on the QA Trac. A full
explanation can be found here:
https://fedoraproject.org/wiki/QA/Test_Days/Create . The SOP for
hosting a test day is here:
Traditionally test days have been held on Thursdays, but if you'd prefer
to have it on another day that's fine too. We're pretty flexible, but
having plenty of lead time helps to get the word out. Just put in your
ticket the date or time-frame you'd like, and we'll figure it out from
If you have any questions about test days or the process, please don't
hesitate to contact me or any other QA Team member in #fedora-qa on
Freenode or respond on the test list.
Thanks and happy testing!
test-announce mailing list
I would like to start providing the latest version of ODB in a COPR for
stable releases of Fedora and RHEL. Is there a "best practice" for this
sort of thing?
The main question I have is:
Is it "better" to use a single repo and continue to update it with the
Or is it better to have a repo for version 2.4 and then a separate one for
when 2.5 comes out?