Processed: transition: json-c

Processing control commands: > block 844452 by -1 Bug #844452 {Done: Nicolas Braud-Santoni } [src:json-c] Updating the json-c Uploaders list 844452 was blocked by: 901726 844452 was not blocking any bugs. Added blocking bug(s) of 844452: 904418 > retitle 844452 Orphan json-c Bug #844452 {Done:

Bug#904418: transition: json-c

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block 844452 by -1 Control: retitle 844452 Orphan json-c Hi, I need to request a transition slot for json-c; the autogenerated tracker [0] seems correct, and I will also need

Re: Building armel on arm64

On Tue, Jul 24, 2018 at 07:27:15AM +0100, Steve McIntyre wrote: >... > The next big problem I can see is in our haskell packages for > armhf. From my build log for haskell-zxcvbn-c_1.0.1-4.log (as an > example): > > ... > Setting up llvm-3.9 (1:3.9.1-19+b1) ... > Setting up ghc (8.2.2-4) ... >

Re: Building armel on arm64

Apologies for delayed response - I've been horrendously busy. :-/ On Sun, Jul 08, 2018 at 11:03:12PM +0300, Adrian Bunk wrote: >On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote: >>... >> armel/armhf: >> >> >> * Undesirable to keep the hardware running beyond 2020.

Re: Building armel on arm64

On Tue, Jul 24, 2018 at 11:22:36AM +0300, Adrian Bunk wrote: >On Tue, Jul 24, 2018 at 07:27:15AM +0100, Steve McIntyre wrote: >>... >> The next big problem I can see is in our haskell packages for >> armhf. From my build log for haskell-zxcvbn-c_1.0.1-4.log (as an >> example): >> >> ... >>

Re: Building armel on arm64

Adrian Bunk wrote... > I'd like to get a clear picture regarding the situation of building > armel for buster on arm64, ideally moving it to arm64 hardwre soon. JFTR, I'd appreciate if armel/armhf could continue to be part of a release. > 1. What issues are considered possible problems for

Re: Building armel on arm64

On 07/24/2018 08:43 PM, Christoph Biedl wrote: > Perhaps just babble and FUD: There was (and probably still is) an issue > in powerpc: In a certain package, upstream's compile options for ppc had > higher CPU requirements than what Debian uses for that architecture. As > a result, the buildd (some

Processed: Re: RM: martian-modem/20080625-2

Processing commands for cont...@bugs.debian.org: > reassign 904483 ftp.debian.org Bug #904483 [release.debian.org] RM: martian-modem/20080625-2 Bug reassigned from package 'release.debian.org' to 'ftp.debian.org'. Ignoring request to alter found versions of bug #904483 to the same values

Bug#904533: nmu: openrpt_3.3.14-1~bpo9+1

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu openrpt_3.3.14-1~bpo9+1 . amd64 . stretch-backports . -m "Rebuild in a clean stretch environment." libopenrpt1v5 (3.3.14-1~bpo9+1) is currently uninstallable in stretch(-backports):

Bug#904545: dw: irssi-plugin-otr_1.0.2-4 irssi-plugin-robustirc_0.6-4 irssi-plugin-xmpp_0.54-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, please binNMU the irssi plugins for the last irssi upload. I did a local test build to confirm that they don't need any source change. So long, Rhonda dw

Bug#904483: RM: martian-modem/20080625-2

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Dear RT. Please remove martian-modem from the Debian Archive. There are several reasons why to do so, first of all this software provides kernel+user space support for quite ancient i386

Bug#904483: RM: martian-modem/20080625-2

Am 24.07.2018 um 18:53 schrieb Dererk: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > Dear RT. > > Please remove martian-modem from the Debian Archive. > > There are several reasons why to do so, first of all this software >