Enabling GOPROXY and GOSUMDB in Fedora
Hi everyone. TL;DR: Remove a patch we ship in Go that disables GOPROXY and GOSUMDB and follow upstream defaults, or keep it? Recently, I had a short conversation in a public forum about two Go features that we modified in Fedora. GOPROXY and GOSUMDB. As I prepare the Fedora 40 and Go 1.22 proposal, it is a great time to discuss it. You can see the conversation here, I think they bring really good points that we should consider: https://mas.to/@zekjur/111359951465906642 So first, what are these variables? - GOPROXY sets the server for fetching module-related information and dependencies. - GOSUMDB sets the checksum database URL to verify module downloads and ensure their integrity during module resolution. You can read them more in detail here: - https://go.dev/ref/mod#environment-variables - https://go.dev/ref/mod#authenticating - https://go.dev/ref/mod#module-proxy There are four approaches as I see this: 1. Keep it the way it is right now. 2. Remove the patch and follow upstream. 3. Create a way to ensure the users know that that option can be changed and leave one of the two previous options as default (by creating two packages, one with the default setting and another that applies the patch). 4. Have a GOPROXY service by Fedora. 1 and 2 are the easiest and most logical ones. 3rd is complex, and I'm not sure it brings any value. 4th would be ideal, but that means maintaining a service with all its costs and time. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
golang-race package relevance
Hi everyone! Currently, golang ships the golang-race package, but this process is going to get trickier with Go 1.20 due to this change: The directory $GOROOT/pkg no longer stores pre-compiled package archives for the standard library: go install no longer writes them, the go build no longer checks for them, and the Go distribution no longer ships them. Instead, packages in the standard library are built as needed and cached in the build cache, just like packages outside GOROOT. This change reduces the size of the Go distribution and also avoids C toolchain skew for packages that use cgo. Source: https://tip.golang.org/doc/go1.20 Under Tools -> Go command It uses the cache, which is a little tricky to retrieve information from. I didn't find anything that requires golang-race, and I'm not sure why someone would want to install the package, so I'm curious if the effort of fixing the issue is worth the time because right now, I can't build Go1.20rc3 unless I remove the package. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Spring Cleaning go-sig/June 2022
Done! golang-github-google-dap and golang-starlark added. Thanks for the script! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Claim delve
(I know, it took a while) I just submitted it for review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2102388 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
About Fedora containers
Hi all! TL;DR: Is there any documentation about how to properly take care of our containers? :) --- The Go container has been outdated for a while, and I would love to update it[0], but I'm not familiar with the container process in Fedora. I checked Python3's container[1] looking for information, and I saw that the rawhide branch is not used in the same way we use it with the RPMs. Also, I saw that the s2i-base image is only available until F35. No F36 or Rawhide. And, it looks like they are only available for x86_64 platforms. So I guess the main big question is: is there any documentation or proposals I should be aware of? Is the Go container relevant? cc'ed Container SIG's mailing list; I didn't see movement in the mailing list, just in case. [0] https://src.fedoraproject.org/container/golang [1] https://src.fedoraproject.org/container/python3 Thank you very much! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Golang
On Fri, Jun 17, 2022 at 7:03 AM Miroslav Suchý wrote: > > I have been asked to add support for Go external dependencies to Mock > >https://github.com/rpm-software-management/mock/issues/919 > > I tried to get the information from > > https://developer.fedoraproject.org/tech/languages/go/go-packages.html > > However, the information there seems to be outdated. "go get" is deprecated. > And even "go install" with the example > there does not work. > > Is here a hero, who will edit the page on developer portal and update it? > Not a hero but I can look into it :). Already subscribed to the github issue too. cc @gol...@lists.fedoraproject.org > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages (incl. go-rpm-macros) looking for new maintainers
I already claimed go-rpm-macros. On Mon, Mar 28, 2022 at 10:53 AM Miro Hrončok wrote: > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will fail to install and/or build when the affected package gets > retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2022-03-28.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > > Package (co)maintainers Status > Change > > augeas-vala orphan 4 weeks ago > beanstalk-client orphan 3 weeks ago > gela-asis orphan, reznik 1 weeks ago > go-rpm-macros eclipseo, go-sig, jcajka,0 weeks ago >orphan, qulogic > gocl orphan 4 weeks ago > golang-github-influxdata- go-sig, orphan 0 weeks ago > influxdb > golang-github-mdlayher-wifi go-sig, orphan 2 weeks ago > lua-ldap orphan 3 weeks ago > mcrouter dcavalca, filbranden, orphan 0 weeks ago > python-aiohttp-cors orphan, python-sig 3 weeks ago > python-aiohttp-negotiate orphan 3 weeks ago > python-fastimport orphan 3 weeks ago > python-hkdf orphan 4 weeks ago > python-lrparsing orphan 3 weeks ago > python-magic-wormhole orphan 4 weeks ago > python-magic-wormhole-mailbox-orphan 4 weeks ago > server > python-magic-wormhole-transit-orphan 4 weeks ago > relay > python-ofxparse orphan 3 weeks ago > python-plyvel orphan 3 weeks ago > python-pystalkorphan 3 weeks ago > python-spake2 orphan 4 weeks ago > python-txtorcon orphan 4 weeks ago > qcommandline orphan 3 weeks ago > qt5-qtcanvas3dkde-sig, orphan 1 weeks ago > qt5-qtenginio kde-sig, lupinix, orphan 1 weeks ago > rubygem-database_cleaner orphan 5 weeks ago > rust-diffus orphan, rust-sig 1 weeks ago > rust-diffus-deriveorphan, rust-sig 1 weeks ago > rust-newsblur_api orphan, rust-sig 1 weeks ago > rust-opml orphan, rust-sig 1 weeks ago > rust-xmltree orphan, rust-sig 1 weeks ago > sems orphan 1 weeks ago > yecht orphan 2 weeks ago > > The following packages require above mentioned packages: > Depending on: go-rpm-macros (1957), status change: 2022-03-22 (0 weeks ago) > Too many dependencies for go-rpm-macros, not all listed here > See https://churchyard.fedorapeople.org/orphans-2022-03-28.txt > > Depending on: golang-github-mdlayher-wifi (1), status change: 2022-03-11 (2 > weeks ago) > golang-github-prometheus-node-exporter (maintained by: eclipseo, > go-sig) > golang-github-prometheus-node-exporter-1.3.1-6.fc36.src > requires > golang(github.com/mdlayher/wifi) = 0-0.12.20200729git84f0b94.fc36 > > golang-github-prometheus-node-exporter-devel-1.3.1-6.fc36.noarch requires > golang(github.com/mdlayher/wifi) = 0-0.12.20200729git84f0b94.fc36 > > Depending on: python-aiohttp-cors (1), status change: 2022-03-02 (3 weeks ago) > gns3-server (maintained by:
Re: F36 Change: Golang 1.18 (System-Wide Change proposal)
On Sat, Dec 18, 2021 at 12:35 PM Fabio Valentini wrote: > On Sat, Dec 18, 2021 at 9:35 AM Alejandro Saez Morollon > wrote: > > > > > > > > On Fri, Dec 17, 2021 at 3:14 PM Fabio Valentini > wrote: > >> > >> Will there be a separate go 1.18 mass rebuild in rawhide? > >> Or will the f36 mass rebuild just happen with go 1.18 (beta/rc) present? > >> > > > > Given the release schedule, I highly doubt that a non beta/rc will be > available at the time of the mass rebuild. > > It's not the first time this has happened as far as I'm aware. That's > the problem with the Go schedule and why I sent an email couple days ago > > asking for input about it. > > That's good and well, but doesn't answer my question. Do you plan to > > - push go 1.18 (beta/rc, whatever is available at the time) to rawhide > in time for the normal f36 mass rebuild, or > - push go 1.18 *after* the f36 mass rebuild and do a separate mass > rebuild of Go packages? > I was planning on doing the first, push go 1.18 beta/rc to rawhide (beta1 is already there in fact). > > > A solution to this situation will be to use modules and keep Fedora N in > a previous release. But this does only solves > > the demands of the users, packages cannot use module streams, right?. > Correct me if I'm wrong, please. > > That is true. It would solve the problem for end users who install a > go compiler, but any Go packages in Fedora would still be stuck with > an EOL toolchain, and I don't think that would be acceptable. > > >> If there's a separate mass rebuild (or any test builds with go 1.18) > >> planned prior to the mass rebuild, that's a bit of a tight timeline, > >> with the winter holidays coming up and the F36 mass rebuild planned to > >> start on Jan. 19, 2021. > > > > My biggest concern is that currently, we have 1.16 in Fedora 34 and > Fedora 35. > > So if we can't update Fedora 36 to Go 1.18, by the EOL we will > > have a non upstream supported Go version with ~1900 packages depending > on it. > > In that scenario, I would personally like to do a mass rebuild to make > 1.17 available on Fedora 35 and 36. > > But I'm not sure about how possible this is. > > > > Any suggestion is highly welcome :) > > Go 1.17 is already available for rawhide / f36, unless I am reading > the state of the package wrong. So even if you do *nothing*, the f36 > mass rebuild will use Go 1.17. However, for f35 / f35, updating Golang > to 1.17 and rebuild almost ~2000 dependent packages in stable releases > won't be feasible, I think. Stable release workflow is just not > tailored towards supporting such big disruptive updates after release; > I think bodhi would just explode if you even tried to create an update > with that many packages in it (the problem of actually needing to > build all those packages without conflicts in a side tag, which is > even a problem if you only have a dozen packages). > > Understood. That is a really important point :) > I also don't understand how the state of fedora 34 and 35 is impacting > the decisions around rawhide / f36. I just want to know whether you > think a golang 1.18 package will be ready in time for the f36 mass > rebuild, or if it will take longer, and require a second f36-golang > mass rebuild :) > > Go 1.18 beta 1 is already in the rawhide branch, so I guess we won't need a second mass rebuild for golang. Regarding the Fedora 34 /35 impacting the decision. What happens if, for whatever reason, 1.18 breaks a lot of builds and we decide to push back the update. As 1.17 was never used in a mass rebuild, aren't the stable versions of Go more suitable for the fall-back mass rebuild? > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: About how Go is updated in Fedora
On Tue, Dec 14, 2021 at 5:01 AM Matthew Miller wrote: > On Mon, Dec 13, 2021 at 02:22:24PM +0100, Alejandro Saez Morollon wrote: > > A hypothetical new release cycle would look like this: > > > >- Fedora N release follows Go upstream as close as we can. > >- Fedora N-1 sticks with the latest major version of Go that was > >available on it until the release of Fedora N. > > > > > > Another hypothetical approach could be using modules with each upstream > > supported release in a stream. > > This seems like the thing Modularity was invented to do, and would have the > advantage of being able to be consistent across a release with a > "baseline" version but also provide options. > > But AFAIK, only users can select a module stream, right? I mean, packages can't be build on top of a module stream so new needs of package maintainers cannot be satisfy with modules. I'm curious about how other SIGs deal with these scenarios... > > > -- > Matthew Miller > > Fedora Project Leader > ___ > golang mailing list -- gol...@lists.fedoraproject.org > To unsubscribe send an email to golang-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Golang 1.18 (System-Wide Change proposal)
On Fri, Dec 17, 2021 at 3:14 PM Fabio Valentini wrote: > On Fri, Dec 17, 2021 at 12:54 AM Ben Cotton wrote: > > > > Note that this replaces the approved Golang 1.17 Change > > > > https://fedoraproject.org/wiki/Changes/golang1.18 > > > > > > == Summary == > > Rebase of Golang package to upcoming version 1.18 in Fedora 36, > > including the rebuild of all dependent packages(the pre-release > > version of Go will be used for the rebuild if released version will > > not be available at the time of the mass rebuild). > > Will there be a separate go 1.18 mass rebuild in rawhide? > Or will the f36 mass rebuild just happen with go 1.18 (beta/rc) present? > > Given the release schedule, I highly doubt that a non beta/rc will be available at the time of the mass rebuild. It's not the first time this has happened as far as I'm aware. That's the problem with the Go schedule and why I sent an email couple days ago asking for input about it. A solution to this situation will be to use modules and keep Fedora N in a previous release. But this does only solves the demands of the users, packages cannot use module streams, right?. Correct me if I'm wrong, please. > > == Contingency Plan == > > * Contingency mechanism:Reverting to golang version 1.16.X if > > significant issues are discovered. > > * Contingency deadline: Beta Freeze(?) > > * Blocks release? No > > * Blocks product? No > > If there's a separate mass rebuild (or any test builds with go 1.18) > planned prior to the mass rebuild, that's a bit of a tight timeline, > with the winter holidays coming up and the F36 mass rebuild planned to > start on Jan. 19, 2021. > My biggest concern is that currently, we have 1.16 in Fedora 34 and Fedora 35. So if we can't update Fedora 36 to Go 1.18, by the EOL we will have a non upstream supported Go version with ~1900 packages depending on it. In that scenario, I would personally like to do a mass rebuild to make 1.17 available on Fedora 35 and 36. But I'm not sure about how possible this is. Any suggestion is highly welcome :) > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
About how Go is updated in Fedora
I've been thinking a little about how Go is updated in Fedora. I would like to hear other opinions about the current state of the releases and improve it. This is not related to the Fedora proposal that I'm planning to submit today regarding the update of Go. I do not pretend to change anything for the next Fedora release, but at least have an idea of if what we are doing right now can be improved. The current state: Each Fedora release has a major release of Go available. For example, Fedora 33 had 1.15, and Fedora 34 had 1.16. The problem: I see two main issues with this approach. 1. Both Go and Fedora have release cycles of 6 months, so the schedule is a little tight. Go releases can be delayed and have issues in the mass rebuild phase. 2. A user needs to wait for the next Fedora release to get a new major version of Go. So consequentially, they will tend to download from upstream, making the Go package just necessary for dependencies but with little use on its own. Also, backport bugs to Fedora releases might be a problem. Releasing packages that depend on new features are an issue too [0]. What I think is an improvement: Suppose a new Go major version is released in the middle of a Fedora life cycle. In that case, I think it is an improvement for the user to be able to update to the following Go release. A hypothetical new release cycle would look like this: - Fedora N release follows Go upstream as close as we can. - Fedora N-1 sticks with the latest major version of Go that was available on it until the release of Fedora N. Another hypothetical approach could be using modules with each upstream supported release in a stream. To help in the decision, I made a report tool/web page [1] that shows the current state of the packages that depend on Go (Thanks to the COPR API). It compares the builds of every single Go dependent package in Fedora 35 using the current available Go package with the same list of Go packages but using the Go package is available on Fedora Rawhide. To rephrase it, it compares Fedora 35 packages built with Go 1.16 with Fedora 35 packages built with Go 1.17. As you can see, right now, from the 1901 packages that depend on Go, 196 have some sort of change and 1705 built exactly the same. You can search for "Same results" or "Something has changed" to see this. Or by the name of the package. The report is not smart enough to say what happened right now so some "issues" are in fact improvements like golang-github-cactus-statsd-client, others like golang-github-briandowns-spinner are real issues. My idea is to improve this report with your suggestions. Hence, if a new Go major release is available, we can confidently say that the package can be updated in the middle of a Fedora release. [0] https://github.com/containers/podman/pull/12544 [1] https://alexsaezm.fedorapeople.org/report.html -> let it load, it has a JS that allows you to search ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Go reviewers needed [was Re: packaging sourcegraph cli -- any volunteers?]
On Wed, Dec 1, 2021 at 5:40 PM Matthew Miller wrote: > > https://github.com/sourcegraph/src-cli > > Okay, so, Jan Kuparinen (copperi) is working on this. I'm happy to sponsor > him, but I am not up on the state of Go packaging, like, even a little bit. > Can someone help by reviewing his packages? He's tackling the various > dependencies, starting with: > > https://bugzilla.redhat.com/show_bug.cgi?id=2026791 > https://bugzilla.redhat.com/show_bug.cgi?id=2026998 > > Any takers? > > > Will do :) > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Question about toolbox purpose/usage
On Mon, Nov 29, 2021 at 2:35 AM Sergio Belkin wrote: > Hi, > I've been playing a bit with toolbox, what is it intended for? > > I understand that was intended primarily for immutable OS. But > documentation says that it can be used on the Workstation edition too. > AFAIK it's only useful if you don't want to mess up your /usr of your host > operating system by installing apps. Beyond that, you can happily destroy > your very $HOME, from overwriting dot files to removing any other of your > important files. > Am I missing something? > Please correct me if I'm wrong. > Thanks in advance! > > Yes, you can totally destroy all your files. That's the "bad" side of it. Look at the bright side: you don't need to deal with different dotfiles depending on your platform. I use toolbox every single day, I can switch versions, try testing packages and even switch distributions. Hope it helps. > -- > -- > Sergio Belkin > LPIC-2 Certified - http://www.lpi.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Go 1.17 and Fedora 35
I just submitted to COPR [0] all of the packages that use Go (I think so...) for an initial test. Let's see how it goes. [0] https://copr.fedorainfracloud.org/coprs/alexsaezm/go1.17/builds/ On Tue, Aug 10, 2021 at 7:46 PM Alejandro Saez Morollon wrote: > > Hi everyone. > > I missed the mass rebuild for several reasons, and I didn't prepare > the Go package for the 1.17 release as I proposed [0]. > > This email thread is to keep everyone up to date on the progress > regarding this issue [1]. > > [0] https://fedoraproject.org/wiki/Changes/golang1.17 > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1982396 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
HEADS UP: Go 1.17 and Fedora 35
Hi everyone. I missed the mass rebuild for several reasons, and I didn't prepare the Go package for the 1.17 release as I proposed [0]. This email thread is to keep everyone up to date on the progress regarding this issue [1]. [0] https://fedoraproject.org/wiki/Changes/golang1.17 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1982396 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Golang 1.17 (System-Wide Change proposal)
For context: https://groups.google.com/g/golang-dev/c/hGwvCceDr14/m/wbyNWwgNBgAJ On Tue, Jun 29, 2021 at 9:02 PM Alejandro Sáez Morollón wrote: > > According to upstream, they are not going to deprecate GOPATH yet in this > version. > > I built etcd with 1.17beta1 and everything went fine. > > > On 29 Jun 2021, at 20:42, Robert-André Mauchin wrote: > > > > On 6/28/21 6:57 PM, Ben Cotton wrote: > >> https://fedoraproject.org/wiki/Changes/golang1.17 > >> == Summary == > >> Rebase of Golang package to upcoming version 1.17 in Fedora 35, > >> including the rebuild of all dependent packages(the pre-release > >> version of Go will be used for the rebuild if released version will > >> not be available at the time of the mass rebuild). > >> == Owner == > >> * Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka| > >> Jakub Čajka]] > >> * Email: a...@redhat.com, jca...@redhat.com > > > > Won't we have a problem since 1.17 is deprecating the gopath way to use Go > > modules instead. We didn't manage to port our macros to Go modules due to > > Nicolas Mailhot being MIA since last year, and even if we manage that, I > > personally won't have the time to rebuild the entire ecosystem. I'm already > > have problems dealing with all the updates, while taking care of the > > Package Reviews too. > > Won't this break our entire Go ecosystem? > > > > Best regards, > > > > Robert-André > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Help with LDFLAGS for a golang package
Did you figure it out? I installed the package from your COPR build and I can see the correct version: ``` Smug - tmux session manager. Version 0.2.2 ``` ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Did golang really get upgraded to 1.16.2?
Go 1.16 enables by default modules. In fact, in 1.17, GOPATH is going to be removed. https://github.com/golang/go/issues/41330 If you are building RPM packages, go-srpm-macros not only contains useful macros but it enables GOPATH. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Did golang really get upgraded to 1.16.2?
Totally my fault. Rawhide branch contained stuff related to 1.16 release candidates and I didn't properly check it. The same thing happens in F34. It should be already solved in rawhide and soon on F34. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Did golang really get upgraded to 1.16.2?
On 09/04/2021 15:36, Richard W.M. Jones wrote: On Fri, Apr 09, 2021 at 08:49:39PM +0800, yanqiy...@gmail.com wrote: Hi folks, I see some reports in FZUG community that this commit [1], supposed to update golang to 1.16.2 in its changelog, didn't change its tarball or n-v-r to new version. And actually builds to 1.16-2. Is it intended to fo the upgrade or the commit is just a normal rebuild with wrong changelog? Looks like it's still version 1.16 to me: $ /usr/bin/go version go version go1.16 linux/amd64 $ rpm -qf /usr/bin/go golang-bin-1.16-2.fc35.x86_64 BTW this version (>= 1.16) breaks GOPATH and defaults to modules, which broke all our existing code. Rich. Thanks both for bringing this up. I'm going to check it right now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Claim delve
Hi there, folks. Delve[0] (a Golang debugger) was retired due to the impossibility of building a new version of delve for dependencies issues. I would like to claim the package and fix the situation. I already have one of the dependencies[1] in the works. I already talked with the original maintainer (he's in cc) and he is OK with it. Thanks. [0] https://src.fedoraproject.org/rpms/delve [1] https://src.fedoraproject.org/rpms/golang-starlark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Also true. Although visudo is probably not a good example because the command itself warns you haha :), Nevertheless, I still think that the user-friendly approach here is to ask the users what they want, not to impose something. On Fri, Jun 26, 2020 at 12:35 PM Christopher Engelhard wrote: > > On 26.06.20 12:20, Ian McInerney wrote: > > > git is not the only program that uses the EDITOR variable. Some > > configuration tools on the command-line, such as crontab, will use the > > editor set in the environment variable if there is one. > > visudo is also a good spot for a beginner to be stuck in vi. > > Christopher > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
100% true. That would be a nice addition to the proposal. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
If the only case is git... which by the way behaves in that way even on Windows... isn't it a git problem? I like not having a default editor and a more user-friendly approach would be to ask the user what they want on the installation or on the first run. I don't consider git a layman application, neither open a terminal to do stuff. On Thu, Jun 25, 2020 at 7:20 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/UseNanoByDefault > > == Summary == > > Let's make Fedora more approachable, by having a default editor that > doesn't require specialist knowledge to use. > > == Owner == > * Name: [[User:chrismurphy| Chris Murphy]] > * Email: chrismur...@fedoraproject.org > > > == Detailed Description == > > Users are exposed to the default editor when they use commands that > call it. The main example here is something like git > commit. > > Fedora does not currently have a default terminal text editor, because > the $EDITOR environment variable is unset by default. But a common > scenario where users wind up in a terminal text editor is when using > 'git commit'. By default, git picks vi. You need to spend time > learning how to use it, for even basic editing tasks. This increases > the barrier to entry for those who are switching to Fedora and don't > know how to use vi. It also makes things hard for those who don't > particularly want to learn how to use vi. (These arguments would apply > just as well if git picked Vim. vi is like hard mode for Vim, with > fewer features, missing syntax highlighting, and no indication of what > mode you are in. Even Vim users may feel lost and bewildered when > using vi.) > > In contrast, Nano offers the kind of graphical text editing experience > that people are used to, and therefore doesn't require specialist > knowledge to use. It is already installed across most Fedora Editions > and Spins. This proposal will make Nano the default editor, while > continuing to install vim-minimal (which provides vi, but > not Vim). People will still be able to call vi if they > want to edit a file. It will also obviously be possible to change the > default editor to vi or Vim, for those who want it. > > Why make Nano default and vi optional, rather than the other way > round? Because Nano is the option that everyone can use. > > == Feedback == > > Pending ... > > == Benefit to Fedora == > > * Makes the default editor across all of Fedora more approachable. > * Nano is also mostly self-documenting, by displaying common keyboard > shortcuts on-screen. > * More in line with the default editor of other distributions. > > == Scope == > * Proposal owners: > ** Modify comps to include nano Fedora wide. > ** Create a new subpackage of nano, called > nano-editor. > ** nano-editor to include > /usr/lib/environment.d/10-nano.conf, which sets > $EDITOR to nano. > > With this approach, if nano is uninstalled, the > configuration will be removed with it. At the same time, installing > nano on its own won't install the conf. > > * Other developers: N/A > > * Release engineering: [https://pagure.io/releng/issue/9522 #9522] > > * Policies and guidelines: N/A > > * Trademark approval: N/A > > == Upgrade/compatibility impact == > > Will not apply to upgrades. > > == How To Test == > > Run export EDITOR="/usr/bin/nano". > > == User Experience == > > Users running git commit will be able to just type their > commit message, rather than having to learn about insert mode, and > they'll be able to cut and paste without having to learn special > shortcuts. > > == Dependencies == > > No additional dependencies are required. > > == Contingency Plan == > The contingency plan is to revert the change by removing the > nano-editor package. > > * Contingency deadline: probably the beta? It's an easy change to revert. > * Blocks release? If the change breaks the redirection to an editor, > it should block the release. However, this is unlikely. > * Blocks product? Potentially all. > > == Documentation == > As part of this change, it would be good to add instructions for > changing the default editor to the > [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs]. > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:
Re: Mock build of GO program fails
Hi. For Go packages, what we do is to use dependencies that are already in the repo and avoid download anything because as you saw, there is no connectivity inside mock. Also, we avoid using vendoring. You should take a look at https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ because there are plenty of useful macros for Go that simplifies the whole process a lot. Another thing that might be relevant is that there's a Go SIG group (golang@) and an IRC channel (#fedora-golang), where we can solve your questions :) On Fri, Apr 3, 2020 at 12:59 PM Ralf Senderek wrote: > > > I need a bit of assistance from a GO package expert. > > I'm trying to package ssh-chat. > (https://bugzilla.redhat.com/show_bug.cgi?id=1819180) > ssh-chat is written in GO and it implements a custom SSH server > (on a different port) that provides a chat room instead of a shell. > > I was successful to build the package locally with network access but when > I run mock the build always fails with the following message: > > go build -ldflags="-B 0x8fed0b1e64bd7424a5e5bae0774d74d15f24add1" > ./cmd/ssh-chat > go: github.com/alexcesaro/log@v0.0.0-20150915221235-61e686294e58: invalid > version: git fetch -f origin refs/heads/*:refs/heads/* > refs/tags/*:refs/tags/* in > /builddir/go/pkg/mod/cache/vcs/016624ec8fded143255b88378860b2bc8e5ac782133a7bec312d6e53ef83caea: > exit status 128: > fatal: unable to access 'https://github.com/alexcesaro/log/': Could > not resolve host: github.com > make: *** [Makefile:12: ssh-chat] Error 1 > > > It's clear that mock cannot access the network. So the source code > which normally will be downloaded must be provided as SOURCE files. > > Can this be resolved by changing the spec file. If so, how? > > Or must the source code be chaged where the imports happen? > > import ( > "bufio" > "fmt" > "io/ioutil" > "net/http" > "os" > "os/signal" > "os/user" > "strings" > > "github.com/alexcesaro/log" > "github.com/alexcesaro/log/golog" > flags "github.com/jessevdk/go-flags" > "golang.org/x/crypto/ssh" > > sshchat "github.com/shazow/ssh-chat" > "github.com/shazow/ssh-chat/chat" > "github.com/shazow/ssh-chat/chat/message" > "github.com/shazow/ssh-chat/sshd" > ) > > > > I have uploaded all relevant information to: > > https://senderek.ie/fedora/ssh-chat > > Thanks in advance for any help. > > Ralf > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Alejandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review request: starlark
Hi everyone Starlark is a Python dialect for configuration purposes written in Go that can be used as a library. In fact, Delve has it as dependency, which by the way I want to upgrade to the latest version. https://bugzilla.redhat.com/show_bug.cgi?id=1803223 Thanks! -- Alejandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
