Escaping macros in %changelog
by Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello everyone,
It seems that a lot of people have %file, %check, %build, %whatsoever in their
changelog section.
Is there any reason I should not go and automatically escape them?
%check → %%check
%build → %%build
%whatsoever → %%whatsoever
There might be valid use-cases, but I'm not sure if they really are:
%{_localstatedir}/ft/ → %%{_localstatedir}/ft/
Thoughts?
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp8dIIACgkQaVcUvRu8
X0zOaA//WIbQAPp0ZjyWEEVAOl3d0EsG6y2Pk38B2K2ubFY8SYzJzpaZdAv3Lkdz
wJDA0rSdLrfNGRKzuEIpciGX03tCRSGENg6XeUT4mGjFPIsN467F0sC9RHkH5nWM
2H1weD4K1MeukqcvEWU8vJjyB+Wqd8qtFKGgpypp+d5jMh1ZOCeJbul4raRzQjGu
mvIVI1Qvg9x/3ZdNKk1GQdBslVRZqq/r+QLubkFjq04abAW1E3Dr5rFnRN+fWhQ7
E56UcuWxuJk21JG6LxRjNeDCMvqwHMZ44So1MqxIxGTPVHlucustNTnJwVFSLMEm
j7iPN4o9PxKew786Pm0/ggw6b49Y1w4ElzdFX6sfzQG4tAWu5Pa10paqUZyn/4IR
RpqQhOyhXjqv1DxN5z+CGvgZNps/CtIXTE9HNG1Gs1bi3taX4tHOh8bpXVlj+ocw
+03Q67LrgFVaqYaKfxW1jgfuvCRWUu3mdz16tx0W5ZuMkDgsq9H6ByYcVR8v/4Ly
W+jL/H6kYzzviCu6k+hlOGccw9PKuhN9Iwg2wmQ100QiKIU58SKlb27YqlmRDVLz
12jl1R9qzLwR9A+yDbkQqxABPKNvOdY4RPOoqMKVGb0ZRuwMsVDLofVYpcnCBfIB
wd8Rs9Kj36PxOO+HrHXKF05qRy2hOYiniS4XncmqPiFitd8GPQ4=
=rcey
-----END PGP SIGNATURE-----
6 years, 1 month
-z defs linker flag activated in Fedora rawhide
by Florian Weimer
I updated redhat-rpm-config to instruct ld to reject linking shared
objects with undefined symbols. Such undefined symbols break symbol
versioning because the are not necessarily bound to the correct symbol
version at run time. (rhbz#1535422)
### Disable strict symbol checks in the link editor (ld)
By default, the link editor will refuse to link shared objects which
contain undefined symbols. In some cases (such as when a DSO is
loaded as a plugin and is expected to bind to symbols in the main
executable), undefined symbols are expected. In this case, you can
add
%undefine _strict_symbol_defs_build
to the RPM spec file to disable these strict checks. Alternatively,
you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
command line). The latter needs binutils 2.29.1-12.fc28 or later.
This is also part of the build flags documentation at:
<https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildf...>
Thanks,
Florian
6 years, 1 month
Trying out More Go Packaging: Bugs and Questions
by Fabio Valentini
Hi everybody,
I've been following the (long overdue) improvements concerning go packaging
in fedora, and since I saw that packages are starting to make use of the
new mechanisms, I wanted to finally check it out and started "converting"
one of my own (one of ~50) golang packages
(golang-github-AudriusButkevicius-cli). However, I came across a few
stumbling blocks (and at least one bug) in the current implementation
(please correct me if I am just doing it wrong):
1) The currently implemented macros have different names than the ones that
were proposed at the "More Go Packaging" wiki page, which confused me. I
had to look at a recently "converted" package to figure out the correct
macro names. I guess the documentation just hasn't caught up yet here.
2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".
3) The %gosource macro doesn't work correctly (at least for github
sources). The "/archive/" part between the "import path" and "%{commit}" or
"%{version}" is missing as far as I can see.
4) The downloaded tarball has potentially ambiguous names, for example one
of my golang packages (github.com/AudriusButkevicius/cli) produces a
"cli-%{shortcommit}" or "cli-%{version}.tar.gz" tarball when using
%gosource, which is why I manually changed the link to
AudriusButkevicius-cli-*.tar.gz back when I generated the .spec file with
gofed. I suggest using both project and repository names for determining
the tarball name to avoid confusion and name clashes.
5) I couldn't figure out how to correctly handle the "post-release
snapshot" case, where both "Version" and "%commit" have to be set. The
macros just generated a Release tag like for packaging a released version,
ignoring the "commit" tag completely.
6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files (and
warnings about duplicate files) - well, it's a source-only library package,
how do I specify this with the new macros?
I hope those issues are only part of the "transitional period", because I'd
really like to clean up my go package .spec files going forward.
The contents of the .spec file at the point where I gave up trying to get
it to build successfully are available via this gist link:
https://gist.github.com/decathorpe/366daeb50e889fcd9153eedb1b761804
Fabio
6 years, 1 month
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
Call for users of darkserver
by Pierre-Yves Chibon
Good Morning Everyone,
The week before DevConf, a number of the members of the Fedora Infrastructure
met in Brno to discuss states and plans for the infrastructure.
One of the question that raised was about darkserver.
This application is available at: https://darkserver.fedoraproject.org/
and is meant to:
enable developer tools to identify exact package builds from which process
images (e.g. core dumps) come. This can enable their analysis, debugging
profiling, by finding out where the rpm / elf / dwarf files may be found, so
they can download them. (This is even better than
abrt-action-install-debuginfo-to-abrt-cache because that apparently cannot query
files no longer indexed by repodata.)
Source: https://fedoraproject.org/wiki/Darkserver
However, it seems this application has not been working for a long time now and
not many people asked about it.
So, is anyone using this service?
If there is little interest for this project, we will likely decommission it in
the coming weeks (say end of March).
Thanks for your attention and your feedback,
Pierre
For the Fedora Infrastructure team
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
6 years, 1 month
389-ds-base and freeipa on 32 bit arches
by Randy Barlow
Greetings gcc maintainers!
A FESCo issue[0] has been filed due to the dropping of 389-ds-base and
freeipa on 32 bit arches for Fedora 28. This was done without a change
request being filed, so FESCo is trying to decide how best to handle it.
It seems there are some concerns about whether the C tooling correctly
handles some cases for 32-bit arches that led to the decision by the IPA
maintainers to drop support for 32-bit. FESCo would like to ask for the
GCC maintainers' input on the issue.
Thanks in advance for your feedback!
[0] https://pagure.io/fesco/issue/1845
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1544386
6 years, 1 month
Add ability to check ABI compliance from fedpkg?
by Richard Shaw
I don't have to do it for many of my packages, but I do regularly check ABI
compliance before performing an update so I know if I need to rebuild
dependencies or not.
Currently my workflow is something like:
$ cd abicompare/<pkgname>
$ mkdir <oldver> <newver>
$ cd <oldver> (unpack pakage and -devel package)
(same for <newver>)
$ abi-compliance-checker -l <package> -vnum <newver> -dump <newver>
$ abi-compliance-checker -l <package> -vnum <oldver> -dump <oldver>
$ abi-compliance-checker -l <package> -old <oldabidump_dir> -new
<newabidump_dir>
$ scp -r <html_report> <fedorapeople>:public_html/compatibility_report/
It would be REALLY nice to automate this to any extent possible PRIOR to
actually building a package (fedpkg <scratch-build | mockbuild>).
I'm partial to abi-compliance-checker because I maintain it and I know how
to interpret the results but any equivalent tool would be fine :)
Thanks,
Richard
6 years, 1 month
