- openSUSE Go

RE: OpenSUSE devel:languages:go repositories for SLES 15 SP2 and SLES15 SP3
by Dreucci, Ettore 25 May '23

25 May '23

Hi Dirk, From: Dirk Müller <dmueller(a)suse.de> Sent: Thursday, May 25, 2023 1:51 PM > Hi Ettore, > Do you need it in the *version* that is in that devel project? Because telegraf is part of the SUSE package hub in slightly older version, and you should be able to consume it from there. > If you need the latest version, then I think practically speaking you could pick it from SLE_15_SP4 as there shouldn't be anything in the build environment of a golang package that makes > it actually SP specific. We don't specifically need that version, but we need it to be >= 1.24.3. In the meantime we'll use the workaround of using the SLE_15_SP4 repository, thanks for the tip. > It is part of SUSE Package hub, in a slightly older version. I'll use this occassion to submit an update. > Greetings, > Dirk It would be really nice if you can do that for the 15 SP2 and 15 SP3 Package Hub. Thanks a lot for your feedback. Regards, Ettore

1 0

FW: OpenSUSE devel:languages:go repositories for SLES 15 SP2 and SLES15 SP3
by Dreucci, Ettore 25 May '23

25 May '23

Dear All, I'm writing in regard to the OpenSUSE 'devel:languages:go' project. Me and my colleagues are managing a few hundreds of SLES 15 SP2 and SLES 15 SP3 machines, and we're using on all of them that project's repositories to be able to install the 'telegraf' package. We are fully aware that this repository doesn't guarantee availability of packages for older unsupported versions and that it is not a stable repository to be used in production environments, but we found ourselves in the situation that we depend, for business reason, to the availability of this package and currently we are unable to upgrade massively all this machines to SLES 15 SP4, for which this package is available in the repository. Using InfluxData's own official repository for RPM based distribution is not a viable option as well, as the telegraf package depends on the shadow-utils package, that is not available on SLES under that name (it is named 'shadow' and an issue to InfluxData is already open, from 2018). We're therefore asking you if there is any chance you can make available again the SLES SP2 and SP3 repositories for the 'devel:languages:go' project, so that we have some more times to plan an upgrade to SP4 and to evaluate other possibilities for installing the telegraf package on those machines. Sincerely, Ettore Ettore Dreucci IT Operations Analyst CCH(r) Tagetik - Italy ettore.dreucci(a)wolterskluwer.com Via Borgo Giannotti, 37u - 55100 - Lucca (Italy) www.wolterskluwer.com www.tagetik.com

3 2

Error when vendoring https://github.com/siderolabs/talos: missing ziphash: open hash: no such file or directory
by Johannes Kastl 24 Apr '23

24 Apr '23

Good morning everyone, I am trying to package talosctl, but vendoring the dependencies using obs-service-go_modules fails: > INFO:obs-service-go_modules:Running OBS Source Service: obs-service-go_modules > INFO:obs-service-go_modules:Using archive talos-1.4.0.obscpio > INFO:obs-service-go_modules:Extracting talos-1.4.0.obscpio to /tmp/tmp_z63f9xy > INFO:obs-service-go_modules:Switching to /tmp/tmp_z63f9xy > INFO:obs-service-go_modules:Detected basename talos-1.4.0 from archive > INFO:obs-service-go_modules:Using go.mod found at /tmp/tmp_z63f9xy/talos-1.4.0/go.mod > INFO:obs-service-go_modules:go mod download > INFO:obs-service-go_modules:go mod vendor > INFO:obs-service-go_modules:go mod verify > ERROR:obs-service-go_modules:github.com/siderolabs/cloud-image-uploader : missing ziphash: open hash: no such file or directory > github.com/siderolabs/talos-hack-docgen : missing ziphash: open hash: no such file or directory > github.com/siderolabs/gotagsrewrite : missing ziphash: open hash: no such file or directory > module-sig-verify : missing ziphash: open hash: no such file or directory > github.com/siderolabs/structprotogen : missing ziphash: open hash: no such file or directory > github.com/siderolabs/talos/pkg/machinery : missing ziphash: open hash: no such file or directory > ERROR:obs-service-go_modules:go mod verify failed > Aborting: service call failed: /usr/lib/obs/service/go_modules --archive talos-1.4.0.obscpio --outdir /home/Buildservice/Branches/Branch_devel_kubic/talosctl/tmpiat0cbsy.go_modules.service Not sure if this is an issue with the service or failing dependencies on my machine or with upstream. Here is the bugreport (in case it is a bug in go_modules). > https://github.com/openSUSE/obs-service-go_modules/issues/31 Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

1 0

Re: Vendoring sub-packages/subdirectories?
by Jeff Kowalczyk 15 Mar '23

15 Mar '23

Hello Johannes, Kubescape appears to be the first example, but this is a case I would like obs-service-go_modules to handle or provide a recommended approach in the README. Agreed, there should be two independent vendor.tar.gz. The question of whether we should support multiple stanzas of the service or multiple go.mod per stanza is a good one. Looking briefly at git2go this is a library with bindings to libgit2. It produces no executable binaries so it shouldn't be its own RPM package. I'll review the specific layout of kubescape and see what might work and stay consistent across similar packages. Thanks for the example. Jeff ________________________________ From: Johannes Kastl Sent: Monday, March 13, 2023 09:39 To: opensuse-go(a)opensuse.org Subject: Vendoring sub-packages/subdirectories? Hi all, kubescape (https://github.com/kubescape/kubescape) is using a git submodule to "include" git2go. This is being built in a separate step and needs its own dependencies. Is there a way to vendor the "main" program and the one in the subdirectory using the go-modules service? Adding a second stanza to the service file and using "subdir" results in a vendor.tar.gz only containing the files for the subdirectory. Or do I need to build the subdirectory separately and pull it in via BuildRequires? Thanks in advance, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 2

Vendoring sub-packages/subdirectories?
by Johannes Kastl 14 Mar '23

14 Mar '23

Hi all, kubescape (https://github.com/kubescape/kubescape) is using a git submodule to "include" git2go. This is being built in a separate step and needs its own dependencies. Is there a way to vendor the "main" program and the one in the subdirectory using the go-modules service? Adding a second stanza to the service file and using "subdir" results in a vendor.tar.gz only containing the files for the subdirectory. Or do I need to build the subdirectory separately and pull it in via BuildRequires? Thanks in advance, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 2

dagger 0.3.6 failing with go error: 'go: -mod may only be set to readonly when in workspace mode, but it is set to "vendor"'
by Johannes Kastl 01 Dec '22

01 Dec '22

Hi all, I just updated dagger to the latest version, and in 0.3.6 the build fails: > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_de… > [ 25s] + go build -mod=vendor -buildmode=pie -o bin/dagger ./cmd/dagger > [ 25s] go: -mod may only be set to readonly when in workspace mode, but it is set to "vendor" > [ 25s] Remove the -mod flag to use the default readonly value, > [ 25s] or set GOWORK=off to disable workspace mode. > [ 25s] error: Bad exit status from /var/tmp/rpm-tmp.e5D1Th (%build) Removing the "-mod=vendor" leads to errors because go tries to pull in all dependencies. Adding the "GOWORK=off" on the beginning of the "go build" line leads to errors regarding inconsistent vendoring: > [ 21s] go: inconsistent vendoring in /home/abuild/rpmbuild/BUILD/dagger-0.3.6: > [ 21s] github.com/google/uuid@v1.3.0: is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod > [ 21s] > [ 21s] To ignore the vendor directory, use -mod=readonly or -mod=mod. > [ 21s] To sync the vendor directory, run: > [ 21s] go mod vendor > [ 21s] error: Bad exit status from /var/tmp/rpm-tmp.j5l1jd (%build) Any ideas on how to solve this? Apart from waiting for upstream to fix the vendoring? Thanks in advance! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

1 0

Warning/Error when building ktop: 'utf-8' codec can't decode byte 0xc2 in position 6583: invalid continuation byte
by Johannes Kastl 04 Jan '22

04 Jan '22

Hi all, I got a funny error when building ktop: > [ 183s] ktop.x86_64: E: readelf-failed /usr/bin/ktop 'utf-8' codec can't decode byte 0xc2 in position 6583: invalid continuation byte > [ 183s] Executing readelf on this file failed, all checks could not be run. Anyone ever encountered that? Any idea how to fix it? This is the package: https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_de… And this is the upstream issue: https://github.com/vladimirvivien/ktop/issues/8 Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

1 1

Latest guidelines on packaging go?
by Johannes Kastl 01 Jan '22

01 Jan '22

Hi everyone, as I lost track of this in the last half a year, what is the latest state of building golang packages? Especially calling "go build" and ensuring fPIE etc. get properly set for all OS releases? https://en.opensuse.org/openSUSE:Packaging_Go is still outdated, I guess. FYI, I just built this one and got two nice warnings. And I think the latter is packaging-related... https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_de… > [ 148s] ktop.x86_64: E: readelf-failed /usr/bin/ktop 'utf-8' codec can't decode byte 0xc2 in position 6583: invalid continuation byte > [ 148s] Executing readelf on this file failed, all checks could not be run. > [ 148s] > [ 148s] ktop.x86_64: W: position-independent-executable-suggested /usr/bin/ktop > [ 148s] This executable should be position independent (all binaries should). Check > [ 148s] that it is built with -fPIE/-fpie in compiler flags and -pie in linker flags. Kind Regards, Johannes P.S.: Happy New Year everyone! -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

1 0

Settings the version in rke does not work
by Johannes Kastl 14 Mar '21

14 Mar '21

Hi all, can someone help me and find my mistake? Package rke: https://build.opensuse.org/package/show/home:ojkastl_buildservice/rke main.go allows setting the version: https://github.com/rancher/rke/blob/master/main.go#L18 I have added this flag to the %gobuild but still the version is reported as "dev": %gobuild -mod=vendor -ldflags="-X main.Version=%{version}" . The grafana package used a "manual build" without the macro to set this (this is where I stole the syntax from), but I thought handing over parameters like -mod=vendor worked with %gobuild in the meantime? Sadly enough, this is not mentioned at all in the Packaging Go documentation... https://en.opensuse.org/openSUSE:Packaging_Go But it states: > As I know, %goprep, %gofix, %gobuild, %goinstall, %gosrc, %gotest are macros that can not be quoted because they allow arguments. which sounds like %gobuild should except arguments? Thanks in advance! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 4

Packaging for Galène videoconferencing server
by Jeff Kowalczyk 18 Jan '21

18 Jan '21

Starting a thread to continue a conversation with Michael Ströder on the buildservice list regarding OBS build and packaging for the Galène videoconferencing server written in Go [1] [2]. Michael encountered difficulties using obs-service-go_modules to assemble dependencies for OBS offline build. These and a few other suggestions are fixed in SR 864032 [3]. Summarizing, upstream currently uses a version scheme tagged as galene-0.2 that was difficult to specify in _service when using tar_scm. The typical go convention of v0.2.0 works better with defaults, but manually setting _service param version bypassing detection worked in this case. This was also an opportunity to test the go1.14+ detection of vendor/ directory, however I found it was still necessary to set -mod=vendor in the go build invocation. I will look into why that is in the hopes most packages can omit that argument going forward. The typical indication of missing or misconfigured vendor/ is "dial tcp: lookup proxy.golang.org [..] connection refused". I don't think there's a way to improve that error message from our position downstream, so it will be documented as output to watch for. Thanks for the Galène package, Michael. I'm looking forward to seeing how the upstream project progresses. Jeff [1] https://github.com/jech/galene [2] https://galene.org/ [3] https://build.opensuse.org/request/show/864032 -- Jeff Kowalczyk Software Engineer, Go Developer Experience SUSE Linux Email jkowalczyk(a)suse.com Timezone US/Pacific http://suse.com

1 0