Update notice FEDORA-2013-13577 (von updates-testing) is broken, or a bad duplicate, skipping
by Reindl Harald
a few days ago i upgraded to F19 and my cron-script checking
for updates as well as "yum check-update" reports these
warnings - unsure where to report a bug because it's not
a specific package, so i post it here
Update notice FEDORA-2013-13577 (von updates-testing) is broken, or a bad duplicate, skipping.
You should report this problem to the owner of the updates-testing repository.
Update notice FEDORA-2013-15734 (von updates-testing) is broken, or a bad duplicate, skipping.
Update notice FEDORA-2013-15106 (von updates-testing) is broken, or a bad duplicate, skipping.
Update notice FEDORA-2013-14132 (von updates-testing) is broken, or a bad duplicate, skipping.
Update notice FEDORA-2013-14172 (von updates-testing) is broken, or a bad duplicate, skipping.
10 years, 5 months
Graphics driver support in F21+
by Adam Jackson
For F21, I plan to orphan the following X video drivers:
xorg-x11-drv-apm
xorg-x11-drv-cirrus
xorg-x11-drv-geode
xorg-x11-drv-glint
xorg-x11-drv-i128
xorg-x11-drv-i740
xorg-x11-drv-mach64
xorg-x11-drv-mga
xorg-x11-drv-neomagic
xorg-x11-drv-r128
xorg-x11-drv-rendition
xorg-x11-drv-s3virge
xorg-x11-drv-savage
xorg-x11-drv-siliconmotion
xorg-x11-drv-sis
xorg-x11-drv-tdfx
xorg-x11-drv-trident
Effectively this means that the graphics team will be focusing on KMS
for graphics support, with vesa and fbdev available as last-ditch
fallbacks. If anyone is interested in taking on support for these
chips, they're welcome to, though we would encourage anyone doing so to
work towards KMS support and not merely do "keep it building"
maintenance.
One other detail: the intel driver currently has both UMS support for
the i810 chipset, and KMS support for everything newer. To be
consistent with the above changes I'll be dropping the i810 support,
which will then fall back to vesa. Again, if someone wants to own the
i810 support, let me know and we can add you as a comaintainer.
- ajax
10 years, 5 months
Moving xine-lib and dependent apps to RPM Fusion Free for F17?
by Kevin Kofler
Hi,
the current xine-lib maintainer speaking. :-)
The Xine project:
http://www.xine-project.org/home
has recently released a new major version, version 1.2.0.
Unfortunately, among the list of changes:
http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/...
there are these new "features":
* Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms,
this makes use of libavutil even outside the FFmpeg decoding plugin,
but avoid duplication of algorithms between different plugins.
* Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed.
* FFmpeg is now required as an external dependency; if you want to build
xine-lib from source, please download a copy of FFmpeg from their SVN
server.
which basically mean that xine-lib now has a global, non-optional dependency
on FFmpeg's libavutil library.
So there are 4 possible ways forward:
(a) Stick with 1.1.x forever. I don't think that's a good idea in the long
run, upstream won't be providing security fixes for the old branch forever.
(b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't
think libavutil, as opposed to libavcodec, is actually patent-encumbered,
though that'd also have to be checked.) The issue there is that FFmpeg
upstream obviously doesn't support this. It would need some more black
packaging magic of the kind already done in xine-lib, and more legal
auditing. I don't think I want to investigate going down that road.
(c) Bundle parts or all of libavutil with xine-lib. Yuck!!!
(d) Move the whole thing (back) to RPM Fusion (where it originally was, before
we started needing xine-lib for Amarok and Phonon, which both no longer
use it). It would go to the Free section, of course.
My proposal is to go with (d).
The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.
In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git
repository, so it will likely have to move to RPM Fusion sooner or later
anyway. This means the affected packages are basically *xine*.
So my plan is to retire (for my packages, resp. have the respective maintainer
retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the
respective maintainer get) them into RPM Fusion Free instead. (I'd take care
of xine-lib and kaffeine myself, I hope the maintainers of the other packages
will take care of them.)
Comments? Objections?
Kevin Kofler
10 years, 5 months
packaging guidelines again
by Reindl Harald
i get somehow tired to report bugs for several packages,
refresh them at each release because maintainers
ignore guidelines all the time
some of them responded and fixed their packages
some insist to ignore them
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
If your package meets any of the following criteria you
MUST enable the PIE compiler flags:
* Your package is long running
* Your package runs as root
____________________________________________
since there is nobody logged in these are *all* long
running processes and enough of them even running as
root and so match *two* reasons for harden them
[root@srv-rhsoft:~]$ checksec --proc-all | grep "No PIE"
X 21342 Partial RELRO Canary found NX enabled No PIE
login 26045 Partial RELRO Canary found NX enabled No PIE
alsactl 642 Partial RELRO Canary found NX enabled No PIE
mdadm 651 Partial RELRO Canary found NX enabled No PIE
upowerd 704 Partial RELRO Canary found NX enabled No PIE
avahi-daemon 705 Partial RELRO Canary found NX enabled No PIE
rtkit-daemon 718 Partial RELRO Canary found NX enabled No PIE
pulseaudio 869 Full RELRO Canary found NX enabled No PIE
10 years, 6 months
F20 System Wide Change: ARM as primary Architecture
by Jaroslav Reznik
= Proposed System Wide Change: ARM as primary Architecture =
https://fedoraproject.org/wiki/Changes/ARM_as_Primary
Change owner(s): Dennis Gilmore <dennis(a)ausil.us>, Peter Robinson
<pbrobinson(a)gmail.com>
Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches
that we build and support. This will mean that all packages supported by the
ARM architecture must build for ARM to be released. With the release of Fedora
19 we have deprecated support for software floating support (ARMv5tel sfp) so
the only proposed addition to primary architectures is currently ARMv7
hardware floating point 32 bit support (ARMv7 hfp 32bit).
== Detailed description ==
The Changing IT landscape has started to focus on greener technologies as well
as cheaper mass produced devices that allow for fully functional cheap devices
for lower socio-economic areas and other markets like education and "makers".
ARM SoCs have traditionally been the domain of embedded and mobile
applications but are now finding their way into more traditional computing
devices like desktop, notebook and server markets. Fedora ARM currently works
on many different devices with wider support coming with each new mainline
kernel release.
For this change we will enable armv7hl builds on primary koji, and compose arm
trees as with the other primary architectures. Fedora has in the Phoenix data
centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will
remain allocated to the arm secondary architecture koji instance for building
updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of
life the ARMv5 softfp nodes will able to be be reallocated to other tasks.
Infrastructure has expressed an interest in testing and experimenting with
some of its workloads on ARM, some are allocated to QA and some for releng.
There is currently 24 nodes configured in primary koji ready to go as builders,
there is the capacity to add up to 24 more when ARM becomes primary if
desired.
The kernel is now a multi platform unified ARMv7 kernel supporting a number of
SoCs with support expanding with each new upstream release. We build a base
and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64)
kernel maintainer working in collaboration with the Fedora kernel team. The
releases are composed using the exact same tooling as used for the primary
architectures. Disk images for development boards are generated by appliance-
creator and the kickstarts live in spin-kickstarts, they take a similar format
as the livecds on primary but are shipped as an OEM disk image, and like
primary initial-setup is used to do final user configuration. Like primary pungi
is used to generate an install tree, PXE install trees are created but current
bootloaders don't support isofs so ISO images aren't currently created.
== Scope ==
Add armv7hl to list of arches for f20-build and future build tags in koji
compose armhfp trees with i386 and x86_64. Requisite build hardware already
exists in phx2 and is configured to work with mainline koji.
Proposal owners: change the arches in koji, import the matching ARMv7 rawhide
builds into koji. Update Release Engineering scripts to automatically build
armhfp trees along with i686 and x86_64.
Other developers: submit builds as normal, in the event of unexpected build
failures liaise with the ARM Team to help debug and fix issues.
Release engineering: Will need to add armhfp to the release processes and make
arm install trees and disk images with each milestone compose. Release
Engineering are part of the team of people proposing the Change.
Policies and guidelines: armv7hl builds will be required to complete for
builds to be successful in koji
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 6 months
anaconda / initial-setup / gnome-initial-setup: can we do this better?
by Adam Williamson
So I'm writing a blog post on this topic ATM, and that really kinda
brought home how messy this design is at present.
Quick refresher for anyone who hasn't looked at it much yet: in F19,
anaconda can create user accounts, and 'firstboot' has been replaced
with two alternative tools, 'initial-setup' which is used in any
graphical install other than a GNOME install and just replicates
anaconda's 'root password', 'user creation' and 'date/time' spokes, and
gnome-initial-setup, which is used in GNOME installs and is its own
whole thing that can also do user creation.
I mapped out all the potential paths through this maze, and got this -
16(!!!) paths:
anaconda: root pw, no user - g-i-s: admin user
i-s: admin user
i-s: regular user
console: root
anaconda: root pw, regular user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: regular user + root
anaconda: root pw, admin user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: admin user + root
anaconda: no root pw, admin user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: admin user + root
Note the paths marked "i-s: edit root pw or user" are pretty messy and
open ended in themselves - initial-setup always runs if installed, no
matter what you set in anaconda, and at least theoretically lets you
change the settings you picked in anaconda.
This is...kinda nuts, and a QA nightmare. Can we maybe take a step back
and look if there's a more sensible way to design this, ideally with the
GNOME and anaconda teams working together?
If we imagined initial-setup didn't exist and we only had the
anaconda/g-i-s case, the proliferation of trees at least looks rather
better, because g-i-s can't set the root password or change what
anaconda did; if you create a user account during anaconda, g-i-s runs
only after you log in with that user account and just lets you configure
various settings for that user account, it doesn't let you create other
user accounts (this is what I've labelled as 'g-i-s: user mode' in the
tree). So the anaconda/g-i-s paths are broadly sane already. It's the
anaconda/i-s paths that are really complicating things. Still, it might
help to just take a step back and decide if we really need all this
flexibility. We could, for instance, simply force user creation during
anaconda, dump initial-setup entirely, and use only
gnome-initial-setup's "user mode" (desktops other than GNOME could
implement something like this "user mode" if they wanted to, or not).
That would be a hell of a lot simpler to code, test, support and
explain, with the minor(?) drawback that you couldn't install without a
user account and then create it on first boot any more. Xkcd Law tells
us that someone will not be happy about this:
https://xkcd.com/1172/
but still, it seems to be worth considering. Alternatively, we could
make i-s behave a lot more like g-i-s: it could dump its 'root password'
and 'date/time' spokes, and only run at all, and only to allow user
creation, if you didn't create a user during anaconda.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10 years, 6 months
