devel December 2017

devel@lists.stg.fedoraproject.org

168 participants
219 discussions

Proposed Fedora packaging guideline: More Go packaging
by nicolas.mailhot＠laposte.net 04 Mar '18

04 Mar '18

Hi, I am proposing for inclusion a set of rpm technical files aimed at automating the packaging of forge-hosted projects. - Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging - https://pagure.io/packaging-committee/issue/734 - go-srpm-macros RFE with the technical files: https://bugzilla.redhat.com/show_bug.cgi?id=1526721 This proposal is integrated with and depends on the https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft It builds on the hard work of the Go SIG and reuses the rpm automation of https://fedoraproject.org/wiki/PackagingDrafts/Go when it exists, and produces compatible packages. What it does: - drastically shorter spec files, up to 90% in some cases, often removing hundreds of lines per spec. - simple, packager-friendly spec syntax - automated package naming derived from the native identifier (import path). No more packages names without any relation with current upstream naming. - working Go autoprovides. No forgotten provides anymore. - working Go autorequires. No forgotten requires anymore. - strict automated directory ownership (used by autorequires and autoprovides). - centralized computation of source URLs (via Forge-hosted projects packaging automation). No more packages lacking guidelines. No more broken guidelines no one notices. - easy switch between commits, tags and releases (via Forge-hosted projects packaging automation). No more packages stuck on commits when upstream starts releasing. - guidelines-compliant automated snapshot naming, including snapshot timestamps (via Forge-hosted projects packaging automation). No more packages stuck in 2014. - guidelines-compliant bootstraping. - systematic use of the Go switches defined by the Go maintainer. Easy to do changes followed by a mass rebuild. - flexibility, do the right thing transparently by default, leave room for special cases and overrides. - no bundling (a.k.a. vendoring) due to the pain of packaging one more Go dependency. - centralized Go macros that can be audited and enhanced over time. - aggressive leverage of upstream unit tests to detect quickly broken code. Please consult packaging draft for full information. The proposal has been tested in Rawhide and EL7 over a set of ~ 140 Go packages. This set is a mix of current Fedora packages, bumped to a more recent version, rewrites of Fedora packages, and completely new packages. I hope posting the second part of the automation will answer some questions people had on the https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft Regards, -- Nicolas Mailhot

14 63

CUPS will change license since 2.3 version - now incompatible with GPLv2
by Zdenek Dohnal 27 Feb '18

27 Feb '18

Hi, CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses ) or try to argument with CUPS developers against this change on their mailing list cups(a)cups.org . Is there someone who is influenced by this change? -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C

17 43

package conflict with source package but not with binary package
by Till Hofmann 26 Jan '18

26 Jan '18

Hi all, I'm preparing Bear [1] as a Fedora package. Unfortunately, the package name bear is already taken by the bear engine [2], so I'm considering the best way to resolve this. Ubuntu [3], Debian [4], Arch (AUR) [5], and Mint [6] all package the compilation database (i.e., the package I'm working on) as bear, while the game engine (the current bear in Fedora) is usually packaged as bear-factory. IMHO, providing the compilation database as bear would be very beneficial, and anything else might be confusing for the users. I noticed that bear does not actually provide a bear package, but only bear-engine, bear-devel, and bear-factory. So, I'm wondering: 1. Can I add "Provides: bear = %{version}-%{release}", as bear does not provide a bear binary package? To me, this seems risky and confusing, but it would solve the issue. 2. If not, would it make sense to rename the current bear (source) package into something else, e.g., bear-factory, so we can use 'bear' for the compilation database? I also asked upstream about possible alternatives [7], and the best answer seems to be buildear, but imho that's far from ideal. Kind regards, Till [1] https://github.com/rizsotto/Bear [2] https://src.fedoraproject.org/rpms/bear [3] https://packages.ubuntu.com/trusty/devel/bear [4] https://packages.debian.org/sid/bear [5] https://aur.archlinux.org/packages/bear/ [6] https://community.linuxmint.com/software/view/bear [7] https://github.com/rizsotto/Bear/issues/198

2 2

Package review requests: Splitting the "sustmi" GNOME Shell extensions into separate packages
by Andrew Toskin 26 Jan '18

26 Jan '18

I'm the RPM package maintainer for these two GNOME Shell extensions: * gnome-shell-extension-sustmi-windowoverlay-icons * gnome-shell-extension-sustmi-historymanager-prefix-search They're both currently subpackages of the main "sustmi" package, because upstream had been developing them in a single git repository. The two shell extensions have nothing to do with each other, though, and upstream finally decided to split them into separate repositories. So I think it now makes sense to also split them into separate packages. I'm not entirely clear on the procedure. This wiki page https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splittin… talks at first about *font* packages, but otherwise seems relevant. So, I've started by splitting and updating the spec files, and creating these review requests. As I understand it, because the packages were already accepted into Fedora, and the extension code hasn't changed, just the packaging, I think all a reviewer should really need to check is whether the upgrade path is sane and works properly. * HistoryManager Prefix Search -- https://bugzilla.redhat.com/show_bug.cgi?id=1506428 * WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429 Please take a look, and let me know if I've missed anything. Thanks, ~ Andrew / terrycloth

2 3

F28 System Wide Change: Annobin
by Jan Kurik 24 Jan '18

24 Jan '18

= Proposed System Wide Change: Annobin = https://fedoraproject.org/wiki/Changes/Annobin Change owner(s): * Nick Clifton <nickc AT redhat DOT com> This change causes extra information to be stored in binary files compiled by gcc. This information can be used by scripts to check on various features of the file, such as the hardening options used of potential ABI conflicts. == Detailed Description == The plan is to use a plugin to gcc to record extra information in the object files it creates. This information can then be examined by static analysis tools. The information is recorded in a compact, extensible format, described here: https://fedoraproject.org/wiki/Toolchain/Watermark The Fedora annobin package is an implementation of the plugin for gcc. It also includes some example scripts that demonstrate how the recorded information can be used to, for example, check that an executable has been compiled with the correct hardening options, or detect if any conflicting ABI options have been used when compiling various parts of the executable. To enable this change it is proposed that the redhat-rpm-config package should be extended to add the "-fplugin=annobin" option to the __global_compiler-flags macro. In theory such a change will be completely invisible to Fedora users but should prove to be very helpful to Fedora Release Management, assuming that they like the idea of these annotated binaries. == Scope == * Proposal owners: Make sure the annobin plugin is ready. * Other developers: An update is needed to the redhat-rpm-config package in order for the plugin to be invoked when gcc is used to compile programs, and to add a dependency upon the annobin package. * Release engineering: https://pagure.io/releng/issue/7069 - Coordination with release engineering is needed. - A mass rebuild will be required. * List of deliverables: All delivered images are affected, however there no changes to the list it self. * Policies and guidelines: No updates needed * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

4 5

Re: [Bug 1529276] New: findbugs-contrib-7.2.0.sb is available
by Jerry James 23 Jan '18

23 Jan '18

On Wed, Dec 27, 2017 at 5:16 AM, <bugzilla(a)redhat.com> wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1529276 > > Bug ID: 1529276 > Summary: findbugs-contrib-7.2.0.sb is available > Product: Fedora > Version: rawhide > Component: findbugs-contrib > Keywords: FutureFeature, Triaged > Assignee: richardfearn(a)gmail.com > Reporter: upstream-release-monitoring(a)fedoraproject.org > QA Contact: extras-qa(a)fedoraproject.org > CC: loganjerry(a)gmail.com, richardfearn(a)gmail.com Why am I on the CC list for this bug? I haven't been a point of contact for this package since March 2010. -- Jerry James http://www.jamezone.org/

3 6

Rstudio
by Steve Grubb 20 Jan '18

20 Jan '18

Hello, I like to have everything on my system in a package. So, I looked around and found no recipe or rpm for Rstudio. This is really a shame because every tutorial on R kinda tells you to install it. Even the Coursera classes in the Data Science track make you install it and send a screenshot to prove it. So, I spent some time getting it packaged and working. I am placing the spec file and necessary patch here so that google finds it and saves other people the trouble. I'm not wanting to submit the package to Fedora because its more work than I have time for. If anyone else wants to take it from here and submit and/or maintain it, feel free. http://people.redhat.com/sgrubb/files/Rstudio/ Enjoy... -Steve

11 10

major elpa update (API and ABI incompatible)
by Dominik 'Rathann' Mierzejewski 14 Jan '18

14 Jan '18

Hi, I intend to update elpa to the latest version (2017.05.002) in rawhide. This is a major change from currently packaged 2015.11.001. It comes with a new API and is ABI-incompatible. Old APIs, especially some private functions which were exposed but not meant for public use by upstream have been removed. New API is described in USERS_GUIDE.md [1]. There are two consumers of elpa in Fedora: cp2k and openmx. I put the maintainers (myself included) of these packages on Cc in this announcement. While cp2k already supports this new elpa, openmx does not. There was some discussion about this in bug #1325933 [2] and upstream [3], but upstream seems to be reluctant to change anything, so in worst case scenario, openmx can switch to using the old bundled copy of elpa. [1] https://gitlab.mpcdf.mpg.de/elpa/elpa/blob/master/USERS_GUIDE.md [2] https://bugzilla.redhat.com/show_bug.cgi?id=1325933 [3] http://www.openmx-square.org/forum/patio.cgi?mode=view&no=2099 Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

1 1

Is there a "Python 3 is available" macro for spec files?
by Richard W.M. Jones 14 Jan '18

14 Jan '18

https://bugzilla.redhat.com/show_bug.cgi?id=1404631#c4 In this commit: https://src.fedoraproject.org/rpms/nbdkit/c/f38f61c339f925928e8cd6e52058196… I accidentally disabled Python 3 support on Fedora. Is there a better way to write this? What I really need is a pair of macros "Python 2 is supported" & "Python 3 is supported" which I can use to conditionalize the spec file. Maybe checking if %{__python2} and %{__python3} are non-empty? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

4 4

SciDAVis and liborigin3 vs liborigin & liborigin2 - bundle or obsolete?
by Alexander Ploumistos 12 Jan '18

12 Jan '18

Hello, Since its retirement from Fedora, SciDAVis[0] has undergone significant development and I think it is ready to be re-included in our package collection. After a few months of private builds that I distributed among co-workers and friends, I set up a copr[1] and I've been keeping up with the upstream project. SciDAVis comes with a bundled copy of liborigin[2], which the upstream developers helped me unbundle. Its version has been bumped to 3.0.0 internally, although there hasn't been a 3.0.0 release yet. In Fedora we carry liborigin2 (code from the latest public release) and liborigin (snapshot from 2008) which both help import different versions of Origin project files. The new release will render them both obsolete. SciDAVis and liborigin share a number of contributors, but at the moment their codebases have diverged; upstream liborigin trunk has been adjusted to work with development versions of LabPlot 2.x, while the copy bundled with SciDAVis is closer to that of a future liborigin-3.0.0 release, but they are not interchangeable. I asked the developers to clarify their plans and I was told[3] that the two versions will merge back, though some API changes might come in the meantime. I have checked if there are any packages at the moment that require liborigin* or liborigin*-devel and I have found none (though I'd be grateful if someone who feels more at ease with dnf could double-check). If not for this divergence, I would submit scidavis and liborigin3 for review as separate packages, with Provides & Obsoletes for the previous liborigin* and liborigin*-devel versions and be done with it. However I would have to use the unbundled copy from SciDAVis as source for liborigin3. Should I proceed with that anyway or should I keep it bundled until such time as the two codebases have merged? Best regards Alex 0. https://sourceforge.net/projects/scidavis/ 1. https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/ 2. https://sourceforge.net/projects/liborigin/ 3. https://sourceforge.net/p/scidavis/discussion/708155/thread/4c8da018/#cf6b

2 4

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