packaging February 2018

packaging@lists.fedoraproject.org

12 participants
15 discussions

help with first package (extractpdfmark, bug 1520922)
by Federico Bruni 05 Feb '18

05 Feb '18

Hi all I've recently submitted my first package here: https://bugzilla.redhat.com/show_bug.cgi?id=1520922 I need some pointer to figure out how to solve a few issues highlighted by the reviewer. There's a lot of information in Fedora wiki, but it's quite overwhelming. I've read a lot, but cannot find the information I need. The problems still to be solved are: [!]: Package does not own files or directories owned by other packages. Note: Dirs in package are owned also by: /usr/lib/.build-id(iputils, efivar-libs, gd, gc, libtomcrypt, gdbm, gpgme, rpm-plugin-selinux,[... cut] [!]: %build honors applicable compiler flags or justifies otherwise. [!]: Package contains no bundled libraries without FPC exception. [!]: Package complies to the Packaging Guidelines BTW, rpmlint does not spot these errors. So I've tried fedora-review and run this command in my RPM package directory: fedora-review --define DISTTAG=fc27 -p -n extractpdfmark and I see that above problems are set to "manual review needed". So the errors were spotted by the reviewer, not by any tool. Back to above problems, the errors related to the libraries are probably about the .build-id directory, but I cannot figure out what should I do. $ rpm -ql x86_64/extractpdfmark-1.0.2-1.fc27.x86_64.rpm /usr/bin/extractpdfmark /usr/lib/.build-id /usr/lib/.build-id/41 /usr/lib/.build-id/41/8cd205d31cf37c25cec9711715265e6c00726b /usr/share/doc/extractpdfmark /usr/share/doc/extractpdfmark/COPYING /usr/share/doc/extractpdfmark/README.ja.md /usr/share/doc/extractpdfmark/README.md /usr/share/licenses/extractpdfmark /usr/share/licenses/extractpdfmark/COPYING /usr/share/man/man1/extractpdfmark.1.gz Thanks in advance Federico

6 16

Summary/Minutes from today's FPC Meeting (2018-02-01 17:00 - 18:00 UTC)
by James Antill 01 Feb '18

01 Feb '18

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 17:00:41 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2018-02-01/fpc.2018- 02-01-17.00.log.html . Meeting summary --------------- * Roll Call (geppetto, 17:00:41) * Schedule (geppetto, 17:05:07) * LINK: https://lists.fedoraproject.org/archives/list/packaging@lists.fedor aproject.org/message/AHRSA6QDS32YGV65QYA5KR4OB4JJHR3A/ (geppetto, 17:05:08) * #654 glibc file triggers (geppetto, 17:07:34) * ACTION: Policy changes due to glibc file triggers from the ticket (+1:5, 0:0, -1:0) (geppetto, 17:15:03) * #702 C/C++ guidelines should say using clang needs an exception (geppetto, 17:15:38) * Policy already says to use GCC if it's possible, which seems strong enough. (geppetto, 17:20:34) * #733 'users and groups' should link to prealloc. list (geppetto, 17:21:29) * Open Floor (geppetto, 17:25:55) * LINK: https://pagure.io/packaging-committee/issue/725 (tibbs, 17:39:52) Meeting ended at 18:00:03 UTC. Action Items ------------ * Policy changes due to glibc file triggers from the ticket (+1:5, 0:0, -1:0) Action Items, by person ----------------------- * **UNASSIGNED** * Policy changes due to glibc file triggers from the ticket (+1:5, 0:0, -1:0) People Present (lines said) --------------------------- * tibbs (87) * geppetto (62) * mbooth (18) * limburgher (16) * zodbot (12) * Rathann|Mobile (9) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Schedule for Thursday's FPC Meeting (2018-02-01 17:00 UTC)
by James Antill 01 Feb '18

01 Feb '18

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2018-02-01 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2018-02-01 09:00 PST US/Pacific 2018-02-01 12:00 EST --> US/Eastern <-- 2018-02-01 17:00 GMT Europe/London 2018-02-01 17:00 UTC UTC 2018-02-01 18:00 CET Europe/Berlin 2018-02-01 18:00 CET Europe/Paris 2018-02-01 22:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2018-02-02 01:00 HKT Asia/Hong_Kong 2018-02-02 01:00 +08 Asia/Singapore 2018-02-02 02:00 JST Asia/Tokyo 2018-02-02 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #654 glibc file triggers .fpc 654 https://pagure.io/packaging-committee/issue/654 #topic #691 noarch *sub*packages with arch-specific dependencies .fpc 691 https://pagure.io/packaging-committee/issue/691 #topic #693 Wiki:Packaging:RPMMacros .fpc 693 https://pagure.io/packaging-committee/issue/693 #topic #694 Packaging guidelines for application independence .fpc 694 https://pagure.io/packaging-committee/issue/694 #topic #702 C/C++ guidelines should say using clang needs an exception .fpc 702 https://pagure.io/packaging-committee/issue/702 #topic #708 Allocating a static uid and gid for openvswitch .fpc 708 https://pagure.io/packaging-committee/issue/708 #topic #710 Ruby packaging guidelines update .fpc 710 https://pagure.io/packaging-committee/issue/710 #topic #713 Forward-looking conditionals by default .fpc 713 https://pagure.io/packaging-committee/issue/713 #topic #714 let's kill file deps! .fpc 714 https://pagure.io/packaging-committee/issue/714 #topic #715 Separately building package documentation .fpc 715 https://pagure.io/packaging-committee/issue/715 #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 #topic #723 Guidelines for handling deprecated dependencies during review .fpc 723 https://pagure.io/packaging-committee/issue/723 #topic #726 Review for SELinux Independent Policy packaging Draft .fpc 726 https://pagure.io/packaging-committee/issue/726 #topic #733 'users and groups' should link to prealloc. list .fpc 733 https://pagure.io/packaging-committee/issue/733 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://pagure.io/packaging-committee , 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.

1 0

Re: <DKIM> Re: Proposed Fedora packaging guideline: More Go packaging
by nicolas.mailhot＠laposte.net 01 Feb '18

01 Feb '18

De: "Owen Taylor" > I'm embarrassed to admit that before I sent my mail I carefully read over > ... the old PackageDrafts/Go :-( My only excuse is that it was in my > browser history. NP, that gave you some context on where Fedora is today. > Having actually read the relevant parts of "More Go Packaging", the > explanation of compat packages and notification procedures does make the > intended operation clearer, Thank you. Do not hesitate to improve the wording in the wiki, or post suggestions here, if you have ideas on how to make it clearer, simpler or more efficient > though the social and technical barrier to a > packager new to Fedora will still be high if packaging their target package > requires creating a compat package and fixing multiple other packages. Unfortunately, packaging something in Go is still going to be harder than packaging software in another language in the near term :( I'd love to find more magic bullets. > I still worry that Fedora is not big enough to move the status-quo in the > Go world - to get the point where Go programs require github.com/foo/bar >= > .2.3 and actually have been tested with a multiple versions in that range, > not exactly the one vendored version shipped with the program. That's a legitimate worry, yes. However given container and cloud people are massively adopting Go, that critical cloud software is now mostly written in Go, I don't think Fedora can afford to pass on Go and still stay relevant server-side. That's even more true for Fedora downstreams and Fedora's main sponsor. So I guess it all boils down to strategic choices for Fedora and Red Hat: invest in Go packaging, even if it *is* painful, or pass, and lose relevance server-side in the near future. Red Hat certainly has the assets, with Openshift and Coreos, to influence the Go world in a Fedora-positive way. I don't know if it will choose, or manage, to leverage them. It can not fail to notice the many Go projects that propose their software as Ubuntu Docker images today. It can not fail to notice that Jakub and Jan, with all their qualities, are a tad overworked and not really sufficient to pull Fedora Go forward the required amount. The Go ecosystem has just grown too big. Lastly, I understand the temptation to let Fedora and RHEL slip in favor of product lines more profitable in the near term. On my employer's side we *do* wish to stay relevant in a Cloud world. My Go contributions are an attempt to partner with the Fedora Centos and RHEL communities on that. If the partnership does not bear fruits, and Fedora/Centos/RHEL do not move in a direction we can use, we'll have to invest elsewhere. I'd regret it but this proposal and the spec dump that will follow are just too much work to do on one's free time. And employer time requires results. > I haven't had time to read through the entire proposal, but it certainly > looks like a major step forward! Please finish reading it and propose all the fixes and comments and improvements you want! Your experience is appreciated. Regards, -- Nicolas Mailhot

1 0

Re: <DKIM> Re: Proposed Fedora packaging guideline: More Go packaging
by Jakub Cajka 01 Feb '18

01 Feb '18

----- Original Message ----- > From: "Owen Taylor" <otaylor(a)redhat.com> > To: "Development discussions related to Fedora" <devel(a)lists.fedoraproject.org> > Cc: golang(a)lists.fedoraproject.org, "Discussion of RPM packaging standards and practices for Fedora" > <packaging(a)lists.fedoraproject.org> > Sent: Wednesday, January 31, 2018 6:50:21 PM > Subject: Re: <DKIM> [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging > > Hi Nicolas, > > Is there a guide for Fedora packagers about how to handle unbundling for > golang packages? The draft guidelines don't seem to go into any details. > I've looked at packaging a few golang packages unbundled, and have > immediately run into: > > A) lots of unpackaged dependencies > B) dependencies that are packaged in Fedora with different, often much older > versions > > A) is a pretty known quantity for any type of package, but I found B) more > intimidating. It seems like to package the new package, I have to get the > maintainer of the library to upgrade the version, and someone needs to > rebuild everything that depends on the rebuilt library and test that the > rebuilt packages work. > > Some tutorial showing a practical example of packaging a golang package for > the first time I think would be very helpful. > > Owen > Unfortunately this is how the situation stand thanks to the wide spread use of vendoring and generally no release and API stability in Go projects. You have to package all not packaged deps and work with other maintainers(which mostly means with Jan Chaloupka, cc'ed) to get other already packaged deps to commonly acceptable version/commit level, although it might not be even possible thanks to API breaks between commits. So you have to stick to bundling in some cases, if you really want to package that project. JC > > On Wed, Jan 31, 2018 at 5:30 AM, < nicolas.mailhot(a)laposte.net > wrote: > > > >De: "Neal Gompa" > > > The only thing I see that might be missing is autogenerating > > bundled(golang()) Provides when a vendor tree exists (with the > > appropriate automatic filters on Requires). > > I had though a little about doing it but first, as many Go elements, > vendoring relies on conventions not standards. The nasty thing about > conventions is that they are not applied 100% the same way by everyone, > making automation a PITA. And second interactions with autodeps can be > nasty: you can filter out provides, but do you filter out requires? What > about all the junk code many projects ship as testing and examples and which > is vendored with the rest? > > I don't say it can't be done, or that it would be difficult to do once the > rest is merged, but I'll live it to someone that absolutely want to ship a > Go package with vendored parts. > > Right now we sidestep the issue in our packages by rm -fr ing anything that > looks like vendored code in %prep. Unbundling takes time but it has a > positive cumulative effect: the more you unbundle the less you need to worry > about in other packages with the same requirements. And unbundling reveals > code/legal problems that it would take about as much work to solve by > auditing the vendored code manually. > > Regards, > > -- > Nicolas mAilhot > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > > > _______________________________________________ > golang mailing list -- golang(a)lists.fedoraproject.org > To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2018