devel September 2013

devel@lists.stg.fedoraproject.org

247 participants
293 discussions

Graphics driver support in F21+
by Adam Jackson 28 Oct '13

28 Oct '13

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

15 29

ABRT is filling private bugs
by Jiri Moskovcak 24 Oct '13

24 Oct '13

Hi, as some of you already noticed ABRT started filling a private bugs which are only readable by reporter and assigned developer. This is an unfortunate UX design together with [1]&[2]. Fixing those two bugzillas should help, but there will always be a possibility that user will create a private bz ticket which I think is a good thing. However if you have some idea how to make this a less pain for developers and still allow users to create private tickets, I'm all ears. Thank you, Jirka 1. https://bugzilla.redhat.com/show_bug.cgi?id=1011916 2. https://bugzilla.redhat.com/show_bug.cgi?id=1009730

3 3

Moving xine-lib and dependent apps to RPM Fusion Free for F17?
by Kevin Kofler 24 Oct '13

24 Oct '13

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/vi… 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

4 15

packaging guidelines again
by Reindl Harald 21 Oct '13

21 Oct '13

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/Guidelines… 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

2 3

Taking owner ship of mod_scgi: re-review, and rutorrent review swap
by Ankur Sinha 16 Oct '13

16 Oct '13

Hi, mod_scgi was orphaned quite a while back since it wouldn't build on new releases, with the new apache. I found a set of patches in the suse rpm that fix the build. I'd like to get mod_scgi back into the repos. It's required by most rtorrent front ends, like rutorrent that I've just submitted for review. I'll be more than happy to co-maintain this module with someone more knowledgeable with apache and friends :) Bugz: https://bugzilla.redhat.com/show_bug.cgi?id=1013485 - mod_scgi re-review https://bugzilla.redhat.com/show_bug.cgi?id=1013488 - rutorrent Review swaps are welcome as always. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

2 1

boost141 and stability of Boost API?
by Dave Johansen 15 Oct '13

15 Oct '13

I just noticed that the boost141 package had been previously available in Fedora, but it has since been removed ( https://fedorahosted.org/rel-eng/ticket/5291 ). I'm not familiar with the recent changes in Boost, but is the API stable enough to support a package to build on EL 5/6 and Fedora? Thanks, Dave

4 6

F20 System Wide Change: ARM as primary Architecture
by Jaroslav Reznik 15 Oct '13

15 Oct '13

= 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

48 256

anaconda / initial-setup / gnome-initial-setup: can we do this better?
by Adam Williamson 15 Oct '13

15 Oct '13

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

14 37

yum picking kernel-debug instead of kernel for 'BuildRequires: kernel'
by Richard W.M. Jones 13 Oct '13

13 Oct '13

If two packages 'provide' the same dependency, isn't yum supposed to pick the one with the shortest name? Anyway, 'BuildRequires: kernel' in Rawhide (on koji) picks 'kernel-debug' instead of 'kernel'. Is there a way to make it pick 'kernel' instead? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

2 2

GPG verification in SPECs
by Till Maas 11 Oct '13

11 Oct '13

Hi, upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at https://build.opensuse.org/package/show/Base:System/gpg-offline They allow to use a keyring and detached signature as additional source in SPECs to get both verified. Since gpg-offline's upstream is willing to create a proper release to allow easy packaging for Fedora, I wonder if I will find any obstacles when I package it. The packaging guidelines allow packaging RPM macros, therefore this should be fine. Also I am interested whether there are better options available. Regards Till

9 13

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2013