Bug#790512: urweb: FTBFS - latex: Command not found

Control: tag -1 patch -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#831088: urweb: FTBFS with GCC 6: memmem.c:77:17: error: this 'if' clause does not guard... [-Werror=misleading-indentation]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 tags 831088 upstream pending forwarded 831088 https://github.com/urweb/urweb/issues/36 thanks -BEGIN PGP SIGNATURE- iQF8BAEBCgBmBQJXj61cXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w

Bug#852645: dafny: FTBFS

Thanks for looking into this. You’re right – it looks like Dafny’s having some trouble linking against Boogie. The Dafny build process statically links Boogie into Dafny; that’s why cp -a /usr/lib/boogie/* Binaries mkdir -p Source/Dafny/bin/Checked cp -a /usr/lib/boogie/*

Bug#821883: ImportError: When using gi.repository you must not import static modules like "gobject"

Package: morituri Version: 0.2.3-2 Followup-For: Bug #821883 I can reproduce this as well. Unlike Martin, I was able to get 0.2.3-1 from Jessie installed, and that version seems to work fine. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990,

Bug#821883: ImportError: When using gi.repository you must not import static modules like "gobject"

Sounds good to me. I've filed an RFP (https://bugs.debian.org/850541). Would you like to take it? I'm also happy to package.

Bug#852645: dafny: FTBFS

1.9.8 builds fine, but that’s a 30,000-plus-LoC diff from 1.9.7, so trying to get the new version into Stretch seems unlikely at this point. I suspect cherry-picking upstream’s dc724533490f66bb553d71be1b971f2008318adc and e7cfcf3eb135c378d12c04f35d9f85f6cb241467 commits into 1.9.7 would be

Bug#852645: dafny: FTBFS

I'm looking at this now.

Bug#852645: dafny: FTBFS

I’m still planning to look at this, though I haven’t had the chance yet.

Bug#871572: urweb FTBFS with gcc 7 on arm64 and mips64el: test failure

On Thu, Aug 24, 2017 at 10:03 PM, Benjamin Barenblat <bba...@mit.edu> wrote: > […] I’ve determined that the problematic optimization on both platforms > is -fcode-hoisting […]. While this doesn’t eliminate either a bug in > MLton or in GCC, it does provide a workaround for this

Bug#871572: urweb FTBFS with gcc 7 on arm64 and mips64el: test failure

On Wed, Aug 9, 2017 at 8:40 AM, Adrian Bunk wrote: > Source: urweb > Version: 20170720+dfsg-1 > Severity: serious > > […] > > https://buildd.debian.org/status/package.php?p=urweb=sid I’m able to reproduce this on asachi, the arm64 porterbox. However, vanilla upstream builds

Bug#871572: urweb FTBFS with gcc 7 on arm64 and mips64el: test failure

On Mon, Aug 21, 2017 at 10:02 AM, Benjamin Barenblat <bba...@mit.edu> wrote: > I did an arm64 build with -O1 (i.e., I put > > export DEB_CFLAGS_MAINT_APPEND := -O1 > > in debian/rules), and everything worked fine […]. I’m doing a mips64el > build with -O1 right

Bug#919462: coq ftbfs on some release architectures

Control: retitle 919462 coq FTBFS on architectures without native OCaml backends Control: owner 919462 ! Coq actually does build, but the test suite fails because I messed up plugin loading on architectures that don’t have ocamlopt. Upstream handles both native and bytecode worlds by installing

Bug#919461: ssreflect ftbfs in unstable

Control: retitle 919461 ssreflect FTBFS in unstable due to missing ssrmatching Control: owner 919461 ! That’s my fault. In my most recent Coq upload, I disabled ssrmatching and a couple of other plugins due to license concerns [1]. Those have now been resolved upstream [2]. I’m going to backport

Bug#918633: why3-coq: package should Depend on a specific Coq version

Package: why3-coq Version: 1.1.1-1 Severity: serious why3-coq Depends on coq, but it contains compiled .vo files that can only be read by Coq 8.6. (In general, Coq .vo files are tied to the minor version of Coq that produced them.) why3-coq should Depend on the minor version of Coq that compiled

Bug#919461: ssreflect ftbfs in unstable

Control: retitle 919461 ssreflect FTBFS in unstable Control: noowner 919461 I’m guessing this is just that 1.6.1 is not compatible with Coq 8.9. Uploading 1.7.0 might resolve the issue, but I’m uninterested in doing that work, particularly since the package is licensed under CeCILL-B, which I

Bug#919462: coq ftbfs on some release architectures

Control: tag 919462 + pending Sorry for the radio silence. I misdiagnosed the issue in #10, but I have properly diagnosed it now and have a fix pending. I’m rolling the fix into my upload of 8.9.0, which should be coming in the next day.

Bug#934950: dafny: unsatisfiable build-dependency in sid

Having dafny drop out of the archive would be fine with me – I’ve had an active RFA out for over a year (https://bugs.debian.org/903143), and nobody seems interested. I’ll officially orphan it and request ftpmaster removal.

Bug#949537: elpa-elfeed-web: depends on CSS and JavaScript not in Debian

Package: elpa-elfeed-web Version: 3.1.0-1 Severity: serious Control: block -1 by 902083 Control: found -1 3.3.0-1 elfeed-web uses Foundation [1], AngularJS [2], and URI.js [3], loading them from various CDN sites in index.html: AngularJS is included in main, but Foundation and

Bug#959675: libgrpc++1: endless looping with default settings

That sounds 100% feasible. I’ll give Abseil packaging some more attention this week and get back in touch.

Bug#959675: libgrpc++1: endless looping with default settings

On Sunday, May 3, 2020, at 8:16 PM +0200, László Böszörményi (GCS) wrote: > Benjamin, do you want to package and maintain [Abseil] instead? I’ve been working on packaging it for the last few weeks, and I’m making good progress. Would an upload this week fit your timetable?

Bug#970333: abseil: autopkgtest needs update for new version of cmake: warning on stderr

Control: owner 970333 ! Control: tags 970333 + pending upstream fixed-upstream Control: forwarded 970333 https://github.com/abseil/abseil-cpp/issues/668 This is a bug in upstream’s CMake support. I’ll patch in their fix

Bug#972827: libgiac-dev: should include config.h

Package: libgiac-dev Version: 1.4.9.69+dfsg1-2 Severity: grave Many Giac headers #include "config.h", and they use its contents in such a way that config.h is essential to define the library ABI. (For example, some members are gated behind #ifdef HAVE_LIBPTHREAD.) Developing against Giac without

Bug#966183: abseil FTBFS on !amd64/ppc64: missing symbols

On Friday, July 24, 2020, at 2:58 PM +0300, Adrian Bunk wrote: > When the soname of the library encodes the exact upstream > version as abseil does, there are exactly zero benefits > of using a symbols - every update of abseil will be a > library transition in any case. Makes sense. I was hoping

Bug#1002707: katex: needs Depends: node-commander

Package: katex Version: 0.10.2+dfsg-8 Severity: serious Installing katex without node-commander yields an unusable katex executable. $ katex internal/modules/cjs/loader.js:818 throw err; ^ Error: Cannot find module 'commander' Require stack: -

Bug#1002708: python3-gleetex: needs Depends: dvisvgm

Package: python3-gleetex Version: 3.1.0-1 Severity: serious SVG output from GleeTeX relies on executing dvisvgm; if that's not installed, attempting to emit SVG will throw an exception. Either GleeTeX or GladTeX needs Depends: dvisvgm; since python3-gleetex already has Depends: dvipng, it seems

Bug#1012885: closing 1012885

close 1012885 0~20220623.0-1 thanks

Bug#1037567: abseil: ftbfs with GCC-13

I’ve been procrastinating on starting the transition because of some lingering MIPS issues. I think they’ve all been sorted out, and I just uploaded my latest work to experimental. If that passes the buildds, I’ll request a transition slot and do the transition as quickly as possible. If waiting

Bug#1037567: abseil: ftbfs with GCC-13

Thank you for the patch, Aurelien! I’ve applied it to the 20220623.1 release and uploaded it to unstable as 20220623.1-2.