devel February 2018

devel@lists.fedoraproject.org

237 participants
244 discussions

-z defs linker flag activated in Fedora rawhide
by Florian Weimer 09 Mar '18

09 Mar '18

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/buildfla…> Thanks, Florian

22 57

Trying out More Go Packaging: Bugs and Questions
by Fabio Valentini 08 Mar '18

08 Mar '18

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

5 19

Attempting to contact unresponsive maintainers - xing, noriko, aortega, jcholast, mzatko
by Kevin Fenzi 06 Mar '18

06 Mar '18

Greetings, we've been told that the email addresses for these package maintainers are no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them in 1 week, I'll have FESCo orphan the packages so that others can take them over. If you have a way to contact these maintainers, please let them know that we'd appreciate knowing what to do with their packages. Thanks! xing: https://src.fedoraproject.org/user/xning Projects: https://src.fedoraproject.org/rpms/perl-Pod-Plainer [product: Fedora] noriko: Projects: translation-quick-start-guide [product: Fedora Documentation] Japanese [ja] [product: Fedora Localization] aortega: Projects: qpidpy [product: Fedora] qpidrb [product: Fedora] jcholast: https://src.fedoraproject.org/user/jcholast Projects: peervpn [product: Fedora] mzatko: https://src.fedoraproject.org/user/mzatko Projects: arandr [product: Fedora] rubygem-slim [product: Fedora] rubygem-awesome_print [product: Fedora] rubygem-colored [product: Fedora] arm-none-eabi-gdb [product: Fedora] kevin

4 4

Proposal to increase the beta freeze to 3 weeks
by Randy Barlow 05 Mar '18

05 Mar '18

Greetings fellow Fedorans! During today's FESCo meeting[0], there was discussion around a proposal to increase the freeze period from 2 weeks to 3 weeks[1]. Several members of FESCo thought this proposal might be unpopular with Fedora developers, so a compromise proposal was made: increase the beta freeze to 3 weeks, but keep the stable freeze at 2 weeks[2]. We would like to ask for feedback from the Fedora community about this proposal. Feel free to reply here, or comment on the FESCo ticket. Thanks in advance for your thoughts! [0] https://meetbot.fedoraproject.org/fedora-meeting/2017-11-17/fesco.2017-11-1… [1] https://pagure.io/fesco/issue/1790 [2] https://pagure.io/fesco/issue/1790#comment-480090

6 8

Schedule for Friday's FESCo Meeting (2018-03-02)
by Zbigniew Jędrzejewski-Szmek 05 Mar '18

05 Mar '18

Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00 UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-03-02 15:00 UTC' Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #1846 F28 approved Changes not in MODIFIED status (considered as not testable) .fesco 1846 https://pagure.io/fesco/issue/1846 #topic #1845 389-ds-base and freeipa on 32 bit arches .fesco 1845 https://pagure.io/fesco/issue/1845 #topic #1820 Adjust/Drop/Document batched updates policy .fesco 1820 https://pagure.io/fesco/issue/1820 = New business = self contained changes: #topic #1856 F29 Self Contained Change: FedoraScientific VagrantBox .fesco 1856 https://pagure.io/fesco/issue/1856 #topic #1854 F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark .fesco 1854 https://pagure.io/fesco/issue/1854 #topic #1852 F29 Self Contained Change: No more automagic Python bytecompilation .fesco 1852 https://pagure.io/fesco/issue/1852 #topic #1851 F29 System Wide Change: Remove GCC from BuildRoot .fesco 1851 https://pagure.io/fesco/issue/1851 #topic #1850 F29 Self Contained Change: True Noarch Erlang Packages .fesco 1850 https://pagure.io/fesco/issue/1850 #topic #1855 F29 Self Contained Change: BINUTILS 2.30 .fesco 1855 https://pagure.io/fesco/issue/1855 #topic #1853 F29 System Wide Change: Enable dbus-broker .fesco 1853 https://pagure.io/fesco/issue/1853 other topics: #topic #1848 Request to Authorize Removal of Blender Source Tarballs from Incorrect Place in Repository .fesco 1848 https://pagure.io/fesco/issue/1848 #topic #1843 FAS bot account sponsoring .fesco 1843 https://pagure.io/fesco/issue/1843 #topic The time of the next meeting. Fesco members, please respond to the whenisgood poll! = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

2 2

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

Call for users of darkserver
by Pierre-Yves Chibon 02 Mar '18

02 Mar '18

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

4 10

389-ds-base and freeipa on 32 bit arches
by Randy Barlow 02 Mar '18

02 Mar '18

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

4 5

Add ability to check ABI compliance from fedpkg?
by Richard Shaw 01 Mar '18

01 Mar '18

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

2 1

Should we have a release manager for each release? (or, "who owns rawhide"?)
by Matthew Miller 01 Mar '18

01 Mar '18

As shown at https://www.happyassassin.net/nightlies.html, we haven't had a successful compose for almost two weeks. AIUI this is mostly worked out now, but it raises the question: who should be keeping track of this and coordinating fixes? For the releases, the blocker bug process basically handles this, so functionally the ownership ends up with QA (and the various heroes of QA who then track down all the problems). For rawhide, we don't have any such thing. Is it rel-eng? Is it FESCo? Is it the FPgM? Is it QA after all? I suspect that right now, the answer is kind of "It's all of us together", which unfortunately practically speaking often comes down to 0.02% per person and rounds down to 0. Or if the answer is: "Matthew, you are the FPL. It's you!" … then fine, but I'm going to then have to find some way to turn around and delegate. :) I was chatting with Kevin Fenzi and he suggested naming a release manager for each release — someone who would keep track of stuff starting at branch, and help coordinate things like this. This would help with more than just Rawhide — I'm sure everyone involved in the blocker bug process would be grateful for more help. At least, if it was someone who isn't already deeply involved in that. I'm thinking probably someone selected from FESCo — but it also could be a way for people with the particular set of skills required here to get involved in a way that's different from FESCo membership. What do you think? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

18 41

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 February 2018