+Maytha who prepared the upload.

On Sun, Jan 28, 2024 at 05:05:55PM +0000, Julian Gilbey wrote:
> Hi Nilesh,
> 
> You did the last upload of this package - do you have any idea about
> this bug?

I've been trying to track it down for the past hour but I don't have a fix that 
I am confident about.
I initially thought it may have been due to some sort of overflow due to 
bitshift so I applied this patch

--- a/fuse/print.go
+++ b/fuse/print.go
@@ -119,7 +119,8 @@
 func (names *flagNames) set(flag int64, name string) {
        entry := flagNameEntry{bits: flag, name: name}
        for i := 0; i < 64; i++ {
-               if flag&(1<<i) != 0 {
+               bitshift := uint64(1) << i
+               if uint64(flag)&bitshift != 0 {
                        if ie := names[i]; ie.bits != 0 {
                                panic(fmt.Sprintf("%s (%x) overlaps with %s 
(%x)", name, flag, ie.name, ie.bits))
                        }

but it did not help.

On compiler level O_LARGEFILE is set to 0x0 on 64 bit systems while it is 
0x8000 (equivalent to 32-bit integer) for i386.
In fuse/print.go, LARGEFILE is hard-coded to "0x8000" which ends up matching 
the value on 32-bit system
and it chokes with the panic.

Interestingly, for all other 32-bit archs that are tested on debci, it is set 
to a value higher than 0x8000 and so
they magically work. Given that the package is written with 64-bit systems in 
focus, this change can work:

-               0x8000:                     "LARGEFILE",
+               0x0:                    "LARGEFILE",

And I have confirmed that it gets the test passing, but this looks... wrong.
OTOH, the if block inside and the panic statements were probably always deadcode
whenever LARGEFILE flag was being passed considering it was geared towards 
64-bit use-cases.

Please let me know what you think about this.

> Best wishes,
> 
>    Julian
> 
> ----- Forwarded message from Paul Gevers <elb...@debian.org> -----
> 
> Date: Sun, 28 Jan 2024 08:50:51 +0100
> From: Paul Gevers <elb...@debian.org>
> Subject: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to
>       testing for too long: i386 autopkgtest regression
> To: sub...@bugs.debian.org
> 
> Source: golang-github-hanwen-go-fuse
> Version: 2.1.0+git20220822.58a7e14-1
> Severity: serious
> Control: close -1 2.4.2-1
> Tags: sid trixie
> User: release.debian....@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:golang-github-hanwen-go-fuse has been trying to migrate
> for 31 days [2]. Hence, I am filing this bug. The version in unstable fails
> its own autopkgtest on i386.
> 
> If a package is out of sync between unstable and testing for a longer period,
> this usually means that bugs in the package in testing cannot be fixed via
> unstable. Additionally, blocked packages can have impact on other packages,
> which makes preparing for the release more difficult. Finally, it often
> exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that hamper
> the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if that
> version or a later version migrates, this bug will no longer affect testing. I
> have also tagged this bug to only affect sid and trixie, so it doesn't affect
> (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg00001.html
> [2] https://qa.debian.org/excuses.php?package=golang-github-hanwen-go-fuse
> 
> 
> 
> 
> 
> ----- End forwarded message -----
Best,
Nilesh

Attachment: signature.asc
Description: PGP signature

Reply via email to