FTBFS tracking bug
by Igor Gnatenko
Hello,
do we have tracking bug for FTBFS? I remember there was one for F24,
but can't find something similar for F26.
--
-Igor Gnatenko
7 years, 4 months
future of official optical media support in Fedora
by Kamil Paral
Now that Fedora 25 is out of the door, I'd like to start a discussion about the future of officially-supported (meaning rigorously tested) optical media for future Fedora releases. Since I'm QA, I'm mainly interested in changes to our release criteria [1].
Let's start by saying I'm not asking for completely dropping optical media support. Even though hardware incapable of booting from USB is getting increasingly rare, I understand that there are still valid use cases from optical media, like pressing a bulk of DVDs for a very small price and handing it out at events or sending them into developing countries (that's how I started with Linux, after all, ~15 years ago). However, the world has moved on since then, I wonder whether some changes in decreasing the importance of optical media could be appropriate. All of that is, of course, motivated by trying to spend QA time more effectively. You can see the current coverage e.g. in this table [2], overall we burn 6 DVDs and perform 12 optical installation (BIOS + UEFI) for every release candidate published. We allow non-complete (yet still substantial) coverage for Alpha and Beta, but 100% coverage for Final for each candidate compose. That is quite time consuming, both burning and installation from optical media take a long time, it requires bare metal testing, and we can't use the machines for anything else during that time.
So, I wonder whether Fedora as a project thinks about de-emphasizing optical media a bit, and if it does, I'd make appropriate changes even in our QA processes. Here are a couple of ideas that I consider could be likely to happen in future Fedora releases.
Idea #1: Do not block on optical media issues for Alpha and Beta releases
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In my guesstimation, the intersection between people able and willing to test pre-releases and people not able to boot from USB or PXE is getting very small. My reasoning for this is:
a) PCs unable to boot from USB are becoming rare. They are probably only (or mostly) very old i386 machines.
b) Users testing pre-releases usually have above-average technical skills and/or are technical enthusiasts, who tend to own newer hardware.
c) We now have Fedora Media Writer for all major operating systems, which can burn the image onto a flash drive with a nice simple user interface, so even people who can boot from both optical drive and USB and used to prefer optical drive (because it was simpler for them) should be covered now with our super-easy USB writing tool.
Implementing this idea doesn't mean optical media would immediately get broken for Alphas and Betas. We would still care about such issues (it would be needed for Final, if nothing else) and we would still test it from time to time during the whole cycle (even though not that frequently - we would rely more on community involvement, e.g. similar to alternative architectures). But we wouldn't block the Alpha/Beta release on these issues, just the Final release.
Idea #2: Do not block on optical media issues for Final release for certain flavors/image types (Server, netinst)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a bolder variant of the previous idea and can be done separately or combined with it. It makes optical media functionality not guaranteed even for Final release, but just for certain Fedora flavors or image types for which it makes sense (not all of them). Which images to cover, that's the heart of the discussion. If you look into our test matrix again, we currently block on 6 of them:
* Workstation Live + netinst
* KDE Live
* Server DVD + netinst
* Everything netinst
What comes first to my mind is Server (DVD + netinst). My guess is that people don't install Server from optical media, but rather from PXE or USB. I can't imagine installing Server boxes from DVDs. But I'd really like to hear from Server users how this is likely or not. Also, Server is most probably not given away at events. I don't know about sending Server DVDs to the developing world, we can make an inquiry about that.
Second idea would be netinst media. They require good network access, so there's no point in shipping them to developing countries, and I can hardly imagine giving them away at events. They are targeted at more professional audience, which is likely to use more modern hardware. We could make an exception of Everything netinst, which is universal and could be used for cases where Live images don't work (netinst can use text mode in case of severe graphical issues even with safe graphics mode on, or perhaps on ultra-low memory configurations).
What do you think? Does it make sense, or is it too early for such a change?
(CCing test list, but let's keep the discussion in a single list only, i.e. devel)
[1] https://fedoraproject.org/wiki/Fedora_Release_Criteria
[2] https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Installation...
7 years, 4 months
libinfinity soname bump
by Till Maas
Hi,
libinfinity will be updated to 0.7.0 soon which includes a soname bump.
AFAICS nothing else depends on it.
Kind regards
Till
7 years, 4 months
Ruby packages free to grap
by Vít Ondruch
Hi all,
Michal Fojtík recently orphaned all his packages due to lack of the
resources to maintain them properly (thans to taking care of them). Feel
free to grab some:
rpms/deltacloud-core -- Deltacloud REST API ( )
rpms/rubygem-aws -- Ruby gem for all Amazon Web Services ( master
f25 f24 )
rpms/rubygem-cri -- Ruby library for building easy-to-use
commandline tools ( master f25 f24 )
rpms/rubygem-deltacloud-client -- Deltacloud REST Client ( master
f25 f24 )
rpms/rubygem-echoe -- A Rubygems packaging tool that provides Rake
tasks for documentation, extension compiling, testing, and deployment (
master f25 f24 )
rpms/rubygem-factory_girl -- Framework and DSL for defining and
using model instance factories ( master f25 f24 )
rpms/rubygem-openstack -- Ruby Openstack Compute and Object-Store
bindings ( master f25 f24 el6 )
rpms/rubygem-progressbar -- Ruby text progress bar generator library
( master f25 f24 )
rpms/rubygem-rack-accept -- HTTP Accept* for Ruby/Rack ( master f25
f24 el6 el5 )
rpms/rubygem-rerun -- Restarts your app when a file changes ( master
f25 f24 el6 el5 )
rpms/rubygem-right_aws -- Interface classes for the Amazon EC2/EBS,
SQS, S3, SDB, and ACF Web Services ( master f25 f24 )
rpms/rubygem-simple-navigation -- Ruby library for creating
navigation for your Rails or Sinatra application ( master f25 f24 )
rpms/rubygem-sinatra-rabbit -- Ruby DSL for creating restful
applications using Sinatra ( master f25 f24 el6 )
rpms/rubygem-will_paginate -- Pagination plugin for web frameworks
and other apps ( master f25 f24 el5 )
rpms/rubygem-xml-simple -- A simple API for XML processing ( master
f25 f24 el6 el5 )
Thanks
Vít
7 years, 4 months
Re: Headsup: Xserver update switching Intel GPUs from
xorg-x11-drv-intel to -modesetting by default coming to rawhide
by Dominik 'Rathann' Mierzejewski
On Thursday, 12 January 2017 at 12:56, Reindl Harald wrote:
> Am 12.01.2017 um 12:44 schrieb Dominik 'Rathann' Mierzejewski:
> > > Yes, we're just changing the default, if you drop a 99-local.conf file in
> > > /etc/X11/xorg.conf.d with the following contents:
> > >
> > > Section "OutputClass"
> > > Identifier "intel"
> > > MatchDriver "i915"
> > > Driver "intel"
> > > EndSection
> > >
> > > Then you should get the intel driver used for any GPUs using the i915
> > > kernel driver.
> >
> > How does one do the opposite (i.e. switch to the modesetting driver) on,
> > say, Fedora 25 running on Haswell? I'd like to test if that works around
> > a particularly annoying system freeze bug
> > (https://bugs.freedesktop.org/show_bug.cgi?id=98760)
>
> exactly the same way?
>
> [root@srv-rhsoft:~]$ cat /etc/X11/xorg.conf.d/02-intel.conf
> # Section "Device"
> # Identifier "Videocard0"
> # Driver "intel"
> # Option "AccelMethod" "uxa"
> # Option "TearFree" "true"
> # Option "DRI" "3"
> # EndSection
>
> Section "Device"
> Identifier "Videocard0"
> Driver "modesetting"
> Option "AccelMethod" "glamor"
> EndSection
Right, thanks. Unfortunately that doesn't help for the above bug.
One other thing. After switching to the modesetting driver, the
xrandr output names change (e.g. from HDMI1 to HDMI-1), which should be
documented as the existing head configurations will not work out of the
box after driver switch.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
7 years, 4 months
Applications with AppData and not visible in the software center
by Richard Hughes
We've been looking at the AppStream extractor issues in Fedora, and
we've come across a few broken applications. Broken apps are not
visible in the application installer. The apps include:
* albumart
* apitrace-gui
* appstream
* asylum
* audience
* bomber
* bovo
* calligra-braindump
* cervisia
* choqok
* classified-ads
* crrcsim
* cube
* curblaster
* dsi
* escape
* ettercap
* font-manager
* freedink-engine
* gap-core
* gnofract4d
* gvrng
* hgview
* hyperrogue
* kaddressbook
* key-mon
* kgraphviewer
* knotes
* konqueror
* LabPlot
* nextcloud-client (maybe fixed in distgit)
* openms
* openvibe
* owncloud-client
* pingus
* pioneer
* portecle
* qdigidoc
* qjackctl
* qsynth
* qtikz
* recoll
* renku
* rodent
* screengrab
* screenruler
* simple-ccsm
* slashem
* spectacle
* speed-dreams
* tennix
* tilp2
* tortoisehg
* trophy
* tzclock
* uzbl-defaults
* vdrift
* vegastrike
* wireshark-gtk
* xfce4-power-manager
* xfpanel-switch
* xskat
* yakuake
* zanshin
* zathura
The full list, along with what failed is available here:
https://dl.fedoraproject.org/pub/alt/screenshots/f26/failed.html
If you want any suggestions or advice, I'm happy to help. Most of the
failures are pretty self explanatory, e.g. "No <summary> in AppData"
or "icon was too small 24x24" -- our guidelines are here:
https://github.com/hughsie/appstream-glib/blob/master/README.md#guideline...
As a reminder, you can validate AppData files using: appstream-util
validate-relax file.appdata.xml
Thanks, and comments welcome. I can set up a script that sends email
to the package maintainer if this would be helpful, but I thought we
might be able to get the majority of these sorted with this email.
Richard.
7 years, 4 months
