Bug#1084824: unblock: rust-sqlx-postgres/0.8.2-3 rust-debversion/0.4.3-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I am trying to get the new versions of rust-sqlx and related packages into testing, this is a prerequisite for getting the new version of rust-base64 into testing. It's currently blocked b

Bug#1082798: unblock: rust-sequoia-keystore-tpm/0.1.0-2

On 26/09/2024 16:02, Paul Gevers wrote: Hi Peter, On 26-09-2024 16:24, Peter Green wrote: Firstly britney is scheduling tests with the old version of rust-sequoia-keystore and the new version of rust-sequoia-keystore-tpm, despite the fact that the old version of rust-sequoia-keystore does not

Bug#1082798: unblock: rust-sequoia-keystore-tpm/0.1.0-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock rust-sequoia-keystore-tpm is blocked from migrating to testing by two issues. I do not believe either of these issues represent real issues in the rust-sequoia-keystore-tpm package and ther

Bug#1080982: unblock: rust-unicode-width/0.1.13-1

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock rust-unicode-width is blocked from migrating to testing by autopkgtest failures in rust-tui. rust-tui is abandoned upstream and we intend to get rid of it (see bugs 1080293 and 1080400). Up

Bug#1079355: unblock: rust-sqlx/0.7.3-4

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock rust-sqlx, it is currently blocked by an autopkgtest "regression" of rust-debversion on riscv64, which is caused by the fact that rust-debversion is uninstable in testing on

Bug#1079040: unblock: rust-debian-copyright/0.1.13-1

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock rust-debian-copyright, it is currently blocked by an autopkgtest "regression" of rust-debian-analyzer on riscv64, which is caused by the fact that rust-debian-analyzer is uni

Bug#1077284: unblock: rust-debian-copyright/0.1.13-1

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock rust-debian-copyright, it is currently blocked by an autopkgtest "pregression" of rust-debian-analyzer on riscv64, which is caused by the fact that rust-debian-analyzer is un

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

That's why the test timeout on riscv64 is double that of other architectures: Unfortunately in many cases, the performance difference seems a lot more than a factor of two. Take rust-gix for example, looking at the results for testing migration tests I see 18-28m on amd64 53-59m on arm64 33-47

Bug#1053800: transition: libgit2

The Rust Team did not react. Too bad. Please raise the bug to RC. Apologies for not engaging with this sooner, I had mentally filed it as "deal with this once the cargo update is done" but the cargo update has been taking a lot longer than hoped. I've uploaded a new version of the rust bindin

re: rust-grep-regex REMOVED from testing

Previous version: 0.1.11-1 Current version: (not in testing) Hint: # 2023-11-04 # blocks lots of packages from migrating # 1053431 Assuming your goal was to allow rust-regex and friends to migrate to testing, you will also want

Re: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye

On 28/04/2023 06:05, Helmut Grohne wrote: Can you go into more detail as to what you mean with "don't support version ranges"? You can place a lower bound on the version, place an upper bound on the version or constrain to a precise version. But you can't constrain to a range of versions. I

Re: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye

Summarising a number of bug reports by Helmut Ghrone: Please ensure that librust---dev has sufficient Breaks and Replaces declarations. The issue specifically appears to be that the breaks+replaces are declared against a virtual package, it seems dpkg is honoring the breaks against the virtua

reason for removal of zeroc-ice on armhf and arm64.

I recently became aware that mumble's build-dependencies were no longer satisfiable on armhf due to a missing zeroc-ice. I looked at the build logs for zeroc-ice and all were green. So I looked at the removal log and found the following. [Date: Sun, 12 Feb 2023 17:56:51 -] [ftpmaster: Scott

Re: Apparently uncoordinated libnetpbm transition.

On 25/04/2022 14:55, Paul Gevers wrote: Hi Andreas, On 07-04-2022 09:21, Andreas Tille wrote: Sorry, that's my fault.  I'm preparing an upload to fix #1007984 targeting new. Looking at https://ftp-master.debian.org/new/netpbm-free_2:10.98.00-1.html, is there any reason why you didn't add "Pr

Bug#1009080: transition: libgit2

libgit2-glib has now been fixed, so I believe it is time to binnmu git-evtag and gnome-builder, both packages were sucessfully binnmu'd in raspbian.

testing migration of mir-core and stdx-allocator binnmus

I noticed that stdx-allocator had unsatisfiable build-dependencies in testing, checking why I discovered that this was because the mir-core binnmus had not migrated to testing. The update_output says. trying: mir-core/i386 skipped: mir-core/i386 (0, 37, 5) got: 25+0: a-1:a-21:a-0:a-0:i-2:m-0

Apparently uncoordinated libnetpbm transition.

A new version of netpbm-free was recently uploaded to unstable which replaced the libnetpbm9, libnetpbm9-dev, libnetpbm10 and libnetpbm10-dev packages with libnetpbm11 and libnetpbm11-dev packages. I could not find any evidence of an attempt to coordinate this transition with the release team, no

Bug#993079: release.debian.org: autopkgtest scheduling does not seem to understand virtual packages correctly.

On 27/08/2021 10:10, plugwash wrote: Britney now seems to understand versioned virtual packages (at least in simple cases) for the main migration and for auto removals, but it still does not seem to properly understand them for testing migration.Typo, that should have said "it still does not see

Bug#988453: rust-rustyline 3.0.0-2+deb10u2 flagged for acceptance

On 11/06/2021 18:21, Adam D Barratt wrote: package release.debian.org tags 988453 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks, unfortunately I've discovered yet another issue (s

Bug#988453: buster-pu: package rust-rustyline/3.0.0-2

On 11/06/2021 09:15, Adam D. Barratt wrote: It looks like that's #932172, which was fixed in dh-cargo 19; buster currently has 17. It would be worth considering a backport of the fix to dh-cargo, to avoid such issues in other packages. Agreed, I'll raise the issue in that bug report and if noon

Bug#988453: buster-pu: package rust-rustyline/3.0.0-2

On 29/05/2021 15:17, Adam D. Barratt wrote: Control: tags -1 + confirmed On Thu, 2021-05-13 at 11:13 +0100, plugwash wrote: rust-rustyline fails to build in buster due to a change of behaviour in rustc, this has been fixed in bullseye/sid for some time and I was able to locate the upstream comm

Re: Fixing rust package FTBFS in buster

On 08/05/2021 17:36, Adrian Bunk wrote: On Wed, May 05, 2021 at 08:01:13AM +0100, peter green wrote: On 04/05/2021 12:28, Santiago Vila wrote: On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote: This was automatically closed by ftpmaster because the package was removed from unstable

Fixing rust package FTBFS in buster (was: Bug#931003: Removed package(s) from unstable )

On 04/05/2021 12:28, Santiago Vila wrote: On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote: This was automatically closed by ftpmaster because the package was removed from unstable, but this still does not fix the FTBFS problem in stable. Unfortunately I don't think a prope

re: Bug#931003: Bug#931003: Removed package(s) from unstable

This was automatically closed by ftpmaster because the package was removed from unstable, but this still does not fix the FTBFS problem in stable. Unfortunately I don't think a proper fix will be forthcoming, upstream has abandoned the crate in question. Afaict the only purpose this package ser

Re: Release status of i386 for Bullseye and long term support for 3 years?

Then there was the short netbook boom, but AFAIR some early ones had 64bit CPUs but 32bit-only firmware. My memory is that at the height of the boom the dominant processors were the N270 and N280, which are 32-bit only. By the time 64-bit netbook processors showed up the boom was on the dec

Bug#971571: transition: libgit2

I've rebuilt the relevant reverse-build-dependencies from unstable In addition to the packages mentioned here, it seems there is another package involved: golang-gopkg-libgit2-git2go.v28 . It only builds arch-all packages and does not directly depend on the library, but it FTBFS and it's autopkg

Bug#970132: buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1

On 17/09/2020 15:06, Emilio Pozuelo Monfort wrote: On 12/09/2020 11:09, Emilio Pozuelo Monfort wrote: This updates buster's rustc to 1.41, as needed by the new firefox 78 ESR. The bootstrap happens with the upstream binaries as we've done in the past. I have also avoided the bump to LLVM 9/10, w

android-framework-23 autorm weirdness.

The tracker for android-framework-23 shows it as due for autoremoval today (and IIRC has been saying that for some time) , and indeed britney is trying to remove it but is failing to do so. Strangely the tracker for andriod-framework-23 says it will cause the autoremoval of android-platform-dal

Bug#969158: expeyes: maybe a false positive generated by mail_autoremovals.pl?

(note: this mail represents my opinions as an ordinary dd, I am not a member of the release team) due to the fact that it is supposed to (build-)depend on binutils-avr, which FTBFS. As I understand it "(build-)depends" should be interpreted as "depends or build-depends" The source package e

Bug#962563: transition: nettle

I just went through the remaining items on the transition tracker for this transition filing bug reports where appropriate. freewheeling: sid-only, unrelated FTBFS bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946863 haskell-hopenpgp/haskell-hopenpgp-tools: haskell-incremental-parser h

Is it time to remove python-numpy from testing?

python-numpy* is no longer buildable in testing due to the removal of the "cython" binary package. The maintainer has requested removal of python-numpy from unstable but the ftpmasters have not yet actioned it, presumably because there are still reverse-dependencies in unstable. A rc bug is pre

why did hypercorn migrate to testing?

At the start of the month python-asynctest and hypercorn were removed from testing due to a rc bug in python-asynctest and the fact that hypercorn build-depends on python3-asynctest (which is built from the python-asynctest source package). However hypercorn just migrated to testing again, despit

future of aufs in Debian.

The aufs package last saw a maintainer upload in September 2019 and was last-updated (by a NMU) in October 2019. It has had broken build-dependencies in testing for half a year now (since Linux 5.3.9-3 migrated to testing in November 2019). According to dak rm the aufs source-package has two r

Bug#958988: key packages script does not take account of virtual packages.

package: qa.debian.org user: qa.debian@packages.debian.org usertags: udd x-debbugs-cc: debian-release@lists.debian.org The debian rust team makes heavy use of virtual packages to reduce the number of real packages in the archive (and in some cases the number of trips through new) while reta

rust-grep testing migration.

Hi Rust-grep is currently blocked from testing migration because of an autopkgtest failure on arm64, it appears that the test failed due to a version mismatch issue. The test was run over three weeks ago and the offending version is no longer in testing. I tried hitting the "retry" button a f

testing migration of gtk-d and tilix binnmus

While investigating self-contained buildability issues in testing I noticed that the gtk-d and tilix binnmus were not migrating to testing. I'm not an expert on reading britney output but I think they may be being blocked by dependencies on each other and britney needs a hint to try them toget

state of the rust ecosystem (and particularly rust-cbindgen) in Debian (was: Requesting backport of cbindgen > 0.10.0 to buster)

(note: these are my observations as a maintainer of a derivative) The rust ecosystem in Debian recently had (and I expect still has) trouble to properly migrate to testing Indeed there are still issues, most notablly IMO that firefox-esr's build-dependencies have been unsatisfiable in testing

re: git-buildpackage to be autoremoved due to python2 transition

Relevant packages and bugs: 943107 git-buildpackage: Python2 removal in sid/bullseye This bug is not marked as rc. Nevertheless I believe that this bug report is in-fact a false positive. From what I can tell git-buildpackage, even in buster, does not (build-)depend on python 2 or any python

Bug#942106: looking at the remaining "bad" packages in the "add python 3.8" transition

There's another kind of issue Yeah, sadly the transition tracker only looks at unstable, so packages that are fixed in unstable but haven't migrated to testing for some reason won't show up. ; here is an example : - sagemath builds only for Python 3.7, so some of this subpackages don't load un

Bug#942106: looking at the remaining "bad" packages in the "add python 3.8" transition

I just took a look at the "add python3.8 transition tracker", and split the remaining "bad" packages into categories. Key package, rc bug with patch. * gpgme1.0 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944774 Not key package, but not marked for autoremoval from testing * macs version i

Re: Bug#948722: qemu-block-extra, (build-)dependencies unsatisfiable on mipsel.

On 14/01/2020 10:24, Michael Tokarev wrote: Control: severity -1 normal Control: tag -1 + moreinfo 12.01.2020 18:37, peter green wrote: Package: qemu-block-extra Version: 1:4.2-1 Severity: serious The binary packages built from the ceph source package were recently removed from mipsel

Re: possible bug in auto-removals.

On 16/12/2019 21:02, Paul Gevers wrote: Hi Peter, On 16-12-2019 01:21, peter green wrote: I have been observing a number of python cruft packages that are still in testing recently, and I noticed that there seems to be an issue with an auto-removal. cruft has never been supposed to be in

possible bug in auto-removals.

I have been observing a number of python cruft packages that are still in testing recently, and I noticed that there seems to be an issue with an auto-removal. My understanding is that auto-removals is supposed to keep track of reverse dependencies and initially delay auto-removal, then later,

astroid2 removal from testing (after removal from unstable)

astroid2 was removed from unstable a couple of weeks ago. However it is still in testing, britney claims. trying: -astroid2 skipped: -astroid2 (424, 28, 295) got: 32+0: a-1:a-0:a-0:a-0:i-28:m-2:m-0:p-0:s-1 * mips64el: python-guiqwt, python3-guiqwt However neither of those packages s

Haskell binnmus is there a problem?

Recently I noticed that haskell binnmus no longer seemed to be happening. For example mediawiki2latex has no been BD-Uninstallable since it was uploaded 24 days ago and https://buildd.debian.org/status/architecture.php?a=arm64&suite=sid doesn't show any haskell binnmus currently being built (th

Bug#892073: transition: poppler

There's also the libpoppler SONAME bump. All rdeps build fine except for pdf2djvu and xpdf. I'll file bugs for those. calligra and ipe-tools are also failing. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911502 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911503 Is the claim in https:

Bug#908980: transition: qrencode (ongoing, apparently uncoordinated)

Package: release.debian.org Severity: normal User:release.debian@packages.debian.org Usertags: transition Control: forwarded -1https://release.debian.org/transitions/html/auto-qrencode.html Control: block -1 by 908929 X-Debbugs-CC:qrenc...@packages.debian.org oops, send this to the list inst

transition: qrencode (ongoing, apparently uncoordinated)

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-qrencode.html Control: block -1 by 908929 X-Debbugs-CC: qrenc...@packages.debian.org Hi debian-release, I thought

Bug#903211: release.debian.org: How to handle unbuildable packages in buster

(note: I am not a member of the release team, just a dd who spots a load of build-depency issues in testing as part of running a derivative) I thought testing with dose-builddebcheck already happened routinely but can't find it. Any historical perspective on that? There is https://qa.debian.

Re: Fixing Linux getrandom() in stable

I don't see any general solution that is both correct and easy. I don't think there is one. In an ideal world all our computers would have a trusted source of true randomness. In practice that is not the case. Older computers don't have a hardware random number generator at all and newer compu

Bug#894049: transition: ncurses

I suspect fpc will also need a sourceful upload for the new ncurses. I would recommend not binnmuing it until the maintainers have had chance to take a look. Is there a full list of differences between the version 5 and 6 ABIs anywhere? chtype has already been mentioned, are there any others?

Status of the marble package.

Marble currently FTBFS in unstable due to a couple of missing symbols and this is preventing the libgps transition from finishing up. The version in experimental fixes the issue but it looks like uploading it to unstable would start a transition. What are the plans here? are the symbols that d

Bug#879520: transition: rtmidi

Block 879520 by 880848 Thanks python-rtmidi still needs attention for this transition to complete. The binnmu built succesfully but the resulting package still depends on the old rtmidi.

Re: What is going on with gtkdatabox?

On 24/11/16 09:04, Andreas Tille wrote: The other problem is that libgtkdatabox-0.9.2-0-dev should not be any more in the pool at all and I have no idea why this is the case. Binary packages that are no longer built by a source package are not removed instantly, they will be cleaned up by t

What is going on with gtkdatabox?

As a derivative maintainer I noticed that there appears to be a gtkdatabox transition going on. Looking at the list archives for debian-release I see no mention of it on there. Specifically it seems that the libgtkdatabox source package has renamed every binary package it generates. libgtkda

Bug#836530: nmu: lazarus_1.6+dfsg-4

nmu lazarus_1.6+dfsg-4 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to fix glibc> 2.23 related issues" Minor nitpick, the working powerpc fix didn't land until -8 nmu pasdoc_0.14.0-1 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to fix glibc> 2.23 related issues" nmu

Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)

> Fixed package is in sid (5.0-3) since Fri, 15 Jul I have installed this on the main raspbian server and I can confirm it works for us with wanna-build. Note1: I had to update wanna-build, the version of wanna-build I had (which was not bang up to date but not all that old either) wouldn't

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

2016-07-02 17:53 GMT+03:00 Otto Kekäläinen: > This is modeled after how default-jdk or default-mta works. Actually default-jdk is a real metapackage, while default-mta is a pure virtual package. I am not sure which way to pick here now. https://packages.debian.org/jessie/default-mta https://pa

Re: [Stretch] Status for architecture qualification

On 07/06/16 19:38, Martin Michlmayr wrote: * Steve McIntyre [2016-06-06 15:14]: However, I will admit (again) that armel is starting to lose upstream support in some cases. I'm tempted to suggest that Stretch should be the last release for armel for that reason. Which upstream proble

Re: [Stretch] Status for architecture qualification

On 05/06/16 23:01, Wookey wrote: Ok, so a total of 6 shared between the two architectures? Thats what it looks like to me. And I think we are building armhf on the arm64 build machines too? I don't think so. At least I see no evidence of it on buildd.debian.org .

Re: [Stretch] Status for architecture qualification

On 05/06/16 11:01, Niels Thykier wrote: all arm ports have DSA concerns. Is there a current reference to what these concerns are? Is there still a lack of out of band management? (the old mail I found on the topic said it was "being worked on", sledge whats the status here?) are there othe

Re: [Stretch] Status for architecture qualification

On 05/06/16 13:00, Holger Levsen wrote: On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote: ppc64: This architecture is basically on par with the release architectures. We have over 11.000 packages installed [...] sparc64: We are close to 11.000 installed

Bug#765639: Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version

The dhparam thing is really about a default that if you generate DH parameters that it defaults to 2048 instead of 1024. This shouldn't break anything itself, nor do I know of any other software that would get broken by this. Apparently Java 6 and 7 will fail to handshake if a server tries to us

Re: ongoing libkdegames transition.

On 17/10/15 10:48, Maximiliano Curia wrote: Hi, On 17/10/15 03:55, peter green wrote: There appears to be a transition going on with the libkdegames source package which seems to require sourceful changes in the rdeps. A substantial number of rdeps have transitioned but a substantial

Bug#802031: nmu: pytaglib_0.3.6+dfsg-2 (arm64/ppc64el)

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Libstdc++6 declares a breaks on python3-taglib (<= 0.3.6+dfsg-2+b2), presumablly as part of the big c++ ABI transition. However the binnmu versions are out of sync across architectures lea

ongoing libkdegames transition.

There appears to be a transition going on with the libkdegames source package which seems to require sourceful changes in the rdeps. A substantial number of rdeps have transitioned but a substantial number have not and no bug reports seem to have been filed on said rdeps, nor does there seem to

Bug#798198: nmu: psi4_4.0~beta5+dfsg-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu There were problems with using psi4 built with gcc-4.9 with a gcc-5 libstdc++6. As a result a breaks was added to libstdc++6 and psi4 was binnmu'd. However the binnmus on arm64 and ppc64e

Bug#791824: nmu: starpu_1.1.4+dfsg-1

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu starpu_1.1.4+dfsg-1 . ALL . -m "Rebuild for gcc 4.9.3" starpu seems to have a strict dependency against the version of gcc-4.9 it was built against. This is blocking the migration of 4.9

Bug#789365: Re: Bug#789365: transition: ghc-7.8

This may need a binNMU: haskell-trifecta (1.4.3-1 to 1.5.1.3-4) Maintainer: Debian Haskell Group 9 days old (needed 5 days) libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-charset-dev-0.3.7.1-1690c libghc-trifecta-dev/ppc64el unsatisfiable Depends: libghc-comonad-

Re: Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.

Reopen 782976 Thanks. On 24/04/15 22:49, Jonathan Wiltshire wrote: On Mon, Apr 20, 2015 at 02:17:25AM +0100, peter green wrote: Release team: can you clarify whether you intend to actually remove kfreebsd from the jessie suite of the official archive before/during the jessie release

Re: Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.

Release team: theres a question for you at the end of the mail. On 20/04/15 00:49, Cyril Brulebois wrote: peter green (2015-04-20): Package: debian-installer-netboot-images Severity: serious The RC policy states "Packages must be buildable within the same release.". In this

Bug#769044: unblock (pre-approval): xfce4-notes-plugin

Jonathan Wiltshire wrote: Looks ok to me. Ok, the maintainer has now made an upload which is substantially the same* as my proposal. The upload has built successfully on all release architectures. unblock xfce4-notes-plugin/1.7.7-5 * he reworeded the changelog entry, used a non-nmu versio

Bug#769371: unblock: umockdev/0.8.8-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package umockdev Version 0.8.8-1 of umockdev failed to build on arm64 with a testsuite failure and as a result we currently have an out of data umockdev in arm64 testing. Th

Bug#769044: unblock (pre-approval): xfce4-notes-plugin

Control: tag -1 -moreinfo I think you meant the "non-attatched" debdiff. ;p Doh, here it is. diff -Nru xfce4-notes-plugin-1.7.7/debian/changelog xfce4-notes-plugin-1.7.7/debian/changelog --- xfce4-notes-plugin-1.7.7/debian/changelog 2014-10-15 19:19:50.0 + +++ xfce4-notes-plug

Bug#769044: unblock (pre-approval): xfce4-notes-plugin

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I'm seeking approval for fixing the arm64 build failure in xfce4-notes-plugin. The package FTBFS due to outdated config.sub/guess. The maintainer doesn't have a problem with the changes but

Bug#767759: unblock: tightvnc/1.3.9-6.5

Tags 767759 -moreinfo Thanks peter green wrote: The package is now uploaded and built on all release architectures except mips. On mips it's currently sitting in needs-build. The package is now built successfully on all release architectures -- To UNSUBSCRIBE, email to debian-release

Bug#767895: TPU binnmus for arm64 and ppc64el

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu When looking through the list of packages that are uninstallable in arm64 testing I belive the following TPU binnmus are appropriate towards the goal of pushing the list of uninstallable arch

Bug#767759: unblock: tightvnc/1.3.9-6.5

Jonathan Wiltshire wrote: Control: tag -1 moreinfo On Sun, Nov 02, 2014 at 01:55:30PM +, peter green wrote: This upload of tightvnc adds arm64 support to the packages build system. The code is all behind conditionals so it shouldn't affect other architectures. This is needed to

Bug#767759: unblock: tightvnc/1.3.9-6.5

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package tightvnc This upload of tightvnc adds arm64 support to the packages build system. The code is all behind conditionals so it shouldn't affect other architectures. Thi

Bug#767714: nmu: lhapdf_5.9.1-3

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu lhapdf_5.9.1-3 . arm64 . -m "Rebuild against octave 3.8" The lhapdf package on arm64 was actually built against octave 3.8, unfortunately it's not installable because octave declares Bre

Re: Debian/ppc64el feasiability to become an official architecture

Breno Leitao wrote: Hi Peter, Thank you for your reply. On 07/24/2014 08:14 PM, peter green wrote: Note: this is the perspective of a dd who is not directly involved with powerc though I have come across some of your bug reports, nor am I a member of the ftp or release teams. It&#

Re: Debian/ppc64el feasiability to become an official architecture

Lennart Sorensen wrote: On Fri, Jul 25, 2014 at 12:14:08AM +0100, peter green wrote: Another question the ftpmasters will likely have is what is the relationship between ppc64 and ppc64el. Is there hardware that will run ppc64 but not ppc64el? is there hardware that will run ppc64el but not

re: Debian/ppc64el feasiability to become an official architecture

Note: this is the perspective of a dd who is not directly involved with powerc though I have come across some of your bug reports, nor am I a member of the ftp or release teams. It's probablly mostly right but i'm sure others will point out any errors. I would like to share the ppc64el port's

p11-kit needs binnmu on kfreebsd-* for new libc0.1

While looking at the buildd pages for liblas I noticed the following BD-Uninstallable explanation for kfreebsd-* liblas build-depends on: - libgdal-dev (>= 1.10.0~) libgdal-dev depends on: - libcurl4-gnutls-dev libcurl4-gnutls-dev depends on: - libgnutls-dev libgnutls-dev depends on: - libgnutls

Please binnmu numpy to support python 3.4

While looking at build failures in raspbian I noticed that numpy could not be imported in python 3.4 ( http://buildd.raspbian.org/status/fetch.php?pkg=pandas&arch=armhf&ver=0.13.1-2&stamp=1392881756 ) . I confirmed that this was not a raspbian specific issue by testing on debian armel. I brou

Bug#731261: transition: Qt5 switching qreal == double for all platforms

Please check qgis, that did FTBFS on arm* with deduced conflicting types for parameter 'const T' ('double' and 'qreal {aka float}') qgis seems to be using qt4. The qreal==double on all platforms switch was only for qt5 (it's way too late to make such a change in qt4 now). -- To UNSUBSCR

Bug#731902: nmu: transmission_2.82-1

Julien Cristau wrote: That'll hopefully fix itself (or at least get better) once qt 5.2 hits sid, as that's built on many more archs. QT 5.2 has now hit sid but transmission is still in bd-uninstallable on four release architectures where it has built in the past. kfreebsd-*: blocked by bui

Re: A new metric for source package importance in ports

Johannes Schauer wrote: Hi, the following is a report of a successful implementation of what I have been talking about with Niels Thykier during debconf13. The question was how important it is for a source package to be compilable or exist in the first place given an incomplete port which is in

Nullmailer can waste massive ammounts of bandwidth and is IMO unfit for release.

I just ran into a particularlly nasty instance of bug 329192 As described in that bug nullmailer ignores permanent errors, has an agressive retry policy and never times out messages stuck in the queue. If a message that is too large for the smarthost to accept gets into the queue this can was

Re: Roll call for porters of architectures in sid and testing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I have an interest in debian on arm devices. My main interest in such devices is for their ability to act as (relatively) low power gateways between embedded hardware and networks such as the internet. I helped with bringing armhf up to release a

migration of libgeotiff-dfsg and liblas

I noticed libgeotiff-dfsg was not migrating to testing and discovered that the reason was that liblas needed updating to also use libtiff5-alt-dev. I prepared such an update and when I got no maintainer response I NMUd it. That NMU has now reached migration age but it doesn't seem to be getting

Bug#706866: [Fwd: re: Bug#706866: transition: libarchive]

Forwarding reply to my query to the bug report. Original Message Subject:re: Bug#706866: transition: libarchive Date: Mon, 6 May 2013 20:17:37 -0400 From: Andres Mejia To: peter green References: <518842df.1000...@p10link.net> Yes, I plan on dis

Bug#706866: transition: libarchive

I am requesting a transition from libarchive12 to libarchive13. libarchive13 is from the latest release of libarchive (3.1.2). A soname bump was done upstream due to some ABI changes, specifically with HFS support. I notice the most recent experimental upload FTBFS on many architectures with

Bug#704769 Libarchive FTBFS on s390x sid buildds.

Package: libarchive Version: 3.0.1b-1 Severity: serious Note: this bug report is a continuation of discussions in the unblock bug for libarchive ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704080 ). my personal guess is that there's probably nothing s390x-specific to it, it's probably br

Bug#704080: unblock: libarchive/3.0.4-3

It seems that Adam D. Barratt unblocked libarchive to fix the security bug. Unfortunately that wasn't enough to get the package into testing. Specifically it seems that s390x has not successfully built this package for some time (since before s390x stopped being considered a "broken and fucked

Bug#704159: unblock (pre-approval) : clang/1:3.0-6.2

Jonathan Wiltshire wrote: I'd rather not have the DEP-3 boilerplate in your first patch; with that removed, please go ahead with an upload to unstable and ping this bug when it is ready. Done. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe

Bug#704159: unblock (pre-approval) : clang/1:3.0-6.2

peter green wrote: Debdiff is attatched Sorry forgot to attatch it, here it is. diff -Nru clang-3.0/debian/changelog clang-3.0/debian/changelog --- clang-3.0/debian/changelog 2013-02-10 14:47:29.0 + +++ clang-3.0/debian/changelog 2013-03-28 18:03:16.0 + @@ -1,3 +1,16

Bug#704159: unblock (pre-approval) : clang/1:3.0-6.2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please approve my upload for package clang, this fixes two issues one of which is filed as a grave bug. The other I also judge to be grave but is not currently filed as a bug in debian (if y

Re: e2fsprogs_1.42.5-1.1_amd64.changes ACCEPTED into unstable

Ok, I can see how it can be confusing. who-uploads does show that it was my gpg signature on the upload. It's just this way I sponsor any other uploads were the code/changes I am not the author of. IMO there is a big difference between asking someone to sponsor and posting a patch to the BTS. I

Re: [Raspbian-devel] libpam-ubico and signed char on arm in debian and derivatives

Simon Josefsson wrote: tor 2013-03-07 klockan 13:51 + skrev peter green: I am a cofounder of a project called raspbian to provide a hard float derivative of debian for the raspberry pi. A user reported a bug to us about libpam-ubico related (so the reported claims) to char signedness

  1   2   >