Bug#1033839: Packaging docker 24.0.9

That's a little bit of a separate concern from what I was talking about (Moby own versions vs code dependencies). In short, no, the upstream project does not currently have any "LTS" branches (and never really had anything *super* long term outside of the enterprise edition that wasn't open

Bug#1033839: Packaging docker 24.0.9

For the dependencies, I'd probably suggest attempting to parse https://github.com/moby/moby/blob/v24.0.9/vendor.mod into a list of versioned Depends: directly, since those aren't likely to be bumped upstream "willy nilly" (and IMO that would make it easier to determine which things need to be

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

On Mon, 6 May 2024 at 17:00, Cyril Brulebois wrote: > I'm adding Tianon to the loop explicitly since I'm definitely no Docker > (or Go) expert, in case some time can be spared to look into this > problem. Otherwise I'll try and come up with something. I think the backport by Reinhard[1][2] is

Bug#1060083: cgroupfs-mount: diff for NMU version 1.4+nmu1

On Sun, 21 Apr 2024 at 17:03, Chris Hofstaedtler wrote: > I've prepared an NMU for cgroupfs-mount (versioned as 1.4+nmu1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. Sorry for the delay in getting to this! Your NMU looks sane, thank you! ♥, -

Bug#1064447: debuerreotype: ineffective diversions (due to /usr-merge DEP17) for obsolete upstart files

On Thu, 22 Feb 2024 at 08:53, Helmut Grohne wrote: > On Thu, Feb 22, 2024 at 08:26:16AM -0800, Tianon Gravi wrote: > > It is precisely those older versions that the code still exists for -- > > I use debuerreotype for creating reproducible rootfs builds all the > &

Bug#1064447: debuerreotype: ineffective diversions (due to /usr-merge DEP17) for obsolete upstart files

On Thu, 22 Feb 2024 at 01:48, Helmut Grohne wrote: > debuerreotype diverts /sbin/initctl. This file is part of upstart, which > has been deleted from Debian since at least bullseye. If it still were > part of Debian, we'd have to move the file and hence this diversion > would become ineffective.

Bug#1047224: python-astor: Fails to build source after successful build

On Thu, 21 Sept 2023 at 09:31, Lucas Nussbaum wrote: > Yes, it was closed on Sept 7th (I retried all packages to close bugs > fixed by the above change). > I'm not sure how you ran into it? Did I mess up something while > mass-closing? Doh, no, sorry; that's gonna be my bad. I had the two bug

Bug#1047435: python-sh: Fails to build source after successful build

On Sun, 13 Aug 2023 at 15:13, Lucas Nussbaum wrote: > > dpkg-source: info: local changes detected, the modified files are: > > python-sh-1.14.2/sh.egg-info/PKG-INFO > > python-sh-1.14.2/sh.egg-info/SOURCES.txt > > python-sh-1.14.2/sh.egg-info/dependency_links.txt > >

Bug#1047224: python-astor: Fails to build source after successful build

On Sun, 13 Aug 2023 at 14:59, Lucas Nussbaum wrote: > > dpkg-source: info: local changes detected, the modified files are: > > python-astor-0.8.1/astor.egg-info/PKG-INFO > > dpkg-source: error: aborting due to unexpected upstream changes, see > > /tmp/python-astor_0.8.1-4.diff.StEqUF This

Bug#1040507: golang-1.21-go: downloads and runs binaries from the Internet without permission

On Thu, 6 Jul 2023 at 14:39, brian m. carlson wrote: > Go 1.21 provides the `GOTOOLCHAIN` environment variable and associated > functionality[0]. As part of this code, if go.mod indicates that a > newer version of Go is required than the current toolchain supports, it > proceeds by default to

Bug#1038149: libmemcached-dev missing depends (recommends?) on libssl-dev for libcrypto.pc

On Thu, 15 Jun 2023 at 16:12, Tianon Gravi wrote: > When running `pkg-config --exists libmemcached` after installing > libmemcached-dev, it returns a non-zero exit code. When I run strace on > it, I can see that it's looking for libcrypto.pc. Feeling sheepish that I used "strace&

Bug#1038149: libmemcached-dev missing depends (recommends?) on libssl-dev for libcrypto.pc

Package: libmemcached-dev Version: 1.1.4-1 Severity: normal X-Debbugs-Cc: tia...@debian.org Dear Maintainer, When running `pkg-config --exists libmemcached` after installing libmemcached-dev, it returns a non-zero exit code. When I run strace on it, I can see that it's looking for libcrypto.pc.

Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion

On Fri, 5 May 2023 at 10:06, Askar Safin wrote: > Current apt behavior also breaks official debian docker images, I > reported this here: > https://github.com/debuerreotype/debuerreotype/pull/153 . The images' > developer said this is apt completion scripts' problem To be clear, there was

Bug#1034886: docker.io: CVE-2022-37708

On Tue, 2 May 2023 at 16:25, Tianon Gravi wrote: > > I have talked to Tianon on 2023-02-28, and we concluded that it's not > > a security issue, just working as expected. > > > > Tianon said he will ask someone inside the Docker company. Not sure if > > they have suc

Bug#1034886: docker.io: CVE-2022-37708

On Wed, 26 Apr 2023 at 13:21, Shengjing Zhu wrote: > On Thu, Apr 27, 2023 at 1:39 AM Moritz Mühlenhoff wrote: > > > > Source: docker.io > > X-Debbugs-CC: t...@security.debian.org > > Severity: important > > Tags: security > > > > Hi, > > > > The following vulnerability was published for

Bug#986207: snapshot.debian.org: "debian-archive/.../debian-security/" is missing "wheezy"

On Wed, 31 Mar 2021 at 08:57, Tianon Gravi wrote: > It would appear that archive.debian.org hasn't been snapshotted since > 2019-03-28 10:54:44, but it has changed since then. The notable change > that caused me to notice was that [0] seems to be missing wheezy, even > though [1]

Bug#1022854: Bug#1030751: debuerreotype: diff for NMU version 0.15-1.1

On Wed, 8 Feb 2023 at 00:06, Adrian Bunk wrote: > The urgency is the freeze deadline, I am currently going through > packages that would miss bookworm if they aren't fixed. Thank you for explaining! I don't love disabling the test just for transition, but I suppose it's reasonable. I've

Bug#1030751: debuerreotype: diff for NMU version 0.15-1.1

On Tue, 7 Feb 2023 at 09:15, Tianon Gravi wrote: > On Tue, 7 Feb 2023 at 01:33, Adrian Bunk wrote: > > Package: debuerreotype > > Version: 0.15-1 > > Severity: normal > > Tags: patch pending > > > > Dear maintainer, > > > > I've prepa

Bug#1022854: Bug#1030751: debuerreotype: diff for NMU version 0.15-1.1

On Tue, 7 Feb 2023 at 01:33, Adrian Bunk wrote: > Package: debuerreotype > Version: 0.15-1 > Severity: normal > Tags: patch pending > > Dear maintainer, > > I've prepared an NMU for debuerreotype (versioned as 0.15-1.1) and > uploaded it to DELAYED/1. Please feel free to tell me if I should >

Bug#1027114: docker.io: FTBFS: daemon/graphdriver/btrfs/btrfs.go:437:11: args.lim.max_referenced undefined (type _Ctype_struct_btrfs_qgroup_limit has no field or method max_referenced)

On Tue, 27 Dec 2022, 15:18 Sebastian Ramacher, wrote: > ---> Making bundle: dynbinary (in bundles/dynbinary) > Building: bundles/dynbinary-daemon/dockerd-20.10.21+dfsg1 > GOOS="" GOARCH="" GOARM="" > # github.com/docker/docker/daemon/graphdriver/btrfs > daemon/graphdriver/btrfs/btrfs.go:437:11:

Bug#1022854: debuerreotype: autopkgtest rebuilds with different toolchain and expects the same result

On Fri, 28 Oct 2022 at 10:42, Luca Boccassi wrote: > (18:32:13) bluca: the debuerrotype maintainer explicitly asked not to, > and instead to ask for a migration hint > (18:32:46) elbrus: we'll not do that > (18:32:58) elbrus: as the autopkgtest regression in testing is RC Sorry, this was my

Bug#1022854: debuerreotype: autopkgtest rebuilds with different toolchain and expects the same result

On Wed, 26 Oct 2022 at 16:03, Tianon Gravi wrote: > On Wed, 26 Oct 2022 at 14:54, Luca Boccassi wrote: > > It seems debuerreotype has an autopkgtest that rebuilds Stretch with a > > new toolchain, compares it to a fixed version and fails if it doesn't > > match. But I d

Bug#1022854: debuerreotype: autopkgtest rebuilds with different toolchain and expects the same result

On Wed, 26 Oct 2022 at 14:54, Luca Boccassi wrote: > It seems debuerreotype has an autopkgtest that rebuilds Stretch with a > new toolchain, compares it to a fixed version and fails if it doesn't > match. But I don't see how this can be supported - if the toolchain > changes, then the result is

Bug#1020085: python-astor: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

forwarded 1020085 https://github.com/berkerpeksag/astor/issues/212 thanks On Sat, 17 Sept 2022 at 23:45, Lucas Nussbaum wrote: > > p = <[ValueError('Exceeds the limit (4300) for integer string conversion') > > raised in repr()] int object at 0x556a03b67200> > > imaginary = False > > > > def

Bug#1013726: python-astor: FTBFS: pytest7 regression, deprecated pytest feature: -k-

On Fri, 24 Jun 2022 at 15:57, Louis-Philippe Véronneau wrote: > I had a closer look at the error log and identified the regression as: > 'deprecated pytest feature: -k-'. Hopefully, that's helpful! Thanks! I've updated Git with a fix now (`-k 'not ...'`), but I'm not sure when I'll have a

Bug#1010091: Debian riscv64 unstable dockerhub image - libxml2 depends.

On Sun, 24 Apr 2022 at 02:24, Radim Kohout wrote: > Package: docker Unfortunately, this isn't really filed in the right place -- this is the bug tracker for https://tracker.debian.org/pkg/docker which is an old WindowMaker app. >From https://hub.docker.com/_/debian, what you're looking for is

Bug#1009857: python3-hy: 'hy' fails to start

On Tue, 19 Apr 2022 at 03:30, IOhannes m zmölnig wrote: > $ hy3 > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/hy/compiler.py", line 1696, in > compile_eval_and_compile > hy_eval(new_expr + body, > File "/usr/lib/python3/dist-packages/hy/compiler.py", line

Bug#1006012: ITP: golang-github-aws-aws-sdk-go -- AWS SDK for the Go programming language.

On Fri, 18 Feb 2022 at 14:30, Benedikt Wildenhain wrote: > * Package name: golang-github-aws-aws-sdk-go > Version : 1.43.1-1 > Upstream Author : Amazon Web Services > * URL : https://github.com/aws/aws-sdk-go > * License : Apache-2.0 > Programming Lang: Go >

Bug#1002344: hy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

On Wed, 22 Dec 2021 at 00:04, Lucas Nussbaum wrote: > Source: hy > Version: 0.19.0-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20211220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

tags 995623 + pending thanks On Sat, 23 Oct 2021 at 07:25, Rod Smith wrote: > > I've fixed this problem with commit 10f838: > > https://sourceforge.net/p/refind/code/commit_browser > > You should be able to cherry-pick that, although changes to NEWS.txt and > include/version.h might need to be

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

On Tue, 19 Oct 2021 at 17:07, Tianon Gravi wrote: > > Hey Rod, this is an interesting one -- looking at the definitions of > the "EFI_DEVICE_PATH_UTILITIES_PROTOCOL" typedef in both refind's code > and grub-efi's, they appear to be compatible to me (which makes sense, > probab

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

Hey Rod, this is an interesting one -- looking at the definitions of the "EFI_DEVICE_PATH_UTILITIES_PROTOCOL" typedef in both refind's code and grub-efi's, they appear to be compatible to me (which makes sense, probably from the same original source?) Is this something you plan to resolve in

Bug#995225: docker: Docker package should depend or at least recommend cgroupfs-mount

reassign 995225 docker.io fixed 995225 0.9.1~dfsg1-1 thanks On Tue, 28 Sept 2021 at 00:45, Andrius Narbutas wrote: > Package: docker > Version: 1.5-2 > Severity: normal As seen in my control bits above, you've got the wrong Docker, unfortunately. I've reassigned the bug appropriately from the

Bug#994950: Command not found after installation

severity 994950 wishlist thanks On Thu, 23 Sept 2021 at 11:12, Abraham Raji wrote: > avronr@alucard:~$ debootstrap > bash: debootstrap: command not found The "debootstrap" command gets installed into "/usr/sbin" so you'll need to either add that to your PATH, use an explicit full path

Bug#991718: u-boot-sifive: only 8GB RAM visible on Sifive Unmatched

On Sat, 7 Aug 2021 at 08:03, Adam Borowski wrote: > On Thu, Aug 05, 2021 at 12:26:57PM -0700, Tianon Gravi wrote: > > > On 2021-07-30, Adam Borowski wrote: > > > > The Unmatched has 16GB memory -- which works fine with the vendor u-boot > > > > it shipped

Bug#991945: refind: debian netinst (bullseye): refind fails to install

On Fri, 6 Aug 2021 at 06:42, Marc Leeman wrote: > I am using refind with an netinst installer. Since bullseye this seems > broken because sysfs/efivarfs is no longer mounted by default in the > target and efibootmgr fails > > I've tested this patch on my side (simply trying to mount sys/efivarfs

Bug#991718: u-boot-sifive: only 8GB RAM visible on Sifive Unmatched

On Fri, 30 Jul 2021 at 19:45, Vagrant Cascadian wrote: > > On 2021-07-30, Adam Borowski wrote: > > The Unmatched has 16GB memory -- which works fine with the vendor u-boot > > it shipped with. Alas, with Debian u-boot from experimental, only 8GB is > > visible (at

Bug#989917: docker.io: docker "buildx" not found

On Tue, 15 Jun 2021 at 15:50, Elana Hashman wrote: > I can't find any patches or files under debian/copyright suggesting this > functionality was patched out of the docker.io package. That'd be because it's not actually part of Docker proper; it just happens to be part of the releases Docker,

Bug#989781: docker.io: Docker fails to run containers because it unsuccessfully tries to load an AppArmor profile

On Sat, 12 Jun 2021 at 15:33, Lars Veldscholte wrote: > I am not sure of the proper way to deal with this issue. Should I > install the AppArmor userspace utilities, even though I do not need them > myself? Or should I disable AppArmor completely by explicity setting a > kernel parameter (which

Bug#985481: debootstrap: Detection of docker container is broken with cgroup v2

Hey Arnaud, thanks for the CC (and sorry for the delay). On Mon, 12 Apr 2021 at 20:48, Arnaud Rebillout wrote: > > Originally, ".dockerenv" was for transmitting the environment > > variables of the container across the container boundary -- I would > > not recommend relying on its existence

Bug#986207: snapshot.debian.org: "debian-archive/.../debian-security/" is missing "wheezy"

Package: snapshot.debian.org Severity: normal It would appear that archive.debian.org hasn't been snapshotted since 2019-03-28 10:54:44, but it has changed since then. The notable change that caused me to notice was that [0] seems to be missing wheezy, even though [1] does include it (folder

Bug#985963: debuerreotype: uses debian-archive-keyring in autopkgtests without real dependency

tags 985963 + pending thanks On Fri, 26 Mar 2021 at 15:45, Gianfranco Costamagna wrote: > Hello, looks like the debian/tests/stretch is using the keyring but the > package has only a recommends on that dependency. > This makes the autopkgtest fail when apt is configured with >

Bug#983512: Bug#983513: debuerreotype: autopkgtest seems to hard-code amd64 signature

On Thu, 25 Feb 2021 at 12:09, Paul Gevers wrote: > On 25-02-2021 20:40, Tianon Gravi wrote: > > Hi Paul! Thanks for filing these -- I've pushed two commits to the > > Git repo which fix both 983512 and 983513 (and made it more forgiving > > of other architectures for the f

Bug#983512: Bug#983513: debuerreotype: autopkgtest seems to hard-code amd64 signature

On Thu, 25 Feb 2021 at 04:18, Paul Gevers wrote: > Your package has an autopkgtest, great. However, it always fails on > non-amd64 architectures. Looking at the error message, it seems to > compare the build tar ball with a pre-computed hash that's only valid on > amd64. (And then the log becomes

Bug#977066: hy FTBFS with pytest 6

On Thu, 10 Dec 2020 at 11:50, Christian Kastner wrote: > Thank you for taking care of this so quickly! > > The rebuild was successful :-) Awesome, love to see it! It was an easy one and my brain had some spare cycles to think through it. :) I'll get it uploaded to unstable Soon. ♥, - Tianon

Bug#977066: hy FTBFS with pytest 6

On Thu, 10 Dec 2020 at 10:57, Christian Kastner wrote: > hy FTBFS with pytest 6 in experimental because it uses removed > feature. The -k option no longer allows a minus "-" as negation, only > "not". See > > https://docs.pytest.org/en/stable/changelog.html#id60 Great find! I've just pushed

Bug#975230: [pkg-go] Bug#975230: golang-pault-go-ykpiv: FTBFS: src/pault.ag/go/ykpiv/ykpiv.go:539:12: _Ctype_struct_ykpiv_state can't be allocated in Go; it is incomplete (or unallocatable)

On Thu, 19 Nov 2020 at 02:01, Lucas Nussbaum wrote: > > src/pault.ag/go/ykpiv/ykpiv.go:539:12: _Ctype_struct_ykpiv_state can't be > > allocated in Go; it is incomplete (or unallocatable) > > src/pault.ag/go/ykpiv/ykpiv.go:569:11: _Ctype_struct_ykpiv_state can't be > > allocated in Go; it is

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

(Going to leave my own opinions on the underlying discussion here aside, but wanted to highlight/echo this bit:) On Wed, 18 Nov 2020 at 23:33, Josh Triplett wrote: > Any inclusion of work into a package necessitates *some* amount of > development and packaging resources by the maintainer of that

Bug#971789: FTBFS: Could not determine section for ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1

On Wed, 7 Oct 2020 at 02:09, Shengjing Zhu wrote: > Maybe due to the go-md2man v2 transition, docker.io is now FTBFS. > > dh_installman: warning: Section for > ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1 is computed as > "2020", which is not a valid section > dh_installman:

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

On Mon, 21 Sep 2020 at 13:48, wrote: > On Sun, Sep 20, 2020 at 09:58:45AM +0700, El boulangero wrote: > > Do you know what's special with the `tianon/true` image? On what OS/release > > is it based? > > It's an image that contains only a single binary that returns 0. That > binary uses no

Bug#970065: [pkg-go] Bug#970065: golang-pault-go-archive: bullseye: /updates -> -security

forwarded 970065 https://github.com/paultag/go-archive/pull/8 thanks ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4

Bug#847694: Bug #847694

On Fri, 8 Dec 2017 at 06:45, Roderick W. Smith wrote: > Running refind-install directly would produce more output, which might > be helpful; however, I'm 80% sure that this is a result of EFI > architecture limitations. Specifically, tools like efibootmgr, upon > which the refind-install script

Bug#948087: future of aufs in Debian.

On Wed, 27 May 2020 at 14:33, Noah Meyerhans wrote: > Docker no longer users aufs by default, though, having switched to > overlayfs some time ago. I'm sure we could get them to drop the > Recommends if we're considering getting rid of it. This is something I'd been considering for quite a

Bug#959446: debuerreotype: Consider additionally providing images on debian infrastructure

On Sat, 2 May 2020 at 06:24, Micah Anderson wrote: > I'm not sure that this is the right place to file this issue, but I was unable > to find a better place. Feel free to redirect to a more suitable place. I > talked > to the debian-cloud people and they didn't think that this was their purview.

Bug#960842: add -go wrappers and golang-go-for-host

On Sun, 17 May 2020 at 06:15, Helmut Grohne wrote: > For that reason, I'm attaching a patch that adds these go wrappers to > golang-defaults. It adds new binary packages golang-go- and a > package golang-go-for-host. Wow, nice work! I'm curious though, is there a technical reason we need so

Bug#959631: hy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

On Tue, 5 May 2020 at 10:55, Tianon Gravi wrote: > I was definitely over my head with this one, so I reached out to the > Hy community and was pointed to https://bugs.python.org/issue39562, > which does seem quite related from my own limited understanding, so > this might technica

Bug#959631: hy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

On Sun, 3 May 2020 at 06:12, Lucas Nussbaum wrote: > > ... > > === warnings summary > > === > > .pybuild/cpython3_3.8_hy/build/tests/native_tests/comprehensions.hy::test_fors[sfor] > > /<>/hy/models.py:133: RuntimeWarning: coroutine '' >

Bug#929417: debconf: Readline frontend should check that stdin is a tty (to fix Docker build freezes)

On Thu, Apr 16, 2020 at 04:56:58PM -0700, Tianon Gravi wrote: > As a bit of added versioning information, this affects Debian Stretch > (1.5.61) and newer, but Debian Jessie (1.5.56+deb8u1) is unaffected > (and over in Ubuntu land, Xenial is unaffected at 1.5.58ubuntu2, but

Bug#929417: debconf: Readline frontend should check that stdin is a tty (to fix Docker build freezes)

On Wed, 22 May 2019 23:36:43 -0400 (EDT) Anders Kaseorg wrote: > When building a Debian- or Ubuntu-based Docker container, installing > perl (so that Term::Readline is available) and a package that asks a > Debconf question causes the build to freeze with an interactive readline > prompt that

Bug#954279: src:openjdk-11: Vcs-* metadata is outdated

Package: src:openjdk-11 Version: 11~18-1 Severity: minor Here's the current Vcs-* values for the openjdk-11 source: | Vcs-Browser: https://code.launchpad.net/~openjdk/openjdk/openjdk11 | Vcs-Bzr: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk11 These 404, and it'd be great if they could

Bug#953759: debootstrap: mandatory security support breaks too many things

On Thu, 12 Mar 2020 at 18:27, Cyril Brulebois wrote: > The latest batch of bug reports filed by Johannes 'josch' Schauer seems > to confirm my initial assessment: this will break (too) many use cases > (#953404, #953588, #953593, #953594, #953617). +1, thanks (to you both) for doing this -- my

Bug#950986: uninstalling cgroupfs-mount wails about sys/fs/cgroup/elogind

On Sun, 9 Feb 2020 at 01:45, Harald Dunkel wrote: > Trying to uninstall lxc and some related packages I got an error from > cgroupfs-mount: We should probably adjust the scripts to bail immediately if systemd is init (both mount and umount). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4

Bug#950672: hy: diff for NMU version 0.17.0-1.1

On Tue, 4 Feb 2020 at 08:57, Stefano Rivera wrote: > I've prepared an NMU for hy (versioned as 0.17.0-1.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. Nice, I think this is perfectly reasonable, thanks! I'm hoping to get 0.18.0 packaged soon, which

Bug#949130: refind-install fails to determine the ESP partition

On Sun, 19 Jan 2020 at 09:40, Pelzi wrote: > I found the cure for the problem: the ESP partition was listed as fs type > „msdos“ in fstab. Changing this to „vfat" made refind-install work for me. Ah nice catch! So it sounds like at most, this should be an upstream feature request to have

Bug#949130: refind-install fails to determine the ESP partition

On Fri, 17 Jan 2020 at 01:39, Andreas Feldner wrote: > on an existing installation, the refind package started to break apt-get > upgrade runs, > presumably with the availability of an update of the package. > > The issue arrived w/o interaction on unattended upgrade runs and can easily >

Bug#926981: golang-1.12-go: Needs /etc/alternatives/go to be useful

On Wed, 4 Sep 2019 at 19:51, Michael Hudson-Doyle wrote: > On Thu, 5 Sep 2019 at 12:39, Nye Liu wrote: >> that is ABSOLUTELY one of the roles of update-alternatives, particularly >> for compiler variants, e.g. gcc, java, etc. > > gcc isn't managed by alternatives though! In general,

Bug#892264: Hy 0.17.0

On Sat, 17 Aug 2019 at 04:04, Tristan Seligmann wrote: > Go for it! Maintainer should probably be DPMT anyway. To be fair, it is, but you're a human listed for the package so I figured I'd reach out to avoid stepping on your toes. Thanks! :) Will be uploading soon, and once/if ACCEPTed will

Bug#892264: Hy 0.17.0

On Tue, 4 Jun 2019 at 16:59, Tianon Gravi wrote: > I've updated Git with what I think is finally successful packaging of > a newer Hy version (0.17.0 ATM). It requires updated "python-astor" > (I tested 0.8.0) and "python-rply" (I tested 0.7.7), which I don't >

Bug#892264: Hy 0.17.0

I've updated Git with what I think is finally successful packaging of a newer Hy version (0.17.0 ATM). It requires updated "python-astor" (I tested 0.8.0) and "python-rply" (I tested 0.7.7), which I don't have time to chase down properly right now. "dh_auto_test" is passing but the autopkgtests

Bug#929889: debootstrap: Support unconventional PATH on foreign distros

On Sun, 2 Jun 2019 at 11:12, Vagrant Cascadian wrote: > The following patch fixes issues when the hard-coded > PATH=/sbin:/usr/sbin:/bin:/usr/bin does not contain chroot or other > commonly used utilities, by changing to PATH=$PATH:/sbin:... Do you think it would make sense to instead use

Bug#710709: debootstrap: consider creating (dangling) /etc/mtab symlink

On Tue, 30 Apr 2019 at 13:03, Hideki Yamane wrote: > + if [ ! -f "$TARGET/etc/mtab" ]; then > + if [ -L "$TARGET/proc/self" ]; then > + cd "$TARGET/etc" && ln -s ../proc/self/mounts > mtab > + elif [ -f

Bug#925514: updated archive.debian.org snapshot?

On Mon, 25 Mar 2019 at 21:06, Tianon Gravi wrote: > It would seem https://snapshot.debian.org/archive/debian-archive/ hasn't > had a snapshot since 2016, which is especially relevant now given that > wheezy and jessie have been removed from the mirrors. https://snapshot.debian.org/archi

Bug#925514: updated archive.debian.org snapshot?

Package: snapshot.debian.org Severity: normal It would seem https://snapshot.debian.org/archive/debian-archive/ hasn't had a snapshot since 2016, which is especially relevant now given that wheezy and jessie have been removed from the mirrors. Any chance we could get a newer snapshot of

Bug#915455: Removal of gb?

On Mon, 3 Dec 2018 at 13:57, Dr. Tobias Quathamer wrote: > Do you think that gb can be fixed to build with golang-1.10? If not, > would you agree to remove gb from unstable? As sad as I am to see it go, it's a non-trivial amount of work to update it for Go 1.10 (and upstream hasn't been very

Bug#913614: [pkg-gnupg-maint] Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"

On Tue, 13 Nov 2018 15:18:22 +0100 Werner Koch wrote: > For any script use you should anyway use --batch which disables the use > of the tty as a side-effect. Even for something that shouldn't have a reason to prompt, like "--recv-keys" with a full fingerprint? It makes some sense logically,

Bug#906229: docker: FTBFS with dpkg-buildpackage -A

On Wed, 15 Aug 2018 at 12:42, Tianon Gravi wrote: > I think the attached patch is likely going to be our simplest fix > unless anyone following along (to src:docker!) sees any issues with > it? Idiot old me, forgot the attachment. ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4

Bug#906229: docker: FTBFS with dpkg-buildpackage -A

On Wed, 15 Aug 2018 at 10:12, Santiago Vila wrote: > > [...] > debian/rules build-indep > make: *** No rule to make target 'build-indep'. Stop. > dpkg-buildpackage: error: debian/rules build-indep subprocess

Bug#902258: any docker command triggers an attempt to unlock my GPG key

On Sat, 23 Jun 2018 at 18:51, Yaroslav Halchenko wrote: > IMHO doker must not ask for unlocking GPG key at all AFAIK, unless may be > some functionality requires signing et. > > I've not yet tried to figure out what exactly leads to it. I'll bet you've got "pass" [1] installed, and this is thus

Bug#901674: postinst: line 112: /usr/lib/jvm/java-11-openjdk-amd64/bin/java: No such file or directory

On Sun, 17 Jun 2018 00:05:03 +0800 Dan Jacobson wrote: > Setting up openjdk-11-jre-headless:amd64 (11~18-1) ... > /var/lib/dpkg/info/openjdk-11-jre-headless:amd64.postinst: line 112: > /usr/lib/jvm/java-11-openjdk-amd64/bin/java: No such file or directory > ignoring dump failure Looks like the

Bug#901808: debootstrap: --merged-usr is silently ignored on "blacklisted" suites like stretch

Package: debootstrap Version: 1.0.102 Severity: serious Justification: https://lists.debian.org/debian-boot/2018/06/msg00238.html See the conversation around/following [1] for more context. [1]: https://lists.debian.org/debian-boot/2018/06/msg00175.html The TLDR is that the previous version of

Bug#900593: diffoscope: GNU tar xattrs result in: libarchive: Ignoring malformed pax extended attribute

On Mon, 11 Jun 2018 at 01:29, Chris Lamb wrote: > > Chris Lamb wrote: > > > Glad I could resolve your use-case. However, I assume there is still a > > diffoscope bug here? > > > > ie. We certainly shouldn't be emitting "Ignoring malformed pax > > extended attribute" to stderr and — as a possible

Bug#900593: diffoscope: GNU tar xattrs result in: libarchive: Ignoring malformed pax extended attribute

On Fri, 1 Jun 2018 at 14:16, Chris Lamb wrote: > Oh, neat! Hm, can you try: > > --pax-option=exthdr.name=%d/PaxHeaders/%f,atime:=0 Hey, that's snazzy! That gives me a reproducible result. :) Without: $ sudo tar --create --directory wtf --numeric-owner --transform 's,^./,,' --sort name

Bug#900593: diffoscope: GNU tar xattrs result in: libarchive: Ignoring malformed pax extended attribute

On Fri, 1 Jun 2018 12:25:15 -0700 Tianon Gravi wrote: > The context for this bug is in [1]. The basic gist is that I need to > preserve extended attributes to get the proper capabilities on > "/bin/ping" inside a rootfs tarball, so I updated my GNU tar invocation > to inclu

Bug#900593: diffoscope: GNU tar xattrs result in: libarchive: Ignoring malformed pax extended attribute

Package: diffoscope Version: 95 Severity: normal First, thanks for diffoscope; it's the best. :) The context for this bug is in [1]. The basic gist is that I need to preserve extended attributes to get the proper capabilities on "/bin/ping" inside a rootfs tarball, so I updated my GNU tar

Bug#891076: docker.io: docker version (1.13.1) in sid reached EOL

On 22 February 2018 at 00:27, Jan Christoph Uhde wrote: > we had a look at https://success.docker.com/article/Maintenance_Lifecycle and > noticed that the docker version in sid reached EOL. Just to be clear, that table _only_ applies to Docker EE, which is a commercial offering

Bug#887189: golang-github-docker-docker-dev should depend on e2fsprogs explicitly

On 12 February 2018 at 08:56, Andreas Henriksson wrote: > Apart from my first comment I'm not sure how useful it is to declare > a dependency in the package shipping go *source* that utilizes a > certain command. AIUI building go basically means you end up with > something

Bug#850753: fresh upstream (and ubuntu) is available (1.12.3)

On 15 November 2017 at 00:36, Bastian Venthur wrote: > If there is something blocking a new release, I could also try to help. Or > maybe adding a few more people to the maintainers list in general would be a > good idea for such an important package? The thing blocking a new

Bug#883558: linux: not yet ready to enter testing

Salvatore Bonaccorso wrote: > We think 4.14.2-1 should not yet enter testing, thus filling a > blocking bug to preventing migration. > > We will close the bug as soon we think 4.14.2-1 or an increment is > good. In the quest for a little more detail (because I'm wanting to test 4.14 on a buster

Bug#878912: docker.io: docker run fails saying that containerd-shim not installed

tags 878912 + moreinfo unreproducible severity normal thanks On 17 October 2017 at 10:05, Antonio Terceiro wrote: > On a completely up to date sid system: > > $ docker run -it --rm debian:sid > docker: Error response from daemon: containerd-shim not installed on system. I

Bug#877146: Bug#877329: Bug#877146: update to runc (1.0.0~rc4) breaks docker

On 10 October 2017 at 12:59, Tianon Gravi <tia...@debian.org> wrote: > I've been working on a "docker-containerd" package today (since that's > going to be useful regardless), and found that there are other > packages needed which depend on > "golang-github-opencon

Bug#877146: Bug#877329: Bug#877146: update to runc (1.0.0~rc4) breaks docker

On 3 October 2017 at 15:52, Bálint Réczey wrote: > I think it would be cleaner to go without the Provides: and adding > docker-containerd build-depending on > golang-github-opencontainers-docker-runc-dev, but feel free to go either way. > > I think the most efficient way

Bug#877329: Bug#877146: update to runc (1.0.0~rc4) breaks docker

On 30 September 2017 at 08:37, Bálint Réczey wrote: > Tianon, could you please switch to docker-runc in docker.io? > > I have the packaging commits in git for docker-runc but I did not want to > push it to the go packages' area so when I get approved to the Docker >

Bug#872807: [pkg-go] Bug#872807: Bug#872807: Bug#872807: dh-make-golang: Please find dependencies based on Homepage, too

On 21 August 2017 at 14:11, Michael Hudson-Doyle wrote: > On 22 August 2017 at 01:17, Paul R. Tagliamonte wrote: >> Why not use the import path I so lovingly put in the generated control >> file for times like these? > > That's still missing from

Bug#871344: golang-1.6: FTBFS: test fails

On 7 August 2017 at 08:51, Lucas Nussbaum wrote: > Source: golang-1.6 > Version: 1.6.3-1 > Severity: serious > Tags: buster sid This has me a bit confused -- there's no "golang-1.6" in sid (or buster) that I can find: - https://packages.debian.org/sid/source/golang-1.6 -

Bug#869923: sbuild --extra-package causes fatal "permission denied" error during "apt-get update"

Package: sbuild Version: 0.73.0-4 Severity: normal While attempting to use sbuild to test the reverse-dependencies of a package before uploading a new upstream revision, I ran into the following error using "--extra-package": | $ sbuild --arch-all --dist=unstable --nolog

Bug#869543: RM: consul-migrate -- ROM; deprecated by upstream

Package: ftp.debian.org Severity: normal See [1]. This was packaged as a dependency of other packages, and is no longer required. Upstream considers it unmaintained and unnecessary. [1]: https://github.com/hashicorp/consul-migrate/issues/1#issuecomment-199456618 | $ ssh

Bug#869242: [pkg-go] Bug#869242: CVE-2017-11468

On 21 July 2017 at 14:35, Moritz Muehlenhoff wrote: > Please see > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11468 Thanks for the report! I've started looking into the fix, and will include my notes here: https://github.com/docker/distribution/releases/tag/v2.6.2

Bug#869242: [pkg-go] Bug#869242: CVE-2017-11468

On 21 July 2017 at 15:17, Tianon Gravi <tia...@debian.org> wrote: > https://github.com/docker/distribution/releases/tag/v2.6.2 is the > release which fixes this (and it links to > https://github.com/docker/distribution/commit/29fa466debaabb64f8559116bbffd20a289d523c > as the spe

Bug#868046: gb uses /usr/lib/go-1.7 even if go 1.8 is installed

On 11 July 2017 at 14:43, Michael Hudson-Doyle wrote: > Maybe it just makes sense for gb to (build-)depend on whichever > golang-1.X-go directly. I think you're probably right... :( (Or perhaps we build-depend on golang-go, and explicitly depend on whichever

Bug#868046: [pkg-go] Bug#868046: gb uses /usr/lib/go-1.7 even if go 1.8 is installed

On 11 July 2017 at 07:11, Jens Kubieziel wrote: > user@linux:> strace -e trace=file gb build > github.com/jteeuwen/go-bindata/go-bindata |& egrep '1\.7' > stat("/usr/lib/go-1.7/src/vendor/github.com/jteeuwen/go-bindata/go-bindata", > 0xc42015a858) = -1 ENOENT (No such file or

  1   2   3   4   5   >