devel January 2019

devel@lists.fedoraproject.org

211 participants
259 discussions

exiv2-0.27.0 coming to rawhide
by Rex Dieter 30 Jan '19

30 Jan '19

Will be working on bringing exiv2-0.27.0 to rawhide over the coming days. Includes both abi and minor api changes. Tracking progress in https://bugzilla.redhat.com/show_bug.cgi?id=1665246 in case anyone's aware of incompatibilities, can block that bug. Thanks. According to repoquery, affected packages include: $ dnf repoquery --whatrequires 'libexiv2.so.26()(64bit)' --repoid=rawhide ... berry-0:1.0.0-8.fc30.x86_64 darktable-0:2.6.0-2.fc30.x86_64 digikam-0:5.9.0-2.fc29.x86_64 geeqie-0:1.4-5.fc29.x86_64 gerbera-0:1.2.0-4.fc30.x86_64 gimp-lensfun-0:0.2.4-9.fc29.x86_64 gipfel-0:0.4.0-17.fc29.x86_64 gnome-color-manager-0:3.30.0-1.fc30.x86_64 gnome-commander-4:1.8.1-1.fc29.x86_64 gpscorrelate-0:1.6.1-25.fc29.x86_64 gthumb-1:3.6.2-1.fc30.x86_64 gwenview-libs-1:18.08.3-1.fc30.x86_64 hugin-0:2018.0.0-5.fc30.x86_64 immix-0:1.3.2-32.fc29.x86_64 kde-runtime-libs-0:17.08.3-9.fc29.x86_64 kf5-kfilemetadata-0:5.53.0-1.fc30.x86_64 kf5-libkexiv2-0:18.12.0-1.fc30.x86_64 kphotoalbum-0:5.2-7.fc29.x86_64 krename-0:5.0.60-1.fc30.x86_64 krita-0:4.1.7-2.fc30.x86_64 libextractor-plugins-exiv2-0:1.6-4.fc28.x86_64 libgexiv2-0:0.10.10-1.fc30.x86_64 librawstudio-0:2.1-0.19.20170414.g003dd4f_rawspeed.20161119.gfa23d1c.fc29.x86_64 luminance-hdr-0:2.5.1-15.fc29.x86_64 merkaartor-0:0.18.3-7.fc29.x86_64 nomacs-0:3.8.1-0.3.20180223git9b305e2.fc29.x86_64 oyranos-libs-0:0.9.5-27.fc29.x86_64 pdf2djvu-0:0.9.11-1.fc30.x86_64 photoqt-0:1.7.1-3.fc29.x86_64 phototonic-0:1.7.21-20161107git24d7b78.fc29.x86_64 pyexiv2-0:0.3.2-36.fc30.x86_64 python3-exiv2-0:0.3.0-2.fc29.x86_64 rawstudio-0:2.1-0.19.20170414.g003dd4f_rawspeed.20161119.gfa23d1c.fc29.x86_64 sir-0:2.5.1-17.fc29.x86_64 ufraw-0:0.22-14.fc29.x86_64 viewnior-0:1.7-3.fc29.x86_64

2 3

Outage 2019-02-02 13:00 UTC -> 15:00 UTC
by Stephen John Smoogen 30 Jan '19

30 Jan '19

This outage is a replacement of an earlier one in December which had to be cancelled. There will be an outage starting at 2019-02-02 13:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2019-02-02 13:00UTC' Reason for outage: Various switches at the colocation are needing updates and reboots to get latest firmware working. While the outage should not take the entire 2 hours, it is being blocked out in case there are problems which are not realized and need backing out or other changes. Affected Services: dl.fedoraproject.org all build services most web services copr and all other cloud services. Ticket Link: https://pagure.io/fedora-infrastructure/issue/7535 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen.

2 2

Self Introduction
by Samuel P 30 Jan '19

30 Jan '19

Hi Folks. My name is Samuel and I have been a user of Fedora for about 7 years now. I am a systems engineer co-maintaining my company's patching infrastructure, working closely with carlwgeorge. I use Fedora as my main workstation with special interest in both exotic display and audio configurations. I've had a lot of enjoyment tinkering with Fedora over the past few years using it as my workstation at the office along with the trials that come along with maintaining it as new releases become available. I currently run Fedora 28 on a few devices and plan on upgrading them to 29 over the next few months. Recently I've been working to get a piece of software known as "fpart" integrated into Fedora and eventually EPEL that I'd be looking to use to solve some automation tasks I deal with on a semi-regular basis. I can pull down the source and build it on my own but I'd prefer to take a cleaner approach of creating proper rpms and go through the process of getting them approved and released within the distribution itself along with maintaining the package as newer releases become available. At this point I'm looking for sponsorship to move to the next step of getting the package integrated; working with carlwgeorge I was able to clean up the package to approval status in the following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1650621 I would be appreciative of any sponsors willing to assist with these endeavors. Thanks. Samuel

1 0

Self Introduction: Gergely Gombos
by Gergely Gombos 30 Jan '19

30 Jan '19

Hi Fedora devs, My name is Gergely Gombos. I've been using Fedora for about 1.5 years and I'm a software developer. I like the FOSS philosophy and using a lot of open-source software in the Javascript world, I'd like to make my contribution, too. I'm looking for a sponsor, and my first RPM package is "pulseaudio-module-bluetooth-aptx" and its dependency "libldac". The original project <https://github.com/EHfive/pulseaudio-modules-bt> - yet to be merged into upstream Pulseaudio - provides awesome audio quality for Bluetooth headsets via aptX, AAC and LDAC codecs. This is something that is hard to set up even on Windows! And this package works seamlessly on Linux. Originally this was in a COPR repo, with >100 downloads, but it got deleted due to legal reasons (ffmpeg build dependency). So I hope it will find a new home in RPMFusion since Fedora users are waiting for it. One of its dependencies is the LDAC library *libldac* which may be eligible for the Fedora repos. The library has an Apache v2 license but Sony may have patented the algorithm - it requires licensing for hardware developers. I've spent quite a lot of time figuring out how RPM packaging works and get this working and (hopefully) conforming to the guidelines - I appreciate your review and help. And of course if this project succeeds, I'm more than happy to take part in further packaging projects. :) The package: libldac - #1671064 <https://bugzilla.redhat.com/show_bug.cgi?id=1671064> Thanks! Best regards, Greg

2 1

Organizing a "packager experience" objective and working group
by Ben Rosser 30 Jan '19

30 Jan '19

Hello, We had a recent discussion on this list last month about (among other things) the current state of Pagure as a replacement for pkgdb [1]. I mentioned in that discussion that there are various issues which have arisen from the deprecation of pkgdb that have made the packager workflow ever so slightly worse. But it's not just pkgdb-- there are lots of places where the packager workflow could use improvement. There are parts of the process that are tedious and manual which could be replaced with (partial) automation, or parts where automation exists but is in need of improvement. For example, there are tools (namely, the "fedora-review" script) to automate parts of the package review process. But fedora-review has been lagging behind the packaging guidelines for some time, and has to be manually ran by packagers over review requests. But, there's no reason we couldn't run fedora-review automatically over every package submission-- which might save both reviewers and submitters a lot of time. Or, as another example, there's currently a lot of work going on in the distribution to support new packaging formats-- like containers and modules. New workflows for making containers or modules out of existing packages are being created, and I think it's vital we make sure these workflows and processes are designed in such a way to make things as easy as possible for packagers. Anyway, as part of that discussion, I was encouraged to propose a new Fedora Community Objective focused on improving the packaging experience and workflow in Fedora. Community Objectives are approved by the Fedora Council and intended to be 12-18 month goals for the entire project. The goal of this Objective would be to identify problems with the current packager workflow(s), put together a group of packagers interested in fixing things, and then fix them! If this sounds like something you'd be interested in helping out with, great! The Objective will need two things, if it's to succeed: 1. People who are interested in helping! Some people did express interest in the other thread, but I thought I would put out a general call for interested packagers and volunteers. Anyone who is interested and thinks they'll have some available time is more than welcome. 2. A concrete list of goals to accomplish. What glitches are there in the current workflow, and how can they be fixed? What do you wish was simpler, or better, or easier to do? What, basically, would make your life easier a packager? I've written an initial draft proposal [2] on the wiki here, though the list of tasks to focus on is pretty sparse at present. If you are interested in helping out, please feel free to add your own thoughts as well. Sincerely, Ben Rosser [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [2] https://fedoraproject.org/wiki/Objectives/Packager_Experience

15 25

[HEADS UP] Removal of ldconfig scriptlets
by Igor Gnatenko 30 Jan '19

30 Jan '19

https://ignatenkobrain.fedorapeople.org/needless-scriptlets.txt Here's the list of packages which have dependency on /sbin/ldconfig with their respective maintainers for packages which do not install any files in /etc/ld.so.conf.d/. During this weekend, I'm going to clean all those packages to switch to the %ldconfig_scriptlets macro (which expands to something only on EPEL). Feel free to drop unneeded scriptlets before that date if you'd like to not have some cruft in your spec file. Thanks for attention!

5 7

Vagrant 2.2 with QEMU Session
by Ben Cotton 30 Jan '19

30 Jan '19

https://fedoraproject.org/wiki/Changes/Vagrant_2.2_with_QEMU_Session == Summary == Upgrade to Vagrant 2.2, the latest stable version of Vagrant. Enable QEMU Session by default. == Owner == * Name: [[User:pvalena | Pavel Valena]], [[User:vondruch | Vit Ondruch]] * Email: pvalena(a)redhat.com, vondruch(a)redhat.com * Release notes owner: == Detailed Description == Vagrant 2.2 is new upstream's major release, that includes many features, improvements, and and bug fixes. Using '''qemu:///session''' instead of '''qemu:///system''' Vagrant will run unprivileged. == Benefit to Fedora == * Enable QEMU Session by default. With this, there's no need for user to input any password, or be present in some group. Everyone is able to use Vagrant, regardless of group or other ACLs. * Add host support for void linux * Add support for VirtualBox 6.0 * Add command for uploading files to guest == Scope == * Proposal owners: ** Finish packaging Vagrant 2.2. Current changes: https://src.fedoraproject.org/rpms/vagrant/pull-request/17 ** Finish packaging Vagrant-Libvirt plugin. Current changes: https://src.fedoraproject.org/rpms/vagrant-libvirt/pull-request/3 ** Work has been done in a Copr repository: https://copr.fedorainfracloud.org/coprs/pvalena/vagrant/ * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issues #8085] ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Because of QEMU Session enabled by defailt, a failure occurs with if Vagrantfile contains: ``` test_vm.vm.network :private_network, :ip => "172.16.0.2" ``` or similar. Can be solved by setting `libvirt.qemu_use_session = false` in Vagrantfile. == How To Test == * No special hardware is needed. * Install Vagrant * Run ```vagrant version``` * Use your Vagrantfiles or create new as before * If something doesn't work as it should, let us know. == User Experience == New features that come with Vagrant 2.2 will be available. Users will not need to add themseles to any group, or have root ACLs and input a password every time they use Vagrant. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A (not a System Wide Change) == Documentation == https://www.vagrantup.com/docs/ == Release Notes == https://github.com/hashicorp/vagrant/blob/master/CHANGELOG.md -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

4 5

F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of performing any real operation
by Ben Cotton 30 Jan '19

30 Jan '19

Remove real functionality from encrypt, encrypt_r, setkey, setkey_r, and fcrypt from the libxcrypt.so.1 compatibility library and let those functions set "errno" to "ENOSYS" when invoked. == Owner == * Name: [[User:besser82 | Björn Esser]] <besser82(a)fedoraproject.org> == Detailed Description == In [[Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt | the system-wide change: "Fully remove deprecated and unsafe functions from libcrypt"]] we propose to remove the named functions from the system default so-version of the crypt library, which is a pre-requirement for this change. It basically is a follow-up announcing to remove the real functionality from those functions in the POSIX-compatibility version of the crypt library as well, and replace them with fully POSIX-compilant stubs, that properly indicate those functions are not supported. This change was basically filed, because it may require additional documentation apart from the system-wide change, that is a pre-requirement for this one. == Benefit to Fedora == Third-party applications, which still use / require these unsafe functions cannot use them anymore, which is the key benefit of this change for our users. == Scope == * Proposal owners: Implement the needed changes in the libxcrypt-compat package. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A, as this is a follow-up of an already evaluated system-wide change. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == N/A (not a System Wide Change) == User Experience == No impact, as nothing in the distribution uses those functions. Third-party applications that are distributed in pre-compiled / binary form only, may have a reduced set of features. Since POSIX explicitly states those functions shall set "errno" to "ENOSYS", if the functionality is not available nor implemented, third-party application that start to malfunction are broken by design. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == Revert the change and rebuild libxcrypt. == Documentation == The version of the libcrypt.so.1 library included with Fedora 30 for POSIX-compatibility has entirely removed the functionality of the encrypt, encrypt_r, setkey, setkey_r, and fcrypt functions, while keeping fully binary compatibility with existing (third-party) applications possibly still using those funtions. If such an application attemps to call one of these functions, the corresponding function will indicate that it is not supported by the system in a POSIX-compliant way. All existing binary executables linked against glibc's libcrypt should work unmodified with this version of the libcrypt.so.1 library supplied by the libxcrypt-compat package. == Release Notes == See the paragraph about documentation above. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

5 8

Re: Server Side Public License (SSPL) v1
by John Harris 30 Jan '19

30 Jan '19

How exactly is SSPLv1 "aggressively discriminatory towards people of a specific class"? How exactly did you determine that the purpose was to spread FUD, and what do you describe as "commercial users"? -- John M. Harris, Jr. <johnmh(a)splentity.com> Splentity https://splentity.com/

2 1

system-config-kickstart -- stay or go?
by David Cantrell 29 Jan '19

29 Jan '19

The system-config-kickstart package in Fedora is on a very low maintenance status at the moment. It is not really promoted much as a tool that people should use, however I know some people still use it (or at least did). But now we are at a cross roads. system-config-kickstart needs to move to Python 3.x which is going to be required by pykickstart soon. Currently system-config-kickstart is all in Python 2.x. Given the near-deprecation state of the software, I propose one of the following options: 1) Mark system-config-kickstart as obsolete in rawhide and remove it. It can then slowly fade away in the remaining supported releases branches it exists in. 2) Someone in the community who wants to keep it around volunteers to take over both ownership of the package and upstream maintainership. This individual would port system-config-kickstart to at least Python 3.x and continue maintaining it as long as people want it around. Thoughts? -- David Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. | Boston, MA | EST5EDT

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
26
Older →

Jump to page:

2026

2025

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 2019