Bug#1068738: gfeeds: python failure at startup
Package: gnome-feeds Version: 2.2.0-2 Severity: grave Hello, after a recent dist-upgrade to unstable, gfeeds crashes at startup. This makes the package unusable. -Ralf. % gfeeds Traceback (most recent call last): File "/usr/bin/gfeeds", line 75, in from gfeeds import __main__ File "/usr/lib/python3/dist-packages/gfeeds/__main__.py", line 9, in from gfeeds.app_window import GFeedsAppWindow File "/usr/lib/python3/dist-packages/gfeeds/app_window.py", line 2, in from gfeeds.main_leaflet import MainLeaflet File "/usr/lib/python3/dist-packages/gfeeds/main_leaflet.py", line 11, in from gfeeds.webview import GFeedsWebView File "/usr/lib/python3/dist-packages/gfeeds/webview.py", line 4, in from gfeeds.util.build_reader_html import build_reader_html File "/usr/lib/python3/dist-packages/gfeeds/util/build_reader_html.py", line 4, in from gfeeds.util.readability_wrapper import RDoc File "/usr/lib/python3/dist-packages/gfeeds/util/readability_wrapper.py", line 3, in from readability.readability import * File "/usr/lib/python3/dist-packages/readability/__init__.py", line 3, in from .readability import Document File "/usr/lib/python3/dist-packages/readability/readability.py", line 11, in from .cleaners import clean_attributes File "/usr/lib/python3/dist-packages/readability/cleaners.py", line 3, in from lxml.html.clean import Cleaner File "/usr/lib/python3/dist-packages/lxml/html/clean.py", line 18, in raise ImportError( ImportError: lxml.html.clean module is now a separate project lxml_html_clean. Install lxml[html_clean] or lxml_html_clean directly. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-feeds depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 ii gir1.2-adw-1 1.5.0-1 ii gir1.2-webkit-6.02.44.1-1 ii python3 3.11.8-1 ii python3-arrow1.3.0-1 ii python3-bs4 4.12.3-1 ii python3-feedparser 6.0.10-1 ii python3-gi 3.48.2-1 ii python3-html5lib 1.1-6 ii python3-humanize 4.9.0-1 ii python3-listparser 0.18-3 ii python3-lxml 5.2.1-1 ii python3-magic2:0.4.27-3 ii python3-pil 10.3.0-2 ii python3-pygments 2.17.2+dfsg-1 ii python3-readability 0.8.1+dfsg1-3 ii python3-requests 2.31.0+dfsg-1 ii python3-syndom 1.0-2 ii python3-tz 2024.1-2 ii xdg-utils1.1.3-4.1 gnome-feeds recommends no packages. gnome-feeds suggests no packages. -- no debconf information
Bug#1050407: tycho: build-depends on obsolete libeclipse-osgi-util-java
Source: tycho Version: 1.6.0-3 Severity: serious Tags: ftbfs Hi, tycho build-depends on libeclipse-osgi-util-java which only exists in oldstable (and older). -Ralf.
Bug#1050402: aws-shell: build-depends on obsolete version of awscli
Source: aws-shell Tags: ftbfs Version: 0.2.1-1 Severity: serious Hi, aws-shell build-depends on awscli (<< 2.0.0). However, the current version of awscli in sid is 2.12.0-1. -Ralf.
Bug#1050400: aws-checksums: build-depends on non-existing libaws-c-common-dev
Source: aws-checksums Severity: serious Tags: ftbfs Version: 0.1.13-1 Hi, aws-checksums build-depends on libaws-c-common-dev which does not exist anywhere in the archive. This is the case since 2022-11-10. -Ralf.
Bug#1041164: dose-distcheck: fails with (W)Dose_common: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe"
For the record : this seems to be related to the option "--latest 1" discarding Essential packages. Here is a minimal Packages file for reproducing the bug: Package: aa Source: aa Version: 1 Essential: yes Architecture: all Package: aa Source: aa Version: 2 Architecture: all -Ralf.
Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe
Hi Raphaël, On Thu, Aug 17, 2023 at 02:07:22PM +0200, Raphael Hertzog wrote: > Hello Ralf, > > Le samedi 15 juillet 2023, Ralf Treinen a écrit : > > In fact it is not related to dose-distcheck being outdated on quantz, I > > get the same error with dose-distcheck on sid. > > > > Since I do not have time to dig further into this atm (leaving for vacation) > > I have now desactivated the unstable_main scenario, which is the only > > one where the error is occurring. > It would be nice if it could be revived. :) Do you have an idea when you > will be able to dig further? I will look into this today. Anyway, it seems that the error does no longer occur with Packages files produced after August 10 (at least). Cheers -Ralf.
Bug#1041164: dose-distcheck: fails with (W)Dose_common: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe"
Package: dose-distcheck Version: 7.0.0-1+b2 Affects: #1040757 dose-debcheck fails on recent unstable main packages file, independently of the architectures : % dose-debcheck -e -f --latest 1 --deb-native-arch=amd64 --fg=/home/rt/dose.debian.net/mirror/unstable/main/binary-amd64/Packages > sid-main-amd64.out (W)Dose_common: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe The applications raised this exception : Not_found
Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe
In fact it is not related to dose-distcheck being outdated on quantz, I get the same error with dose-distcheck on sid. Since I do not have time to dig further into this atm (leaving for vacation) I have now desactivated the unstable_main scenario, which is the only one where the error is occurring. -Ralf.
Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe
Hello, On Mon, Jul 10, 2023 at 01:35:44PM +0800, Paul Wise wrote: > Package: qa.debian.org > Severity: important > User: qa.debian@packages.debian.org > Usertags: dose > X-Debbugs-CC: Ralf Treinen > > The dose cron job has been producing these errors since 2023-07-02: [...] The version of dose-distcheck installed on quantz is very old (5.0.1-12, form oldoldstable). The version in bookworm is 7.0.0-1+b2. I can't tell yet whether more recent versions of dose fix the problem, but do you have plans for upgrading quantz ? Cheers -Ralf.
Bug#486226: ocaml-mode: caml-mode bogusly binds C-c combinations
Hello, I have tagged this bug as wontfix. What you ask for is too invasive on users of caml-mode, changing these key bindings would mean that users of the debian package will have completely different key bindings than users of the upstream package. Best -Ralf.
Bug#1029314: RM: coccinelle [armhf] -- ROM; compilation on armhf crashes "out of memory"
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: coccine...@packages.debian.org Control: affects -1 + src:coccinelle Hi, compilation of coccinelle on armhf keeps on failing with message "out of memory", which blocks migration to testing. -Ralf.
Bug#984229: mccs: diff for NMU version 1:1.1-9.1
Hi Adrien, On Mon, Jan 16, 2023 at 07:34:53PM +0200, Adrian Bunk wrote: > I've prepared an NMU for mccs (versioned as 1:1.1-9.1) and uploaded > it to DELAYED/14. Please feel free to tell me if I should cancel it. thanks a lot, I just uploaded version 1.1-10, which includes your patch, to unstable. Cheers -Ralf.
Bug#1023712: why3 breaks frama-c (autopkgtest): missing versioned Breaks?
Hi Paul, On Wed, Dec 21, 2022 at 09:16:32PM +0100, Paul Gevers wrote: > Control: reassign -1 frama-c > > Dear maintainers, > > On Tue, 8 Nov 2022 21:53:18 +0100 Paul Gevers wrote: > > [kernel] User Error: cannot load plug-in 'frama-c-wp': cannot load module > >Details: implementation mismatch on Why3 > > [kernel] User Error: Deferred error message was emitted during > > execution. See above messages for more information. > > [kernel] Frama-C aborted: invalid user input. > > autopkgtest [20:18:19]: test eva > > I'm now seeing the above error message in the frama-c test in testing, so it > seems that the issue is rather that the autopkgtest of frama-c doesn't > properly declare it's *versioned* test dependency on why3? Should the > Recommends be versioned? (Not sure if that actually works as intended, but > apparently the tested plug-in only works correctly with the right version of > why3). Sorry for not replying earlier, the last weeks have been very busy at work. The problem is that for some reason the package build of frama-c does not pick up the versioned dependency on libwhy3-ocaml-dev (this should be done by dh_ocaml). I'm looking into this now. Cheers -Ralf.
Bug#1025733: libxmlada: unsatisfiable buil-dependency on unicode-data
Source: libxmlada Version: 22.0.0-3 Severity: serious Hi, libxmlada build-depends (in Build-Depends-Arch) on unicode-data (>= 14~), unicode-data (<< 15~) but the version of unicode-data in sid is 15.0.0-1. -Ralf.
Bug#1025731: libghc-pcre-light-doc: depends on non-existing haddock-interface-35
Package: libghc-pcre-light-doc Version: 0.4.1.0-1 Severity: serious libghc-pcre-light-doc cannot be installed since it depends on haddock-interface-35 which does not exist in sid. -Ralf.
Bug#1023357: python3-morse-simulator: depends on non-existing python3 (< 3.9)
Package: python3-morse-simulator Version: 1.4-6+b1 Severity: serious Hi, python3-morse-simulator depends on python3 (< 3.9) which is only satisfiable in oldstable or older. -Ralf.
Bug#1023356: libdune-pdelab-dev: unsatisfiable dependency on libdune-common-2.7.0
Package: libdune-pdelab-dev Version: 2.7~20200605-2 Severity: serious Hi, this package depends on libdune-common-2.7.0 which does not exist in sid. -Ralf.
Bug#1023355: limereg: depends on non-existing libboost-program-options1.67.0
Package: limereg Version: 1.4.1-4+b1 Severity: serious Hi, limereg depends on libboost-program-options1.67.0 which only exists in oldstable. -Ralf.
Bug#1023173: freeture: not installable, depends on libaravis-0.6-0
Package: freeture Version: 1.3.0-1+b1 Severity: serious Hi, freeture is not installable in sid as it depends on libaravis-0.6-0, which only exists in oldstable. -Ralf.
Bug#1023172: dropwatch: not installable since dependency on outdated libbinutils
Package: dropwatch Version: 1.5.3-1+b2 Severity: serious Hi, dropwatch is not installable in sid as it depends on libbinutils (< 2.35.1), however the current version of that package in sid is 2.39-8. -Ralf.
Bug#1023171: cernlib: unsatisfiable dependency on geant321-doc
Package: cernlib Version: 20061220+dfsg3-4.4 Severity: serious Hi, cernlib is not installable in sid as it depends on geant321-doc, which is not available in sid. -Ralf.
Bug#1023116: gitlab-ci-multi-runner build-depends on non-existing golang-github-gorilla-context-dev
Source: gitlab-ci-multi-runner Version: 13.3.1+dfsg-4 Severity: serious Hi, gitlab-ci-multi-runner build-depends on golang-github-gorilla-context-dev but that package does not exist in sid any more (it only exists in stable and older). -Ralf.
Bug#1023114: libaws: build-depends on crufty libtemplates-parser14-dev
Source: libaws Version: 20.2-2 Severity: serious Hi, libaws build-depends on libtemplates-parser14-dev which is not installable, and which seems to be cruft since the current version of libtemplates-parser in sid produces libtemplates-parser15-dev . -Ralf.
Bug#664396: vsdump: Helping to update to packaging format 3.0
Raising severity to serious as dpatch is now removed from sid, which makes the package FTBFS. -Ralf.
Bug#1022927: libghc-aeson-dev depends on non-existing libghc-semialign-dev-1.2.0.1-ebc3a
Package: libghc-aeson-dev Version: 2.0.3.0-1+b4 Severity: serious Hi, libghc-aeson-dev on amd64c depends on libghc-semialign-dev-1.2.0.1-ebc3a which does not exist in the archive. The situation is the same on other arches with a different hash of libghc-semialign-dev-1.2.0.1. -Ralf.
Bug#1022867: libghc-persistable-record-doc: depends on non-existing haddock-interface-35
Package: libghc-persistable-record-doc Version: 0.6.0.5-1 Severity: serious Hi, libghc-persistable-record-doc depends on haddock-interface-35 but that package does not exist in the archive. -Ralf.
Bug#1022866: libghc-product-isomorphic-doc: depends on non-existing haddock-interface-35
Package: libghc-product-isomorphic-doc Version: 0.0.3.3-2 Severity: serious Hi, libghc-dice-doc depends on haddock-interface-35 but that package does not exist in the archive. -Ralf.
Bug#1022842: libghc-dice-doc: depends on non-existing haddock-interface-35
Package: libghc-dice-doc Version: 0.1.0.1-1 Severity: serious Hi, libghc-dice-doc depends on haddock-interface-35 but that package does not exist in the archive. -Ralf.
Bug#1022841: libghc-lambdabot-core-doc: unsatisfiable sdependency on haddock-interface-35
Package: libghc-lambdabot-core-doc Version: 5.3.0.1-1 Severity: serious Hi, libghc-lambdabot-core-doc depends on haddock-interface-35 but that package does not exist in the archive. -Ralf
Bug#1022796: haskell-heist unsatisfiable build-dependency libghc-aeson-dev < 1.5
Source: haskell-heist Version: 1.1.0.1-3 Severity: serious Hi, haskell-heist build-depends on libghc-aeson-dev (<< 1.5) but the version of that package in sid is 2.0.3.0-1. -Ralf.
Bug#1022795: libghc-crypto-numbers-doc: depends on non-existing haddock-interface-35
Package: libghc-crypto-numbers-doc Version: 0.2.7-10 Severity: serious Hi, libghc-crypto-numbers-doc depends on haddock-interface-35 but this package does not exist in the archive. -Ralf.
Bug#1022794: libghc-highlighting-kate-doc: depends on non-existing haddock-interface-35
Package: libghc-highlighting-kate-doc Version: 0.6.4-6 Severity: serious Hi, libghc-highlighting-kate-doc depends on haddock-interface-35 which does not exist in the archive. -Ralf.
Bug#1022786: glirc: unsatisfiable build-dependency libghc-attoparsec-dev (<< 0.14)
Source: glirc Version: 2.36-3 Severity: serious Hi, glirc build-depends on libghc-attoparsec-dev (<< 0.14). However, the current version of that package in sid is 0.14.4-2+b1. -Ralf.
Bug#1022785: guacamole-client: build-depends on removed libangular-maven-plugin-java
Source: guacamole-client Version: 0.9.9+dfsg-1 Severity: serious Hi, guacamole-client build-depends on libangular-maven-plugin-java but that package only exists in oldoldstable. -Ralf.
Bug#1012464: libvtk6.3: not installable in sid
Package: libvtk6.3 Version: 6.3.0+dfsg2-8.1+b1 Severity: serious Hi, libvtk6.3 is currently not installable in sid as it depends on libjsoncpp24. That package only exists in stable, in sid and testing we have libjsoncpp25. -Ralf.
Bug#1012326: python-jenkinsapi: build-depends on pylint3
Source: python-jenkinsapi Version: 0.3.11-5 Severity: serious Usertags: edos-uninstallable Hi, python-jenkinsapi build-depends on pylint3 but that package only exists in stable and older stable releases. -Ralf.
Bug#1012320: materialize: build-depends on non-existing libjs-anime
Source: materialize Version: 1.1.0~alpha+ds-1 Severity: serious Usertags: edos-uninstallable Hi, materialize build-depends on libjs-anime, which does not exist in sid. -Ralf.
Bug#999753: wine-development: unsatisfiable build-dependency on unicode-data (< 14)
Source: wine-development Version: 6.0+repack-1 Severity: serious Usertag: edos-uninstallable Hi, wine-development build-deoends on unicode-data (< 14) but the version in testing and in sid is 14.0.0-1.1. -Ralf.
Bug#998874: nmu: xmlrpc-light_0.6.1-5+b5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu xmlrpc-light_0.6.1-5+b5 . ANY . unstable . -m "rebuild against ocamlnet 4.1.8-2+b1" Binary packages generated from this source package have broken dependencies since the rebuild of ocamlnet, and block the transition of ocamlnet and other packages. Thanks -Ralf.
Bug#998873: nmu: pxp_1.2.9-2+b4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu pxp_1.2.9-2+b4 . ANY . unstable . -m "rebuild against ocamlnet 4.1.8-2+b1" Binary packages generated from this source package have broken dependencies since the rebuild of ocamlnet, and block the transition of ocamlnet and other packages. Thanks -Ralf.
Bug#998872: nmu: ocamlrss_2.2.2-1+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ocamlrss_2.2.2-1+b1 . ANY . unstable . -m "rebuild against ocamlnet 4.1.8-2+b1" Binary packages generated from this source package have broken dependencies since the rebuild of ocamlnet, and block the transition of ocamlnet and other packages. Thanks -Ralf.
Bug#998870: nmu: ocaml-lastfm_0.3.2-1+b5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ocaml-lastfm_0.3.2-1+b5 . ANY . unstable . -m "rebuild against ocamlnet 4.1.8-2+b1" Binary packages generated from this source package have broken dependencies since the rebuild of ocamlnet, and block the transition of ocamlnet and other packages. Thanks -Ralf.
Bug#998871: nmu: ocamldap_2.4.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ocamldap_2.4.2-1 . ANY . unstable . -m "rebuild against ocamlnet 4.1.8-2+b1" Binary packages generated from this source package have broken dependencies since the rebuild of ocamlnet, and block the transition of ocamlnet and other packages. Thanks -Ralf.
Bug#998869: nmu: ocaml-http_0.1.6-1+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ocaml-http_0.1.6-1+b1 . ANY . unstable . -m "rebuild against ocamlnet 4.1.8-2+b1" Binary packages generated from this source package have broken dependencies since the rebuild of ocamlnet, and block the transition of ocamlnet and other packages. Thanks -Ralf.
Bug#997979: nmu: dose3_6.0.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu dose3_6.0.1-2 . ANY . unstable . -m "rebuild against camlzip 1.11-1, camlbz2 0.7.0-1, cudf 0.9-2" Hello, Binary packages generated from dose3 are currently not installable since we have a new versions of libzip-ocaml, libbz2-ocaml and libxudf-ocaml. This is also one of the blockers for the migration of these library packages. Thanks -Ralf.
Bug#997978: nmu: ocamlnet_4.1.8-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ocamlnet_4.1.8-2 . ANY . unstable . -m "rebuild against camlzip 1.11-1" Hello, The binary packages generated from ocamlnet are currently not installable since we have a new version of libzip-ocaml. This is also one of the blockers for the migration of camlzip. Thanks -Ralf.
Bug#995910: gitaly: unsatisfiable build-dependency
Source: gitaly Version: 13.4.6+dfsg1-2 Severity: serious Usertags: edos-uninstallable Hello, gitaly build-depends on golang-gopkg-libgit2-git2go.v28, but this package was removed from sid on 2021-02-08. -Ralf.
Bug#995908: php-async-aws-core: unsatisfiable build-dependency
Source: php-async-aws-core Version: 1.7.2-1 Severity: serious Usertags: edos-uninstallable Hi, php-async-aws-core build-depends on php-symfony-deprecation-contracts, but that package lives only in experimental. -Ralf.
Bug#995806: nmu: js-of-ocaml_3.8.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu js-of-ocaml_3.8.0-2 . ANY . unstable . -m "rebuild against menhir 20210929" libjs-of-ocaml-dev is no longer installable and needs to be rebuild against the version of menhir in unstable. This is also blocking the migration of menhir to testing. -Ralf.
Bug#977258: libssreflect-coq: ABI break by coq binNMU
Hello, On Sun, Dec 13, 2020 at 06:28:01PM +0900, Nobuhiro Ban wrote: > I cannot use the ssreflect library in my Debian coq env (amd64 testing). > > the code: > > Require Import mathcomp.ssreflect.ssreflect. > > gets an error: > > > Compiled library mathcomp.ssreflect.ssreflect (in file > > /usr/lib/coq/user-contrib/mathcomp/ssreflect/ssreflect.vo) makes > > inconsistent assumptions over library Coq.Init.Ltac I have now recompiled the package (and updated to a newer version), so it is at least solved for the moment. > I think this package should depend on "libcoq-ocaml-", > because "coq-+" is insufficient for binNMUs. I am not sure what exactly has to be done, will have to consult with the teamm. -Ralf.
Bug#979493: Error: Rule failed to generate the following targets: _doc/_html/highlight.pack.js
Hi Josch, On Thu, Jan 07, 2021 at 11:47:06AM +0100, Johannes 'josch' Schauer wrote: > I now investigated further and it seems that the package has an > autopkgtest (yay!) so I triggered that and it failed with the same error > message that I got: > > https://ci.debian.net/data/autopkgtest/unstable/amd64/o/ocaml-odoc/9469763/log.gz > > Since the logs are removed after some time, here the last lines from the > log: > > autopkgtest [02:11:21]: test odoc-on-odoc: [--- > File series fully applied, ends at patch > debian/patches/no-vendored-js-highlight > File "_doc/_html/_unknown_", line 1, characters 0-0: > Error: Rule failed to generate the following targets: > - _doc/_html/highlight.pack.js That seems to be due to a missing libjs-highlight.js. This used to be only a Recommends, and hence was not pulled in by the test runner. I have now made it a Depends, I hope that will solve the problem. > [ I also took the liberty to add salsaci to the ocaml-odoc repository on > salsa and it seems there is also a FTBFS which I was unable to trigger > locally using sbuild: > https://salsa.debian.org/ocaml-team/ocaml-odoc/-/pipelines/216353 ] > > This makes me believe that this is probably not a problem with my system > but with the ocaml-odoc package itself. Error: Too many opam files for package "dune_odoc_test": 1285- test/dune/dune_odoc_test.opam 1286- debian/output/source_dir/test/dune/dune_odoc_test.opam That is weird. In particular I have no idea where that debian/output is coming from. Anyway, I think that this is an indepenent problem. Cheers -Ralf.
Bug#979140: RM: frama-c-base [armel mipsel mips64el] -- ANAIS; frama-c no longer buildson archs without ocaml native code compiler
Package: ftp.debian.org Severity: normal Hello, frama-c does no longer compile on architectures that only have a bytecode compiler for ocaml. I have reported this to upstream but have no idea how fast they can fix it, so since the freeze is coming please remove the frama-c-base binary package from these three architectures. Thanks -Ralf.
Bug#978972: RM: checkbot -- ROM; upstream dead since 2009, alternatives exist, does not support well recent HTML standard
Package: ftp.debian.org Severity: normal please remove src:checkbot which is obsolete. -Ralf.
Bug#976355: liquidsoap: FTBFS type error in stream/frame.ml
Source: liquidsoap Version: 1.4.3-1 Severity: serious Hi, liquidsoap fails to compile on an up-to-date amd64 sid machine: OCAMLOPT -c stream/frame.ml File "stream/frame.ml", line 363, characters 25-59: 363 | contents = [(!!size, create_content (type_of_kind kind))]; ^^ Error: This expression has type (float array array, Video.t array, MIDI.buffer array) fields but an expression was expected of type content = (audio_t array, video_t array, midi_t array) fields Type float array is not compatible with type audio_t = (float, Bigarray.float32_elt, Bigarray.c_layout) Bigarray.Array1.t here is the output of the configure: checking for a BSD-compatible install... /usr/bin/install -c checking for GNU make... make checking whether user liquidsoap exists... no configure: WARNING: Won't be able to install log and PID directories! checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for ocamlc... ocamlc OCaml version is 4.11.1 checking if ocaml compiler supports first-class modules... yes OCaml library path is /usr/lib/ocaml checking for ocamlopt... ocamlopt checking for ocamlc.opt... ocamlc.opt checking for ocamlopt.opt... ocamlopt.opt checking for ocaml... ocaml checking for ocamldep... ocamldep checking for ocamldep.opt... ocamldep.opt checking for ocamlmktop... ocamlmktop checking for ocamlmklib... ocamlmklib checking for ocamldoc... ocamldoc checking for ocamldoc.opt... ocamldoc.opt checking for ocamlbuild... ocamlbuild checking for camlidl... camlidl checking for ocamllex... ocamllex checking for ocamllex.opt... ocamllex.opt checking for ocamlyacc... ocamlyacc checking for camlp4... camlp4 checking for camlp4boot... camlp4boot checking for camlp4o... camlp4o checking for camlp4of... camlp4of checking for camlp4oof... camlp4oof checking for camlp4orf... camlp4orf checking for camlp4prof... camlp4prof checking for camlp4r... camlp4r checking for camlp4rf... camlp4rf checking for ocamlfind... ocamlfind checking for ocaml standard library path... /usr/lib/ocaml checking for caml/threads.h... yes checking whether ocamlopt accepts -ffast-math... no checking for ocamlc version... 4.11.1 checking for ocaml bytes module... ok checking for ocaml pcre module... ok checking for ocaml sedlex module >= 2.0... ok checking for ocaml menhirLib module... ok checking for ocaml dtools module >= 0.4.0... ok checking for ocaml duppy module >= 0.6.0... ok checking for ocaml cry module >= 0.6.0... ok checking for ocaml mm module >= 0.5.0... ok checking for ocaml xmlplaylist module >= 0.1.3... ok checking for ocaml lastfm module >= 0.3.0... ok checking for ocaml ogg module >= 0.5.0... ok checking for ocaml vorbis module >= 0.7.0... ok checking for ocaml opus module >= 0.1.3... ok checking for ocaml speex module >= 0.2.1... ok checking for ocaml mad module >= 0.4.4... ok checking for ocaml flac module >= 0.1.5... ok checking for ocaml flac.ogg module... ok checking for ocaml dynlink module... ok checking whether ocaml compiler supports dynlink... yes checking for ocaml lame module >= 0.3.2... ok checking for ocaml shine module >= 0.2.0... ok checking for ocaml gstreamer module >= 0.3.0... ok checking for ocaml frei0r module >= 0.1.0... ok checking for ocaml fdkaac module >= 0.3.1... Not found. checking for ocaml theora module >= 0.3.1... ok checking for ocaml gavl module >= 0.1.4... ok checking for ocaml ffmpeg module >= 0.4.1... ok checking for ocaml bjack module >= 0.1.3... ok checking for ocaml alsa module >= 0.2.1... ok checking for ocaml ao module >= 0.2.0... ok checking for ocaml samplerate module >= 0.1.1... ok checking for ocaml taglib module >= 0.3.0... ok checking sys/soundcard.h usability... yes checking sys/soundcard.h presence... yes checking for sys/soundcard.h... yes checking for ocaml ssl module >= 0.5.2... ok checking for ocaml osx-secure-transport module... Not found. checking for ocaml magic module... ok checking for ocaml camomile module >= 1.0.0... ok checking for ocaml inotify module >= 1.5... ok checking for ocaml yojson module... ok checking fo
Bug#975894: Breaks build of many reverse dependencies
Hi, On Thu, Nov 26, 2020 at 12:03:41PM +0100, Stéphane Glondu wrote: > Package: ocaml-dune > Version: 2.7.1-1 > Severity: serious > > Dear maintainer, > > It seems the latest ocaml-dune breaks many reverse dependencies, see > for example #975821 (ocp-indent). The strange thing is that ocp-indent builds fine on my development environment updated to the latest sid, but I can reproduce the bug in a pbuilder chroot. When I rename in my development environment /usr/bin/ocamlfind to something else, then I also get the build error. So maybe the latest dune requires a dependency on the ocaml-findlib package ? A quick grep in the dune source code shows that dune does stuff differently depending on whether you have ocamlfind installed or not. -Ralf.
Bug#974916: [Pkg-rust-maintainers] Bug#974916: librust-combine+combine-regex-1-dev: not installable in sid
Salut Sylvestre, On Mon, Nov 16, 2020 at 03:18:44PM +0100, Sylvestre Ledru wrote: > This is the same issue. No need to fill separate bugs :) OK I try to take this into account the next time, and use an Affects (there are more bug reports to come). Cheers -Ralf
Bug#974920: librust-deflate+gzip-header-dev: not installable in sid
Package: librust-deflate+gzip-header-dev Version: 0.7.19-2 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, librust-deflate+gzip-header-dev is not installable in sid since 2019-05-05. It depends on librust-gzip-header-0.2+default-dev which does not exist in sid. -Ralf.
Bug#974919: librust-deflate+gzip-dev: not installable in sid
Package: librust-deflate+gzip-dev Version: 0.7.19-2 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, librust-deflate+gzip-dev is not installable in sid since 2019-05-05. It depends on librust-gzip-header-0.2+default-dev which does not exist in sid. -Ralf.
Bug#974917: librust-combine+regex-dev: not installable in sid
Package: librust-combine+regex-dev Version: 3.8.1-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, librust-combine+regex-dev is not installable in sid since 2019-02-04. It depends on librust-regex-0.2+default-dev which does not exist in sid. -Ralf.
Bug#974916: librust-combine+combine-regex-1-dev: not installable in sid
Package: librust-combine+combine-regex-1-dev Version: 3.8.1-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, librust-combine+combine-regex-1-dev is not installable in sid since 2019-02-04. It depends on librust-combine-regex-1-1+default-dev which does not exist in sid. -Ralf.
Bug#974840: qa-feature-table: unsatisfiable build-dependencies
Source: q2-feature-table Version: 2019.10.0+dfsg-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, q2-feature-table build-depends both on python3-pandas (indirectly, via a dependency of qiime), and on q2-types. python3-pandas version 1.1.4+dfsg-1 Breaks q2-types (<< 2019.10.0-1.1~). However, the only version of q2-types in the archive is 2019.10.0-1. -Ralf.
Bug#974839: q2-feature-classifier: unsatisfiable build-dependency
Source: q2-feature-classifier Version: 2019.4.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, q2-feature-classifier build-depends both on python3-pandas (indirectly, via a dependency of qiime), and on q2-types. python3-pandas version 1.1.4+dfsg-1 Breaks q2-types (<< 2019.10.0-1.1~). However, the only version of q2-types in the archive is 2019.10.0-1. -Ralf.
Bug#974765: med-imaging: suggests removed package python-dipy
Package: med-imaging Version: 3.6 User: trei...@debian.org Usertags: edos-uninstallable Hi, med-imaging Suggests python-dipy, but this transitional package is no longer build from the dipy source. -Ralf.
Bug#974764: python-dipy-doc: suggests removed package python-dipy
Package: med-imaging-dev Version: 3.6 User: trei...@debian.org Usertags: edos-uninstallable Hi, med-imaging-dev Suggests python-dipy, but this was a transitional package that is no longer build from the dipy source. -Ralf.
Bug#974759: insighttoolkit4-python: not installable with python 3.8
Package: insighttoolkit4-python
Version: 4.13.2-dfsg1-1
Severity: serious
User: trei...@debian.org
Usertag: edos-unstallable
Hi,
insighttoolkit4-python depends on python3 (< 3.8), the current version
of python3 in sid however is 3.8.6-1. The dependency is generated from
${python3:Depends} so it might be sufficient to recompile the package.
-Ralf.
Bug#974733: q2-quality-filter: unsatisfiable build-dependencies
Source: q2-quality-filter Version: 2019.10.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, q2-quality-filter build-depends both on python3-pandas (indirectly, via a dependency of qiime), and on q2-types. python3-pandas version 1.1.4+dfsg-1 Breaks q2-types (<< 2019.10.0-1.1~). However, the only version of q2-types in the archive is 2019.10.0-1. -Ralf.
Bug#974726: q2-metadata: unsatisfiable build-dependencies
Source: q2-metadata Version: 2019.10.0+dfsg-2 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, q2-metadata build-depends both on python3-pandas and on q2-types. python3-pandas version 1.1.4+dfsg-1 Breaks q2-types (<< 2019.10.0-1.1~). However, the only version of q2-types in the archive is 2019.10.0-1. -Ralf.
Bug#974716: q2-cutadapt: unsatisfiable build-dependency
Source: q2-cutadapt Version: 2019.10.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, q2-cutadapt build-depends both on python3-pandas and on q2-types. python3-pandas version 1.1.4+dfsg-1 Breaks q2-types (<< 2019.10.0-1.1~). However, the only version of q2-types in the archive is 2019.10.0-1.
Bug#974717: q2-demux: unsatisfiable build-dependency
Source: q2-demux Version: 2019.10.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, q2-demux build-depends both on python3-pandas and on q2-types. python3-pandas version 1.1.4+dfsg-1 Breaks q2-types (<< 2019.10.0-1.1~). However, the only version of q2-types in the archive is 2019.10.0-1.
Bug#974539: diff NMU for aspcud_1.9.4-2.1
Hello, On Thu, Nov 12, 2020 at 10:02:57PM +0100, Anton Gladky wrote: > Dear maintainer, > > I have prepared an NMU (versioned as 1.9.4-2.1) and > uploaded to DELAYED/10. I have just uploaded 1.9.4-3 including your patch, so you may cancel your upload. Thanks for your patch -Ralf.
Bug#974606: rust-tokio-process: unsatisfiable build-dependency
Source: rust-tokio-process Version: 0.2.4-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-tokio-process build-depends on librust-crossbeam-queue-0.1+default-dev. This package does not exist in sid or in the NEW queue. -Ralf.
Bug#974604: rust-sloppy-rfc4880: unsatisfiable build-dependency
Source: rust-sloppy-rfc4880 Version: 0.1.5-2 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-sloppy-rfc4880 build-depends on librust-base64-0.11+default-dev | librust-base64-0.10+default-dev. However none of these exists in sid. -Ralf.
Bug#974551: linphone: missing build-dependency on python-pystache
Source: linphone Version: 3.12.0-3.1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, linphone build-depends on python-pystache. However, sid has only python3-pystache. -Ralf.
Bug#974197: rust-hdrhistogram: unsatisfiable build-dependency
Source: rust-hdrhistogram Version: 6.3.4-2 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-hdrhistogram build-depends on librust-base64-0.11+default-dev | librust-base64-0.10+default-dev. However, neither of these exists in sid or in the NEW queue. -Ralf.
Bug#974195: rust-crossbeam FTBFS missing build-dependency librust-crossbeam-channel-0.3+default-dev
Source: rust-crossbeam Version: 0.7.2-2 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-crossbeam build-depends on librust-crossbeam-channel-0.3+default-dev. However, this package does not exist in sid or in the NEW queue. -Ralf.
Bug#974118: rust-pbkdf2: FTBFS build-depends on librust-base64-0.10+default-dev
Source: rust-pbkdf2 Version: 0.3.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-pbkdf2 build-depends on librust-base64-0.10+default-dev, but no such package exists in sid or in the NEW queue. -Ralf.
Bug#974116: rust-trust-dns-proto: FTBFS build-depends on librust-smallvec-0.6+default-dev
Source: rust-trust-dns-proto Version: 0.8.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-trust-dns-proto build-depends on librust-smallvec-0.6+default-dev but no such package exists in sid or the NEW queue. -Ralf.
Bug#974117: rust-image: FTBFS build-depends on librust-tiff-0.3+default-dev
Source: rust-image Version: 0.22.1-2 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-image build-depends on librust-tiff-0.3+default-dev, but no such package exists in sid (or in the NEW queue). Maybe this should be librust-tiff-dev ? -Ralf.
Bug#971439: Build procedure is incorrect and produces invalid files
Hello, On Thu, Oct 01, 2020 at 07:50:13AM +0200, Stéphane Glondu wrote: > Le 30/09/2020 à 18:12, Emilio Jesús Gallego Arias a écrit : > > and either: > > > > - using the officially released .tbz archive that for example > > dune-release produces, which will contain the right metadata for > > version numbers, etc... > > > > - or if using a git checkout, `dune subst` _must_ be run before the > > build so the metadata is update prior build. > > Oh... I wasn't aware of that. The policy in Debian is to take the > officially released .tbz. On the other hand, it is common to take a git > checkout, either because it is easier to monitor newer versions, or > because generated stuff are a pain. I don't know what motivated Ralf to > take a git checkout in the case of lablgtk3. that was indeed the reason. I will see wheather I succeed to tweak the debian/watch file to look for the official release tarballs. -Ralf.
Bug#970510: why3: does not work with current version of cvc4
Hello, On Wed, Sep 23, 2020 at 02:04:24PM +0200, Fabian Wolff wrote: > And while we're at it, even though this is technically an unrelated > problem, it also has something to do with SMT solver versions: In the > autopkgtests control file [0], you have the following code: > > Tests: why3+z3 > Depends:why3, z3 (<< 4.8.7) > Restrictions: skip-not-installable > > This is not a big issue, because it doesn't block migration of z3 > (unlike the cvc4 failure [1]), you might still want to adjust this > version restriction, given that the current z3 version in unstable is > 4.8.9 (unless, of course, there is a reason why why3 won't work with > more recent versions of z3). this version constraint is coming from share/provers-detection-data.conf, so why3 will refuse to work with newer versions of z3, and I am on myself not able to attest that it is safe to override this check. -Ralf.
Bug#969451: coccinelle: use the system pyml library
Hello, On Thu, Sep 03, 2020 at 09:13:26AM +0200, Pino Toscano wrote: > Adding libpyml-ocaml-dev as build dependency and libpyml-ocaml as > dependency does the job: the system version is found and used; > patch attached for this. Yes. In fact I had this already sitting in the git repository for the next upload. I will even, starting from the next upstream release on, filter out the bundle/ directory from the tarball. Best -Ralf.
Bug#963705: debian package for frama-c
Hello, thanks for your bug report regarding the version of frama-c in debian not supporting the current version of why3. This is just to let you know that I am currently working on upgrading the frama-c package to scandium. Your offer to help with thesting the debian package (once it is ready) is greately appreciated. I'll come back to you later about how to set this up. Best- Ralf. -- Ralf Treinen Institut de Recherche en Informatique Fondamentale Pôle Preuves, Programmes et Systèmes Université de Paris http://www.irif.fr/~treinen/
Bug#959166: RM: mathpartir -- ROM; transitional package
Package: ftp.debian.org Severity: normal This is a transitional package to texlive-science. It can be removed now as it was distributed with the last stable release. -Ralf.
Bug#956271: nmu: aac-tactics_8.11.0-1
Hi, On Fri, Apr 10, 2020 at 11:32:41AM +0200, Emilio Pozuelo Monfort wrote: > Control: tags -1 moreinfo > > On 09/04/2020 10:51, Ralf Treinen wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > nmu aac-tactics_8.11.0-1 . ANY . unstable . -m "rebuild against coq > > 8.11.0-1+b1" > > Package: coq > Source: coq (8.11.0-1) > Version: 8.11.0-1+b1 > Provides: coq-8.11.0+4.08.1 > > > Package: libaac-tactics-coq > Source: aac-tactics > Version: 8.11.0-1 > Architecture: all > Depends: libaac-tactics-ocaml (>= 8.11.0-1), coq-8.11.0+4.08.1 > > So I don't see why a rebuild is needed. Maybe it's because of another package, > so it would help if the request had been clearer, so I don't have to be > looking > around and guessing. Can you clarify why this is needed? > > Besides if it's because of libaac-tactics-coq, since it's arch:all it can't be > binNMU'ed (the ocaml bindings can, but those don't seem to depend on coq). It is not for libaac-tactics-coq, I know that it cannot be binNMUed, and it is not neccesarry. It is for libaac-tactics-ocaml and libaac-tactics-ocaml-dev which are Architecture=any, and which are now not installable since coq has been recompiled to version 8.11.0-1.b1. AFAICS, this will block the migration of lablgtk3 3.1.0, and of the recompiled coq. Sorry for not having explained that in my bug report. -Ralf.
Bug#956271: nmu: aac-tactics_8.11.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu aac-tactics_8.11.0-1 . ANY . unstable . -m "rebuild against coq 8.11.0-1+b1" -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956108: nmu: coq_8.11.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu coq_8.11.0-1 . amd64 arm64 ppc64el . unstable . -m "rebuild against lablgtk3 3.1.0-2" lablgtk3 3.1.0-2 has entered unstable today, please rebuild coq. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#885677: liblablgtksourceview2-ocaml: Depends on unmaintained gtksourceview2
Hello, On Fri, Apr 03, 2020 at 07:22:41AM +0200, Stéphane Glondu wrote: > Le 02/04/2020 à 22:23, Thomas Leonard a écrit : > > My package (https://tracker.debian.org/pkg/zeroinstall-injector) > > depends on lablgtk2 and the tracker says it will be removed on 4th Apr > > due to this issue. that is, removed from testing. > > I can't upgrade to lablgtk3 because Debian/unstable only has an old > > beta release of that (3.0~beta6-2), which is missing some functions. > > There is 3.1.0 in experimental. Does it suit your needs? > > Ralf, what are your plans concerning lablgtk3? The only blocker for an upload of 3.1 is that the current version of why3 was not compiling with lablgtk3.1. Now, there is a new version of why3, which does, but there are a few issues with it that I wanted to resolve before uploading the new why3 and lablgtk 3.1 to sid. Some more urgent issues with other packages took the priority in the meantime. Now it is a bit late, as April 4 is tomorrow. Would it really be a big problem when zeroinstall-injector temporarilly drops out of testing? > Just wait. Either lablgtk2 leaves testing and I will fix it quickly and > it (and its reverse dependencies such as your package) will migrate back > to testing. Or lablgtk3 will be updated. I hope to be able to work on the why3/lablgtk3 issue next week. -Ralf.
Bug#955494: `menhir --suggest-menhirLib` suggests wrong directory
Hello Stéphane, On Wed, Apr 01, 2020 at 05:22:44PM +0200, Stéphane Glondu wrote: > Severity: important > `menhir --suggest-menhirLib` returns `/usr/lib/menhirLib` which does > not exist. It think it should return `/usr/lib/ocaml/menhirLib`. why severity=important ? I wasn't even aware of this option. -Ralf.
Bug#885267: coccinelle: Depends on unmaintained pygtk
Hello, On Tue, Mar 24, 2020 at 09:48:50PM +0100, Moritz Mühlenhoff wrote: > On Tue, Feb 04, 2020 at 03:14:22PM -0300, eamanu wrote: > > Source: coccinelle > > Version: 1.0.4.deb-3 > > > > Hi everybody, > > > > This issue was forward to upstream [1]. > > > > The dependency will be remove from coccinelle soon > > > > [1] https://systeme.lip6.fr/pipermail/cocci/2020-February/006836.html > > Dear Ocaml maintainers, > This was fixed in > https://github.com/coccinelle/coccinelle/commit/2a8bcf6dbb1eb68004a3db56341c35d3d6daace4 > > It would be great if this were uploaded soon, coccinelle is among the last > handful of packages blocking the pygtk removal now. A team upload of coccinelle fixing this is scheduled for April 4 (as I wanted the other team members give the occassion to give feedback). -Ralf.
Bug#954292: RM: why3-coq [armel armhf i386 mips64el mipsel s390x] -- ROM; why3-coq no longer build on all architectures
Package: ftp.debian.org Severity: normal Hi, the why3 source package now builds the why3-coq binary package only on those architectures where coq is available. Please remove why3-coq version 1.2.1-3 on the indicated architectures as it will block the migration of why3, coq and its satellites. Thanks -Ralf.
Bug#954223: RM: aac-tactics [i386] -- ROM; package no longer built on 386
Package: ftp.debian.org Severity: normal Hi, For some reason, aac-tactics still lives in testing on i386, even though it was removed from unstable on i386, as a consequence of the removal of coq on some architectures. aac-tactics build-depends on coq. Currently, coq does no longer build on i386, hence the same is true for aac-tactics. This will block migration of aac-tactics to testing. I should state that I am not the Maintainer but only the team member who does the upload of aac-tactics. Thanks for considering -Ralf. Note: this was a request for a partial removal from testing, converted in one for unstable
Bug#953765: coq-float: FTBFS with coq 8.11.0
Source: coq-float Version: 1:8.9.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, coq-float fails to compile against coq 8.11.0: COQC Faux.v File "./Faux.v", line 218, characters 57-61: Error: The reference Zabs was not found in the current environment. make[4]: *** [Makefile.coq:678: Faux.vo] Error 1 make[3]: *** [Makefile.coq:327: all] Error 2 -Ralf.
Bug#953739: aac-tactics: FTBFS in sid
Hi, On Thu, Mar 12, 2020 at 08:02:48PM +0100, Gianfranco Costamagna wrote: > Source: aac-tactics > Version: 8.9.0-1 > Severity: serious > > Hello, looks like some changes in sid made aac-tactics FTBFS in sid, log is > available here: There is a new upstream version 8.11.0 of aac-tactics. The version number seems to indicate that this one compiles with coq 8.11.0. -Ralf.
Bug#953408: RM: coq [armel armhf i386 mipsel mips64el s390x] -- ROM; FTBFS (mostly on 32bit architectures, or where ocaml has only a bytecode compiler)
Package: ftp.debian.org Severity: normal Hi, recent coq has testsuite failures on many architectures, mostly due to a problem with coq/ocaml on 32bit architectures. This is currently being investigated by upstream, but will take some time. OTOH, it is time to move on to coq 8.11.0 as this version is build against lablgtk3 (previous versions vhere build against lablgtk2). Thanks -Ralf.
Bug#953229: coq: FTBFS test failures
On Fri, Mar 06, 2020 at 09:50:01AM +0100, Gianfranco Costamagna wrote: > Source: coq > Version: 8.11.0-1 > Severity: serious > > Hello, looks like the latest coq is FTBFS because of test failures on various > architectures. Coq is notoriously troublesome. Of course we are monitoring the build status, and discussing build failures with upstream. -Ralf.
Bug#951444: List packages where maintainer might be unfit
> Packages that reporters worry that the maintainer is otherwise not > worthy of being the maintainer, and should have a new maintainer. De we really want a page judging the merits of individual maintainers? I do not think so. -Ralf.
Bug#951683: rust-selectors: build-depends on non-existing librust-cssparser-0.25+default-dev
Source: rust-selectors Version: 0.21.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-selectors build-depends on librust-cssparser-0.25+default-dev which does not exist in unstable. -Ralf.
Bug#951682: rust-html5ever: build-depends on non-existing librust-markup5ever-0.9+default-dev
Source: rust-html5ever Version: 0.24.0-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-html5ever build-depends on librust-markup5ever-0.9+default-dev which does not exist in unstable. -Ralf.
Bug#951632: ITP: coq-menhirlib -- Support library for verified Coq parsers produced by Menhir
On Wed, Feb 19, 2020 at 10:02:55AM +0100, Stéphane Glondu wrote: > Le 19/02/2020 à 09:06, Ralf Treinen a écrit : > > - coq does not build on all architectures, and the situation for building > > coq has become worse starting with 8.11. Menhir however is a parser > > generator, like bison, and should be available on all architectures. > > Could you elaborate? What makes coq 8.11 so much worse w.r.t portability? already 8.10.2: https://buildd.debian.org/status/package.php?p=coq&suite=experimental A package for 8.11.0 is in the experimental/master branch, but I haven't uploaded to experimental yet. It builds on amd64. I also tried - on an armel porterbox which leads to a compilation error in some debug tool. This can be circumvented, but we have not even reached the point of running the test suite. - on an i386 porterbox, leading to failure in the test-suite which according to upstream (ejgallego) is critical: https://github.com/coq/coq/issues/11624 -Ralf. -- Ralf Treinen Institut de Recherche en Informatique Fondamentale Pôle Preuves, Programmes et Systèmes Université de Paris http://www.irif.fr/~treinen/
Bug#951632: ITP: coq-menhirlib -- Support library for verified Coq parsers produced by Menhir
Package: wnpp Severity: wishlist Owner: Ralf Treinen * Package name: coq-menhirlib Version : 20200123-1 Upstream Author : Jacques-Henri Jourdan * URL : http://gallium.inria.fr/~fpottier/menhir/ * License : LGPL3+ Programming Lang: Coq Description : Support library for verified Coq parsers produced by Menhir The Menhir parser generator, when invoked with the --coq option, produces parser code in the Coq language. . These parsers must be linked against this library, which provides both an interpreter (which allows running the generated parser) and a validator (which allows verifying, at parser construction time, that the generated parser is correct and complete with respect to the grammar). This package will be maintained by ocaml-team. Rationale: this is currently part of the menhir package. The plan is to split the menhir source package into two source packages: menhir, and the new coq-menhirlib, with the objective to drop the build-dependency on coq from the menhir package. This will resolve two problems: - having menhir build-depend on coq increases considerably the depth of the dependency graph for ocaml-related packages. Removing this build-dependency for menhir itself will make things easier, in particular for transitions to new versions of ocaml or coq. - coq does not build on all architectures, and the situation for building coq has become worse starting with 8.11. Menhir however is a parser generator, like bison, and should be available on all architectures.
