Bug#1077958: nmu: rust-async-broadcast_0.7.1-1

On Mon, Aug 5, 2024 at 2:44 PM Paul Gevers wrote: > Hi > > On 05-08-2024 14:03, Reinhard Tartler wrote: > > I need some help to understand how skipped tests lead to delaying the > > package migration to testing. My naive understanding is that this flag > > would rather

Re: Bug#1052119: autopkgtest in experimental: sometimes just fails for rust libraries with "crate directory not found"

Matthias Geiger writes: > - From my limited observation this only happens in experimental for rust > crates. I don't know what causes this. The autopkgtest ran fine when I > built the packages before uploading. I believe this problem is much more widespread in testing than experimental and is ho

Bug#1077958: nmu: rust-async-broadcast_0.7.1-1

On Sun, Aug 4, 2024 at 10:27 PM Jeremy Bícha wrote: > That is not the actual contents of the .deb. Download the .deb and > open it in file-roller or something to check for yourself. Or look at > the build log. > > https://buildd.debian.org/status/package.php?p=rust-async-broadcast > > Some Rust a

Bug#1077958: nmu: rust-async-broadcast_0.7.1-1

Package: release.debian.org Severity: normal X-Debbugs-Cc: rust-async-broadc...@packages.debian.org, debian-r...@lists.debian.org Control: affects -1 + src:rust-async-broadcast User: release.debian@packages.debian.org Usertags: binnmu nmu rust-async-broadcast_0.7.1-1 . riscv64 . unstable . -m

Re: Coordingating/planning various golang transitions

I'd appreciate any kind of reply, ideally in the form of: "please hold of, here is a list of things we need to consider and/or look at first.". thank you so much for your assistance! -rt On Sat, Jul 13, 2024 at 6:53 PM Reinhard Tartler wrote: > Hi, > > We currently shi

Re: Coordingating/planning various golang transitions

On Sat, Jul 13, 2024 at 2:57 PM Simon Josefsson wrote: > Reinhard Tartler writes: > > > My takeaway is that we need to update a large number of packages at the > > same time, starting with src:golang-google-genproto > > and src:golang-google-grpc. This will unblock a

Coordingating/planning various golang transitions

Hi, We currently ship docker version 20.10 in Debian oldstable, stable and currently testing. This is an EOL version that I really don't think Debian trixie should be shipping with. I've been working over the last couple of weeks (months?) on updating podman and docker to recent versions, includi

Re: Bug#1070411: containerd fails to build as a normal user due to sysctl

Jochen Sprickerhof writes: > containerd uses sysctl during the build which fails as a normal user: > > === RUN TestLinuxSandboxContainerSpec > sandbox_run_linux_test.go:241: TestCase "spec should reflect original > config" > sandbox_run_linux_test.go:71: Check PodSandbox annotations

Bug#1055059: nmu: runc_1.1.5+ds1-1+b4

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: r...@packages.debian.org Control: affects -1 + src:runc nmu runc_1.1.5+ds1-1+b4 . ANY . unstable . -m "rebuild against golang-github-urfave-cli_1.22.14-1" please rebuild runc

Bug#1031097: bullseye-pu: package conmon/2.0.25+ds1-1.1

On 10/8/23 8:01 AM, Jonathan Wiltshire wrote: Hi, This request was approved but not uploaded in time for the previous point release (11.8). Should it be included in 11.9, or should this request be abandoned and closed? Apologies for dropping the ball here. I've just uploaded conmon 2.0.25+d

Bug#1034493: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u4

ncy=medium + + * Recompile to fix parsing of DBUS_SESSION_BUS_ADDRESS (Closes: #1018816) + + -- Reinhard Tartler Sun, 16 Apr 2023 18:16:11 -0400 + libpod (3.0.1+dfsg1-3+deb11u3) bullseye; urgency=medium * Fix and tighten dependencies diff -Nru libpod-3.0.1+dfsg1/debian/control libpod-3.0.1+dfsg1/debi

Bug#1034198: bullseye-pu: package golang-github-containers-common/0.33.4+ds1-1+deb11u1

ff --git a/debian/changelog b/debian/changelog index c23b4b9b..97d97794 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +golang-github-containers-common (0.33.4+ds1-1+deb11u2) bullseye; urgency=medium + + * Fix parsing of DBUS_SESSION_BUS_ADDRESS, Closes: #1018816 + + -- Reinha

Bug#1034039: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u1

Argh, my bad, I'll upload a new version later today Thanks for spotting -rt On April 7, 2023 4:41:41 AM EST, "Adam D. Barratt" wrote: >On Thu, 2023-04-06 at 19:46 -0400, Reinhard Tartler wrote: >> This code change picks up code changes in golang-github-containers- >

Bug#1034039: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u1

1,10 @@ +libpod (3.0.1+dfsg1-3+deb11u2) bullseye; urgency=medium + + * CVE-2022-1227: pickup changes in containers/psgo, Closes: #1020907 + * CVE-2022-27649: do not set the inheritable capabilities, Closes: #1020906 + + -- Reinhard Tartler Wed, 05 Apr 2023 21:00:36 -0400 + libpod (3.0.1+

Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1

Control: tag -1 -moreinfo On 4/1/23 7:04 PM, Reinhard Tartler wrote: On 4/1/23 3:51 PM, Adam D. Barratt wrote: Control: tags -1 + moreinfo Apologies for the delay in getting back to you on this. On Wed, 2022-12-28 at 22:26 -0500, Reinhard Tartler wrote: In order to fix CVE-2022-1227, an

Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1

On 4/1/23 3:51 PM, Adam D. Barratt wrote: Control: tags -1 + moreinfo Apologies for the delay in getting back to you on this. On Wed, 2022-12-28 at 22:26 -0500, Reinhard Tartler wrote: In order to fix CVE-2022-1227, an update to golang-github-containers- psgo is needed, more specifically

Bug#1031097: bullseye-pu: package conmon/2.0.25+ds1-1.1

Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: con...@packages.debian.org, Dan Nicholson Control: affects -1 + src:conmon [ Reason ] conmon 2.0.25 contains a bug where the container will hang when there is lots

Bug#1027258: bullseye-pu: package golang-github-containers-psgo/1.5.2-2~deb11u1

6..0448fdf 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +golang-github-containers-psgo (1.5.2-2~deb11u1) bullseye; urgency=medium + + * CVE-2022-1227: do not join the process user namespace + + -- Reinhard Tartler Wed, 28 Dec 2022 21:21:57 -0500 + golang-github-containers-p

Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1

ebian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +golang-github-containers-storage (1.24.8+dfsg1-2~deb11u1) bullseye; urgency=medium + + [ Vignesh Raman ] + * prereq to fix CVE-2022-1227: pkg: idtools: export RawTo{Container,Host} + + -- Reinhard Tartler Wed, 28 Dec 2022 21:39:17 -0500 + g

Bug#1025401: unblock: libpod/4.3.1+ds1-5

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libpod libpod needs to migrate together with: golang-github-containers-common_0.50.1+ds1-2 golang-github-containers-buildah_1.28.0+ds1-3 [ Reason ] There have been

Bug#1013349: release.debian.org: Please hint golang-github-openshift-imagebuilder and golang-github-containers-buildah into testing

Package: release.debian.org Severity: normal The following two packages need to go into testing together: golang-github-openshift-imagebuilder_1.2.3+ds1-1 golang-github-containers-buildah_1.23.1+ds1-3 golang-github-openshift-imagebuilder introduced some API changes that broke the compilation of

Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1

;> > >> On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote: > >>> diff -Nru runc-1.0.0~rc93+ds1/debian/changelog runc- > >>> 1.0.0~rc93+ds1/debian/changelog > >>> --- runc-1.0.0~rc93+ds1/debian/changelog2022-06-12 > >>

Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1

On Sun, Jun 12, 2022 at 10:57 PM Shengjing Zhu wrote: > X-Dbackport: do not set inheritable capabilities, Fixes: > CVE-2022-29162ebbugs-CC: siret...@debian.org, t...@security.debian.org > > Hi, > > On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote: > > d

Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1

2022-06-12 14:49:36.0 -0400 +++ runc-1.0.0~rc93+ds1/debian/changelog2021-05-19 14:46:14.0 -0400 @@ -1,10 +1,3 @@ -runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium - - * Team upload. - * backport upstream patch: Honor seccomp defaultErrnoRet, Closes: #10

Bug#1004533: bullseye-pu: package golang-github-opencontainers-specs/1.0.2.41.g7413a7f-1

specs (1.0.2.41.g7413a7f-1+deb11u1) bullseye; urgency=medium + + * Backport seccomp patches from upstream to allow execution of newer +syscalls, Closes: #994451 + + -- Reinhard Tartler Mon, 27 Sep 2021 12:12:47 -0400 + golang-github-opencontainers-specs (1.0.2.41.g7413a7f-1) unstable; ur

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

Hi Paul, On Sun, Oct 3, 2021 at 12:39 PM Paul Gevers wrote: > Hi Reinhard, > > > The consistent OOM is surprising given that you state that the worker > > has 250GB of RAM. Looking at the logs, > > I note that the tests are being passed the option -p 160 by the > > dh-golang helper, so it will b

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

Hi Paul, thanks for getting back to me so quickly. Adding Nilesh and Shengjing, we were discussing this issue on a separate, private email conversation. On Wed, Sep 29, 2021 at 2:45 PM Paul Gevers wrote: > Hi Reinhard, > > On 29-09-2021 02:56, Reinhard Tartler wrote: > >

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package golang-github-klauspost-compress The problem is with autopkgtest, on armel and armhf, the test machines frequently run out of memory when executing the extensive test

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

ink. 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 >>

Bug#993650: unblock: golang-github-openshift-imagebuilder/1.2.1+ds1-3

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Please hint golang-github-openshift-imagebuilder and golang-github-containers-storage to migrate to testing together The migration of golang-github-openshift-imagebuilder is blocked because it was built agai

Bug#989899: unblock: libpod/3.0.1+dfsg1-3

+connection issue "Connection reset by peer", Closes: #989803 + + -- Reinhard Tartler Sun, 13 Jun 2021 18:28:49 -0400 + libpod (3.0.1+dfsg1-2) unstable; urgency=medium * Prefer crun over runc, Closes: #985379 diff --git a/debian/patches/networking-lookup-child-IP-in-network

Bug#987155: unblock: libpod/3.0.1+dfsg1-2

#985379 + * Add depends in iptables, Closes: #987207 + + -- Reinhard Tartler Wed, 21 Apr 2021 17:36:07 -0400 + libpod (3.0.1+dfsg1-1) unstable; urgency=medium * New upstream release diff --git a/debian/control b/debian/control index dedbb4462..d3865b0c1 100644 --- a/debian/control +++

Bug#987155: unblock: libpod/3.0.1+dfsg1-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: siret...@tauware.de, Filippo Giunchedi Please unblock package libpod Note that I have not uploaded the package yet, this is a pre-approval request. [ Reason ] I as maintaine

Bug#985822: unblock: slirp4netns/1.0.1-2

/debian/changelog @@ -1,3 +1,9 @@ +slirp4netns (1.0.1-2) unstable; urgency=medium + + * Apply patch from upstrema to make ipv6 usable (Closes: #985780) + + -- Reinhard Tartler Wed, 24 Mar 2021 07:43:48 -0400 + slirp4netns (1.0.1-1) unstable; urgency=medium * New upstream version 1.0.1 diff --git

Re: golang-github-revel-revel: Depends on network in tests

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. > Rai

Re: golang-github-revel-revel: Depends on network in tests

Dear Golang Team, On Mon, Feb 15, 2021 at 1:23 PM Paul Gevers wrote: > On 15-02-2021 15:08, Reinhard Tartler wrote: > > Control: severity -1 important > > I agree with this. The Debian infra allows for use of the internet (if > not used to download programs, that's for

golang-github-revel-revel: Depends on network in tests

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.

Bug#982030: nmu: libpod_libpod

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu It seems that there is a problem with the image cache in podman 3.0-rc2, which turns out to be a bug in 'buildah'. I've uploaded a fix to unstable as golang-github-containers-buildah_1.19.3+d

Re: Podman 3.0 and Debian bullseye

On Tue, Feb 2, 2021 at 3:01 PM Paul Gevers wrote: > Unfortunately I believe we're not really in the position to advise you > on the matter at hand as there are obviously pro's and con's for both > side which require detailed knowledge to balance them. It seems to me > that your having a decent di

Re: Podman 3.0 and Debian bullseye

On Tue, Feb 2, 2021 at 11:54 AM Adrian Bunk wrote: > On Sat, Jan 30, 2021 at 09:08:36PM -0500, Reinhard Tartler wrote: > >... > > On Mon, Jan 25, 2021 at 7:15 PM Dmitry Smirnov > wrote: > >... > > A low-effort workaround could be to add a build-dependency on pod

Re: Podman 3.0 and Debian bullseye

On Mon, Feb 1, 2021 at 4:58 PM Dmitry Smirnov wrote: > > > The fact that as has been mentioned in this thread a) bullseye is around > > the corner b) nomad-driver-podman isn't even in testing right now, c) > > podman itself is a much more popular package than nomad-driver-podman > > (or nomad for

Re: Podman 3.0 and Debian bullseye

On Sat, Jan 30, 2021 at 10:33 PM Dmitry Smirnov wrote: > > > > No it hasn't... :( There is a serious regression: > > > https://github.com/hashicorp/nomad-driver-podman/issues/69 > > > > I'm having a hard time considering this a "serious" regression. The > problem > > as far as I understand is t

Re: Podman 3.0 and Debian bullseye

trimming cc-list On Mon, Jan 25, 2021 at 7:15 PM Dmitry Smirnov wrote: > On Monday, 25 January 2021 10:47:25 PM AEDT Reinhard Tartler wrote: > > It seems that https://packages.qa.debian.org/n/nomad-driver-podman.html > > has never made it to testing, which makes me wonder whether

Re: Podman 3.0 and Debian bullseye

On Sat, Jan 30, 2021 at 5:03 PM Antonio Terceiro wrote: > FWIW I have been using podman 3.0.0~rc1 from experimental for a few days > and haven't noticed anything wrong with it. I hope we can have that > version in bullseye. > Me too. Dear release team, do you have any opinion on this topic? t

Re: Podman 3.0 and Debian bullseye

On Sun, Jan 24, 2021, 21:52 Dmitry Smirnov wrote: > On Monday, 25 January 2021 12:02:26 PM AEDT Reinhard Tartler wrote: > > - Podman 3 drops the legacy varlink interface. To the best of my > > knowledge, there are no packages in debian/testing that would require > > varli

Podman 3.0 and Debian bullseye

Dear release-team, I'm proposing to have podman 3.0 in debian/bullseye. As maintainer of the package, I'm convinced this is a good step for Debian because: - podman 3.0 will be included in RHEL 8.4, which will be released in May 2021. I expect security support for podman in Debian to become sign

Re: New consul package not migrating to testing because of patroni autopkgtest?

On Wed, Dec 9, 2020 at 2:32 PM Paul Gevers wrote: > > These kind of build failures should be fixed. Builds that regularly fail > are not OK. Same goes for autopkgtest. Flaky tests are RC. > Agreed. > > What's involved with retrying autopkgtests on arm64? -- CC'ing > > debian-release@, maybe th

Re: New consul package not migrating to testing because of patroni autopkgtest?

successfully. That's why I'm optimistic about retrying the autopkg tests for consul. What's involved with retrying autopkgtests on arm64? -- CC'ing debian-release@, maybe they have some input? Best, -rt On Mon, Dec 7, 2020 at 6:43 AM Reinhard Tartler wrote: > Ok, than

Re: Update for buster slirp4netns CVE-2019-9824

t place. >> >> On Wed, Aug 07, 2019 at 06:13:08PM -0400, Reinhard Tartler wrote: >>> Hi Security Team, >>> >>> I have not received an answer to my question below. Any chance you >>> could get back to me on that? >> >> Unless I severe

Bug#929855: unblock: libheif/1.3.2-2

9452979..23246df 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +libheif (1.3.2-2) unstable; urgency=medium + + * Team Upload + + [ Dylan Aïssi ] + * Add patch to fix CVE-2019-11471, Closes: #928210 + + -- Reinhard Tartler Sat, 01 Jun 2019 17:56:05 -0400 + libheif

Bug#927042: unblock: gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5

g fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message() +in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963). + + -- Reinhard Tartler Sat, 13 Apr 2019 16:41:15 -0400 + gpac (0.5.2-426-gc5ad4e4+dfsg5-4.1) unstable; urgency=medium * CVE-2018-7752 (Closes: #8

Bug#926704: unblock: pcsc-cyberjack/3.99.5final.sp09-2

edium + + * Acknowledge 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

Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2

+ + * 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

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

On 4/4/19 3:38 PM, Moritz Mühlenhoff wrote: > On Tue, Apr 02, 2019 at 10:40:44PM -0400, Reinhard Tartler wrote: >> Ah, that's great news. I didn't realize that Moritz backported the >> security fixes to an earlier upstream version. I managed to locate the >> git comm

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

On 4/2/19 3:08 PM, Niels Thykier wrote: > Thorsten Alteholz: >> Hi Reinhard, >> >> On Tue, 2 Apr 2019, Reinhard Tartler wrote: >>> Now about 6 weeks have passed since I've been uploading this package, and >>> I do have a question: Is there anything wr

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

Dear ftp-master team, On 2/15/19 7:20 AM, Debian FTP Masters wrote: > binary:libgpac7 is NEW. > binary:libgpac7 is NEW. > > Your package has been put into the NEW queue, which requires manual action > from the ftpteam to process. The upload was otherwise valid (it had a good > OpenPGP signature a

Bug#859216: unblock: jackd2/1.9.10+20150825git1ed50c92~dfsg-5

+1,11 @@ +jackd2 (1.9.10+20150825git1ed50c92~dfsg-5) unstable; urgency=medium + + * Move libjackserver into package libjack-jackd2-0. This avoids a +dangling symbolic link in the package libjack-jackd2-dev. +(Closes: #858525) + + -- Reinhard Tartler Mon, 27 Mar 2017 22:44:11 -0400

Re: boxbackup 0.11.1~r2837-2 migration issue

un 12, 2016 at 11:55 AM Adam D. Barratt wrote: > On Sun, 2016-06-12 at 15:41 +, Reinhard Tartler wrote: > > > I wonder why boxbackup did not migrate to testing. According to > > https://release.debian.org/migration/testing.pl?package=boxbackup the > > issue is a mis

boxbackup 0.11.1~r2837-2 migration issue

Hi, I wonder why boxbackup did not migrate to testing. According to https://release.debian.org/migration/testing.pl?package=boxbackup the issue is a missing armhf build. However, https://buildd.debian.org/status/logs.php?arch=armhf&pkg=boxbackup&ver=0.11.1~r2837-1 indicates it built just fine. Wh

Bug#807280: jessie-pu: package keepassx/0.4.3+dfsg-0.1

On December 7, 2015 4:37:03 PM EST, "Adam D. Barratt" wrote: >Control: tags -1 + pending > >On Sun, 2015-12-06 at 19:33 -0500, Reinhard Tartler wrote: >> I'm writing you to request approving my recent upload of >> keepassx_0.4.3+dfsg-0.1+deb8u1. This updat

Bug#807280: jessie-pu: package keepassx/0.4.3+dfsg-0.1

Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu Dear Release Team, I'm writing you to request approving my recent upload of keepassx_0.4.3+dfsg-0.1+deb8u1. This update addresses CVE-2015-8378/#791858. I'm copying Moritz, since he

Re: Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright

On Fri, Nov 28, 2014 at 1:34 AM, Niels Thykier wrote: > Control: tags -1 -wheezy-ignore > > On 2014-11-27 23:23, Jonas Smedegaard wrote: >> Quoting Niels Thykier (2014-11-27 22:14:25) >>> [...] >> >> In prior similar bugreport - >> referenced from

Re: FFmpeg in Jessie

On Fri, Sep 26, 2014 at 5:28 PM, Andreas Barth wrote: > That sounds like we should drop libav and release with ffmpeg. Is this > also the opinion of the libav maintainers? Or is there a strong reason > why this is not possible? This was extensively discussed previously on debian-devel this Augus

Bug#757917: transition: libav11

On Tue, Aug 26, 2014 at 6:31 PM, Reinhard Tartler wrote: > On Tue, Aug 26, 2014 at 4:29 PM, Emilio Pozuelo Monfort > wrote: >> On 26/08/14 16:05, Reinhard Tartler wrote: >>> On Mon, Aug 18, 2014 at 4:25 PM, Emilio Pozuelo Monfort >>> wrote: >>>> On 18/

Bug#757917: transition: libav11

On Tue, Aug 26, 2014 at 4:29 PM, Emilio Pozuelo Monfort wrote: > On 26/08/14 16:05, Reinhard Tartler wrote: >> On Mon, Aug 18, 2014 at 4:25 PM, Emilio Pozuelo Monfort >> wrote: >>> On 18/08/14 21:33, Andrew Kelley wrote: >>>> On Aug 18, 2014 12:22 PM, &

Bug#757917: transition: libav11

On Mon, Aug 18, 2014 at 4:25 PM, Emilio Pozuelo Monfort wrote: > On 18/08/14 21:33, Andrew Kelley wrote: >> On Aug 18, 2014 12:22 PM, "Emilio Pozuelo Monfort" wrote: >>> >>> I want to get perl in first. Ping me again when that happens if I haven't >> replied. >> >> Pardon my ignorance but why can

Bug#757917: transition: libav11

On Sat, Aug 16, 2014 at 11:24 AM, Reinhard Tartler wrote: >> vlc FAIL (silly configure check fail, will sort out with upstream) > > Turns out to be sligtly more complicated as thought. After > consultation with j-b (videolan upstream), we decided that we really > should g

Bug#757917: transition: libav11

On Wed, Aug 13, 2014 at 9:07 PM, Reinhard Tartler wrote: > linphone FAIL, #758017, NMU uploaded to 5/days > vlc FAIL (silly configure check fail, will sort out with upstream) Turns out to be sligtly more complicated as thought. After consultation with j-b (videolan upstream), we decide

Bug#757917: transition: libav11

On Aug 14, 2014 8:18 AM, "Emilio Pozuelo Monfort" wrote: > > On 12/08/14 13:41, Reinhard Tartler wrote: > > A prerelease for > > Libav11 that passes upstream's extensive test suite is currently in > > debian/experimental, and I'll make sure that the

Bug#757917: transition: libav11

On Wed, Aug 13, 2014 at 9:07 PM, Reinhard Tartler wrote: > gst-libav1.0 FAIL (fixed in 11~alpha2-1) [...] > gst-libav: will be fixed with a new libav package that I'm about to upload confirmed that gst-libav can now that be binNMUed against libav_11~alpha2-1 or later.

Bug#757917: transition: libav11

On Wed, Aug 13, 2014 at 5:25 PM, Emilio Pozuelo Monfort wrote: > > There already is https://release.debian.org/transitions/html/auto-libav.html Lovely! > This sounds good in principle, but I would like to hear about the results of a > mass-rebuild of the rdeps. > OK, I've let me amd64 workstati

Bug#757917: transition: libav11

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to upload libav11 to unstable, which requires the recompilation of any package that links against it. A prerelease for Libav11 that passes upstream's extensive test suit

Bug#753822: aspectc++: please allow transition to testing

Package: release.debian.org I believe Aspectc++ is currently kept out of testing because it FTBFS on armel and armhf. Neither I nor upstream have the resources to support these architectures, and users won't use this package on arm generally anyways. Can you please give guidance on what can be do

Bug#739079: transition: libav10

Now that libav transitioned to testing, and https://release.debian.org/transitions/ says '100%' next to the libav transition, what's left to be done here? Best, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas

Bug#739079: First round of binNMU request for libav 10

On Thu, May 15, 2014 at 12:39 PM, Moritz Muehlenhoff wrote: > On Tue, May 13, 2014 at 10:31:14PM +0200, Julien Cristau wrote: >> On Tue, May 13, 2014 at 17:37:58 +0200, Julien Cristau wrote: >> >> > On Tue, May 13, 2014 at 17:00:32 +0200, Moritz Muehlenhoff wrote: >> > >> > > nmu tupi_0.2+git04-1

Bug#739079: First round of binNMU request for libav 10

On Mon, May 12, 2014 at 5:01 AM, Julien Cristau wrote: > On Sun, May 11, 2014 at 22:02:38 -0400, Reinhard Tartler wrote: > >> Hi, >> >> The following packages from pkg-multimedia build just fine for me: >> >> nmu lives_2.2.4~ds0-2 . ALL . -m"rebuild agains

Bug#739079: First round of binNMU request for libav 10

Hi, The following packages from pkg-multimedia build just fine for me: nmu lives_2.2.4~ds0-2 . ALL . -m"rebuild against libav10" nmu chromaprint_1.1-1 . ALL . -m"rebuild against libav10" nmu libffms2-3_2.19.1-1 . ALL . -m"rebuild against libav10" nmu idjc_0.8.14-1 . ALL . -m"rebuild against liba

Bug#739079: transition: libav10

On Sun, May 11, 2014 at 12:20 PM, Julien Cristau wrote: > Control: tag -1 confirmed > > On Sun, May 11, 2014 at 12:05:55 -0400, Reinhard Tartler wrote: > >> On Sun, May 11, 2014 at 11:50 AM, Julien Cristau wrote: >> > Would a timeline like this work for you: >>

Bug#739079: transition: libav10

On Sun, May 11, 2014 at 11:50 AM, Julien Cristau wrote: > On Sun, May 11, 2014 at 11:25:49 -0400, Reinhard Tartler wrote: > >> for the rest, I'd think that there is a very good chance that the >> respective maintainers are going to fix them before they turn out to >&

Bug#739079: transition: libav10

On Sun, May 11, 2014 at 9:16 AM, Julien Cristau wrote: > On Thu, May 8, 2014 at 20:35:55 -0400, Reinhard Tartler wrote: > >> On Tue, May 6, 2014 at 9:39 AM, Bálint Réczey wrote: >> >> > When do you plan starting the transition? How about opening it with >> >

Bug#739079: transition: libav10

On Tue, May 6, 2014 at 9:39 AM, Bálint Réczey wrote: > When do you plan starting the transition? How about opening it with > Libav 10.1? ;-) > I think we are in a pretty good position for startin now. I agree. Let me upload 10.1 this weekend to unstable to finally start this transition. -- reg

Bug#740210: transition: gpac

On 31.03.2014 15:27, Julien Cristau wrote: On Wed, Feb 26, 2014 at 22:37:41 +, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I believe this should should be rather easy, as only libx264 links against

Bug#738978: transition: x264

On Sat, Apr 5, 2014 at 9:31 AM, Reinhard Tartler wrote: > > On 05.04.2014 08:46, Julien Cristau wrote: >> >> Control: tag -1 confirmed >> >> On Fri, Feb 14, 2014 at 13:27:53 +, Reinhard Tartler wrote: >> >>> Package: release.debian.org

Bug#738978: transition: x264

On 05.04.2014 08:46, Julien Cristau wrote: Control: tag -1 confirmed On Fri, Feb 14, 2014 at 13:27:53 +, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I've prepared a new upstream release of li

Bug#738978: transition: x264

On Sun, Mar 16, 2014 at 3:10 PM, Julien Cristau wrote: > Control: tag -1 moreinfo > > On Fri, Feb 14, 2014 at 13:27:53 +, Reinhard Tartler wrote: > >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Userta

Bug#739079: transition: libav10

On Tue, Feb 18, 2014 at 4:48 PM, Moritz Mühlenhoff wrote: > I made a rebuild and the transitions isn't ready to go at all. > > IMO the API changes are far too agressive; if 2/3 of all packages in > the archive FTBFS, the affected APIs are clearly not that deprecated. > > I can understand the remov

Bug#740444: Please remove xine-lib from jessie/testing

Package: xine-lib Severity: serious Hi, According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739453#17, the plan is to migrate all applications to xine-lib-1.2 anyways. This bug may or may not be reused to coordinate this transition. -- System Information: Debian Release: 7.4 APT pr

Bug#740210: transition: gpac

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I believe this should should be rather easy, as only libx264 links against gpac AFAIUI. I'd therefore suggest to do this transition together with #738978. Ben file: title = "gpac"; is_a

Re: Bug#739079: transition: libav10

On Sun, Feb 16, 2014 at 11:22 AM, Moritz Mühlenhoff wrote: > Reinhard Tartler schrieb: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Hi, >> >> We have a ne

Bug#739079: transition: libav10

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We have a new libav transition pending. Libav 10 is prepared in debian/experimental, and I've started to build packges against this new version; in fact, more or more packages requir

Bug#738978: transition: x264

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I've prepared a new upstream release of libx264, and we need to rebuild all applications that link against it. AFAIUI, this transition should be rather smooth because it affects only a fe

Why doesn't aspectc++ migrate?

Hi, I wonder why the package aspect++ does not migrate. According to http://release.debian.org/migration/testing.pl?package=aspectc++, it seems to be because of missing arm builds. I expected that not to matter as the package is no longer in testing, but obviously I'm wrong. Upstream is aware of

Bug#725864: Bug#726433: Unknown option on the command line

On Wed, Oct 16, 2013 at 10:01 AM, Alessio Treglia wrote: > On Wed, Oct 16, 2013 at 2:49 PM, Fabian Greffrath > wrote: >> Cool, thanks! So, when will this be uploaded? > > Unfortunately not earlier than Wheezy's next point release. > Alessio, I think there is a misunderstanding. AFAIUI, you can

Bug#706798: some packages remaining for the transition.

On Wed, Oct 9, 2013 at 10:16 AM, shirish शिरीष wrote: > Hi all, > It was nice to see updates happening on this transition but some > packages are still to go through (it seems). > > I did the updates and only one of the obsolete packages have some > dependencies which have not been updated to newe

Bug#706798: transition: Libav 9

On Sun, Aug 18, 2013 at 1:15 AM, Julien Cristau wrote: > On Wed, Aug 14, 2013 at 16:18:38 +0200, Moritz Muehlenhoff wrote: > > > > > Since libx264 is largely subsumed by libav, I think it makes very > > > > much sense to do them both at the same time. I am convinced that we > > > > will have less

Bug#706798: transition: Libav 9

On Di, Aug 13, 2013 at 14:30:03 (CEST), Julien Cristau wrote: > On Tue, Aug 13, 2013 at 12:56:46 +0200, Reinhard Tartler wrote: > >> On 13.08.2013 11:48, Julien Cristau wrote: >> >On Sun, May 5, 2013 at 07:45:40 +0200, Reinhard Tartler wrote: >> > >> >>

Bug#706798: transition: Libav 9

On 13.08.2013 11:48, Julien Cristau wrote: On Sun, May 5, 2013 at 07:45:40 +0200, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to upload Libav 9 to unstable at your earliest convinience. To

Bug#706798: transition: Libav 9

On Sun, Jun 2, 2013 at 11:32 AM, Julien Cristau wrote: >> Procedural question: Are these bugs blockers to start the transition? >> Does the release team require all of them to be fixed in experimental >> (via MU or NMUs) before uploading libav9 to unstable? >> > Not necessarily, but we'd like to

Re: Bug#706798: transition: Libav 9

On Sun, Jun 2, 2013 at 1:27 AM, Sebastian Ramacher wrote: > Control: block -1 by 692980 694131 693560 693639 693641 692809 692505 > > For the record, the following packages are known to FTBFS against libav > 9: > > audacious-plugins: #692505 > audacity: #692809 > electricsheep: #692980 > qutecom:

Re: Incomplete ben file for libav9 transition?

On Thu, May 30, 2013 at 8:54 AM, José Manuel Santamaría Lema wrote: > Hello Reinhard, > > Reinhard Tartler >> On Wed, May 29, 2013 at 12:18 AM, José Manuel Santamaría Lema >> >> wrote: >> > Hello, >> > >> > unless I'm missing

  1   2   3   >