Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 6:01 PM Sebastiaan Couwenberg wrote: > > On 1/19/23 10:26, Shengjing Zhu wrote: > > On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > >>> The history record for golang point release doesn't show regressions. > >> > >> That's good, are you talking about point release in general, or releases > >> to stable? > > > > Missed this one. I'm talking about the upstream point release. We > > haven't met regression so far when we update golang-1.x packages in > > unstable. > > I remember 1.18.4 introducing a regression that broke icingadb: > > https://bugs.debian.org/1015088 > Oh! you're right. I do forget this. However it happens when people are too eager to use "generic" in Go, when it's said by upstream that "generic" is not stable in Go1.18. But yeah it's still breakage in point release. So upstream decides[1] not fixing any "generic" bugs in later Go1.18 point release. [1] https://github.com/golang/go/issues/53852#issuecomment-1184912669 -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
On 1/19/23 10:26, Shengjing Zhu wrote: On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: The history record for golang point release doesn't show regressions. That's good, are you talking about point release in general, or releases to stable? Missed this one. I'm talking about the upstream point release. We haven't met regression so far when we update golang-1.x packages in unstable. I remember 1.18.4 introducing a regression that broke icingadb: https://bugs.debian.org/1015088 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Processed: Re: Bug#1028452: unblock: golang-1.19/1.19.5-1
Processing control commands: > tag -1 confirmed Bug #1028452 [release.debian.org] [pre-approval] unblock: golang-1.19/1.19.5-1 Added tag(s) confirmed. -- 1028452: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028452 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1028452: unblock: golang-1.19/1.19.5-1
Control: tag -1 confirmed Hi, On 19-01-2023 10:22, Shengjing Zhu wrote: On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: On 11-01-2023 09:32, Shengjing Zhu wrote: This is a point release for golang 1.19 which happens today. Where can I find the upstream policy on point release updates? It's documented at https://go.dev/doc/devel/release#policy Yes, only bug fix. Usually there are only a few commits in each point release. Please go ahead. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > > The history record for golang point release doesn't show regressions. > > That's good, are you talking about point release in general, or releases > to stable? Missed this one. I'm talking about the upstream point release. We haven't met regression so far when we update golang-1.x packages in unstable. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > > Dear Shengjing, > > On 11-01-2023 09:32, Shengjing Zhu wrote: > > This is a point release for golang 1.19 which happens today. > > Where can I find the upstream policy on point release updates? Or, if > not documented in one place, can you describe it? Is 1.19 a bug-fix only > branch already, or are new feature appearing in point release updates > too? In other words, help us assess the risk. > It's documented at https://go.dev/doc/devel/release#policy Yes, only bug fix. Usually there are only a few commits in each point release. > > [ Impact ] > > > > If we can be closer to upstream latest release, it will be easier to > > backport > > security patch for bookworm. > > That holds for every package, but we're now frozen, so we need to balance. > > > The history record for golang point release doesn't show regressions. > > That's good, are you talking about point release in general, or releases > to stable? For security updates in Debian stable releases, have you also > been uploading new point releases, or did you pick patches every time? > For bullseye, I uploaded the last point release of Go1.15. See https://tracker.debian.org/news/1284112/accepted-golang-115-11515-1deb11u1-source-into-proposed-updates-stable-new-proposed-updates/ It's a bit sad that upstream support is very short, which is 1 year for a major version. For Go1.19, it will EOL on 2023 Aug, which is very close to bookworm release. So I'll try to upload the last point release of Go1.19 in the 12.1 or 12.2 cycle. After that we would only backport security patches back. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
Dear Shengjing, On 11-01-2023 09:32, Shengjing Zhu wrote: This is a point release for golang 1.19 which happens today. Where can I find the upstream policy on point release updates? Or, if not documented in one place, can you describe it? Is 1.19 a bug-fix only branch already, or are new feature appearing in point release updates too? In other words, help us assess the risk. [ Impact ] If we can be closer to upstream latest release, it will be easier to backport security patch for bookworm. That holds for every package, but we're now frozen, so we need to balance. The history record for golang point release doesn't show regressions. That's good, are you talking about point release in general, or releases to stable? For security updates in Debian stable releases, have you also been uploading new point releases, or did you pick patches every time? Just for confidence, I'm currently leaning to accept this. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1028452: unblock: golang-1.19/1.19.5-1
Hi, On 19-01-2023 03:17, Shengjing Zhu wrote: Sorry not to make it clear. It's a pre-approval request. Sorry from my side too, I forgot the context and only looked at the subject and my first reply... (There was an other unblock request that didn't require any action and I thought it was this one) Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1028452: unblock: golang-1.19/1.19.5-1
Control: reopen -1 Control: retitle -1 [pre-approval] unblock: golang-1.19/1.19.5-1 Hi, On Thu, Jan 19, 2023 at 3:45 AM Debian Bug Tracking System > On Thu, 12 Jan 2023 16:28:51 +0100 Paul Gevers wrote: > > But golang-1.19 is in sync between unstable and testing. > > Closing. > > Paul Sorry not to make it clear. It's a pre-approval request. -- Shengjing Zhu
Processed: Re: Bug#1028452: unblock: golang-1.19/1.19.5-1
Processing control commands:
> reopen -1
Bug #1028452 {Done: Paul Gevers } [release.debian.org]
unblock: golang-1.19/1.19.5-1
Bug reopened
Ignoring request to alter fixed versions of bug #1028452 to the same values
previously set
> retitle -1 [pre-approval] unblock: golang-1.19/1.19.5-1
Bug #1028452 [release.debian.org] unblock: golang-1.19/1.19.5-1
Changed Bug title to '[pre-approval] unblock: golang-1.19/1.19.5-1' from
'unblock: golang-1.19/1.19.5-1'.
--
1028452: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028452
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1028452: unblock: golang-1.19/1.19.5-1
Am Thu, Jan 12, 2023 at 09:17:18PM +0100 schrieb Paul Gevers: > On 12-01-2023 16:50, Shengjing Zhu wrote: > > > But this bug report triggered me: did the golang security situation > > > already improved during this release cycle. I may be misremembering, but > > > I recall the problems on the security archive side haven't been fixed, > > > have they? > > > > For some reference, I did several security updates for golang-1.15 for > > bullseye, but we didn't rebuild other packages. These security updates > > are not urgent enough anyway. > > And others also update some Go packages for bullseye. In general, we > > just do the usual update for stable release. > > > > As for the security archive, IIRC, for bullseye, the security team did > > need to ask ftp-master to copy some individual packages manually. I'm > > not sure how it is going now. But given the low update frequency I > > overseved for bullseye, probably that works. > > Do you agree with this view for bookworm? I know you want the situation > improved, but as far as I am aware nobody (from either side) has been > pushing this forward so it feels a bit late to make this blocking. I agree with what Shengjing wrote. The situation around Go isn't great, but it's pretty much identical to what we had in past releases, so no specific concerns there. Let's simply carry over the existing entry from the release notes. The biggest blocker to fixing this on the toolchain level (like e.g. a script which programatically detects dependencies in need of rebuilds and issues binNMUs) is still the split ftp.d.o/security.d.o, which prevents binNMUs and causes a lot of churn with Built-Using whenever a Go-based program is updated. One possible solution discussed was to import all of each stable distro into security.debian.org, but that disk space demand would mean to move security-master to baremetal (it's currently a Ganeti VM). I don't think there has ever been a solution/outcome so far TTBOMK. Cheers, Moritz
Bug#1028452: unblock: golang-1.19/1.19.5-1
Hi Security team, We stumbled upon golang... On 12-01-2023 16:50, Shengjing Zhu wrote: But this bug report triggered me: did the golang security situation already improved during this release cycle. I may be misremembering, but I recall the problems on the security archive side haven't been fixed, have they? For some reference, I did several security updates for golang-1.15 for bullseye, but we didn't rebuild other packages. These security updates are not urgent enough anyway. And others also update some Go packages for bullseye. In general, we just do the usual update for stable release. As for the security archive, IIRC, for bullseye, the security team did need to ask ftp-master to copy some individual packages manually. I'm not sure how it is going now. But given the low update frequency I overseved for bullseye, probably that works. Do you agree with this view for bookworm? I know you want the situation improved, but as far as I am aware nobody (from either side) has been pushing this forward so it feels a bit late to make this blocking. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 12, 2023 at 11:28 PM Paul Gevers wrote: > > Hi Shengjing, > > On 11-01-2023 09:32, Shengjing Zhu wrote: > > Please unblock package golang-1.19 > > But golang-1.19 is in sync between unstable and testing. > Because I haven't uploaded. This unblock request is for 1.19.5-1, while unstable has 1.19.4-1. > > This is a point release for golang 1.19 which happens today. > > I suspect you're asking for an exception as golang is on our toolchain > list [0]? In *my* interpretation of the freeze date, you have until > today to upload. (Yes, I know others in the team have argued differently > on irc, we'll need to clarify that better next round). So, if you're > quick you didn't even *need* to ask for an exception if you otherwise > meet the criteria [1]. Please check and if you meet them, go ahead if > you upload happens within 2 days. > Yes, for toolchain freeze. golang-1.19 doesn't have autopkgtest for itself. So it will take 5 days to migrate. So it's already late for me to upload. As I read the backlog on irc, when someone asks for rust update, they are told the package should be in testing when the freeze starts. > > + Many Go packages still record Built-Using field, so this upload will > > block >Go packages from migration. Release team need to rebuild outdated > Built-Using. > > I don't think it blocks migration (but maybe I'm misunderstanding what > you mean). But why hasn't this been fixed by now? Do you know if bugs > have been filed? > I mean if I upload golang-1.19 to unstable, and if it's unapproved to migrate to testing, then any Go packages built with golang-1.19/unstable will be blocked on migration. Since they have Built-Using of golang-1.19/unstable, and must be migrated after golang-1.19. And for abuse of Built-Using field, dpkg has added a new field, which is called Static-Built-Using. Anthony Fok has implemented it in dh-golang, and has migrated some packages to use that new field. But this is not something that can be automated. So all Go packages need manual update. There's no call for doing this inside the team yet. That's slow in progress. > >The Go point release or security release may happen several times during > > freeze. > >What kind of release can be expected to be unblocked during freeze? > > Again, it's written in [1]. Please let me know if there's something unclear. > > But this bug report triggered me: did the golang security situation > already improved during this release cycle. I may be misremembering, but > I recall the problems on the security archive side haven't been fixed, > have they? > For some reference, I did several security updates for golang-1.15 for bullseye, but we didn't rebuild other packages. These security updates are not urgent enough anyway. And others also update some Go packages for bullseye. In general, we just do the usual update for stable release. As for the security archive, IIRC, for bullseye, the security team did need to ask ftp-master to copy some individual packages manually. I'm not sure how it is going now. But given the low update frequency I overseved for bullseye, probably that works. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
Hi Shengjing, On 11-01-2023 09:32, Shengjing Zhu wrote: Please unblock package golang-1.19 But golang-1.19 is in sync between unstable and testing. This is a point release for golang 1.19 which happens today. I suspect you're asking for an exception as golang is on our toolchain list [0]? In *my* interpretation of the freeze date, you have until today to upload. (Yes, I know others in the team have argued differently on irc, we'll need to clarify that better next round). So, if you're quick you didn't even *need* to ask for an exception if you otherwise meet the criteria [1]. Please check and if you meet them, go ahead if you upload happens within 2 days. + Many Go packages still record Built-Using field, so this upload will block >Go packages from migration. Release team need to rebuild outdated Built-Using. I don't think it blocks migration (but maybe I'm misunderstanding what you mean). But why hasn't this been fixed by now? Do you know if bugs have been filed? The Go point release or security release may happen several times during freeze. What kind of release can be expected to be unblocked during freeze? Again, it's written in [1]. Please let me know if there's something unclear. But this bug report triggered me: did the golang security situation already improved during this release cycle. I may be misremembering, but I recall the problems on the security archive side haven't been fixed, have they? Paul [0] https://release.debian.org/testing/essential-and-build-essential.txt [1] https://release.debian.org/testing/freeze_policy.html OpenPGP_signature Description: OpenPGP digital signature
Bug#1028452: unblock: golang-1.19/1.19.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: golang-1...@packages.debian.org, z...@debian.org
Control: affects -1 + src:golang-1.19
Please unblock package golang-1.19
This is a point release for golang 1.19 which happens today.
[ Reason ]
Update the latest release.
[ Impact ]
If we can be closer to upstream latest release, it will be easier to backport
security patch for bookworm.
[ Tests ]
Upstream does well tests. And I have tried to use the new version to compile
some programs.
[ Risks ]
The history record for golang point release doesn't show regressions.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
+ This package doesn't have autopkgtest.
+ Many Go packages still record Built-Using field, so this upload will block
Go packages from migration. Release team need to rebuild outdated Built-Using.
The Go point release or security release may happen several times during
freeze.
What kind of release can be expected to be unblocked during freeze?
unblock golang-1.19/1.19.5-1
diff -Nru golang-1.19-1.19.4/debian/changelog
golang-1.19-1.19.5/debian/changelog
--- golang-1.19-1.19.4/debian/changelog 2022-12-07 06:10:54.0 +0800
+++ golang-1.19-1.19.5/debian/changelog 2023-01-11 15:35:00.0 +0800
@@ -1,3 +1,13 @@
+golang-1.19 (1.19.5-1) unstable; urgency=medium
+
+ * Team upload
+ * Add NO_PNG_PKG_MANGLE to prevent mangling testdata.
+This is Ubuntu specific behaviour so they can sync the package without
+vendor patch.
+ * New upstream version 1.19.5
+
+ -- Shengjing Zhu Wed, 11 Jan 2023 15:35:00 +0800
+
golang-1.19 (1.19.4-1) unstable; urgency=medium
* New upstream version 1.19.4
diff -Nru golang-1.19-1.19.4/debian/rules golang-1.19-1.19.5/debian/rules
--- golang-1.19-1.19.4/debian/rules 2022-12-07 06:10:54.0 +0800
+++ golang-1.19-1.19.5/debian/rules 2023-01-11 15:35:00.0 +0800
@@ -7,6 +7,9 @@
# for DEB_VERSION_UPSTREAM
include /usr/share/dpkg/pkg-info.mk
+# Ubuntu mangles png files by default, which can break the testdata.
+export NO_PNG_PKG_MANGLE := 1
+
export GOVER := $(shell echo $(DEB_VERSION_UPSTREAM) | grep -oP
'^([0-9]+\.[0-9]+)')
export GOROOT := $(CURDIR)
diff -Nru golang-1.19-1.19.4/misc/cgo/testcshared/cshared_test.go
golang-1.19-1.19.5/misc/cgo/testcshared/cshared_test.go
--- golang-1.19-1.19.4/misc/cgo/testcshared/cshared_test.go 2022-12-02
02:12:53.0 +0800
+++ golang-1.19-1.19.5/misc/cgo/testcshared/cshared_test.go 2023-01-10
06:38:01.0 +0800
@@ -329,30 +329,46 @@
if err != nil {
return fmt.Errorf("unable to find dlltool path:
%v\n%s\n", err, out)
}
- args := []string{strings.TrimSpace(string(out)), "-D", args[6],
"-l", libgoname, "-d", "libgo.def"}
-
- // This is an unfortunate workaround for
https://github.com/mstorsjo/llvm-mingw/issues/205 in which
- // we basically reimplement the contents of the dlltool.sh
wrapper: https://git.io/JZFlU
- dlltoolContents, err := os.ReadFile(args[0])
- if err != nil {
- return fmt.Errorf("unable to read dlltool: %v\n", err)
+ dlltoolpath := strings.TrimSpace(string(out))
+ if filepath.Ext(dlltoolpath) == "" {
+ // Some compilers report slash-separated paths without
extensions
+ // instead of ordinary Windows paths.
+ // Try to find the canonical name for the path.
+ if lp, err := exec.LookPath(dlltoolpath); err == nil {
+ dlltoolpath = lp
+ }
}
- if bytes.HasPrefix(dlltoolContents, []byte("#!/bin/sh")) &&
bytes.Contains(dlltoolContents, []byte("llvm-dlltool")) {
- base, name := filepath.Split(args[0])
- args[0] = filepath.Join(base, "llvm-dlltool")
- var machine string
- switch prefix, _, _ := strings.Cut(name, "-"); prefix {
- case "i686":
- machine = "i386"
- case "x86_64":
- machine = "i386:x86-64"
- case "armv7":
- machine = "arm"
- case "aarch64":
- machine = "arm64"
+
+ args := []string{dlltoolpath, "-D", args[6], "-l", libgoname,
"-d", "libgo.def"}
+
+ if filepath.Ext(dlltoolpath) == "" {
+ // This is an unfortunate workaround for
+ // https://github.com/mstorsjo/llvm-mingw/issues/205 in
which
+ // we
