> To me the vendoring approach Fedora is going for feels wrong, but I can
> understand they aren't happy with the current situation.
It feels wrong to me as well, but seems Fedora decided to "give in"
instead of educating Go developers to reign in on the dependency
sprawl. This is a very telling q
Hi,
This might be an interesting reaf to people in Debian's Go team:
https://fedoraproject.org/wiki/Changes/GolangPackagesVendoredByDefault
I am not advocating we should do something just because Fedora did, but it
is good to be aware what major players in the field are doing and what they
motiva
Hi!
> > Where did you find MRs for updates on 2 branches?
>
> See this for example:
>
> https://salsa.debian.org/go-team/packages/golang-github-buger-goterm/-/merge_requests/3
> https://salsa.debian.org/go-team/packages/golang-github-buger-goterm/-/merge_requests/4
>
> And another one:
>
> https:/
Hi!
> > This should be fairly easy. For example Vincent submitted a package
> > update as MR in
> > https://salsa.debian.org/go-team/packages/fzf/-/merge_requests/6.
> > Jianfeng submitted a new package in
> > https://salsa.debian.org/go-team/packages/apt-transport-oci/-/merge_requests/4
> > and L
Hi all whom I have been mentoring or otherwise discussing this topic with,
While mentoring multiple people in 2025 I have noticed that reviewing
Debian packaging, both for updates of existing packages and creation
of new packages, is by far most convenient if there is a Merge Request
on Salsa.
It
Hi Go packagers!
If you are in Brest, I hope to have time chat with you all and
hopefully you can also attend the BoF session on Monday at 16:30 on
packaging workflows:
https://debconf25.debconf.org/talks/135-merge-request-based-collaboration-for-debian-packages/
On Thursday at 14:00 there is als
:50, Otto Kekäläinen wrote:
>
> Hi,
>
> What is the current maintenance plan for these?
>
> https://salsa.debian.org/go-team/infra/pkg-go-tools
> https://salsa.debian.org/go-team/infra/provisioning
> https://salsa.debian.org/go-team/migrate-pkg-go-to-salsa
> https
Hi all!
I was today reviewing a bunch of Go team packages with the intent to
sponsor uploads, but they all have in common that Salsa CI is not
running at all, or is not being triggered correctly.
https://salsa.debian.org/go-team/packages/apt-transport-oci
https://salsa.debian.org/go-team/packages
Hi!
> I want to package and help maintain the Ethereum software written in go.
>
> I've started exploring the Debian process with this request for sponsorship:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108304
>
> Is there a kind mentor available here to guide me?
>
> I would like to l
Hi!
I read the commits and added some comments. As there is no MR, I
commented directly on the commits at
https://salsa.debian.org/go-team/packages/apt-transport-oci
I can upload this after a bit of polish.
> > Personally, I am compelled by being able to change my current workflow from:
> >
> > gbp dch --release --commit
> > git-buildpackage -S
> > debsign *.changes
> > dput ftp-master *.changes
>
> I have seen so many broken source packages, that don't even build or
> don't create the intended binary
> > how's the go teams stance on tag2upload?
>
> I don't see any advantage of tag2upload, so I won't use it.
You are the FTP Master in Debian, right? Why do you not see any
advantages? The system seems seriously flawed if FTP Master thinks it
has no benefits.
Personally, I am compelled by being
Tere Raul!
I can review and sponsor all your packages, but I am traveling right now,
so I will do it next week.
Hi!
There are currently 101 open MRs at
https://salsa.debian.org/groups/go-team/-/merge_requests
If you have spare time this weekend, I would appreciate if you can take a
look and provide some feedback. Even a shallow review is helpful.
Of the 101, 8 are mine. For the other 93 in the list it see
Thanks Aloïs for the information.
I posted https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/6
to have this recorded in context, in the repo README where the next
person looking at the repo and wondering what it is about is more
likely to stumble across it. I am happy to iterate
seless and should be deleted and replaced with
Salsa CI.
On Mon, 28 Apr 2025 at 10:50, Otto Kekäläinen wrote:
>
> Hi,
>
> What is the current maintenance plan for these?
>
> https://salsa.debian.org/go-team/infra/pkg-go-tools
> https://salsa.debian.org/go-team/infra/provisionin
Hi,
In https://salsa.debian.org/go-team/packages/usql/-/merge_requests/2 I
am planning to introduce alongside the binary `usql` package also a
`golang-github-xo-usql-dev` that can be used by other Go packages to
build with this usql as a dependency.
The main change is:
override_dh_auto_install:
d
Hi,
What is the current maintenance plan for these?
https://salsa.debian.org/go-team/infra/pkg-go-tools
https://salsa.debian.org/go-team/infra/provisioning
https://salsa.debian.org/go-team/migrate-pkg-go-to-salsa
https://salsa.debian.org/go-team/stapelbergtest
Should we plan to stop using them a
Hi!
Thanks for your previous reviews and this too!
> licenserecon fails on MIT <-> Expat. My reading on [1] suggests that it is
> OK to use expat on all of these unless the text differs from that of Expat.
This is actually already fixed in latest version on
https://salsa.debian.org/go-team/packa
Hi,
I believe https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1
is ready for review now. It is a new package 'usql' and will go into
NEW queue, so I also filed in parallel
https://salsa.debian.org/newgateway-team/reviews/-/issues/10 to test
how the new initiative for pre-review wor
> Nice. Could you describe with example commands how you do the import of
> the debian/vendor/? I think I can understand the end result, but not
> how you get there. Is it this step?
>
> https://salsa.debian.org/go-team/packages/usql/-/blob/60a45c4e5e18b89c297b6cb6adf62115041a9d8b/debian/vendor/
Hi!
After assessing pros and cons, I decided to stick with the `go mod
vendor` -> debian/vendor/ approach. See example in
https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1 and
specifically commit
https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1/diffs?commit_id=60a4
Hi Nilesh,
Thanks a lot for your help in getting a couple tricky ones sorted!
I have all the build issues sorted out now at
https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1
Only thing that remains is updating the debian/copyright to include
the debian/vendor/ files.
This MR als
> I: Unpacked source needs 1612020 KiB (according to du -k) and you have
> 2034956 KiB free (according to df -k).
If you run these commands manually in the build directory inside the
build container, what do they print?
Your previous df output was from root directory.
Hi,
> >Note I got this far by skipping the test suite. I will need to revisit
> >it though, but getting end-to-end working first makes optimizing
> >stages easier workflow-wise.
>
> What are the other failing tests?
Alright, I have now everything else woking apart from the test suite.
Currently i
Thanks!
You patch works to get dh_golang pass and generate the package headers:
---
/home/otto/debian/go-team/debcraft-build-usql-1744309270.479b82f+import.0.19.19/control.log
2025-04-10 21:21:59.419959916 +0300
+++
/home/otto/debian/go-team/debcraft-build-usql-1744394161.882a13f+import.0.19.19
Thanks!
Note I got this far by skipping the test suite. I will need to revisit
it though, but getting end-to-end working first makes optimizing
stages easier workflow-wise.
...
> So, dh-golang runs `go list -f` to generate a dependency list and propagate
> to substvar as per the
> manpage[1].
>
Hi!
> On 09/04/25 11:18 pm, Otto Kekäläinen wrote:
> > I am still working on this
> > https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1
> >
> > Currently I am stuck with another build scope issue. Any tips from anyone?
> >
> > Seems the test
Hi all,
I am still working on this
https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1
Currently I am stuck with another build scope issue. Any tips from anyone?
Seems the tests depend on files that the build system does not copy,
and Go tests fail. Full log in MR pipeline above an
Is the goal of having the version string in all go packages?
Or should golang-github-minio-minio-go be kept in the archive and just
updated to latest?
ql/-/jobs/7283520
Error output for context:
# dpkg-buildpackage -b
dpkg-buildpackage: info: source package usql
dpkg-buildpackage: info: source version 0.19.19-1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Otto Kekäläinen
dpkg-buildpackage:
Hi!
Thanks all, I am having (slow) progress at
https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1 with
the tips.
Thanks Taavi and Ahmad for your tips!
Unfortunately none of the `debian/rules` tricks worked, see what I
tried and notes in commit 77a3d40c at
https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1/commits
Eventually, the only thing that worked was adding `//go:build ignore`
lines in s
Hi,
Are people in the Go team always packaging every individual go.mod
require as a separate package? Or are people here occasionally
"vendoring" packages in e.g. debian/vendor/ to avoid polluting Debian
archives with tiny packages?
I am considering doing this in usql
(https://salsa.debian.org/go
> Thanks! I gave some comment on the merge request.
Thanks!
> Where are we with enabling Salsa CI pipeline for all Go projects by
> default? Given that Go packages often need new dependencies, I would
> suggest to add `SALSA_CI_DISABLE_APTLY: 0` so that you can easily access
> the Salsa-built *
Hi!
The man page https://manpages.debian.org/unstable/dh-golang/dh_golang.1p.en.html
recommends using `Built-Using: ${misc:Static-Built-Using}`, which was
confirmed by Nilesh to be correct and advisable practice, but any
package using this will run into the Lintian nag that recommends using
the o
Hi Simon and others,
You raised earlier a concern that using GITLAB_TOKEN directly in glab
is a security concern
as users may end up storing API keys in plain text in .bashrc files or similar.
I just filed
https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/5
that uses the secre
Hi,
Thanks for looking into golang-x-tools.
Salsa CI does not yet have built-in reverse deps check, but you can see an
experimental one we tested in
https://salsa.debian.org/go-team/packages/golang-golang-x-net/-/merge_requests/1
to while planning to update golang-x-net. Running ratt manually is
Hi!
For the record, Guillem and Tina today removed the "proposed workflow
2025" section at
https://go-team.pages.debian.net/workflow-changes.html#_2025_01_changes_proposed
so nobody can see it, and reverted almost all of my improvements in
the dh-make-golang tool.
Details at
https://github.com/De
Hi!
Thanks Arnaud for a thoughtful reply. The list of top contributors is
a great data point!
Hi!
Thanks Tina for following up on the mailing list!
> > Can we agree to update the Go team policy to follow this and default
> > to 'debian/latest' going forward?
>
> I strongly oppose this: not only it would create an enormous amount of
> churn, but it is also a regression as many have already
Hi Arnaud and Mathias!
> Can we agree to update the Go team policy to follow this and default
> to 'debian/latest' going forward?
>
> There are <2000 packages in Debian that use the 'debian/sid' branch
> name, and out of these ~1300 are from the Go team. The Go team should
> not diverge from gener
Nice, glad to see you are taking on more packages!
Just out of curiosity, what are you using it for?
A large part of the FOSS community has moved to Podman instead of
Oracle affiliated Docker. Have you checked if a Podman BuildKit plugin
could do the same?
Hi!
Michael Stapelberg proposed in 2017 that the Go team should use
'debian/sid' as the default branch, in effort to unify with DEP-14 at
the time
(https://go-team.pages.debian.net/workflow-changes.html#_new_workflow_3).
Turns out using 'sid' as the git HEAD wasn't a good idea, as it may
lead to
Hi,
> I know we are using Static-Built-Using similar to the Rust Team to track
> build dependencies of libraries, but it doesn't seem to be known to
> lintian. Is there a proposal to add this and eliminate the warning?
>
> In the mean time, it is worth it to add an override to hide it?
>
> Even if
Hi Guillem!
> > I plan to upload dh-golang and dh-make-golang to Debian unstable by
> > the end of the month to get all the new features in use.
> >
> > I would appreciate it if team members can review open PRs/MRs so we
> > get as many improvements as possible included in this upload:
> >
> > htt
> > Any existing package that is updated with pkg-go-tools will get Salsa
> > CI because of
> > https://salsa.debian.org/go-team/infra/pkg-go-tools/-/commit/da61572b858250c1da6a00852455149cbc5b7a10
>
> I don't know what that is, when and how is that used?
Package https://salsa.debian.org/go-team/
> > I plan to upload dh-golang and dh-make-golang to Debian unstable by
> > the end of the month to get all the new features in use.
>
> I support making an upload earlier, to more strongly trigger review by
> the code. For easier review, everyone can use this link:
Sure, I can do it in a couple
Hi all!
I plan to upload dh-golang and dh-make-golang to Debian unstable by
the end of the month to get all the new features in use.
I would appreciate it if team members can review open PRs/MRs so we
get as many improvements as possible included in this upload:
https://github.com/Debian/dh-make
> Will new projects created by 'dh-make-golang create-salsa-project' get
> them enabled by default too, or does that require upgrading
> 'dh-make-golang'?
Any existing package that is updated with pkg-go-tools will get Salsa
CI because of
https://salsa.debian.org/go-team/infra/pkg-go-tools/-/comm
to unblock anyone from trying to run Salsa CI.
Example of a package already using Salsa CI:
https://salsa.debian.org/go-team/packages/glow/-/pipelines/787862
Implemented via:
https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/4
On Sun, 24 Nov 2024 at 17:22, Otto Kekäläinen
Thanks everybody for feedback!
Nice to see a lot of people participated in the discussion this week.
Based on the and some people being against having merge requests as
part of the recommended workflow, and some also objected having Salsa
CI as part of the team workflow, I decided to split that n
Hi,
Thanks everyone for the feedback, I have updated
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/7
Direct link to artifact:
https://otto.pages.debian.net/-/go-team.pages.debian.net/-/jobs/6923949/artifacts/build/workflow-changes.html
On Tue, 14 Jan 2025 at 12:45, Ni
Thanks Nilesh and Simon for the feedback here, and thanks Maytham and
Taavi for posting feedback on the MR!
> About the "Give and get reviews" in your MR: to clarify, that is, in no way,
> mandatory right?
> I guess that from work "should" instead of "must".
The MR text says: "Reviews are recomm
Hi!
In line with what I have already been doing, I now published a draft
for workflow changes at
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/7
Direct link to latest build artifact for convenience:
https://otto.pages.debian.net/-/go-team.pages.debian.net/-/jobs/69171
> I support enabling Salsa CI pipelines for all Go projects.
>
> I gave a GitLab merge request "thumbs up" now, but I feel that such
> indication is more about reviewing the actual code (which I'm not
> qualified to do) than to actually give you a +1 on the overall purpose.
Thanks! We are a team a
to paint the full picture of all my proposals combined
help to optimize the Go packaging workflow.
On Thu, 2 Jan 2025 at 00:27, Otto Kekäläinen wrote:
>
> Hi all!
>
> Next step in this list would be number 5.
>
> Changing defaults for new packages and a script to bulk upd
> But there are packages (e.g.,
> cosign) that ultimately Build-Depends on both, so both has to be
> installed at the same time.
Ah, in that case it makes sense to have both in the same package as
the workaround.
Hi,
The go-tuf version string 2.0.2+0.7.0-1 seems cryptic. How is the
package lifecycle planned to go if it actually contains the same
package twice?
Would it not be much simpler to just have two source packages in
Debian, just like all other packages that have multiple versions?
Hi all!
I found out about Gophian[1, 2] yesterday and I had no clue it
existed. It seems new, from summer 2025. I wonder how many people are
using it? What do you think about it?
I noticed Nicolas is working on
https://github.com/Debian/dh-make-golang/pull/240 which seems to have
been one of the
Hi!
> > > I think it would be a good idea to use the script at [1] to update all
> > > the Go team repos, after it's updated to account for the
> > > "%{project_path}" variable, as well as replacing
> > > "github.com/xanzy/go-gitlab" with its new import path.
> > >
> > > It also needs to be update
Hi,
> Does this mean that maintaining upstream Git history will be standard in
> the Go team?
Yes, it means that you can git blame on upstream code (outside of
debian/) and see what was introduced when, and you can run gbp switch
--force and git cherry-pick -x to backport fixes
from newer upstre
Hi!
> I'm in full support of these changes, thank you for working on this.
Thanks!
> I think it would be a good idea to use the script at [1] to update all
> the Go team repos, after it's updated to account for the
> "%{project_path}" variable, as well as replacing
> "github.com/xanzy/go-gitlab"
On Sat, 4 Jan 2025 at 22:19, Otto Kekäläinen wrote:
>
> Hi,
>
> Personally I use Files-Excluded in the d/copyright file and import
> with gbp import-orig which handles everything automatically correctly
> assuming the d/gbp.conf is configured correctly and has the
> upstream-
Hi,
Personally I use Files-Excluded in the d/copyright file and import
with gbp import-orig which handles everything automatically correctly
assuming the d/gbp.conf is configured correctly and has the
upstream-vcs-tag format so gbp can do the git merge. See the gbp.conf
template I suggest all pack
Hi Loren!
..
> > https://salsa.debian.org/go-team/packages/gh/-/merge_requests/3
> >
> > I manually started the Salsa CI job after filing the MR, but I see that
> > is it stuck waiting for a Runner in the provision stage due to no
> > available runners. Otto, is this because this is being run outs
Hi all!
Next step in this list would be number 5.
Changing defaults for new packages and a script to bulk update all
existing repositories posted at
https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/4
Feedback welcome!
On Thu, 5 Dec 2024 at 21:58, Otto Kekäläinen wrote
> OK, I've created a second merge request with a fix for another CVE. I've
> left it as a draft as I haven't had a chance to do manual testing of the
> feature yet.
Thanks! I already did first pass of review on
https://salsa.debian.org/go-team/packages/gh/-/merge_requests/2
Posting link here so ot
Hi Loren!
> We can hold off on the Bookworm update for a little bit if that would
> help. As this is my first attempt at getting a package into
> stable-updates, I am learning a bit myself. Another developer pointed me
> at the appropriate part of the developer reference for this so I realize
> th
Hi,
> > If there is a true emergency then sure, go ahead an upload a package
> > without coordination. But this wasn't so urgent, Santiago could have
> > easily waited one or two days instead of the 2h he did now. Just
> > waiting a bit longer isn't that much extra work, it is just a matter
> > of
> >> You bypassed now both code reviews and uploaded despite failing CI.
>
> As far as I know, there's no hard-bound team policy to upload only when
> the pipeline passes.
No, there isn't a policy, but the pipeline here isn't the main point
here. Do you notice the culture aspect of hero behavior v
Hi all,
There are currently 91 open merge requests in the Go team:
https://salsa.debian.org/groups/go-team/-/merge_requests
Some of them might be stalled for various reasons, but I there are
many that are genuinely pending review/feedback. If you have some
spare time, please go and check out a co
Hi Loren!
> As this package doesn't really follow the dh-make-golang workflow, I did
> not have as much documentation to go with (no pun intended). Does
> uploading a package to mentors help here or is just making a fork on
> Salsa the best way to go here? Is there a BKM I should be following
> he
The CVE is two months old, it alone isn't a reason to rush an upload within
hours specifically today.
I am just trying to highlight here that while it is good that we have
heroes who do a bunch of solo work for Debian, doing things a bit slower
and inclusively will help build teams and grow colla
Hi Santiago!
I see you now tagged debian/2.46.0-2 and likely uploaded it.
Why were you in such a hurry? Why couldn't you let the Go team take care of
this?
You bypassed now both code reviews and uploaded despite failing CI.
I am glad you put work into this but it would have been more collaborat
Hi!
On Wed, 18 Sept 2024 at 11:48, Louis-Philippe Véronneau
wrote:
>
> On 2024-09-15 11:45, Otto Kekäläinen wrote:
> > Hi!
> >
> >>> I was reviewing a new Debian package at
> >>> https://salsa.debian.org/lintian/lintian-ssg/-/merge_requests/2 where
&
Hi all,
> 4. Start running Salsa CI on Go team packages manually
>
> The current Go team CI run is incomprehensible to me. It does at least
> *not* test the most important thing a CI in Debian should do, which is
> to tell if a package builds in Debian or not. This can be fixed right
> away by mak
Hi!
> I'm trying to package the soci-snapshotter for nerdctl. This package
> requires and embeds a patched copy of zlib, and I've added a lintian
> override for this reason:
> https://salsa.debian.org/go-team/packages/golang-github-awslabs-soci-snapshotter/-/blob/a7bf099/debian/soci-snapshotter.li
Hi!
Can somebody press the "Approve" button at
https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2
so I feel confident merging it?
The current Salsa CI pipeline in go-team does not test if the Go
package can build so having basic Salsa CI capability seems like an
obvious thing
Hi,
> The extra permissions the owners have is related to some security
> things and role management and the likes iirc. I believe the
> documentation[0] has the full info.
>
> --
> Best,
> Ananthu
>
> [0] - https://docs.gitlab.com/ee/user/permissions.html
>
> On 17 December 2024 7:35:33 am UTC, S
you
could add me as the 97th DD with owner permissions in the group.
On Tue, 3 Dec 2024 at 22:42, Otto Kekäläinen wrote:
>
> Hi Aloïs and Anthony!
>
> I know the packages are team maintained, but just to be sure I wanted
> to check if you are OK if I update the mentioned packages
Hi,
> > https://github.com/Debian/dh-make-golang/blob/d70d43c2c98bd8419d41c7dc741ece4bff437ff1/make.go#L575
> >
> > We maintain a list of well-known hosts. If you want to change the
> > value for this host, please submit PR against this list.
> > dh-make-golang also says that:
>
> I just looked at
Hi,
I wanted to bump up this once more, and remind that each suggestion has a
corresponding MR/PR which you can "thumbs up" in Salsa/GitHub as a token of
approval.
..or thumbs down to show that oppose it so I know not to merge it in
coming month.
On Thu., Dec. 5, 2024, 21:58 Otto
Hi Ahmad!
I use personally nfty and I am happy to provide reviews to MRs on Salsa for
the various subtasks you are working on here.
Simon already replied on your questions. Additionally I suggest you ask
upstream what they recommend as the best was to build ntfy without Stripe.
That way you can m
Hi!
On Sat, 7 Dec 2024 at 05:45, Nilesh Patra wrote:
> On 07/12/24 5:37 pm, Simon Josefsson wrote:
> > I think we exagerate the salsa CI load concerns. My perception is that
> > while the Go package system is substantial, the churn is actually fairly
> > low and building Go packages is much faste
Hi Simon and others,
Can somebody grant me admin permissions to the equivalent
go-team/packages repos so I can modernize them and have Salsa CI
properly enabled?
> https://salsa.debian.org/go-team/packages/golang-github-charmbracelet-glamour
> https://salsa.debian.org/go-team/packages/golang-gith
Hi,
I am about to upload these packages to Debian unstable:
https://salsa.debian.org/otto/golang-github-charmbracelet-glamour
https://salsa.debian.org/otto/golang-github-muesli-gitcha
https://salsa.debian.org/otto/golang-github-caarlos0-env
They have already been discussed on this list, they are
Hi!
> > 1. Switch to most recent and final DEP14 names 'debian/latest' and
> > 'upstream/latest': https://github.com/Debian/dh-make-golang/pull/225
> >
> > Go team already follows DEP14 since 2019, but the standard evolved, so
> > Go team should update accordingly. We can start doing this in new
>
Hi all Go team members,
I am proposing we update the Go team workflow for 2025 on a few points:
1. Switch to most recent and final DEP14 names 'debian/latest' and
'upstream/latest': https://github.com/Debian/dh-make-golang/pull/225
Go team already follows DEP14 since 2019, but the standard evolv
Thanks Simon for working on this!
Can you point to a man page or blog post or README to help people like
me learn what this is and how it is designed to be used?
Hi Aloïs and Anthony!
I know the packages are team maintained, but just to be sure I wanted
to check if you are OK if I update the mentioned packages to latest
version, ask for review on this list and then upload to unstable? I
already did test imports and reverse dep builds in my fork so I know
i
Hi,
I am about to upload these packages to NEW:
https://salsa.debian.org/go-team/packages/golang-github-muesli-mango-pflag
https://salsa.debian.org/go-team/packages/golang-github-muesli-mango-cobra
https://salsa.debian.org/go-team/packages/glow
They have already been discussed on this list, they
Hi!
Thanks for the tips! I think I prefer the dak method, as it does not
require me to update/fetch package lists locally, and it has sensible
output that confirms if I used the correct package name.
± ssh mirror.ftp-master.debian.org "dak rm -Rn -b golang-github-muesli-gitcha"
Nothing to do.
±
Hi!
I am planning to upload new versions of some Go libraries, and before
doing it I wanted to test that the reverse dependencies don't break.
However, for these two I can't find any:
# apt-cache rdepends golang-github-caarlos0-env
E: No packages found
# apt-cache rdepends golang-github-caarlos0-
Thanks Nicolas for pointing out off-thread that dh_golang already had these:
DH_GOLANG_EXCLUDES
DH_GOLANG_EXCLUDES_ALL
https://manpages.debian.org/unstable/dh-golang/Debian::Debhelper::Buildsystem::golang.3pm.en.html#DH_GOLANG_EXCLUDES
I switched to using these in all the packages and it works w
> > I wonder if Go in Debian has something like ${misc:Go-Depends} similar
> > how C programs will automatically populate the correct run-time
> > libraries based on what was used during the build into the
> > ${shlibs:Depends} variable.
>
> I don't think there's something like this for Go debhelpe
Hi Nicolas!
> > That in turn leads down another rabbit hole, as
> > updating these libraries need to be tested for compatibility with
> > existing packages, and a quick rdepends test build on e.g.
> > https://salsa.debian.org/otto/golang-github-charmbracelet-glamour/-/pipelines/770887
> > shows th
Hi!
I filed the estimate bug at https://github.com/Debian/dh-make-golang/issues/231
This command I had not tried before turned out very useful:
# dh-make-golang check-depends
NEW dependency github.com/charmbracelet/lipgloss
(golang-github-charmbracelet-lipgloss-dev)
NEW dependency github.com/cha
Hi!
While working on Go packages recently, I noticed many of them have the
subdirectories
examples/
testdata/
The stuff in examples/ is shipped in many Debian packages currently in
the binary deb files. In one case the examples/ even lead to a
/usr/bin/example being generated and it would have go
Hi!
> Yes. See go.mod for required versions.
> https://salsa.debian.org/go-team/packages/glow/-/blob/debian/latest/go.mod?ref_type=heads#L10
It is a bit too much to manually go through each one. Also, that is
not needed most of the time, as running dh-make-golang itsel already
does a pretty decen
1 - 100 of 117 matches
Mail list logo
