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é
Hi Go SIG,
Recently I received an email from Robert-André inviting me to join the
SIG. As a package maintainer who co-maintains a bunch of Go packages, I
am willing to joining the SIG.
As requested in the email, I added *commit* access to go-sig on the
following 16 packages. If admin access is needed in specific case,
please drop emails with the package owner copied so that we can have
more in-depth discussion.
golang-github-BurntSushi-freetype-go
golang-github-BurntSushi-graphics-go
golang-github-BurntSushi-xgb
golang-github-BurntSushi-xgbutil
golang-github-alecthomas-assert
golang-github-alecthomas-colour
golang-github-alecthomas-kingpin
golang-github-alecthomas-repr
golang-github-alecthomas-template
golang-github-alecthomas-units
golang-github-axgle-mahonia
golang-github-disintegration-imaging
golang-github-howeyc-fsnotify
golang-github-msteinert-pam
golang-github-nfnt-resize
golang-github-sergi-go-diff
However I did not add the SIG any access to the following packages
deepin-api
golang-deepin-go-lib
golang-github-linuxdeepin-dbus-factory
golang-github-linuxdeepin-go-x11-client
I would like to explain the reason a bit. As we are packaging the Deepin
Desktop Environment into Fedora, we found that Deepin is not keeping a
stable API - sometimes their library updates a long time earlier than
their applications. As a result, we need a huge amount of time to test
before updating any of the dependencies. So in case we are not in sync
by the time we are updating deepin* packages, we tend to keep them
within us for now.
--
Ziqian SUN (Zamir)
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
想了解更多中文资讯,访问 https://zh.fedoracommunity.org/
Hello all,
For the Fedorans among you (and Richard), you may be aware that a
number of us met at Flock[0] and decided we wanted to do something
about the poor state of affairs on supporting Go in Linux
distributions. After the success we've had with Rust by collaborating
with different distributions early on to have roughly unified
packaging[1] (for the SUSE folks, yes, an OBS service for
autogenerating crate packaging is in the works[2]), we want to try to
replicate this success with Go.
This is a fairly opportune time to revisit how we approach Go in Linux
distributions, as the Go ecosystem is finally starting to realize the
folly of their approach to the ecosystem with the introduction of
versioned modules as an eventual first class citizen[3].
In Fedora, we've been working on revisiting and improving our Go
packaging, for both applications and modules. This has led to some
interesting developments[4][5]. We've also built tools for supporting
automating the management of Go packages (e.g. gofed). We're working
on collecting all the various aspects of our Go tooling under our
Pagure group[6].
I am aware that within the SUSE ecosystem, there's been some churn in
how Go packaging works, and at this point, it's not really
well-defined anymore (at least from my experience packaging Go stuff
in openSUSE).
I would like to personally invite interested members of the (open)SUSE
Go community to work with us in the Fedora Go SIG so that we can build
better solutions for the Go ecosystem together. As I am both a member
of Fedora and openSUSE, I am willing to assist with getting our
solutions in place in both distributions.
Here are the major contact points for the Fedora Go SIG:
* Mailing list: golang(a)lists.fedoraproject.org
* IRC channel: #fedora-golang on Freenode
* Forum section in Fedora Discourse: https://discussion.fedoraproject.org/c/go
Our current work is currently spread across Pagure, Dist-Git[7], and
GitHub[8], and we're actively working on collecting everything in one
place in our Pagure group so that it's easier to look over and
contribute to.
Please let me know what you guys think, and I hope that we can work
together to make a better future for Go in our Linux distributions!
[0]: https://flocktofedora.org/
[1]: https://fedoramagazine.org/oxidizing-fedora-try-rust-applications-today/
[2]: https://pagure.io/fedora-rust/obs-service-rust2rpm
[3]: https://golang.org/doc/go1.11#modules
[4]: https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
[5]: https://fedoraproject.org/wiki/More_Go_packaging
[6]: https://pagure.io/group/GoSIG/
[7]: https://src.fedoraproject.org/
[8]: https://github.com/gofed
--
真実はいつも一つ!/ Always, there's only one truth!
Hi,
Following some long discussions on rpm's and mock issue tracker¹, I
wrote the following to permit using BuildRequires, computed from the
content of the packaged archive:
https://github.com/nim-nim/mock-installhttps://copr.fedorainfracloud.org/coprs/nim/mock-install/https://bugzilla.redhat.com/show_bug.cgi?id=1629371
A review would be appreciated
Usage is pretty simple:
%<--
BuildRequires: mock-install
[…]
%prep
[…] # Do something to compute yourbr1 … yourbrX
mock-install yourbr1 … yourbrX
%<--
I intend to integrate it in the next version of Fedora Go packaging
macros. I'm told the Java guys already do something similar within
javapackages-tools, but it's hidden inside java-specific python
packaging code, you can't really use it standalone for other kinds of
packaging.
Of course the utility is written in Go, so will only build on arches
that support Go but *shrug* at this point I don't care, feel free to
write something better if you want. The Go code is small and trivial.
Regards,
¹ https://github.com/rpm-software-management/mock/issues/160
--
Nicolas Mailhot
Dear all,
You are kindly invited to the meeting:
Go SIG on 2018-09-12 from 16:00:00 to 17:00:00 UTC
At fedora-golang@FreeNode
The meeting will be about:
Initial meeting of Go SIG.
Agenda:
1. Introduction
2. Pagure
3. Meeting processes(voting,...)
4. Next Meeting
5. Open Floor
Source: https://apps.fedoraproject.org/calendar/meeting/9344/
Hello,
let's try figure out best slot for it. https://framadate.org/DrEWMnFlw1e8Pd8J please fill in this survey so we can get best possible time for the most.
Looking forward to meet with you to discuss the issues and future plans.
JC