devel January 2017

devel@lists.stg.fedoraproject.org

204 participants
254 discussions

Xulrunner - intent to remove from Fedora 24
by Martin Stransky 27 Jun '17

27 Jun '17

Hi, does anyone use the xulrunner package? (and gecko-devel actually). Mozilla does not maintain it any more and the XUL as technology is going to be removed/deprecated. I'd like to remove the package from Fedora 24. ma.

21 30

F25 Self Contained Change: IBus Emoji Typing
by Jaroslav Reznik 09 May '17

09 May '17

= Proposed Self Contained Change: IBus Emoji Typing = https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing Change owner(s): * Takao Fujiwara <tfujiwar [at] redhat [dot] com> The IBus core will provide the Emoji Unicode typing with the IBus XKB engines. == Detailed Description == IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now we think the similar implementation for the Emoji typging. With IBus XKB engines, Emoji typing will be provided with the Emoji annotations [1] following Ctrl- Shift-e. == Scope == * Proposal owners: - IBus core provide the dictionary of the Emoji typing. - IBus XKB engines load the Emoji dictionary. * Other developers: N/A * Release engineering: N/A - List of deliverables: N/A * Policies and guidelines: N/A * Trademark approval: N/A [1] http://unicode.org/emoji/charts/index.html#col-annotations

7 24

iproute package update policy
by Phil Sutter 14 Mar '17

14 Mar '17

Hi, So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports. But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support. Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system? Any comments/advice are highly appreciated. Thanks, Phil

7 13

whatever happened to yum + btrfs snapshotting?
by Neal Becker 13 Mar '17

13 Mar '17

Some time back there was discussion of being able to rollback yum updates via btrfs snapshotting. As I recall, it turned out that the default btrfs install was not setup correctly to make this feasible (I had briefly tested it on my machine). I haven't heard anything since - this seems like a great idea. -- -- Those who don't understand recursion are doomed to repeat it

7 7

Is Kalpa Welivitigoda still active at maintaining packages?
by Iiro Laiho 25 Feb '17

25 Feb '17

Hi, I am asking if anyone knows anything about the whereabouts of Fedora developer Kalpa Welivitigoda? He is the maintainer of unetbootin package. Bug 1229874 would need fixing, but it seems that he is not responding to the bug comments anymore. I tried to ask him about that matter via Facebook as well last Tuesday, but he doesn't seem to respond there either. – Iiro Laiho

3 2

Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide
by Hans de Goede 23 Feb '17

23 Feb '17

Hi, A while back Debian has switched to using the modesetting Xorg driver rather then the intel Xorg driver for Intel GPUs. There are several good reasons for this, rather then repeating them I'm just going to point to the Debian announcement: https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now… This mail is to let all Fedora users know that starting with Fedora-26 / rawhide as of today, we are making the same change. Note that the xorg-x11-drv-intel package has already been carrying a Fedora patch to not bind to the GPU on Skylake or newer, even before Debian announced this, this just makes the same change for older Intel GPUs. For people who are using the now default GNOME3 on Wayland session, nothing changes, since Xwayland always uses glamor for X acceleration, just like the modesetting driver. If you encounter any issues causes by this change, please file a bug in bugzilla. Regards, Hans

14 29

F26 Self Contained Change: Anaconda LVM RAID
by Jan Kurik 22 Feb '17

22 Feb '17

= Proposed Self Contained Change: Anaconda LVM RAID = https://fedoraproject.org/wiki/Changes/AnacondaLVMRAID Change owner(s): * Vratislav Podzimek (Anaconda/Blivet) <vpodzime AT redhat DOT com> * Heinz Mauelshagen (LVM) <heinzm AT redhat DOT com> Use LVM RAID instead of LVM of top of MD RAID in the Anaconda installer. == Detailed Description == In the current situation when a user chooses LVM (or Thin LVM) partitioning in the Custom Spoke and then sets RAID level for the VG Anaconda (and Blivet) create an MD RAID device which is used as a PV for the VG. With this change we are going to use LVM RAID directly instead. That means that all the LVs in that VG will be RAID LVs with the specified RAID level. LVM RAID provides same functionality as MD RAID (it shares the same kernel code) with better flexibility and additional features expected in future. == Scope == * Proposal owners: -- Blivet developers: Support creation of LVM RAID in a similar way as LVM on top of MD RAID. (Creation of RAID LVs is already supported.) -- Anaconda developers: Use the new way to create LVM RAID instead of creating LVM on top of MD RAID. -- LVM developers: LVM RAID already has all features required by this change. * Other developers: N/A (not a System Wide Change) * Release engineering: * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: * Trademark approval: -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

15 35

Is there something wrong with the Koji builders?
by Kaleb S. KEITHLEY 19 Feb '17

19 Feb '17

I've done two builds for rawhide this morning. On the first the armv7hl and ppc64le builds failed because the source tar file could not be unpacked. On the second the aarch64 build failed because the source tar file could not be unpacked. All the other arches built successfully. -- Kaleb

10 19

F26 System Wide Change: GCC7
by Jan Kurik 15 Feb '17

15 Feb '17

= System Wide Change: GCC7 = https://fedoraproject.org/wiki/Changes/GCC7 Change owner(s): * Jakub Jelínek <jakub AT redhat DOT com> Switch GCC in Fedora 26 to 7.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 27. == Detailed Description == GCC 7 is currently in stage3, will move to stage4 on January 19th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. We are working on scratch gcc rpms and will perform a test mass rebuild. == Scope == All packages should be rebuilt with the new gcc once it hits f26, or, if there is not enough time for that, just all packages built after the new gcc hits the buildroots. * Proposal owners: Build gcc in f26, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin, odb). * Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-7/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report. * Release engineering: Organize a mass rebuild, either in f26 or in f27 * Policies and guidelines: No policies need to be changed -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

5 4

Call to retire gstreamer-0.10
by Michael Cronenworth 13 Feb '17

13 Feb '17

Hi, As I'm sure everyone is well aware gstreamer-0.10 is obsolete and has been replaced by gstreamer-1.0. An upstream release for gst-0.10 has not been made in over 4 years. Last month there were a handful of security vulnerabilities disclosed[1] and upstream no longer maintains the 0.10 series. While we could patch and update our Fedora packages this is a perfect opportunity to retire it. Here is an approximate list of packages depending on gst-0.10. They themselves should be considered obsolete or retirement material as their upstreams may not have adopted gst-1.0. If the package doesn't have a gst-1.0 equivalent there may be some cases where we could patch in support for gst-1.0. Are there any non-Fedora software that would prevent retirement from being possible? anchorman banshee-community-extensions bigloo-libs clutter-gst compat-wxGTK3-gtk2-media drawtk evas-generic-loaders flumotion gcompris gloobus-preview gnome-mud gnomebaker gstreamer-devel gstreamer-ffmpeg gstreamer-plugins-bad gstreamer-plugins-bad-free gstreamer-plugins-bad-free-extras gstreamer-plugins-base gstreamer-plugins-base-tools gstreamer-plugins-good gstreamer-plugins-good-extras gstreamer-plugins-ugly gstreamer-python gstreamer-rtsp gstreamer-rtsp-python gstreamermm gstreamermm-devel ignuit iptux libgnome-media-profiles libnice-gstreamer lordsawar media-explorer moodbar oggconvert perl-GStreamer perl-GStreamer-Interfaces player pocketsphinx-plugin presence psimedia qt-mobility-multimediakit sap subtitleeditor vagalume winswitch wxGTK-media wxGTK3-media xfce4-mixer xfce4-volumed Thank you, Michael [1] https://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-advancing-expl…

18 34

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 January 2017