golang October 2018

golang@lists.fedoraproject.org

5 participants
5 discussions

Go SIG is live!
by Robert-André Mauchin 14 Nov '18

14 Nov '18

Guys and gals, The SIG Group has been approved, we're rolling. We have now a SIG specific mailing list: https://lists.fedoraproject.org/admin/ lists/go-sig.lists.fedoraproject.org It is set to private because we could receive security bugs. We have now a group in FAS: https://admin.fedoraproject.org/accounts/group/ members/go-sig I have added all the relevant people. You just have to relog in Pagure to update the details there. **Robbi Nespu (robbinespu)** and **Zachary Snyder (sadin)**, I couldn't add you because you're not member of the packager group. The bugzilla account for the SIG is not yet created, I'm waiting for the bugzilla mail in the spam box. Now the hardest part is coming, convincing all Golang maintainers to assign the SIG to their packages. We can start with all our packages: in the package settings on Pagure, assign the group "go-sig" as admin. Yes we have to do that manuallyfor each package, it's gonna be a pain in the butt if you have a lot of packages. I will now send a mail to all Golang maintainers enjoining them to do the same and to join the SIG. Best regards, Robert-André

6 9

Go-SIG meeting reminder
by Jakub Cajka 24 Oct '18

24 Oct '18

Hello, sending late reminder for today's Go-SIG IRC meeting held on #fedora-golang at 1600h UTC. For agenda see https://pagure.io/GoSIG/go-sig/issues?status=Open&tags=meeting tagged issues. Sorry for sending late notice as I have misconfigured the Fedocal entry... it should be fixed now. JC

1 0

Intent to orphan / give to go-sig some unused leaf golang packages
by Fabio Valentini 22 Oct '18

22 Oct '18

Hi everybody, I'm cleaning up my packages a bit, and I currently maintain some leaf packages which aren't used by anything (or anything I use) at this point in time. The packages all have the go-sig as co-admin already, but I intend to drop them from my radar completely. You know, cognitive burden and stuff. - golang-github-AudriusButkevicius-kcp-go - golang-github-AudriusButkevicius-pfilter - golang-github-calmh-luhn - golang-github-ccding-go-stun - golang-github-cznic-b - golang-github-cznic-fileutil - golang-github-cznic-golex - golang-github-cznic-internal - golang-github-cznic-lex - golang-github-cznic-lexer - golang-github-cznic-lldb - golang-github-cznic-mathutil - golang-github-cznic-ql - golang-github-cznic-sortutil - golang-github-cznic-strutil - golang-github-cznic-zappy - golang-github-edsrzf-mmap-go - golang-github-klauspost-reedsolomon - golang-github-remyoudompheng-bigfft - golang-github-templexxx-cpufeat - golang-github-templexxx-reedsolomon - golang-github-templexxx-xor - golang-github-tjfoc-gmsm - golang-github-xtaci-kcp-go - golang-github-xtaci-smux - golang-github-zillode-notify The length of this list of now unused leaf packages tells its own story about the go ecosystem. As far as I can tell, nothing in fedora depends on this set of packages anymore, except some inter-dependencies between the packages themselves. All the packages are up-to-date with either the latest stable release (where available) or the current git master branch, and all the packages use the new golang packaging macros ("spec 3.0"). Tests are run where available and pass (except where they don't). If somebody wants to take over a package personally instead of it being inherited by the go-sig group, I will give them the package instead. I'll give up the remaining packages on Mon, 22 Oct. 2018. Fabio

1 1

[RFC] Default rpm macro packaging layout and conventions
by Nicolas Mailhot 10 Oct '18

10 Oct '18

Hi, I'd like Fedora and FPC in general to agree to a general layout for macros and their associated material like templates, so the next step can focus on the actual macros and their documentation, and not on how the result is shipped to users. https://pagure.io/packaging-committee/issue/813 The reason being I'm currently wrapping up three sets of rpm macros for Fedora⁰. The coding and first-pass testing for each macro set is mostly done, the next step is packaging, documenting, and guideline-ing. I'd like to do the documenting and guideline-ing for each macro set via standard templates. Wiki (or the new docs site) is a huge time sink to write and update, and most packagers do not read the result, so it's mostly a waste of time. OTOH templates are operational and do work. Thus with hindsight, a short paragraph in guidelines that points to a package of templates, works loads better than a wall of wiki text Here is how I understand today's Fedora best practices. To my knowledge, they are mostly unwritten packager lore. (obviously stuff in redhat-rpm-config is a special case) %<-- A. A single project hosts macros, templates, readmes, so everything is kept in sync B. For macros that process <foo> material, the project is named <foo>-macros or <foo>packages (which one does FPC prefer?) C. The project SHOULD be hosted on Fedora infra, or a cross-distro hosting site (ie pagure.io, even if I find it severely limitating from a forge POW) D. The result is packaged as a <foo>-macros or <foo>packages srpm (whichever FPC chose in B) E. The srpm CAN BuildRequire anything (though usually it will be composed of macros, docs, scripts, that do not need much building, anything binary is likely to end up in its own package that is then BuildRequired) F. This srpm generates the following subpackages (using -n, otherwise you end up with very awkward package names) F.1 A package named <foo>-srpm-macros, sufficient to create <foo> srpms: * this package MUST be in the default build root (buildsys group) * it MUST NOT require anything: we want builds to be fast and efficient, and package ecosystems not to pollute the builds of other package ecosystem * it MUST define a pivot macro expected to be present in every <foo> spec * this macro SHOULD generate a BuildRequires on <foo>-rpm-macros * this package MUST define every other macro or constant needed by rpmbuild to assemble <foo> srpms (mostly, anything dealing with <foo> sources or the SRPM name) F.2 A package named <foo>-rpm-macros, sufficient for the build stage of <foo> packages * this package MUST NOT assume it can be in the default build root * it CAN and SHOULD Require anything typically needed to build <foo> packages. Require restrictions are for <foo>-srpm-macros, not <foo>-rpm-macros * anything used in %prep, %build, %install, %check, or to compute <foo>-style deps * for example: for Go packages, the Golang compiler, for fonts packages, fontconfig * it MUST provide the associated macros and constants (typically the constant defining standard filesystem locations for <foo> stuff) * it MUST require <foo>-filesystem * it SHOULD NOT be necessary to install <foo> packages once built, not be depended on by those packages F.3 A package named <foo>-filesystem * this package MUST materialize and own the filesystem locations defined in <foo>-rpm-macros * this package MUST NOT require anything except other filesystem-style packages * this way it can be depended on by <foo> packages without pulling in all the build infra of <foo>-rpm-macros F.4 A package named <foo>packages-devel ? <foo>-macros-devel ? <foo>packages-templates ? <foo>-macro-templates ? What is the FPC preference? * this package SHOULD depend on rpmdevtools * this package SHOULD provide at least one template in %{_sysconfdir}/rpmdevtools/ showing how <foo> macros are supposed to be used * this package SHOULD contain every other additionnal documentation file, necessary to understand those templates * this package SHOULD NOT be necessary to install <foo> packages once built, not be depended on by those packages F.5 A package named <foo>packages-tools ? <foo>-macros-tools ? What is the FPC preference? * holds anything not strictly necessary to run the macros or understand the templates, but can be useful to some packages, typically convenience scripts %<-- Did I get this right or did i forget something important? Regards, ⁰ 1. "forge macros" v2 (v1 was merged in redhat-rpm-config 9 months ago) macros to map <url,version,tag,commit,branch> metadata to classical rpm Source, URL, %setup, %dist, etc verbs, when a project is hosted on Gitlab, GitHub, etc (*not* Pagure because Pagure is missing needed functionality). There are hundreds if not thousands of packages in the distro that can make use of this. v2 adds the ability to process multiple archives in a single source rpm.¹ 2 "go macros" v2 (v1 was merged in go-compilers and go-srpm macros about the same time as the forge macros) automation for packaging software written in the Go language (Go language). Go is getting huge nowadays, it's the language in which kubernetes, docker, and a lot of cloud infra software is being written today. This is really why I'm doing all this, the forge macros are just a spinoff of generic non-Go-specific functionality that Go macros need. v2 add the ability to process multiple archives in a single source rpm, and Go BuildRequires automation (one of the huge missing bits in the v1)² 3 font macros v2 (v1 + associated guidelines were written by myself around a decade ago) Another spinoff of 1. and 2. Mostly because golang-x-image is the upstream of the Go fonts, which has caused me to revisit the subject. With the framework code written for 1., ten years of hindsight, experience, and rpm improvements, I can and did write macros that remove known problems in the current set, add missing functionalities like appstream handling, and are generally more convenient to use (took me about a week-end of hacking)³ ¹ A first version has already been completed and merged in redhat-rpm-config 9 months ago. Thanks to everyone involved. https://src.fedoraproject.org/rpms/redhat-rpm-config/c/7c4cd330850ee228ca72… It worked and still works fine, you can use it today in your packages, but it has a huge limitation: it assumes you only need to process a single source archive in the specfile. People rightly pointed out in the review that, while it's the general and preferred case, some packages do need to mix source archives (esp. on EL given the hard constrains EL has on not touching existing package layout). Therefore I've prepared a new version that *can* process multiple sources. It's backwards-compatible, multi-source is achieved via new flags, in the absence of those flags it will assume a single source like the current merged code does. https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35 It adds a huge level of complexity macro-side, rpm does not really provide the framework to do this kind of multiplexing, the framework had to be coded from scratch in lua macro code. However, the framework has been coded now, it's generic, and rightly belongs in a generic package like redhat-rpm-config ² Currently in the final stages of technical testing before I document it and send a PR https://github.com/nim-nim/go-macros/commits/dev ³ Currently past the technical testing, need to document it, send myself a PR, send the result to FPC and the Fonts SIG to switch existing packaging guidelines -- Nicolas Mailhot

1 0

Golang rebase to 1.11.1 in epel6
by Jakub Cajka 09 Oct '18

09 Oct '18

Hello, I have rebased golang from 1.9.7 to the 1.11.1 in epel6 as go1.9 is no longer supported in upstream. Bodhi update: https://bodhi.fedoraproject.org/updates/golang-1.11.1-1.el6 I have observed one test failing due to broken pipes(on x86_64), but it doesn't look too serious to me, so I took the liberty to ignore it. If anybody would be interested in investigating this further, I would much appreciate it. Karma and testing is as usual welcomed. If there will be no issues or objections I will push it in to the stable when possible. JC

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang October 2018