Bug#1068755: closing 1068755

[Reinhard Tartler]

close 1068755 20.10.25+dfsg1-3
thanks

docker.io 20.10.25+dfsg1-3 comes with a backported patch that addresses this
FTBFS

Bug#1069310: FTBFS: tests failed

[Reinhard Tartler]

I spent about half an hour looking at this, and wanted to share my thoughts:

- the build / tests succeed on all architectures but mips64el
- the panic in question appears to come from here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
--
a map[int64]string is being set with the key "syscall.O_DIRECT" to the
value "DIRECT".
- that map is pre-initialized here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
- on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
set to the value 0x4000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
- on mipsel64, the value is set to 0x8000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
- this value conflicts with
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
so
we now get conflicting values for the same key. This explains the message
"panic: DIRECT (8000) overlaps with LARGEFILE (8000).

-- 
regards,
Reinhard

Bug#1068755: FTBFS: tests failed

[Reinhard Tartler]

please ignore the above, it was meant to be sent to #1069310 instead

On Mon, May 6, 2024 at 6:34 AM Reinhard Tartler  wrote:

> I spent about half an hour looking at this, and wanted to share my
> thoughts:
>
> - the build / tests succeed on all architectures but mips64el
> - the panic in question appears to come from here:
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
> -- a map[int64]string is being set with the key "syscall.O_DIRECT" to the
> value "DIRECT".
> - that map is pre-initialized here:
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
> - on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
> set to the value 0x4000, cf.
> https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
> - on mipsel64, the value is set to 0x8000, cf.
> https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
> - this value conflicts with
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
> so we now get conflicting values for the same key. This explains the
> message "panic: DIRECT (8000) overlaps with LARGEFILE (8000).
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1068755: FTBFS: tests failed

[Reinhard Tartler]

I spent about half an hour looking at this, and wanted to share my thoughts:

- the build / tests succeed on all architectures but mips64el
- the panic in question appears to come from here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
-- a map[int64]string is being set with the key "syscall.O_DIRECT" to the
value "DIRECT".
- that map is pre-initialized here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
- on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
set to the value 0x4000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
- on mipsel64, the value is set to 0x8000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
- this value conflicts with
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
so we now get conflicting values for the same key. This explains the
message "panic: DIRECT (8000) overlaps with LARGEFILE (8000).


-- 
regards,
Reinhard

Bug#1068755: docker.io: FTBFS: failing tests

[Reinhard Tartler]

Turns out that backporting
https://github.com/moby/moby/commit/97921915a801dd82b1f5a70e0a69353539c1e3ae.patch
seems to actually make the test pass

I'm not sure why that worked before, but I've pushed a backport of that
patch to
https://salsa.debian.org/go-team/packages/docker/-/commit/d33659365984dbb47b6aac2836727e507c1ce737
to let the salsa pipeline work on it.

I plan to make a team-upload tomorrow or later in the week. Please let me
know if you have concerns or thoughts on this.

Thanks
-rt

On Sun, May 5, 2024 at 11:20 AM Reinhard Tartler  wrote:

> I've been looking at this test failure, but remain puzzled.
>
> Basically, the source for this test is here:
> https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
> This test is testing code in
> https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
> which has only two external dependencies
> (golang-github-docker-distribution-dev) and
> (golang-github-sirupsen-logrus-dev).
>
> I've checked the build log of the previous build at
> https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
> and note that the same test passes in that build. This also uses the same
> package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
> golang-github-sirupsen-logrus-dev==1.9.0-1
>
> I also note that the old build was using golang 1.21, and the FTBFS was
> introduced after upgrading unstable to golang 1.22.
>
> Shengjing, I believe you handled the recent update of the golang toolchain
> from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
> resulted from using a newer golang compiler?
>
> I am considering just disabling this test, as the rest of the testsuite
> seem to pass, but I'm getting nervous that this wouldn't just paper over a
> real issue.
>
> Thanks,
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1068755: marked as pending in docker.io

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1068755 in docker.io reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/docker/-/commit/d33659365984dbb47b6aac2836727e507c1ce737


fix test TestMaxDownloadAttempts, closes: #1068755


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1068755

Bug#1068755: docker.io: FTBFS: failing tests

[Reinhard Tartler]

I've been looking at this test failure, but remain puzzled.

Basically, the source for this test is here:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
This test is testing code in
https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
which has only two external dependencies
(golang-github-docker-distribution-dev) and
(golang-github-sirupsen-logrus-dev).

I've checked the build log of the previous build at
https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
and note that the same test passes in that build. This also uses the same
package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
golang-github-sirupsen-logrus-dev==1.9.0-1

I also note that the old build was using golang 1.21, and the FTBFS was
introduced after upgrading unstable to golang 1.22.

Shengjing, I believe you handled the recent update of the golang toolchain
from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
resulted from using a newer golang compiler?

I am considering just disabling this test, as the rest of the testsuite
seem to pass, but I'm getting nervous that this wouldn't just paper over a
real issue.

Thanks,


-- 
regards,
Reinhard

Bug#1061032: Not reproducible

[Reinhard Tartler]

Control: severity -1 normal
Control: tags -1 unreproducible

Hey Lucas,

I've been unable to reproduce, please see my build log attached to this email.
Maybe some test is flaky?

I'm lowering severity as I am unconvinced that removing this package from
testing, along with all of its reverse dependencies is doing anyone a
service.

<#part type="text/plain" 
filename="/srv/scratch/packages/go-team/golang-github-go-kit-kit.autopkgtest.log/log"
 disposition=inline description="successful build log">
<#/part>

Bug#1058795: Docker.io breaks libvirt/qemu bridge network

[Reinhard Tartler]

Control: severity -1 minor
Control: tag -1 wontfix
Control: retitle -1 Docker.io breaks libvirt/qemu bridge network

Please review the package's postinst script to convince yourself that the 
Debian docker.io package does not ship any firewall rules:

https://salsa.debian.org/go-team/packages/docker/-/blob/master/debian/docker.io.postinst?ref_type=heads

However, the docker.io package does indeed manipulate iptables rules to provide 
container isolation. This is a well-known and documented feature at 
https://docs.docker.com/network/packet-filtering-firewalls/

The particular issue that you are experiencing is probably  described best at 
https://serverfault.com/questions/963759/docker-breaks-libvirt-bridge-network. 
That article also container an detailed description on why this is actually a 
feature and how to work around it.

On a personal note, consider installing the 'podman-docker' package instead of 
the 'docker.io' package, this might be sufficient depending on your use-case.

I'm leaving this bug open as I'm not the regular maintainer of the docker.io 
package. Probably this should be documented in the README.md file or similar.

Happy Holidays,
-rt

Bug#1054755: closing 1054755

[Reinhard Tartler]

close 1054755 4.7.1+ds4-4
thanks

Fixed in earlier upload

Bug#1054460: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1054460 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/6cd165bbd5b60cc9e5f63417ecd80f89b788fa34


avoid file conflicts with docker-compose (Closes: #1054460)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1054460

Bug#1050299: rust-webpki: RUSTSEC-2023-0052

[Reinhard Tartler]

Hi Salvatore,

thanks for filing this bug.

> Please see https://rustsec.org/advisories/RUSTSEC-2023-0052.html .

This page is giving a very general description of the problem:

>> When this crate is given a pathological certificate chain to validate, it
>> will spend CPU time exponential with the number of candidate certificates at
>> each step of path building.

>>Both TLS clients and TLS servers that accept client certificate are affected.


The page is also indicating that the issue was fixed in version 0.22.1, hence,
I've packaged that version and closed this bug. While this might not address
all concerns, (at least https://github.com/briansmith/webpki/issues/69
indicates that there is more work to do),
https://github.com/briansmith/webpki/issues/69#issuecomment-1699894848
indicates:


>> There is a webpki 0.22.1 release that implements the signature count 
>> mitigation.


Additional, you are asking:

> Should rust-webpki be removed from Debian testing and unstable?

```
siretart@coccia:~$ dak rm -nR  rust-webpki
Will remove the following packages from unstable:

librust-webpki-dev |   0.22.0-2 | amd64, arm64, armel, armhf, i386
rust-webpki |   0.22.0-2 | source

Maintainer: Debian Rust Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.
```

I think this indicates that it can indeed be safely removed from Debian? I'm
CC'ing developers that have made uploads to this packages in the past for
additiponal opinions as I suspect the issue is more subtle than that.

-rt

Bug#1042194: netavark: FTBFS: unsatisfiable build-dependencies: librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~), librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~)

[Reinhard Tartler]

Thank you so much for these patches.

May I ask you to NMU this and and potentially aardvark-dns as necessary? -- I'm 
about to start traveling, and will have very limited internet access. No need 
to wait for NMU delays or things. Your diff looks great to me!

best,
-rt

On 8/10/23 8:37 PM, Peter Green wrote:

tags 1042194 +patch
thanks


During a rebuild of all packages in sid, your package failed to build
on amd64.


The attached patch makes netavark build again (note: some of the packages
it depends on have only just been accepted, so it may be a little time
before binaries are available in sid).

Bug#1038870: marked as pending in golang-github-grpc-ecosystem-grpc-gateway

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1038870 in golang-github-grpc-ecosystem-grpc-gateway reported by you has 
been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-grpc-ecosystem-grpc-gateway/-/commit/78518f0f189b37cadfda6e047c1873ad34bbc00e


Avoid building protoc-gen-swagger, Closes: #1038870


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1038870

Bug#1041040: Fwd: Bug#1041040: aspectc++ autopkg tests fail with GCC 13

[Reinhard Tartler]

On 7/23/23 9:13 AM, Reinhard Tartler wrote:


Turns out, the fix only works on amd64/i386, but not for instance on Arm, 
Matthias, our GCC maintainer has filed 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041040 for this.

I looked over the patch and couldn't find anything architecture specific. Can 
you make any rhyme or reason for why it might fail on arm64?

Here are some more test logs:
https://ci.debian.net/packages/a/aspectc++/unstable/arm64/


This issue also occurs during a regular package build, not only during 
autopkgtest. I could reproduce it on the amdhal.debian.org in a sid chroot and 
got this:

Weaving aspects into PreFileIncluder.cc...
  
Weaving aspects into PreprocessorParser.cc...

Weaving aspects into UnitManager.cc...
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreFileIncluder.cc:19:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/TokenStream.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h:27:
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h_0_virt:66:9:
 error: __float128 is not supported on this target
typedef __float128 _Float128;
^
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PrePrintVisitor.cc:19:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTree.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h:24:
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h_0_virt:66:9:
 error: __float128 is not supported on this target
typedef __float128 _Float128;
^
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreprocessorParser.cc:19:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Token.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h:25:
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h_0_virt:66:9:
 error: __float128 is not supported on this target
typedef __float128 _Float128;
^
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/UnitManager.cc:19:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Unit.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/List.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/ListElement.h:27:
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/ListElement.h_0_virt:66:9:
 error: __float128 is not supported on this target
typedef __float128 _Float128;
^

Bug#1028810: aspectc++: FTBFS: ld: cannot find -lPolly: No such file or directory

[Reinhard Tartler]

Control: reassign -1 llvm-14
Control: affects -1 aspectc++

Hi Lucas,

thanks for filing this report.

My understanding of this issue is that a recent change in llvm 14 leads to the 
list of libraries listed by `llvm-config-14 --libs` to be incomplete. I think 
that this build would succeed if it included -lPolly.

You can see how aspectc++ invokes llvm-config here: 
https://salsa.debian.org/debian/aspectc/-/blob/791f390f845b2fafd19ff0c648618e8e14cee726/AspectC++/Makefile#L79

Dear LLVM maintainers, does this make sense to you?

-rt

On 1/14/23 7:30 AM, Lucas Nussbaum wrote:

Source: aspectc++
Version: 1:2.3+git20221129-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230113 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

make[2]: Entering directory '/<>/AspectC++/ACModel'
---
Making ACModel library for TARGET=linux-release
Compiler = g++ -DNDEBUG  -std=gnu++11 -I../../Puma/extern `xml2-config 
--cflags`  -O2 -g -Wall -pipe -Wno-deprecated-declarations -Wall -pipe 
-Wno-deprecated-declarations
---
Making dependency file ObjFiles/linux-release/Elements.o.
---
Making dependency file ObjFiles/linux-release/MatchExpr.o.
Making dependency file DepFiles/linux-release/ACConfig.d.
Making dependency file ObjFiles/linux-release/MatchName.o.
Making dependency file DepFiles/linux-release/ACProject.d.
Making AspectC++ for TARGET=linux-release
Making dependency file DepFiles/linux-release/AdviceInfo.d.
Making dependency file ObjFiles/linux-release/MatchTemplateArg.o.
   Compiler = g++ -DNDEBUG  -std=gnu++11 -I../Puma/extern -I../Puma/include 
-I/usr/include/libxml2  -I/usr/lib/llvm-14/include -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-DFRONTEND_CLANG -O2 -g -Wall -pipe -Wno-deprecated-declarations  -fno-rtti 
-Wno-strict-aliasing  -std=gnu++14
   Linker   = g++ -O2 -g -Wall -pipe -Wno-deprecated-declarations  -fno-rtti 
-Wno-strict-aliasing  -std=gnu++14   -L../Puma/lib/linux-release 
-lMiniPuma  -lxml2  -lclangRewriteFrontend -lclangRewrite -lclangFrontend 
-lclangSerialization -lclangDriver -lclangParse -lclangSema -lclangAnalysis 
-lclangEdit -lclangAST -lclangLex -lclangBasic -lLLVMAsmParser -lLLVMMCParser 
-lLLVMBitReader -lLLVMTransformUtils -lLLVMCore -lLLVMMC -lLLVMOption -lLLVMSupport 
-Wl,--as-needed -latomic -Wl,--no-as-needed -Xlinker 
--wrap=_ZN5clang4Sema19canSkipFunctionBodyEPNS_4DeclE -Xlinker 
--wrap=_ZN5clang4Sema21ProcessStmtAttributesEPNS_4StmtERKNS_25ParsedAttributesWithRangeERN4llvm15SmallVectorImplIPKNS_4AttrEEE
 -L/usr/lib/llvm-14/lib  -lLLVMWindowsManifest -lLLVMXRay -lLLVMLibDriver 
-lLLVMDlltoolDriver -lLLVMCoverage -lLLVMLineEditor -lLLVMM68kDisassembler 
-lLLVMM68kAsmParser -lLLVMM68kCodeGen -lLLVMM68kDesc -lLLVMM68kInfo 
-lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo 
-lLLVMX86TargetMCA -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen 
-lLLVMX86Desc -lLLVMX86Info -lLLVMWebAssemblyDisassembler -lLLVMWebAssemblyAsmParser 
-lLLVMWebAssemblyCodeGen -lLLVMWebAssemblyDesc -lLLVMWebAssemblyUtils 
-lLLVMWebAssemblyInfo -lLLVMVEDisassembler -lLLVMVEAsmParser -lLLVMVECodeGen 
-lLLVMVEDesc -lLLVMVEInfo -lLLVMSystemZDisassembler -lLLVMSystemZAsmParser 
-lLLVMSystemZCodeGen -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSparcDisassembler 
-lLLVMSparcAsmParser -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo 
-lLLVMRISCVDisassembler -lLLVMRISCVAsmParser -lLLVMRISCVCodeGen -lLLVMRISCVDesc 
-lLLVMRISCVInfo -lLLVMPowerPCDisassembler -lLLVMPowerPCAsmParser -lLLVMPowerPCCodeGen 
-lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc 
-lLLVMNVPTXInfo -lLLVMMSP430Disassembler -lLLVMMSP430AsmParser -lLLVMMSP430CodeGen 
-lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMipsDisassembler -lLLVMMipsAsmParser 
-lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMLanaiDisassembler 
-lLLVMLanaiCodeGen -lLLVMLanaiAsmParser -lLLVMLanaiDesc -lLLVMLanaiInfo 
-lLLVMHexagonDisassembler -lLLVMHexagonCodeGen -lLLVMHexagonAsmParser 
-lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMBPFDisassembler -lLLVMBPFAsmParser 
-lLLVMBPFCodeGen -lLLVMBPFDesc -lLLVMBPFInfo -lLLVMAVRDisassembler -lLLVMAVRAsmParser 
-lLLVMAVRCodeGen -lLLVMAVRDesc -lLLVMAVRInfo -lLLVMARMDisassembler -lLLVMARMAsmParser 
-lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMUtils -lLLVMARMInfo -lLLVMAMDGPUTargetMCA 
-lLLVMAMDGPUDisassembler -lLLVMAMDGPUAsmParser -lLLVMAMDGPUCodeGen -lLLVMAMDGPUDesc 
-lLLVMAMDGPUUtils -lLLVMAMDGPUInfo -lLLVMAArch64Disassembler -lLLVMAArch64AsmParser 
-lLLVMAArch64CodeGen -lLLVMAArch64Desc -lLLVMAArch64Utils -lLLVMAArch64Info 
-lLLVMPerfJITEvents -lLLVMOrcJIT -lLLVMMCJIT -lLLVMJITLink -lLLVMInterpreter 
-lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMOrcTargetProcess -lLLVMOrcShared 
-lLLVMDWP -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMDebugInfoGSYM -lLLVMOption 
-lLLVMObjectYAML -lLLVMMCA -lLLVMMCDisassembler -lLLVMLTO 

Bug#1026588: Fix pending in the NEW queue

[Reinhard Tartler]

Control: tag 1026588 pending
Control: block 1026598 by 1026588

I really should have mentioned this bug in debian/changelog before
uploading. It is currently pending at
https://ftp-master.debian.org/new/rust-trust-dns-server_0.22.0-1.html

Dear ftp-master, happy holidays!

Any chance you could fast-track this package so that I can fix 2 RC bugs?
I'm concerned that if not fixed in time, aardvark-dns would be removed from
testing, which would break podman and friends.

Thanks in advance!

-- 
regards,
Reinhard

Bug#1027116: marked as pending in golang-github-containers-storage

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1027116 in golang-github-containers-storage reported by you has been fixed 
in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-containers-storage/-/commit/a4b6809d1b9f4a3854f5f852d355ca9a17c93404


Fix FTBFS golang-containerd-btrfs 1.0, closes: #1027116, #1027116

Field members were renamed upstream in
https://github.com/kdave/btrfs-progs/commit/03451430de7cd2fad18b0f01745545758bc975a5


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1027116

Bug#1026598: blocked by NEW queue

[Reinhard Tartler]

In order to fix this issue, I'm waiting for
https://ftp-master.debian.org/new/rust-trust-dns-server_0.22.0-1.html to
make it out of (binary) NEW.



-- 
regards,
Reinhard

Bug#1024032: rust-criterion: FTBFS: needs to be compiled against librust-cast (>> 0.3)

[Reinhard Tartler]

Package: librust-criterion+async-futures-dev
Severity: serious
X-Debbugs-Cc: none, Reinhard Tartler 

The rust-cast crate has been updated from version 0.2 to 0.3 on 2022/11/11.

Can you please build against that new version of rust-cast?

-rt


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1019206: librust-criterion+async-std-dev: Package is uninstallable, rust-async-std missing in debian

[Reinhard Tartler]

Package: librust-criterion+async-std-dev
Severity: serious
Justification: packages must be installable, prevents other packages from 
reaching testing
X-Debbugs-Cc: d...@jones.dk, debian-r...@lists.debian.org

The package librust-criterion+async-std-dev is currently uninstallable in
unstable and testing, which prevents it and other dependent packages (like
rust-rustls) from reaching testing. Currently, this even threats the removal
unrelated packages from testing, cf. #1018225

I see two options out here:

 a) disable the 'async-std' feature
 b) package 'async-std'

Note that while working on the rust-rtnetlink package, a similar issue popped 
up, and I've
opted for option a). Should 'async-std' become available, I'd be happy to 
change 'rust-rtnetlink'
to enable the 'async-std' feature.

Best,
-rt


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages librust-criterion+async-std-dev depends on:
pn  librust-async-std-1+default-dev  
pn  librust-criterion-dev

librust-criterion+async-std-dev recommends no packages.

librust-criterion+async-std-dev suggests no packages.

Bug#1011869: marked as pending in golang-github-containers-buildah

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1011869 in golang-github-containers-buildah reported by you has been fixed 
in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/-/commit/d6277761885a440c03b88892c18d4b15c908fa72


Fix FTBFS, closes: #1011869

backport upstream patch 08613ccd6b4f9889f3fadb4326ac6dc1d05b9d0f to make
the current version of buildah work with the newer imagebuilder


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1011869

Bug#1011875: golang-github-opencontainers-runtime-tools: FTBFS unreproducible

[Reinhard Tartler]

My hunch might have been correct, the fresh upload did build successfully
on buildds. yay!

On Sun, Jun 5, 2022 at 7:12 AM Reinhard Tartler  wrote:

> Just a hunch, is it possible that your build environment did not have the
> package 'ca-certificates' present whereas mine does?
>
> I wonder whether I need to add 'ca-certificates' to "Build-Depends". What
> do you think?
>
> On Sun, Jun 5, 2022 at 7:10 AM Reinhard Tartler 
> wrote:
>
>> Please find the buildlog of my attempt attached to this email
>>
>> As far as I can tell, the tests are executing in the same way as in your
>> logs, but I may be missing something.
>>
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1011875: marked as pending in golang-github-opencontainers-runtime-tools

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1011875 in golang-github-opencontainers-runtime-tools reported by you has 
been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-opencontainers-runtime-tools/-/commit/2a5b1ca2b214bf7ce354492592ebd73788607203


Build-depend on ca-certificates, Closes: #1011875


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1011875

Bug#1011875: golang-github-opencontainers-runtime-tools: FTBFS unreproducible

[Reinhard Tartler]

Just a hunch, is it possible that your build environment did not have the
package 'ca-certificates' present whereas mine does?

I wonder whether I need to add 'ca-certificates' to "Build-Depends". What
do you think?

On Sun, Jun 5, 2022 at 7:10 AM Reinhard Tartler  wrote:

> Please find the buildlog of my attempt attached to this email
>
> As far as I can tell, the tests are executing in the same way as in your
> logs, but I may be missing something.
>


-- 
regards,
Reinhard

Bug#1011875: golang-github-opencontainers-runtime-tools: FTBFS unreproducible

[Reinhard Tartler]

Please find the buildlog of my attempt attached to this email

As far as I can tell, the tests are executing in the same way as in your
logs, but I may be missing something.


golang-github-opencontainers-runtime-tools_0.9.0+git20220423.g0105384-1_amd64-2022-06-05T02:02:05Z.build
Description: Binary data

Bug#1011875: golang-github-opencontainers-runtime-tools: FTBFS unreproducible

[Reinhard Tartler]

Control: tags -1 = moreinfo unreproducible
Hi Lucas,

Thank you for reaching out. I've been looking into this report and am a
bit confused. I'm trying to reproduce it on my laptop, but it builds just
fine for me. Can you please help me understand why it would fail on your
end?

-- 
regards,
Reinhard

Bug#1010000: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #101 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/83c9b9ab138c751220f2784c510f126bf280324e


debian/control: rebuild against opencontainers/runtime-tools >> 
0.9.0+git20220423

Closes: #101


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/101

Bug#1009374: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1009374 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/d2b41302320b9db37b32c387b01b52e3d9a83f33


Stop installing systemd socket units under /usr/lib

debian/rules already installs the system support files in
override_dh_auto_install using the upstream build system (make
install.systemd), there is no need to also keep this ones here (they get
installed automatically by debhelper, but get under /usr/lib which is
Wrong™ for now).

Closes: #1009374


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1009374

Bug#1005147: marked as pending in golang-github-sylabs-sif

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1005147 in golang-github-sylabs-sif reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-sylabs-sif/-/commit/bfaa90e89589cd245a6042f2b5aebb1dc97552f6


don't install ./usr/bin/test, closes: #1005147


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1005147

Bug#1008396: marked as pending in consul

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1008396 in consul reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/consul/-/commit/0ff5f561e8e4522154ba693fbf98bb4b5c4874a5


debian/rules: disable DH_GOLANG_GO_GENERATE, closes: #1008396

This avoids regenerating "mockery" managed fakes, which breaks as this package
has become rather old in debian whereas the depdendencies move ahead.

Also various cleanups to debian/rules to improve readability and
exclude some additional tests that broke for me


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1008396

Bug#889714: marked as pending in etcd

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #889714 in etcd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/etcd/-/commit/093417b94965a8ed009887068744a2a6455298f6


Avoid postinst crashes, Closes: #889714


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/889714

Bug#994451: marked as pending in golang-github-opencontainers-specs

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #994451 in golang-github-opencontainers-specs reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-opencontainers-specs/-/commit/b10b754211b3d231f701295074f75e5efdbc6b60


seccomp: allow to override default errno return code

Backport upstream patch f7ef278d1bbaa6f97b8ef511fad478a31e953290

LP: #1943049
Closes: #994451


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/994451

Bug#1003663: marked as done (golang-github-containers-image: FTBFS: tests fail with 'key has been revoked')

[Reinhard Tartler]

>
>
> Hi Andreas, thank you for your report,
>
> I've tried rebuilding the package on my laptop in a clean sid chroot,
> and for some reason, it works just fine.
>
> Can you please have a look at my build log and help me understand why
> the build is failing for you but not for me?
>
>
I looked a bit more at the code, and it appears to me that the code that is
failing is accessing the kernel "session" keyring using the kernel API here:

https://man7.org/linux/man-pages/man3/keyctl_get_keyring_ID.3.html

It seems to me that on your system, someone or something has revoked the
keys using "keyctl revoke" or some equivalent system call. As said, this
does not appear to be happening on my system, and it also doesn't appear to
be happening on the debian buildd machines.

Have a great weekend,
-rt


-- 
regards,
Reinhard

Bug#1000318: docker.io: FTBFS on mipsen: FAIL: profiles/seccomp TestUnmarshalDefaultProfile

[Reinhard Tartler]

On 11/21/21 8:14 AM, Reinhard Tartler wrote:
> Source: docker.io
> Version: 20.10.5+dfsg1-1
> Severity: serious
> Justification: FTBFS - prevents depending packages from migrating
> 
> the docker.io package FTBFS on mipsen in the same way:
> 
> - 
> https://buildd.debian.org/status/fetch.php?pkg=docker.io=mips64el=20.10.10%2Bdfsg1-1=1636015943=0
> - 
> https://buildd.debian.org/status/fetch.php?pkg=docker.io=mipsel=20.10.10%2Bdfsg1-1=1636015191=0
> 
> === Failed
> === FAIL: profiles/seccomp TestUnmarshalDefaultProfile (0.15s)
> seccomp_test.go:68: assertion failed: 
> --- expected.Syscalls
> +++ profile.Syscalls
>   []*seccomp.Syscall{
>   ... // 14 identical elements
>   &{Names: {"clone"}, Action: "SCMP_ACT_ALLOW", Args: {&{Value: 
> 2114060288, Op: "SCMP_CMP_MASKED_EQ"}}, Excludes: {Caps: {"CAP_SYS_ADMIN"}, 
> Arches: {"s390", "s390x"}}},
>   &{Names: {"clone"}, Action: "SCMP_ACT_ALLOW", Args: {&{Index: 
> 1, Value: 2114060288, Op: "SCMP_CMP_MASKED_EQ"}}, Comment: "s390 parameter 
> ordering for clone is different", ...},
>   &{
>   Name: "",
>   Names:{"clone3"},
>   Action:   "SCMP_ACT_ERRNO",
> - ErrnoRet: &89,
> + ErrnoRet: &38,
>   Args: {},
>   Comment:  "",
>   ... // 2 identical fields
>   },
>   &{Names: {"reboot"}, Action: "SCMP_ACT_ALLOW", Args: {}, 
> Includes: {Caps: {"CAP_SYS_BOOT"}}, ...},
>   &{Names: {"chroot"}, Action: "SCMP_ACT_ALLOW", Args: {}, 
> Includes: {Caps: {"CAP_SYS_CHROOT"}}, ...},
>   ... // 8 identical elements
>   }
> 


I've been looking at the upstream source code changes: 
https://github.com/moby/moby/commits/master/profiles/seccomp
but it's not obvious (at least not to me) which might be related. I'm aware 
that there have been "recent" glibc changes
wrt to the clone3 syscall that required adaptation in docker and podman, but 
I'm a bit surprised to see this issue on mipsen only.

-rt

Bug#1000318: docker.io: FTBFS on mipsen: FAIL: profiles/seccomp TestUnmarshalDefaultProfile

[Reinhard Tartler]

Source: docker.io
Version: 20.10.5+dfsg1-1
Severity: serious
Justification: FTBFS - prevents depending packages from migrating

the docker.io package FTBFS on mipsen in the same way:

- 
https://buildd.debian.org/status/fetch.php?pkg=docker.io=mips64el=20.10.10%2Bdfsg1-1=1636015943=0
- 
https://buildd.debian.org/status/fetch.php?pkg=docker.io=mipsel=20.10.10%2Bdfsg1-1=1636015191=0

=== Failed
=== FAIL: profiles/seccomp TestUnmarshalDefaultProfile (0.15s)
seccomp_test.go:68: assertion failed: 
--- expected.Syscalls
+++ profile.Syscalls
  []*seccomp.Syscall{
... // 14 identical elements
&{Names: {"clone"}, Action: "SCMP_ACT_ALLOW", Args: {&{Value: 
2114060288, Op: "SCMP_CMP_MASKED_EQ"}}, Excludes: {Caps: {"CAP_SYS_ADMIN"}, 
Arches: {"s390", "s390x"}}},
&{Names: {"clone"}, Action: "SCMP_ACT_ALLOW", Args: {&{Index: 
1, Value: 2114060288, Op: "SCMP_CMP_MASKED_EQ"}}, Comment: "s390 parameter 
ordering for clone is different", ...},
&{
Name: "",
Names:{"clone3"},
Action:   "SCMP_ACT_ERRNO",
-   ErrnoRet: &89,
+   ErrnoRet: &38,
Args: {},
Comment:  "",
... // 2 identical fields
},
&{Names: {"reboot"}, Action: "SCMP_ACT_ALLOW", Args: {}, 
Includes: {Caps: {"CAP_SYS_BOOT"}}, ...},
&{Names: {"chroot"}, Action: "SCMP_ACT_ALLOW", Args: {}, 
Includes: {Caps: {"CAP_SYS_CHROOT"}}, ...},
... // 8 identical elements
  }




-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue

[Reinhard Tartler]

Control: tag -1 patch

On Wed, Nov 10, 2021 at 7:55 AM Shengjing Zhu  wrote:

>
> > > Cloud you backport following commit?
> > >
> > >
> https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b
> > >
>
> This patch updates libocispec/Makefile.am, which is needed to be
> backported.
>
> This patch looks like doing nothing to C part, because the generated source
> is removed in upstream repo. Theses files(which are added in Makefile.am)
> can
> be generated by `make -C libocispec generate`. So please also uncomment
> this
> line in debian/rules.
>
>
>
D'oh, my bad, I've overlooked the Makefile.am parts. So the generator *is*
already
invoked, but the automake system doesn't pick up all files, leading to the
linker failures.

I've implemented your suggestion in
https://salsa.debian.org/debian/crun/-/merge_requests/1/diffs and can
confirm that the package now builds fine.

Dmitry, please let me know if you are comfortable with me NMU'ing the
package with the patch from salsa.


-- 
regards,
Reinhard

Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue

[Reinhard Tartler]

Looking more into it, here are more observations:

- crun upstream has a git submodule on 'libocispec' (the repo you asked me
to backport). The release tarballs contain a copy of the submodule contents
at the time of the release
- the 'libocispec' submodule contains two additional submodules
'image-spec' and 'runtime-spec'
- the debian package replaces only the two "inner" submodules 'image-spec'
and 'runtime-spec' with sources found in Debian packages, but not the outer
'libocispec', which isn't found in debian
- the Debian packages of 'image-spec' and 'runtime-spec' have been updated
last August, and contain specification for the "zos" platform
- the 'libocispec' repository contains a generator that reads those
specifications and generates code. It seems to me that this is the code
generator that lacks some zos related definition and thus causes the linker
failure
- the 'libocispec' repository has last synced with 'image-spec' and
'runtime-spec' last January, and thus is missing the zos related changes

This is very messy. I can totally understand upstream's stance to just
vendor the specs so that the generator is only used with versions of the
specifications that have actually been tested. I don't think it is a good
use of Debian's developers' time to play this game of catching up.


On Wed, Nov 10, 2021 at 7:27 AM Reinhard Tartler  wrote:

> That's not sufficient.
>
> the commit you point out does two things:
>
>  - update the submodules for 'image-spec' and 'runtime-spec' (which the
> Debian package currently overrides with the distro-provided copies)
>  -  zos-related changes to the rust bindings (which the Debian package
> doesn't have at all at this point)
>
> The missing definitions that the linker stumbles over are generated from
> the json files. But I haven't found where that generation exactly happens
> and what change is missing to it.
>
> Thanks for your swift reply!
>
> On Tue, Nov 9, 2021 at 8:47 PM Shengjing Zhu  wrote:
>
>> Cloud you backport following commit?
>>
>> https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b
>>
>>
>> (Sent on my mobile phone)
>>
>> Reinhard Tartler  于 2021年11月10日周三 07:05写道：
>>
>>> I took a look at the issue and here are my thoughts:
>>>
>>> - the build error is a failure to link some test binaries. excluding
>>> them from the build might be possible with some patching.
>>> - I've upgraded the package to the latest upstream 1.3, and was seeing
>>> exactly the same build failure
>>> - the build failure goes away when not stripping the bundled copies of
>>> runtime-spec and image-spec
>>> - Dimtry had a conversation about this with upstream at
>>> https://github.com/containers/crun/issues/240. It seems to be that
>>> upstream strongly recommends to just use the vendored copies of image-spc
>>> and runtime-spec
>>> -  I've pushed my work to
>>> https://salsa.debian.org/debian/crun/-/merge_requests/1
>>> - I believe the issue was introduced by Shengjing's update in
>>> https://tracker.debian.org/news/1249177/accepted-golang-github-opencontainers-specs-10266g20a2d97-1-source-into-unstable/
>>> -- but that was already months ago. So that may not be true
>>>
>>> With this, I'd like to suggest to move ahead with my merge request and
>>> don't strip image-spec and runtime-spec from the package.
>>>
>>> Any thoughts?
>>>
>>> --
>>> regards,
>>> Reinhard
>>>
>>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue

[Reinhard Tartler]

That's not sufficient.

the commit you point out does two things:

 - update the submodules for 'image-spec' and 'runtime-spec' (which the
Debian package currently overrides with the distro-provided copies)
 -  zos-related changes to the rust bindings (which the Debian package
doesn't have at all at this point)

The missing definitions that the linker stumbles over are generated from
the json files. But I haven't found where that generation exactly happens
and what change is missing to it.

Thanks for your swift reply!

On Tue, Nov 9, 2021 at 8:47 PM Shengjing Zhu  wrote:

> Cloud you backport following commit?
>
> https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b
>
>
> (Sent on my mobile phone)
>
> Reinhard Tartler  于 2021年11月10日周三 07:05写道：
>
>> I took a look at the issue and here are my thoughts:
>>
>> - the build error is a failure to link some test binaries. excluding them
>> from the build might be possible with some patching.
>> - I've upgraded the package to the latest upstream 1.3, and was seeing
>> exactly the same build failure
>> - the build failure goes away when not stripping the bundled copies of
>> runtime-spec and image-spec
>> - Dimtry had a conversation about this with upstream at
>> https://github.com/containers/crun/issues/240. It seems to be that
>> upstream strongly recommends to just use the vendored copies of image-spc
>> and runtime-spec
>> -  I've pushed my work to
>> https://salsa.debian.org/debian/crun/-/merge_requests/1
>> - I believe the issue was introduced by Shengjing's update in
>> https://tracker.debian.org/news/1249177/accepted-golang-github-opencontainers-specs-10266g20a2d97-1-source-into-unstable/
>> -- but that was already months ago. So that may not be true
>>
>> With this, I'd like to suggest to move ahead with my merge request and
>> don't strip image-spec and runtime-spec from the package.
>>
>> Any thoughts?
>>
>> --
>> regards,
>> Reinhard
>>
>

-- 
regards,
Reinhard

Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue

[Reinhard Tartler]

I took a look at the issue and here are my thoughts:

- the build error is a failure to link some test binaries. excluding them
from the build might be possible with some patching.
- I've upgraded the package to the latest upstream 1.3, and was seeing
exactly the same build failure
- the build failure goes away when not stripping the bundled copies of
runtime-spec and image-spec
- Dimtry had a conversation about this with upstream at
https://github.com/containers/crun/issues/240. It seems to be that upstream
strongly recommends to just use the vendored copies of image-spc and
runtime-spec
-  I've pushed my work to
https://salsa.debian.org/debian/crun/-/merge_requests/1
- I believe the issue was introduced by Shengjing's update in
https://tracker.debian.org/news/1249177/accepted-golang-github-opencontainers-specs-10266g20a2d97-1-source-into-unstable/
-- but that was already months ago. So that may not be true

With this, I'd like to suggest to move ahead with my merge request and
don't strip image-spec and runtime-spec from the package.

Any thoughts?

-- 
regards,
Reinhard

Bug#997133: More information in the ubuntu bugtracker

[Reinhard Tartler]

the ubuntu tracker claims this is golang 1.16 related:
https://bugs.launchpad.net/debian/+source/consul/+bug/1940152

not sure how to proceed here, though...

-- 
regards,
Reinhard

Bug#997133: Relevant part of the consul log

[Reinhard Tartler]

Here is the actual relevant part of the build log:

=== RUN   TestDynamicTLSConfig
tls_test.go:263:
Error Trace: tls_test.go:263
tls_test.go:339
Error:   Not equal:
expected:
{byName:map[string][]int{"0\x141\x120\x10\x06\x03U\x04\x03\x13\tTest
CA 8":[]int{0}},
lazyCerts:[]x509.lazyCert{x509.lazyCert{rawSubject:[]uint8{0x30, 0x14,
0x31, 0x12, 0x30, 0x10, 0x6, 0x3, 0x55, 0x4, 0x3, 0x13, 0x9, 0x54, 0x65,
0x73, 0x74, 0x20, 0x43, 0x41, 0x20, 0x38}, getCert:(func()
(*x509.Certificate, error))(0x620fe0)}},
haveSum:map[x509.sum224]bool{x509.sum224{0xe4, 0x16, 0x91, 0x60, 0xba,
0x36, 0xe7, 0x67, 0x2, 0x8c, 0x57, 0x41, 0x7c, 0x7, 0x17, 0x39, 0x39, 0xd6,
0x4d, 0x32, 0x89, 0x2a, 0xf3, 0x85, 0xa3, 0x67, 0xbc, 0xbb}:true}}
actual  :
{byName:map[string][]int{"0\x141\x120\x10\x06\x03U\x04\x03\x13\tTest
CA 8":[]int{0}},
lazyCerts:[]x509.lazyCert{x509.lazyCert{rawSubject:[]uint8{0x30, 0x14,
0x31, 0x12, 0x30, 0x10, 0x6, 0x3, 0x55, 0x4, 0x3, 0x13, 0x9, 0x54, 0x65,
0x73, 0x74, 0x20, 0x43, 0x41, 0x20, 0x38}, getCert:(func()
(*x509.Certificate, error))(0x620fe0)}},
haveSum:map[x509.sum224]bool{x509.sum224{0xe4, 0x16, 0x91, 0x60, 0xba,
0x36, 0xe7, 0x67, 0x2, 0x8c, 0x57, 0x41, 0x7c, 0x7, 0x17, 0x39, 0x39, 0xd6,
0x4d, 0x32, 0x89, 0x2a, 0xf3, 0x85, 0xa3, 0x67, 0xbc, 0xbb}:true}}

Diff:
Test:   TestDynamicTLSConfig
--- FAIL: TestDynamicTLSConfig (0.00s)


I could confirm the FTBFS with a quick test rebuild on my laptop.

-- 
regards,
Reinhard

Bug#994451: golang-github-containers-common: secomp.json does not include newer syscall used by stable kernel/glibc on arm

[Reinhard Tartler]

User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
Severity: normal
stop

sorry for the abrupt ending of the previous mail.

I'm attaching the debdiffs for the three uploads to this email.

I'm happy to do the 3 uploads at any time. Please let me know what you
think.



On Mon, Sep 27, 2021 at 12:08 PM Reinhard Tartler 
wrote:

>
> On Thu, Sep 16, 2021 at 4:18 AM Bastien Roucariès <
> roucaries.bast...@gmail.com> wrote:
>
>> Package: golang-github-containers-common
>> Version: 0.33.4+ds1-1
>> Severity: critical
>> Tags: upstream
>> Forwarded:
>> https://github.com/containers/common/commit/42d1db16bfc0dbaee5781d230dc2bcbaa0849c6e
>> Control: fixed -1 0.42.1+ds1-1
>>
>> Dear Maintainer,
>>
>> golang-github-containers-common in stable does not include recent syscall
>> used
>> by stable kernel/glibc breaking in my case simple container that do
>> unattended-
>> upgrade on arm
>> particularly syscall=436 that is timer_settime64
>>
>> I believe this should be fixed in a point release.
>>
>
> I agree. I realized that these syscall changes also affect amd64. I was
> able to reproduce the issue
> by running a distribution that ships with glibc 2.34, such as ubuntu
> impish. The testcase would be:
>
> $ podman run --rm -it ubuntu:impish sh -c 'apt update -qq && apt -y
> full-upgrade && apt install -y libc6 jq'
>
> The symptom is described in more detail at
> https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1943049
>
> The problem here is that the issue is not simply dealt with updating the
> secomp.json file, but also some code changes are required
> that allow setting the default return value for some syscalls. This means
> that in order to fix this issue in stable, 3 uploads are needed:
>
> - golang-github-opencontainers-specs
> - golang-github-containers-common
> - libpod
>
> I'm cloning this bug appropriately so that these uploads can be tracked
> separately.
> For now,I've backported and verified the changes. For your convenience,
> I've uploaded the packages I got so far to
> https://people.debian.org/~siretart/bug.994451/
>
>
>> BTW I strongly believe that  seccomp.json is a config file and should be
>> shipped in /etc and 988443  should also be shipped in stable.
>>
>
> I could get convinced if the issue was fixable by just upading the
> seccomp.json policy file.
> Sadly, that's not the case.
>
> Stable Release team, I think this bug should be cloned with those
> instructions:
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard


golang-github-opencontainers-specs.debdiff
Description: Binary data


golang-github-opencontainers-specs.debdiff
Description: Binary data


podman.debdiff
Description: Binary data

Bug#994451: golang-github-containers-common: secomp.json does not include newer syscall used by stable kernel/glibc on arm

[Reinhard Tartler]

On Thu, Sep 16, 2021 at 4:18 AM Bastien Roucariès <
roucaries.bast...@gmail.com> wrote:

> Package: golang-github-containers-common
> Version: 0.33.4+ds1-1
> Severity: critical
> Tags: upstream
> Forwarded:
> https://github.com/containers/common/commit/42d1db16bfc0dbaee5781d230dc2bcbaa0849c6e
> Control: fixed -1 0.42.1+ds1-1
>
> Dear Maintainer,
>
> golang-github-containers-common in stable does not include recent syscall
> used
> by stable kernel/glibc breaking in my case simple container that do
> unattended-
> upgrade on arm
> particularly syscall=436 that is timer_settime64
>
> I believe this should be fixed in a point release.
>

I agree. I realized that these syscall changes also affect amd64. I was
able to reproduce the issue
by running a distribution that ships with glibc 2.34, such as ubuntu
impish. The testcase would be:

$ podman run --rm -it ubuntu:impish sh -c 'apt update -qq && apt -y
full-upgrade && apt install -y libc6 jq'

The symptom is described in more detail at
https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1943049

The problem here is that the issue is not simply dealt with updating the
secomp.json file, but also some code changes are required
that allow setting the default return value for some syscalls. This means
that in order to fix this issue in stable, 3 uploads are needed:

- golang-github-opencontainers-specs
- golang-github-containers-common
- libpod

I'm cloning this bug appropriately so that these uploads can be tracked
separately.
For now,I've backported and verified the changes. For your convenience,
I've uploaded the packages I got so far to
https://people.debian.org/~siretart/bug.994451/


> BTW I strongly believe that  seccomp.json is a config file and should be
> shipped in /etc and 988443  should also be shipped in stable.
>

I could get convinced if the issue was fixable by just upading the
seccomp.json policy file.
Sadly, that's not the case.

Stable Release team, I think this bug should be cloned with those
instructions:


-- 
regards,
Reinhard

Bug#987207: podman not running out-of-the-box as root

[Reinhard Tartler]

Control: tag -1 pending
Control: severity -1 important
Control: retitle -1 Missing dependency on "iptables"

On Wed, Apr 21, 2021 at 6:07 AM Laurent Bigonville  wrote:

> So the problem here is, again, linked to the fact that I'm using a test
> SELinux policy that doesn't contain all the needed contexts, so yeah it's a
> mix of configuration issue and the fact that podman is not ignoring these
> errors if SELinux is in permissive. I'll ping upstream again.
>
Thanks, let's track this in #984879

> So the remaining problem here is iptables command not being installed (and
> the seccomp.json file missing to a lower extend)
>
Agreed.

-- 
regards,
Reinhard

Bug#987207: podman not running out-of-the-box as root

[Reinhard Tartler]

Control: tag -1 moreinfo

Hi Laurent,

I've downloaded the Bullseye Alpha 3 debian installer and installed using
kvm to have a super clean new system. Unfortunately, I was unable to
reproduce the issue that you described below. (I did find some issues with
rootless podman outside of a gnome-session, but that's a different story).

The symptoms sound a lot like described in this upstream bug:
https://github.com/containers/podman/issues/5721

Can you please compare your notes with that upstream bug? Can you confirm
that the 'overlay' kernel module is loaded? (in my test, it was loaded
automatically). If you still think this is an issue in the Debian package,
please let me know. I may require your assistance with reproducing this
issue.

-rt

On Mon, Apr 19, 2021 at 11:54 AM Laurent Bigonville 
wrote:

> Package: podman
> Version: 3.0.1+dfsg1-1
> Severity: serious
>
> Hello,
>
> After installing podman, I cannot run it as root out of the box as it
> fails with:
>
> ERRO[] [graphdriver] prior storage driver overlay failed: kernel does
> not support overlay fs: 'overlay' is not supported over extfs at
> "/var/lib/containers/storage/overlay": backing file system is unsupported
> for this graph driver
> Error: kernel does not support overlay fs: 'overlay' is not supported over
> extfs at "/var/lib/containers/storage/overlay": backing file system is
> unsupported for this graph driver
>
> Looking at fedora it seems that they have a containers-common package
> that ships a default storage.conf file:
>
>
> https://src.fedoraproject.org/rpms/containers-common/blob/rawhide/f/storage.conf
>
> I see that the debian package is shipping a file in
> /usr/share/containers/storage.conf (in the containers-storage package),
> but that file is apparently not read (strace only shows that the file in
> /etc/containers is read) and anyway unlike in fedora:
>
> 1) the driver is not set to overlay
> 2) the file is installed only if the containers-storage package is
> installed, which is not done by default.
> 3) that file is not read anyway, strace only shows that
> /etc/containers/storage.conf is read and not
> /usr/share/containers/storage.conf, so the file is apparently useless
>
> Shouldn't debian do the same thing than fedora so everything works OOTB?
>
> As a side note, I can see they are shipping also other files as well,
> like the seccomp.json file, using strace, it seems that podman tries to
> read them:
>
> [pid 14835] newfstatat(AT_FDCWD, "/etc/containers/seccomp.json",
> 0xcee6b8, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
> [pid 14835] newfstatat(AT_FDCWD, "/usr/share/containers/seccomp.json",
> 0xcee788, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
>
> Shouldn't that file be shipped by default too?
>
> Kind regards,
> Laurent Bigonville
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_BE:fr
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
>
> Versions of packages podman depends on:
> ii  conmon   2.0.25+ds1-1
> ii  containernetworking-plugins  0.9.0-1+b3
> ii  golang-github-containers-common  0.35.4+ds1-1
> ii  init-system-helpers  1.60
> ii  libc62.31-11
> ii  libdevmapper1.02.1   2:1.02.175-2.1
> ii  libgpgme11   1.14.0-1+b2
> ii  libseccomp2  2.5.1-1
> ii  runc 1.0.0~rc93+ds1-3
>
> Versions of packages podman recommends:
> ii  buildah   1.20.0+ds1-1
> ii  fuse-overlayfs1.4.0-1
> ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b4
> ii  slirp4netns   1.0.1-2
> ii  tini  0.19.0-1
> ii  uidmap1:4.8.1-1
>
> Versions of packages podman suggests:
> ii  containers-storage  1.24.8+dfsg1-1+b1
> ii  docker-compose  1.25.0-1
>
> -- no debconf information
>
>

-- 
regards,
Reinhard

Bug#983395: podman lacks a runtime dependency on rootlesskit

[Reinhard Tartler]

Control: retitle -1 Please print nicer error message if newuidmap is not
installed
Control: severity -1 wishlist
Control: tag -1 upstream

Andrey, please stop this bug ping-pong.

Feel free to escalate this to the TC, but I don't think you are being
reasonable here.

-- 
regards,
Reinhard

Bug#982967: FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64

[Reinhard Tartler]

Source: docker.io
Version: 19.03.4+dfsg2-2
Severity: serious
Justification: FTBFS

During a test rebuild of the docker.io package, I noticed that it declares a
build-depends relationship on a non-existing package:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


It appears this package has been removed as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744

Bug#982957: FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64

[Reinhard Tartler]

Source: docker-registry
Version: 2.7.1+ds2-7
Severity: serious
Justification: FTBFS

In a rebuild, I noticed that this package fails to build from source:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


Apparently it depends on golang-github-rsc-letsencrypt-dev which is has been
removed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Got it.

On Tue, Feb 16, 2021 at 4:03 PM Sebastian Ramacher 
wrote:

> Control: severity -1 serious
>
> [...]
> Tests are executed as part of the binary target:
>
> dh binary --no-act  | grep auto_test
>dh_auto_test
>
> So the "no required targets may attmept network access" rule applies.
> Raising the severity accordingly. Please disable the tests that access
> the network.
>

Thanks for getting back to me. I've just made a sourceful upload that
disables the problematic test.

-- 
regards,
Reinhard

Bug#977542: marked as pending in golang-github-revel-revel

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #977542 in golang-github-revel-revel reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-revel-revel/-/commit/f3a1c0a862806c283f7c0c6e09d5842396860336


Skip TestGetCustom which requires network access

Closes: #977542


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/977542

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Control: severity -1 important

Dear release team,

I'm writing as a member of the pkg-go team and am mostly concerned about
potential removal of depending packages.

The package itself appears to be fine. The tests fail if and only if the
test setup doesn't provide (proper) internet connectivity. In fact, it
tries at test time to reach http://httpbin.org/get - a service aimed at
developing and debugging programs that do HTTP/REST calls.

Based on this, I'm not convinced about removing a significant amount of
packages from the buster release because of this issue. I'm therefore
downgrading the issue to important and would recommend fixing it right
after buster release.

I'm reaching out to you to confirm this thinking. If you do believe this is
something that ought to be fixed for buster, I'd be happy to upload the
proposed patch to sid right away, as it seems appropriate to disable the
test -- the additional test coverage that it could provide is in no
relationship compared to the effort it would take to fake out the internet
service.

--
regards,
Reinhard

Bug#982288: podman: Can't run caontainers - failed to connect to container's attach socket

[Reinhard Tartler]

Control: tag -1 upstream
Control: severity important
Control: retitle -1 rootless podman fails with very long uids

On Mon, Feb 8, 2021 at 6:09 AM Sam Morris  wrote:

> Package: podman
> Version: 3.0.0~rc2+dfsg1-2+b1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: s...@robots.org.uk
>
> After upgrading to podman 3, I can't run any containers any more.
>
> $ podman run --rm -it docker.io/library/debian:10
> Error: failed to connect to container's attach socket:
> /run/user/876099160/libpod/tmp/socket/3178d20b8a3a42642dc6a7f32884df47019bc4a2a82af94fe4928b00ed3293c9/attach:
> no such file or directory
>
> The directory /run/user/876099160/libpod/tmp/socket is empty.
>

It works just fine for me:


siretart@x1:/tmp$ podman run --rm -it docker.io/library/debian:10
Trying to pull docker.io/library/debian:10...
Getting image source signatures
Copying blob b9a857cbf04d done
Copying config e7d08cddf7 done
Writing manifest to image destination
Storing signatures
root@55ebd48e763b:/# exit



> According to unix(7), socket paths are limited to 108 bytes, but the
> path in the error message is slightly longer than that:
>
> $ echo -n 
> /run/user/876099160/libpod/tmp/socket/18654637587d169f834095dce40d4812378e0056936974c9b7073ba1ae767bfa/attach
> | wc -c
> 109
>
>
Is 876099160 really the uid of your user? That seems absurdly long to me,
for me it is '1000'.



> Podman had a similar sounding bug a couple of years ago,
> , but that was
> fixed in podman 0.11.1.
>

That indeed seems related. Would you mind filing a new bug with this
information at https://github.com/containers/podman/issues/new and tell me
the bug number?

Thanks.

Bug#979313: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #979313 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/2b95096f49f379cc8d5ce8bc432c82195c8364e5


Ignore containers.conf sysctl when namespaces set to host

Closes: #979313


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/979313

Bug#976924: Test timeouts on ppc64el not RC

[Reinhard Tartler]

Control: severity -1 normal

Looking at the logs, it really looks like timeouts in the testsuite. We could 
disable the tests on problematic architectures, patches welcome. As a 
workaround, I'd suggest building the package with export 
DEB_BUILD_OPTIONS=notest. With this, I'm downgrading the severity to normal to 
avoid having dozens of packages removed from testing.

-rt

Bug#976509: marked as pending in golang-github-shirou-gopsutil

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #976509 in golang-github-shirou-gopsutil reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-shirou-gopsutil/-/commit/5085339ce0de2687d9729e011f049e222598e580


Disable cpuinfo related test, Closes: #976509)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/976509

Bug#977502: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #977502 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/bafa6d42d5dfc209c6e864494fe0fc8d16d0494d


Rely on upstream's build scripts to install manpages (Closes: #977502)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/977502

Bug#977502: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #977502 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/7377dad97a3c3352ad41c9d45c8faedacfa8ef20


Remove conflicting manpage container-mounts(5), Closes: #977502


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/977502

Bug#977502: podman,golang-github-containers-common: both ship /usr/share/man/man5/containers-mounts.conf.5.gz

[Reinhard Tartler]

Hi Valentin,

I just received the bug below. It seems that the manpage duplication is
actually upstream:
-
https://github.com/containers/common/blob/master/docs/containers-mounts.conf.5.md
-
https://github.com/containers/podman/blob/master/docs/source/markdown/containers-mounts.conf.5.md

They both seem to have identical content. Maybe one of those copied should
be deleted? How do the fedora packagers get around this issue?

Thanks and best regards,
-rt


On Tue, Dec 15, 2020 at 2:51 PM Andreas Beckmann  wrote:

> Package: podman,golang-github-containers-common
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> Control: found -1 2.1.1+dfsg1-2
> Control: found -1 0.28.1+ds1-1
>
> Hi,
>
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
>
>   Preparing to unpack
> .../golang-github-containers-common_0.28.1+ds1-1_all.deb ...
>   Unpacking golang-github-containers-common (0.28.1+ds1-1) over
> (0.26.3+ds1-2) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/golang-github-containers-common_0.28.1+ds1-1_all.deb
> (--unpack):
>trying to overwrite '/usr/share/man/man5/containers-mounts.conf.5.gz',
> which is also in package podman 2.1.1+dfsg1-2
>   Errors were encountered while processing:
>
>  /var/cache/apt/archives/golang-github-containers-common_0.28.1+ds1-1_all.deb
>
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
>
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
>   usr/share/man/man5/containers-mounts.conf.5.gz
>
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
>
> Cheers,
>
> Andreas
>
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html
>


-- 
regards,
Reinhard

Bug#976943: golang-github-seccomp-libseccomp-golang: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 github.com/seccomp/libsec

[Reinhard Tartler]

> === RUN   TestRuleAddAndLoad
> seccomp_test.go:588: Syscall should have returned error code!
> --- FAIL: TestRuleAddAndLoad (0.00s)


Source code is here: 
https://sources.debian.org/src/golang-github-seccomp-libseccomp-golang/0.9.1-2/seccomp_test.go/#L529-L589

This test is basically loading a seccomp rule and expects that the
getpid() syscall fails with the rule loaded, but in that test it seems
to pass. This might mean that seccomp isn't working on that box.

Lucas, can you elaborate a bit what kind of test system you were using?
Do you have any explanation what might be going on with the test setup that
would make seccomp not work or only under certain conditions?

-rt

Bug#976543: marked as pending in golang-github-rcrowley-go-metrics

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #976543 in golang-github-rcrowley-go-metrics reported by you has been fixed 
in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-rcrowley-go-metrics/-/commit/22d89f6515f7fabdae307ba8911756552dee13cc


Fix test on !amd64, Closes: #976543


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/976543

Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/

[Reinhard Tartler]

Control: forwarded -1 https://github.com/shirou/gopsutil/issues/881

I'm having a hard time seeing bugs like this as RC-critical. Looking at
the testsuite more specifically, I strongly believe this is upstream bug
https://github.com/shirou/gopsutil/issues/881

Lucas, can you please post /proc/cpuinfo from the amd64 machine you
tested on so that we confirm that it doesn't report a modelname?

I'd concur with Andreas to disable running tests on !amd64, maybe with
something like this patch:

modified   debian/rules
@@ -10,3 +10,9 @@ export CIRCLECI := true
 
 %:
dh $@ --buildsystem=golang --with=golang
+
+
+override_dh_auto_test:
+ifneq (,$(filter $(DEB_HOST_ARCH), amd64))
+   dh_auto_test --buildsystem=golang
+endif



Alternativly, we could also disable the "problematic part" of the test until 
the upstream bug is fixed properly:

diff --git a/cpu/cpu_test.go b/cpu/cpu_test.go
index e8e0e8d..dbcaaae 100644
--- a/cpu/cpu_test.go
+++ b/cpu/cpu_test.go
@@ -85,11 +85,6 @@ func TestCpuInfo(t *testing.T) {
if len(v) == 0 {
t.Errorf("could not get CPU Info")
}
-   for _, vv := range v {
-   if vv.ModelName == "" {
-   t.Errorf("could not get CPU Info: %v", vv)
-   }
-   }
 }


In any case, I'm unconvinced that this bug is severe enough to claim it
as 'release critical' would warrant removing the package from unstable.

Bug#975584: marked as pending in consul

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #975584 in consul reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/consul/-/commit/9650adb23f7363d8e0d5a19522542e3be78b9f72


New upstream release (Closes: #975584)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/975584

Bug#976410: glibc breaks libpod autopkgtest: dh_auto_build: error: cd _output && go install -trimpath ...

[Reinhard Tartler]

On Fri, Dec 4, 2020 at 3:24 PM Aurelien Jarno  wrote:

>
> I have tried and for me the issue is reproducible with both old and new
> glibc. I am therefore reassign the bug to libpod.
>
This is because of an upstream update in a dependency. It should be very
straight-forward to fix. Unfortunately, libpod is currently in binary NEW.
I'll upload a fix as soon as it clears.
-- 
regards,
Reinhard

Bug#968207: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #968207 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/10fddc1e38732f9c7f8eaba514f913c842a62893


Bug fix: "Breaks docker", thanks to Jan Hudec (Closes: #968207).

No longer create symlink /run/docker.sock to avoid interfering
with the docker daemon. Users that wish to replace the docker
daemon with podman are advised to install the symlink themselves
and arrange appropriate permissions for podman.sock.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/968207

Bug#961814: Debian Bugs information: logs for Bug#961814

[Reinhard Tartler]

Thanks!

Will incorporate in the next upload.

Bug#961814: Debian Bugs information: logs for Bug#961814

[Reinhard Tartler]

On Mon, Aug 3, 2020 at 8:30 AM Shengjing Zhu  wrote:

> If I read the comments in upstream issue correctly, it will be solved in 2
> months (they said 6 months later at April). What's the urgent thing we need
> to address in this two months?
>

I realized that podman 2.0 requires this newer version of protobuf. I've
changed podman to vendor the sources for now. Urgency is in the eye of the
beholder, I guess.

It just seems weird to me to not be able to use this package until this bug
is addressed.

-rt

Bug#961814: Debian Bugs information: logs for Bug#961814

[Reinhard Tartler]

>From: Shengjing Zhu 
>To: Debian Bug Tracking System 
>Subject: Not ready for using
>Date: Fri, 29 May 2020 23:36:43 +0800
>
> Package: golang-google-protobuf
> Severity: serious
>
> Though it has been packaged, it's not ready for using.
>
> The current version will generate .pb.go files which requires
> v1.4+ version of `github.com/golang/protobuf/proto`
> .
> See the reason at https://github.com/golang/protobuf/issues/1077
>
> Besides, I split the /bin/protoc-gen-go to a separated package.
> Now two packages offer /bin/protoc-gen-go:
>
> + golang-goprotobuf-dev (1.3.x, by src:golang-goprotobuf):
>   both /bin/protoc-gen-go and github.com/golang/protobuf/* files
> + protoc-gen-go (1.23.0, by src:golang-google-protobuf):
>   only /bin/protoc-gen-go
>   Go files google.golang.org/protobuf/* are in golang-google-protobuf-dev
>
> The 1.23.0 version of protoc-gen-go will generate files which import
> both google.golang.org/protobuf and github.com/golang/protobuf, and
> require 1.4.0+ github.com/golang/protobuf.
>
> Any suggestions how can we move forward are appreciated.
>
> Maybe the easiest way is to wait upstream fixing issue #1077.
>
>
Have you considered to revert upstream patch at
https://go-review.googlesource.com/c/protobuf/+/218939/4/cmd/protoc-gen-go/internal_gengo/main.go
for
debian locally? As far as I understand, this is the change (i.e., revert)
upstream plans to make in a couple of months. I think Debian could move
ahead with this to unblock other packages using this.

What do you think?

-rt

Bug#966501: 2.0.3 REST API regression: Failed to parse parameters for /v1.12/libpod/events: unexpected end of JSON input

[Reinhard Tartler]

Control: severity -1 important

Hi Martin,

On Wed, Jul 29, 2020 at 8:42 AM Martin Pitt  wrote:

> Package: podman
> Version: 2.0.3+dfsg1-1
> Severity: serious
> Tags: upsteam fixed-upstream
>
> Version 2.0.3 breaks the REST API really hard, which breaks cockpit-podman
> and
> any other API user. This is tracked here:
>
>   https://github.com/containers/podman/issues/7078
>
> This has been fixed upstream and will be in 2.0.4. I'd like to block this
> version from testing to avoid the regression.
>
> If you disagree and would rather get this in ASAP (given how young the
> package
> is still), I'm fine with that as well, and disable the cockpit-podman test
> on
> debian-testing for a while.
>
>
Thank you for your bugreport. I looked into backporting the change and
checked in with my contact upstream. It turns out that this is not the only
issue with the REST interface, and neither of them are easy to backport to
2.0.3. A new release will come out soon that should be suitable for
cockpit-podman.

Cockpit looks like a really cool project. I do need to find some time to
play with it, in particular with the upcoming cockpit-podman component.
Thanks for packaging it! Are you working full time on "cockpit"?

Given that the REST interface is not available in testing (the respective
systemd units were only introduced in 2.0.3+dfsg1-1), and podman provides a
lot of value even without them, I'd rather have the current package migrate
to testing at this point. Having said this, I do really appreciate your bug
report and will see to a remedy as soon as it becomes available in the form
of a new upstream release.

For the time being, I'd recommend disabling the cockpit-podman test for the
time being and re-enable it when this bug gets closed properly.

Thanks for your understanding.

-- 
regards,
Reinhard

Bug#950816: marked as pending in mpv

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #950816 in mpv reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/multimedia-team/mpv/-/commit/3b52150eed39653c009ecf6474a5eccb7655f149


Bug fix: "unintended code execution vulnerability", thanks to astian (Closes: 
#950816). Patch backported from upstream


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/950816

Bug#965114: golang-github-shenwei356-bwt: FTBFS: unsatisfiable build dependency

[Reinhard Tartler]

Package: golang-github-shenwei356-bwt
Severity: serious
Justification: FTBFS

While trying to rebuild this package, it appears it build depends on the
package golang-github-shenwei356-bpool-dev

Find the buildlog attached to this email.



golang-github-shenwei356-bwt_0.0~git20200418.ae79c98-2
Description: Binary data


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#964870: snapd: FTBFS: FAIL: squashfs_test.go:130: SquashfsTestSuite.TestInstallSimpleNoCp

[Reinhard Tartler]

Package: snapd
Version: 2.44.1-2
Severity: serious

While trying to rebuild the package, I noticed that one of the tests in
the testsuite fails:

=== RUN   Test

--
FAIL: squashfs_test.go:130: SquashfsTestSuite.TestInstallSimpleNoCp

squashfs_test.go:151:
c.Check(linked, Equals, 1)
... obtained int = 0
... expected int = 1

squashfs_test.go:152:
c.Check(cmd.Calls(), HasLen, 0)
... obtained [][]string = [][]string{[]string{"cp", "-av", 
"/tmp/check-8449157405891831569/79/foo.snap", 
"/tmp/check-8449157405891831569/83/target.snap"}}
... n int = 0

OOPS: 36 passed, 1 FAILED
--- FAIL: Test (0.38s)
FAIL
FAILgithub.com/snapcore/snapd/snap/squashfs 0.391s


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 2.13.4-2
ii  ca-certificates  20200601
ii  gnupg2.2.20-1
ii  libapparmor1 2.13.4-2
ii  libc62.30-8
ii  libcap2  1:2.34-2
ii  libseccomp2  2.4.3-1+b1
ii  libudev1 245.6-1
ii  openssh-client   1:8.3p1-1
ii  squashfs-tools   1:4.4-2
ii  systemd  245.6-1
ii  udev 245.6-1

Versions of packages snapd recommends:
ii  gnupg  2.2.20-1

Versions of packages snapd suggests:
ii  zenity  3.32.0-5

-- Configuration Files:
/etc/sudoers.d/99-snapd.conf [Errno 13] Permission denied: 
'/etc/sudoers.d/99-snapd.conf'

-- no debconf information

Bug#964045: marked as pending in golang-github-shirou-gopsutil

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #964045 in golang-github-shirou-gopsutil reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-shirou-gopsutil/-/commit/986588f388e0b93bf020bb19bb668539fb3a3a4f


Disable more tests to avoid FTBFS (Closes: #964045)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/964045

Bug#964045: marked as pending in golang-github-shirou-gopsutil

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #964045 in golang-github-shirou-gopsutil reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-shirou-gopsutil/-/commit/14d011ddbd64b9bedcec2354b1598b521e563c91


Also ignore test TestVirtual_memory

Closes: #964045


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/964045

Bug#963346: marked as pending in golang-github-openshift-api

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #963346 in golang-github-openshift-api reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-openshift-api/-/commit/af4722b98b0504ca5e60007c1ab24aade60d6a28


Add build depends on golang-gopkg-yaml.v2-dev

Fixes FTBFS

Closes: #963346


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/963346

Bug#961421: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #961421 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/35785958eb8d2e17fd502599ad62e65aa23734b4


Do not copy up when volume is not empty (CVE-2020-1726)

Add patch from upstream to fix security issue

Closes: #961421


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/961421

Bug#953540: [Aspectc-developers] Fwd: Bug#953540: aspectc++: FTBFS on armel

[Reinhard Tartler]

Control: forwarded -1 aspectc-develop...@aspectc.org

Hi Adrian,

Olaf, the upstream developer, has a question regarding your patch to aspectc++.
Would you mind having a look and ideally sharing your reply to everyone?

Thank you!
-rt

On 3/17/20 11:05 AM, Olaf Spinczyk wrote:
> Hi Reinhard!
> 
> Do you understand the reasons behind the patch?
> 
> The difference is the following addition for linking:
> 
>  -Wl,--as-needed -latomic -Wl,--no-as-needed
> 
> (1) I wonder why the atomics (e.g. __atomic_fetch_add_4) are not
> available by default in armel. They seem to be on most other platforms.
> 
> (2) Why is "--as-needed ... --no-as-needed" necessary?
> 
> (3) Could -latomic also be placed at the end of the list of libraries
> (behind the additional libraries needed for Clang 9.0.x)?
> 
> Cheers,
> 
> Olaf
> 
> Am 17.03.20 um 14:10 schrieb Reinhard Tartler:
>> Hi aspect c++ developers,
>>
>> Would the attached patch be acceptable for svn trunk?
>>
>> Please have a look at the Debian bug for context. I'm happy to clarify any 
>> questions.
>>
>> Best
>> Rt
>>
>>
>>  Original Message 
>> From: Adrian Bunk 
>> Sent: March 17, 2020 7:04:58 AM EDT
>> To: Ivo De Decker , 953...@bugs.debian.org
>> Subject: Bug#953540: aspectc++: FTBFS on armel
>>
>> Control: tags -1 patch
>>
>> On Tue, Mar 10, 2020 at 11:12:16AM +, Ivo De Decker wrote:
>>> package: src:aspectc++
>>> version: 1:2.2+git20200229-1
>>> severity: serious
>>> tags: ftbfs
>>>
>>> Hi,
>>>
>>> The latest upload of aspectc++ to unstable fails on armel:
>>>
>>> https://buildd.debian.org/status/package.php?p=aspectc%2B%2B
>>
>> Fix attached.
>>
>>> Cheers,
>>>
>>> Ivo
>>
>> cu
>> Adrian
>>
>>
>> ___
>> aspectc-developers mailing list
>> aspectc-develop...@aspectc.org
>> http://aspectc.org/listinfo/aspectc-developers
>>
> ___
> aspectc-developers mailing list
> aspectc-develop...@aspectc.org
> http://aspectc.org/listinfo/aspectc-developers
> 

Bug#947486: FTBFS due to failing test case TestDefaultCache

[Reinhard Tartler]

Thanks for this bug report.

Your snippet above unfortunately skips the actual error that is happening.
Here is the relevant error:

=== RUN   TestDefaultCache
time="2019-12-28T16:50:03Z" level=error
msg="/tmp/TestDefaultCache173385111/unwritable:
{name:\"unwritable\", size:4096, mode:0x8140,
modTime:time.Time{wall:0xac045b5, ext:63713148603, loc:(*tim\
e.Location)(0x9f64a0)}, sys:syscall.Stat_t{Dev:0x40, Ino:0x7e664e,
Nlink:0x2, Mode:0x4140, Uid:0x0, Gid:0x0, X__pad0:0, Rdev:0x0, Size:4096,
Blksize:4096, Blocks:8, Atim:syscall.Timespec{Sec:1577551803, Nsec:18\
0372917}, Mtim:syscall.Timespec{Sec:1577551803, Nsec:180372917},
Ctim:syscall.Timespec{Sec:1577551803, Nsec:180372917},
X__unused:[3]int64{0, 0, 0}}}"
--- FAIL: TestDefaultCache (0.00s)
default_test.go:151:
Error Trace:default_test.go:151
Error:  Object expected to be of type
*memory.cache, but was *boltdb.cache
Test:   TestDefaultCache
default_test.go:163:
Error Trace:default_test.go:163
Error:  Object expected to be of type
*memory.cache, but was *boltdb.cache
Test:   TestDefaultCache
FAIL
FAILgithub.com/containers/image/pkg/blobinfocache   0.004s


I believe this is because of an outdated version of the
https://tracker.debian.org/pkg/golang-github-coreos-bbolt package, at least
upstream explicitly references version 1.3.3. I've filed #947617 for this.


-- 
regards,
Reinhard

Bug#938818: whatthepatch: diff for NMU version 0.0.5-2.1

[Reinhard Tartler]

Thanks for the upload, Sandro.

Happy holidays!
rt

On December 23, 2019 11:22:37 PM GMT+01:00, Sandro Tosi  
wrote:
>Control: tags 938818 + patch
>
>
>Dear maintainer,
>
>I've prepared an NMU for whatthepatch (versioned as 0.0.5-2.1). The
>diff
>is attached to this message.
>
>Regards.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#929697: fixed in pyglet 1.3.0-2.1

[Reinhard Tartler]

On 6/13/19 3:15 AM, Paul Gevers wrote:
> Hi,
> 
> On Tue, 04 Jun 2019 21:03:47 + Reinhard Tartler
>  wrote:
>>* Disable ClockTimingTestCase (Closes: #929697)
> 
> ^^ If this is supposed to go into buster, somebody has to prepare a
> targeted upload to unstable (d/copyright improvement can stay). Most of
> the current delta is not acceptable for an unblock at this stage of the
> release, so without action, we will remove pyglet from buster soon. To
> be clear, I'm *not* offering tpu.
> 

I've uploaded an NMU to testing-proposed-updates. Debdiff attached.

-rt
diff -Nru pyglet-1.3.0/debian/changelog pyglet-1.3.0/debian/changelog
--- pyglet-1.3.0/debian/changelog   2018-01-04 17:15:56.0 -0500
+++ pyglet-1.3.0/debian/changelog   2019-06-13 08:00:23.0 -0400
@@ -1,3 +1,16 @@
+pyglet (1.3.0-1.1) testing-proposed-updates; urgency=medium
+
+  [ Yaroslav Halchenko ]
+  * No strings exceptions is allowed in Python2.6
+
+  [ Scott Kitterman ]
+  * Update debian/copyright
+
+  [ Reinhard Tartler ]
+  * Disable Problematic tests (Closes: #929697)
+
+ -- Reinhard Tartler   Thu, 13 Jun 2019 08:00:23 -0400
+
 pyglet (1.3.0-1) unstable; urgency=medium
 
   * The released version
diff -Nru pyglet-1.3.0/debian/copyright pyglet-1.3.0/debian/copyright
--- pyglet-1.3.0/debian/copyright   2018-01-04 17:15:56.0 -0500
+++ pyglet-1.3.0/debian/copyright   2019-06-13 08:00:23.0 -0400
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: pyglet
 Upstream-Contact: Alex Holkner 
 Source: https://bitbucket.org/pyglet/pyglet/
@@ -25,25 +25,72 @@
 Copyright: 2006, Johann C. Rocholl 
 Note: derived from png.py
 License: MIT
-  Permission is hereby granted, free of charge, to any person
-  obtaining a copy of this software and associated documentation files
-  (the "Software"), to deal in the Software without restriction,
-  including without limitation the rights to use, copy, modify, merge,
-  publish, distribute, sublicense, and/or sell copies of the Software,
-  and to permit persons to whom the Software is furnished to do so,
-  subject to the following conditions:
-  .
-  The above copyright notice and this permission notice shall be
-  included in all copies or substantial portions of the Software.
-  .
-  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
-  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
-  ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-  SOFTWARE.
+
+Files: pyglet/extlibs/future/py2_3/past/__init__.py, 
+   tests/extlibs/future/py2_3/past/__init__.py,
+   pyglet/extlibs/future/py2_3/future/__init__.py,
+   tests/extlibs/future/py2_3/future/__init__.py
+Copyright: 2013-2015 Python Charmers Pty Ltd, Australia.
+License: MIT
+
+Files: pyglet/extlibs/future/py2_3/future/backports/email*,
+  test/extlibs/future/py2_3/future/backports/email*,
+Copyright:  (C) 2001-2007 Python Software Foundation
+License: Python
+
+Files: pyglet/extlibs/future/py2_3/libfuturize/fixes/fix_metaclass.py,
+   test/extlibs/future/py2_3/libfuturize/fixes/fix_metaclass.py
+Copyright: (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
+   2011, 2012, 2013 Python Software Foundation. All rights reserved.
+License: Python
+
+Files: pyglet/extlibs/future/py2_3/future/backports/xmlrpc/client.py,
+   tests/extlibs/future/py2_3/future/backports/xmlrpc/client.py
+Copyright: (c) 1999-2002 by Secret Labs AB, (c) 1999-2002 by Fredrik Lundh
+License: Secret Labs
+
+Files: pyglet/extlibs/future/py2_3/future/backports/urllib/robotparser.py,
+   tests/extlibs/future/py2_3/future/backports/urllib/robotparser.py
+Copyright: (C) 2000  Bastian Kleineidam
+License: GPL2 or Python
+
+Files: pyglet/extlibs/future/py2_3/future/backports/socketserver.py,
+   tests/extlibs/future/py2_3/future/backports/socketserver.py
+Copyright: (C) 2000  Luke Kenneth Casson Leighton 
+License: Python
+
+Files; pyglet/extlibs/future/py2_3/libfuturize/fixes/fix_print.py,
+   tests/extlibs/future/py2_3/libfuturize/fixes/fix_print.py
+Copyright: 2006 Google, Inc. All Rights Reserved.
+License: Python
+
+Files: tests/extlibs/mock.py
+Copyright: (C) 2007-2012 Michael Foord & the mock team
+License: BSD-3
+
+Files: pyglet/extlibs/future/py2_3/future/backports/http/cookies.py,
+   tests/extlibs/future/py2_3/future/backports/http/cookies.py
+Copyright: 2000 by Timothy O'Malley 
+License: Omalley
+ All Rights Reserved
+ 
+  Permission to use, copy, modify

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

Agreed!

In this case, the bug was reported on Aug 24 2018 by Adrian Bunk. It was
removed about a months later, namely on September 23, for failing to build
from source. Four weeks is arguably quite fast. Or quite slow, depending on
whom you talk to.

I probably could have reacted by disabling the test suite. Or by prodding
you in those four weeks harder. Or at last have the bug fixed by end of
last year, which would have left enough time to re-migrate to testing. In
the future, I'll know better.

Again, sorry. I'm happy to help with getting the package to
buster-backports once it opens.

-rt

On Sun, Jun 9, 2019 at 5:29 PM Chris Wilson 
wrote:

> Hi all,
>
> It seems a bit egregious to kick out packages that were broken by a minor
> version upgrade in one of their dependencies (which after all is not
> supposed to break anything), without any warning, let alone time to fix
> such a complex issue properly.
>
> I hope that Debian will consider carefully whether this course of action
> was really in the best interests of its users.
>
> Thanks, Chris.
>

-- 
regards,
Reinhard

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

On Wed, Jun 5, 2019 at 7:46 PM Chris Wilson  wrote:

> Hi Reinhard,
>
> Could you have a look at this patch
>  (documented
> here
> )
> to see if it's something like what you were hoping for?
>
>
Hi Chris,

I've uploaded this patch now to unstable, looks good, thanks for the patch.
It is still about 80k big, thoguh :-( - quite a lot to review manually.
Most of it is actually test code though!

Unfortunately, I have bad news. I totally missed that boxbackup has already
been removed on 23 Sep 2018:
https://tracker.debian.org/news/989096/boxbackup-removed-from-testing/
That's a bummer, because the freeze guidelines rule out migration of
packages that aren't part of testing since beginning of February (cf.
https://release.debian.org/buster/freeze_policy.html).

Sorry about that, that's totally on me, I should have been more vocal about
this end of last year and totally dropped the ball here.

I guess we'll have to go the backports route then.

Best,
-rt
-- 
regards,
Reinhard

Bug#928948: hostapd: syslog is spammed every two seconds

[Reinhard Tartler]

Hi,

I'm trying to help out with remaining RC bugs for buster.

> The postinst is set up in a way so that if /etc/hostapd/hostapd.conf
> is not readable or missing, the hostapd.service is masked during the
> package installation unless it was already running.

I wonder if that is really necessary and couldn't be avoided by using the
following drectitve in hostapd.service:

ConditionPathExists=/etc/hostapd/hostapd.conf

If my understading of systemd.unit(5) is correct, I believe this might
simplify significantly simplify the postinst script.

-- 
regards,
Reinhard

Bug#929697: pyglet: diff for NMU version 1.3.0-2.1

[Reinhard Tartler]

Control: tags 929697 + patch
Control: tags 929697 + pending

Dear maintainer,

I've prepared an NMU for pyglet (versioned as 1.3.0-2.1) and uploaded
it to DELAYED/2-days. Please feel free to tell me if I should delay it
longer.

Please note that this upload is *not* suitable for buster, as there
are many changes from 1.3.0-1 to 1.3.0-2 (including a conversion from
CDBS to dh) that don't meet the release team's criteria for updates to
buster this late in the game. This patch may need to be uploaded to
testing-proposed-updates separately.

Regards,
-rt

diff -Nru pyglet-1.3.0/debian/changelog pyglet-1.3.0/debian/changelog
--- pyglet-1.3.0/debian/changelog   2019-03-01 22:45:26.0 -0500
+++ pyglet-1.3.0/debian/changelog   2019-06-02 15:17:34.0 -0400
@@ -1,3 +1,14 @@
+pyglet (1.3.0-2.1) unstable; urgency=medium
+
+  [ Yaroslav Halchenko ]
+  * No strings exceptions is allowed in Python2.6
+
+  [ Reinhard Tartler ]
+  * Non-Maintainer upload.
+  * Disable ClockTimingTestCase (Closes: #929697)
+
+ -- Reinhard Tartler   Sun, 02 Jun 2019 15:17:34 -0400
+
 pyglet (1.3.0-2) unstable; urgency=medium
 
   [ Scott Kitterman ]
diff -Nru pyglet-1.3.0/debian/rules pyglet-1.3.0/debian/rules
--- pyglet-1.3.0/debian/rules   2019-03-01 21:13:15.0 -0500
+++ pyglet-1.3.0/debian/rules   2019-06-02 15:17:34.0 -0400
@@ -20,6 +20,8 @@
 EXCLUDED_TESTS += and not test_issue429
 EXCLUDED_TESTS += and not test_issue241
 EXCLUDED_TESTS += and not test_issue471
+# cf. #929697
+EXCLUDED_TESTS += and not ClockTimingTestCase
 
 export PYBUILD_NAME=pyglet
 export PYBUILD_TEST_PYTEST=1

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

On Fri, May 31, 2019 at 5:03 PM Chris Wilson  wrote:

> Hi Reinhard,
>
> Presumably the many other affected packages have had similar difficulty in
> developing a comprehensive solution? I also wasn't aware of a time
> constraint. Not that it would have helped me much, as I was moving house,
> but it would have been good to know that there was a risk of not making
> Debian 10.
>

I'm sorry, I should have communicated that point earlier. I've been bitten
by this with other packages as well.
The release schedule is documented here:
https://wiki.debian.org/DebianBuster
The most recent update from the release team is
https://lists.debian.org/debian-devel-announce/2019/04/msg3.html - and
newer updates will be linked from https://release.debian.org/.

In short: The team is minimizing changes as much as possible, and getting
updates in becomes more and more a similar big deal as updating something
in stable.

I could create a special branch with a cut-down version of the solution,
> e.g. forcing the SecurityLevel to -1 (compatibility and warn) for the time
> being, in order to get the fix out in time for Debian 10, and then put the
> full version into backports?
>

That would be amazing, if the patch is easy to review, I'd be happy to
upload it as a distro patch based on the current package and try to get
this approved by the release team. It might even be accepted as a stable
update, depending on how invasive it is.


Thanks,
-rt

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

Hi Chris,

On Sun, May 19, 2019 at 12:21 PM Chris Wilson 
wrote:

> Hi Reinhard and all,
>
> Good news, I have just finished fixing this problem, and merged it into
> master with https://github.com/boxbackup/boxbackup/pull/36. Please could
> you cut a new Debian package release and see if the tests pass for you? Or
> if not, point me to the failure logs?
>
> If anyone wants to know more, the issue is quite complex, and there are no
> easy answers, which is why it took so long to fix. I've done my best to
> describe it at
> https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates. Please
> feel free to correct any mistakes that I've made.
>

Thanks a lot for your assistance!

I've now (finally) uploaded the package to debian/experimental, the build
logs will be available at
https://buildd.debian.org/status/package.php?p=boxbackup=experimental
 soon.

Unfortunately, the changes are quite invasive and do not qualify for
inclusion into "Debian testing" this late in the Debian release cycle (cf.
https://salsa.debian.org/debian/boxbackup/commit/6017757bc079f4446aa77bc5c0855c52741280f4?w=1
- all of which would need to be reviewed and approved by the Release Team).
That's very unfortunate, because it very likely means that boxbackup will
not be part of Debian 10 (buster).

I am also sympathetic -- the nature of the issue seems to require such
invasive changes and coming up with a simple, focused and reviewable fix is
super hard.

The best that we can do at this point is to get it included into
"buster-backports" as soon as that suite opens, probably shortly after
buster is released, which should be within (hopefully) a small number of
weeks.


Best,
-rt

-- 
regards,
Reinhard

Bug#926103: Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2

[Reinhard Tartler]

Hi Release Team,

Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve 
the attached debdiff, so that I can upload the fixed package to unstable.

Thank you for your consideration.

Best,
Reinhard
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog 
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29 
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08 
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+  * Acknoledge NMU.
+  * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler   Mon, 08 Apr 2019 17:58:31 -0400
+
 pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2017-05-29 
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2019-04-08 
17:58:31.0 -0400
@@ -1 +1,2 @@
 enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
--- 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
1969-12-31 19:00:00.0 -0500
+++ 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber 
+Date:   Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
 b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+   uint32_t Len;
+-  uint16_t wLenRsp=0;
+-  uint16_t wLenErr=0;
++  uint32_t wLenRsp=0;
++  uint32_t wLenErr=0;
+   if(ResponseLen!=0)
+-  wLenRsp=(uint16_t)*ResponseLen;
++  wLenRsp=*ResponseLen;
+   if(ApplicationErrorLength!=NULL)
+-  wLenErr=(uint16_t)*ApplicationErrorLength;
+-  if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++  wLenErr=*ApplicationErrorLength;
++  Len=4+wLenRsp+wLenErr;
++  if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++  return CJ_ERR_WRONG_PARAMETER;
+ 
+   
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+   {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+   *ApplicationErrorLength=0;
+   return Res;
+   }
+-  memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+-  wLenRsp=ReaderToHostShort(wLenRsp);
+-  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+-  wLenErr=ReaderToHostShort(wLenErr);
++
++  uint16_t wLenRsp16 = 0;
++  uint16_t wLenErr16 = 0;
++  memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++  wLenRsp=ReaderToHostShort(wLenRsp16);
++  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++  wLenErr=ReaderToHostShort(wLenErr16);
++
+   if(ApplicationErrorLength)
+   {
+   if(wLenErr>*ApplicationErrorLength)

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

>
> On Mon, Jan 7, 2019, 16:58 Chris Wilson >
>>> Hi Reinhard,
>>>
>>> If I make the workaround suggested on this thread
>>>  (change
>>> SECLEVEL to 1 in /etc/ssl/openssl.cnf) then test/basicserver passes again.
>>> This is at least a good start, so that users who don't want to replace
>>> their certificates have a workaround. I think I'll need to modify the CA
>>> scripts that generate certificates so that they produce 2048-bit keys that
>>> do not need this workaround, and document it or catch and improve the error
>>> message.
>>>
>>>
Any progress on updating the CA scripts that generate certificates so that
they produce 2048-bit keys?

I've updated the package to git20180819.g2f5b556, but am still experiencing
a test failure:

make[1]: Leaving directory '/<>/test/basicserver'
TEST: test/basicserver
Killing any running daemons...
Removing old test files...
chmod: cannot access 'testfiles': No such file or directory
Copying new test files...
NOTICE:  Running test basicserver in debug mode...
INFO:Starting server: ./_test --test-daemon-args= srv1
testfiles/srv1.conf
Waiting for server to die (pid 16575): . done.
INFO:Starting server: ./_test --test-daemon-args= srv2
testfiles/srv2.conf
Waiting for server to die (pid 16579): . done.
INFO:Starting server: ./_test --test-daemon-args= srv3
testfiles/srv3.conf
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:628
ERROR:    TEST FAILURE: Condition [HUPServer(pid)] failed at
test/basicserver/testbasicserver.cpp:631
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:633
ERROR:   SSL or crypto error: loading certificates from
testfiles/clientCerts.pem: error:140AB18F:SSL
routines:SSL_CTX_use_certificate:ee key too small
WARNING: Exception thrown: ServerException(TLSLoadCertificatesFailed) at
lib/server/TLSContext.cpp(93)
FAILED: Exception caught: TLSLoadCertificatesFailed



-- 
regards,
Reinhard

Bug#893227: libbluray FTBFS with openjdk-9

[Reinhard Tartler]

Hi Adrian,

On Wed, Jan 23, 2019 at 12:54 PM Adrian Bunk  wrote:

> Due to popcon (and reverse dependencies) libbluray is a key package
> that won't be autoremoved (otherwise it would have been autoremoved
> from buster 9 months ago).
>

That's good to know, thanks for pointing it out.


> A lowered severity only hides the problem, and the later it gets brought
> up the fewer changes are permitted for fixing - until the end of February
> you could even upload a new upstream version, but after that it will be
> unlikely that this will be approved by the release team.
>

Well, the question is whether a new upstream version becomes
available in time. The current version does simply not work
at all with OpenJDK11. Given that we need a new upstream release,
which I expect to introduce significant changes, we may run
into trouble with qualifying for a "soft-freeze" update. It
seems safer to upload (and test, i.e., have it migrated to testing),
way before Feb 12 2019.

The libbluray-bdj binary package has no reverse dependencies,
> so removing it might be a Plan B if no better option would
> be available.
>

I just looked at the code, and it doesn't look like it is
possible to build it without OpenJDK-8 at all. There are files
unconditionally built that #include .

You might be suggesting to use OpenJDK-8 to build, but "simply"
not ship the libbluray-bdj package. That would effectively
drop support for BD menus from Debian, which is why I wouldn't
consider this as a viable plan B.

-- 
regards,
Reinhard

Bug#893227: libbluray FTBFS with openjdk-9

[Reinhard Tartler]

Control: severity -1 important

On Tue, Jan 22, 2019 at 7:48 AM Emmanuel Bourg  wrote:

> OpenJDK 8 will be kept in Buster but it should be used in exceptional
> cases (for example the lombok package requires both OpenJDK 8 and 11 to
> build). The default Java runtime for Buster is OpenJDK 11 and the
> packages have to work properly with it.
>

Thank you for this clarification. I agree that we should switch
to OpenJDK 11 as soon as there is an upstream version available
that allows this.

Since openjdk-8 is going to be kept in Buster, I don't think
we need to keep this bug at RC severity. I'm concerned that keeping
this bug at RC severity might risk having libbluray being removed
from testing, which I don't think is in the best interest of our
users.


-- 
regards,
Reinhard

Bug#893227: libbluray FTBFS with openjdk-9

[Reinhard Tartler]

Hi Petri,

The schedule for Debian can be seen at https://wiki.debian.org/DebianBuster:

   -

   2014-11-09: Distribution codename announced
   <https://lists.debian.org/debian-devel-announce/2014/11/msg5.html>
   -

   2017-06-17: Stretch <https://wiki.debian.org/DebianStretch> is released,
   and buster becomes testing <https://wiki.debian.org/DebianTesting>
   -

   2019-01-12: Transition freeze (announced
   <https://release.debian.org/buster/freeze_policy.html>)
   - 2019-02-12: Soft freeze
   - 2019-03-12: Full freeze

So assuming the new libblueray doesn't require changes in
depending packages we have until Feburary 12 to upload (AND TEST)
an updated package.

Hi Emmanuel,

You may or may not remember, the Debian Multimedia team has been
asked earlier last year to look into getting libbluray to work
with newer JDKs. There is some progress, but apparently we are
just not quite there yet, please see Petri's message below.

Can you please give us an update on the roadmap for Java?
What's the status on removing openjdk-8 from buster?

Best,
-rt

On Tue, Jan 22, 2019 at 3:02 AM Petri Hintukainen 
wrote:

> Hello,
>
> On Wed, Jan 16, 2019 at 7:14 AM Reinhard Tartler wrote:
> > Looking at the commit history, it seems that there have been some
> > changes wrt java
> > compatibility, mostly by you. I wonder whether you'd expect libbluray
> > to work with
> > openjdk-11. If not, is this something on your roadmap, or do you
> > consider this a
> > stretch goal for the forseeable future?
>
> Build issues should be fixed in git. OpenJDK 11 can be used to build
> the package, and resulting Java binary code is compatible with OpenJDK
> 6...11.
>
> There are still few runtime issues, so libbluray does not try to load
> JVM 9 ... 11 yet. But these remaining issues are more or less trivial,
> and just need some testing.
>
> I've switched to use OpenJDK 11. OpenJDK 9 and 10 are still more or
> less untested, but 11 seems more important version to support.
>
> What kind of schedule do you have ? We could have libbluray release
> with OpenJDK 11 support in couple of weeks. Even earlier if we fix the
> remaining issues and OpenJDK 9/10 issues in later releases. Anyway, I'd
> expect some new issues when people start using libbluray with OpenJDK
> 9..11.
>
> - Petri
>
>
>

-- 
regards,
Reinhard

Bug#893227: libbluray FTBFS with openjdk-9

[Reinhard Tartler]

Hi Petri,

I'm following up on a question that Sebatian (CC'ed) asked on the mailing
list last march [1].
The issue is that Debian intends to drop openjdk-8 in favor of openjdk-11,
and we as package
maintainers of libbluray are asked to look into this transition. Your
response back then
was that there are non-trivial changes to the code necessary to make this
work.

Looking at the commit history, it seems that there have been some changes
wrt java
compatibility, mostly by you. I wonder whether you'd expect libbluray to
work with
openjdk-11. If not, is this something on your roadmap, or do you consider
this a
stretch goal for the forseeable future?

Please let me know what your thoughts on this issue are..

Best,
-rt

[1]
https://mailman.videolan.org/pipermail/libbluray-devel/2018-March/002890.html

On Sat, Mar 17, 2018 at 9:15 AM Adrian Bunk  wrote:

> Source: libbluray
> Version: 1:1.0.2-2
> Severity: serious
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libbluray.html
>
> ...
>
> compile:
> [javac] /build/1st/libbluray-1.0.2/src/libbluray/bdj/build.xml:24:
> warning: 'includeantruntime' was not set, defaulting to
> build.sysclasspath=last; set to false for repeatable builds
> [javac] Using javac -source 1.4 is no longer supported, switching to
> 1.6
> [javac] Using javac -target 1.4 is no longer supported, switching to
> 1.6
> [javac] Compiling 664 source files to
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/build
> [javac] warning: [options] bootstrap class path not set in conjunction
> with -source 1.6
> [javac] warning: [options] source value 1.6 is obsolete and will be
> removed in a future release
> [javac] warning: [options] target value 1.6 is obsolete and will be
> removed in a future release
> [javac] warning: [options] To suppress warnings about obsolete
> options, use -Xlint:-options.
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java-j2se/java/awt/peer/BDFramePeer.java:176:
> error: package sun.awt.CausedFocusEvent does not exist
> [javac] public boolean requestFocus(Component c, boolean a,
> boolean b, long l, sun.awt.CausedFocusEvent.Cause d) {
> [javac]
> ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/blurayx/s3d/ti/StereoscopicCodingType.java:37:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] type =
> (CodingType)constructor.newInstance(new String[] { "MPEG4_MVC_VIDEO" });
> [javac]
> ^
> [javac]   cast to Object for a varargs call
> [javac]   cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/blurayx/uhd/ti/UHDCodingType.java:38:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] type =
> (CodingType)constructor.newInstance(new String[] { "HEVC_VIDEO" });
> [javac]
> ^
> [javac]   cast to Object for a varargs call
> [javac]   cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:81:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if
> (classDepth("javax.crypto.JceSecurityManager") < 3) {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:88:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if (classDepth("org.videolan.Libbluray") == 3)
> {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:97:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if (classDepth("sun.awt.AWTAutoShutdown") > 0) {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:222:
> warning: [removal] checkSystemClipboardAccess() in SecurityManager has been
> deprecated and marked for removal
> [javac] public void checkSystemClipboardAccess() {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java-j2se/java/io/BDFileSystemImpl.java:21:
> error: BDFileSystemImpl is not abstract and does not override abstract
> method getNameMax(String) in FileSystem
> [javac] class BDFileSystemImpl extends BDFileSystem {
> [javac] ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] Note: Some input files use unchecked or unsafe 

Bug#909032: Additional build failures

[Reinhard Tartler]

Seems that additional issues have shown up:

dh_auto_configure
make[1]: Leaving directory '/<>/cadvisor-0.27.1+dfsg2'
   dh_auto_build -a -O--buildsystem=golang -O--builddirectory=_build
cd _build && go install 
-gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" 
-asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v 
-p 4 github.com/google/cadvisor github.com/google/cadvisor/api 
github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory 
github.com/google/cadvisor/client 
github.com/google/cadvisor/client/clientexample 
github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector 
github.com/google/cadvisor/container 
github.com/google/cadvisor/container/common 
github.com/google/cadvisor/container/crio 
github.com/google/cadvisor/container/docker 
github.com/google/cadvisor/container/libcontainer 
github.com/google/cadvisor/container/raw 
github.com/google/cadvisor/container/rkt 
github.com/google/cadvisor/container/systemd 
github.com/google/cadvisor/container/testing 
github.com/google/cadvisor/devicemapper 
github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events 
github.com/google/c
 advisor/fs github.com/google/cadvisor/healthz github.com/google/cadvisor/http 
github.com/google/cadvisor/http/mux github.com/google/cadvisor/info/v1 
github.com/google/cadvisor/info/v1/test github.com/google/cadvisor/info/v2 
github.com/google/cadvisor/integration/framework 
github.com/google/cadvisor/integration/runner 
github.com/google/cadvisor/integration/tests/api 
github.com/google/cadvisor/integration/tests/healthz 
github.com/google/cadvisor/machine github.com/google/cadvisor/manager 
github.com/google/cadvisor/manager/watcher 
github.com/google/cadvisor/manager/watcher/raw 
github.com/google/cadvisor/manager/watcher/rkt 
github.com/google/cadvisor/metrics github.com/google/cadvisor/pages 
github.com/google/cadvisor/pages/static github.com/google/cadvisor/storage 
github.com/google/cadvisor/storage/bigquery 
github.com/google/cadvisor/storage/bigquery/client 
github.com/google/cadvisor/storage/bigquery/client/example 
github.com/google/cadvisor/storage/elasticsearch github.com/google/cadvi
 sor/storage/influxdb github.com/google/cadvisor/storage/kafka 
github.com/google/cadvisor/storage/redis 
github.com/google/cadvisor/storage/statsd 
github.com/google/cadvisor/storage/statsd/client 
github.com/google/cadvisor/storage/stdout 
github.com/google/cadvisor/storage/test github.com/google/cadvisor/summary 
github.com/google/cadvisor/utils github.com/google/cadvisor/utils/cloudinfo 
github.com/google/cadvisor/utils/container 
github.com/google/cadvisor/utils/cpuload 
github.com/google/cadvisor/utils/cpuload/netlink 
github.com/google/cadvisor/utils/cpuload/netlink/example 
github.com/google/cadvisor/utils/docker 
github.com/google/cadvisor/utils/oomparser 
github.com/google/cadvisor/utils/oomparser/oomexample 
github.com/google/cadvisor/utils/procfs github.com/google/cadvisor/utils/sysfs 
github.com/google/cadvisor/utils/sysfs/fakesysfs 
github.com/google/cadvisor/utils/sysinfo github.com/google/cadvisor/utils/tail 
github.com/google/cadvisor/validate github.com/google/cadvisor/version githu
 b.com/google/cadvisor/zfs
src/github.com/google/cadvisor/container/common/inotify_watcher.go:20:2: cannot 
find package "golang.org/x/exp/inotify" in any of:

/<>/cadvisor-0.27.1+dfsg2/_build/src/github.com/google/cadvisor/vendor/golang.org/x/exp/inotify
 (vendor tree)
/usr/lib/go-1.11/src/golang.org/x/exp/inotify (from $GOROOT)
/<>/cadvisor-0.27.1+dfsg2/_build/src/golang.org/x/exp/inotify 
(from $GOPATH)
dh_auto_build: cd _build && go install 
-gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" 
-asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v 
-p 4 github.com/google/cadvisor github.com/google/cadvisor/api 
github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory 
github.com/google/cadvisor/client 
github.com/google/cadvisor/client/clientexample 
github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector 
github.com/google/cadvisor/container 
github.com/google/cadvisor/container/common 
github.com/google/cadvisor/container/crio 
github.com/google/cadvisor/container/docker 
github.com/google/cadvisor/container/libcontainer 
github.com/google/cadvisor/container/raw 
github.com/google/cadvisor/container/rkt 
github.com/google/cadvisor/container/systemd 
github.com/google/cadvisor/container/testing 
github.com/google/cadvisor/devicemapper 
github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events 
githu
 b.com/google/cadvisor/fs github.com/google/cadvisor/healthz 
github.com/google/cadvisor/http github.com/google/cadvisor/http/mux 
github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test 
github.com/google/cadvisor/info/v2 
github.com/google/cadvisor/integration/framework 
github.com/google/cadvisor/integration/runner 

Bug#890024: npapi-vlc: upcoming Firefox ESR dropping support for NPAPI

[Reinhard Tartler]

I agree that it's time to have the package npapi-vlc removed from unstable.

Let's proceed with the RM bug.

Bug#902220: Needs porting to LLVM 6.0.1

[Reinhard Tartler]

Control: retitle -1 Needs porting to LLVM 6.0.1

Well, I just checked, even the latest trunk does not support LLVM 6.0.1. 
Or rather, it builds (with some minor, obvious modifications), but 
doesn't work. I haven't tested LLVM 6.0.0, it may or may not work.



This needs to be looked into more.


-rt

Bug#902220: Processed: reopening 902220

[Reinhard Tartler]

On 08/29/2018 08:24 AM, Adrian Bunk wrote:
> AspectC++ upstream code already seems to support LLVM 6 (untested).

That's contradictory to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906972#10

This needs to be looked into more.

Also, why do you need to have this bug at severity serious? If llvm-4.0 was 
removed from testing, that would prevent packages such as aspectc++ from 
migrating as well?

-rt 

Bug#902220: Processed: reopening 902220

[Reinhard Tartler]

Control: severity -1 normal

Hi Adrian,

Thanks for your bug maintenance work, much appreciated!

On 08/28/2018 08:27 PM, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
>> reopen 902220
> Bug #902220 {Done: Reinhard Tartler } [aspectc++] 
> aspect++: Please use llvm-dev instead of llvm-4.0-dev


Are you sure about the severity "serious" of this bug? AspectC++ still needs 
porting to llvm-6.0 and won't build right now. llvm-4.0-dev is still in testing 
at this point. Please provide a reference to the llvm upgrade timeline that I 
could share with upstream.

Best,
-rt

Bug#870233: smplayer: executes javascript code downloaded from insecure URL

[Reinhard Tartler]

​Sorry, I messed up Ricardo's email address in my previous follow-up, so
his reply went to me only. I'm quoting his input with his permission:

​Older versions of SMPlayer downloaded a javascript function from
> http://updates.smplayer.info/yt.js in order to decrypt a signature,
> which it's necessary to play some Youtube videos (mostly music
> videos). Newer versions don't do it anymore because now SMPlayer
> downloads the original function from a Youtube page. If you consider
> this to be also insecure, you can disable it by commenting the line
> DEFINES += YT_USE_SIG in smplayer.pro.


It seems that I confused the define YT_USE_SIG (which is still enabled)
with the define YT_USE_*YT*SIG (which is currently commented out in
smplayer.pro). My bad, sorry. I'll add a patch to the debian packaging that
disables that shortly.

I'm also happy to upload it as soon as I hear back from Mateusz regarding
my question(s) about mongoose.

Thanks everyone!

-- 
regards,
Reinhard

Bug#870233: smplayer: executes javascript code downloaded from insecure URL

[Reinhard Tartler]

On Sun, Jun 3, 2018 at 9:36 PM Jonas Smedegaard  wrote:
>
> Hi Reinhard,
>
> Excerpts from Reinhard Tartler's message of juni 3, 2018 10:48 pm:
> > On Mon, Jul 31, 2017 at 1:48 AM Jonas Smedegaard  wrote:
> >> smplayer includes code in src/basegui.cpp to download and (I guess)
> >> execute javascript code for parsing youtube paths.  The download URL
> >> is http://updates.smplayer.info/yt.js which is insecure and therefore
> >> I suspect easy to replace with evil code.
> >
> > Apparently, this was already fixed upstream quite some time ago in
> > package version 17.11.2~ds0-1 without mentioning this in
> > debian/changelog. I'm therefore closing this bug manually.
>
> Sorry, but I don't see any such change, and it seems the problematic
> code is still there:
>
>
> $ git grep updates.smplayer.info
> src/links.h:#define URL_YT_CODE "http://updates.smplayer.info/yt.js;
> src/links.h:#define URL_VERSION_INFO
> "http://updates.smplayer.info/version_info.ini;
>
>
> $ grep -C5 URL_YT_CODE src/basegui.cpp
> void BaseGui::YTUpdateScript() {
> static CodeDownloader * downloader = 0;
> if (!downloader) downloader = new CodeDownloader(this);
> downloader->saveAs(Paths::configPath() + "/yt.js");
> downloader->show();
> downloader->download(QUrl(URL_YT_CODE));
> }
> #endif // YT_USE_YTSIG
> #endif //YOUTUBE_SUPPORT
>
> void BaseGui::gotForbidden() {
>
>
> Could you perhaps reference the git commit you believe fixed this?

>From Matteusz' patch 2831d03e5e7cbb9328469ad92e0fea8ec19ee943 in the
'stretch' branch (unfortunately not uploaded to salsa yet, Matteusz,
do you happen to have the jessie and stretch branches available on
your computer? If so, please kindly upload them to salsa - I found it
in my mail archive), I conclude that in order to solve the issue, we
need to make sure that the define YT_USE_YTSIG is not set:


diff --git a/debian/patches/07-fixyoutube.patch
b/debian/patches/07-fixyoutube.patch
index b968a03..78d3fe5 100644
--- a/debian/patches/07-fixyoutube.patch
+++ b/debian/patches/07-fixyoutube.patch
@@ -1,5 +1,6 @@
 Description: Fix connections to youtube.
 Bug-Debian: http://bugs.debian.org/869411
+Author: Ricardo Villalba 

 --- a/src/youtube/sig.cpp
 +++ b/src/youtube/sig.cpp
diff --git a/debian/patches/08-870233.patch b/debian/patches/08-870233.patch
new file mode 100644
index 000..d6a0975
--- /dev/null
+++ b/debian/patches/08-870233.patch
@@ -0,0 +1,16 @@
+Description: Disable executes javascript code downloaded from insecure URL
+Author: Mateusz Łukasik 
+Bug-Debian: https://bugs.debian.org/870233
+Last-Update: 2017-07-31
+
+--- a/src/smplayer.pro
 b/src/smplayer.pro
+@@ -439,7 +439,7 @@ contains( DEFINES, YOUTUBE_SUPPORT ) {
+
+   contains( DEFINES, YT_USE_SCRIPT ) {
+   DEFINES += YT_USE_SIG
+-  DEFINES += YT_USE_YTSIG
++  #DEFINES += YT_USE_YTSIG
+   QT += script
+   }
+


This is done as per upstream version 17.11.2 and that's why I have
closed the bug with that version. It appears to me that undefining
URL_YT_CODE disables more functionality than strictly necessary, but I
may be misreading the code. In any case, comments on this are more
than welcome. I'd also appreciate comments from Richardo, who is
listed as the author of the patch.

Jonas, do you have reason to believe that the bug is still present in
the 18.2.2 (the version that is currently in unstable)? If so, please
elaborate.

Best,
Reinhard

Bug#898943: Multiple vulnerabiliities in Mongoose

[Reinhard Tartler]

On Thu, Jun 7, 2018 at 6:20 AM Mateusz Łukasik  wrote:

> This is not fixed for me. I made patch with add latest Mongoose version
> which included fixed for all of this cve's.
> It pushed now to salsa.
>
> --

Thank you!

I see that you've added
https://salsa.debian.org/multimedia-team/smplayer/blob/master/debian/patches/03-update-mongoose-to-6.11.patch
- which is a pretty big patch. I wouldn't know how to test it (I don't
use that feature) or even verify that the patch work. Matteusz, can
you please elaborate how you verified the patch  and how confident are
you that it doesn't introduce unwanted side-effects?

Ricardo, would that patch be acceptable for upstream inclusion? - Your
opinion is highly valued and would be helpful in forming an opinion on
Mateusz' patch.

Mateusz, I also see that you prepared a new upstream version. That's
great, in fact, I've also prepared it locally to see if the issue
happened to be fixed upstream, but determined mongosse was not updated
and concluded the problem still persists. I've therefore decided to
not upload the new upstream version and focus on the existing issues
instead. Hence, I've applied the patch to disable the build of
mongoose in the present package version. I see that you disabled it in
https://salsa.debian.org/multimedia-team/smplayer/commit/5d780999b6ee7a84d737fdb5dbc07ea9a25e4cde
(the commit message didn't help with finding that SHA1, I'd appreciate
more accurate messages in the future) - which is fine by me *if* we
are confident that the mongoose update actually fixes the problem (see
my question above).

Also, did you verify that the new mongoose patch builds with GCC-8? My
patch to disable mongoose takes care of that as well, it would be a
shame to reintroduce #897863 again.

-- 
regards,
Reinhard