Proposed Fedora packaging guideline: More Go packaging
by nicolas.mailhot＠laposte.net
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
6 years, 1 month
CUPS will change license since 2.3 version - now incompatible with
GPLv2
by Zdenek Dohnal
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
6 years, 1 month
package conflict with source package but not with binary package
by Till Hofmann
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
6 years, 2 months
Package review requests: Splitting the "sustmi" GNOME Shell
extensions into separate packages
by Andrew Toskin
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_splitt...
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
6 years, 3 months
F28 System Wide Change: Annobin
by Jan Kurik
= 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
6 years, 3 months
Re: [Bug 1529276] New: findbugs-contrib-7.2.0.sb is available
by Jerry James
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/
6 years, 3 months
Rstudio
by Steve Grubb
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
6 years, 3 months
