Bug#1068738: gfeeds: python failure at startup

2024-04-10 Thread Ralf Treinen
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

2023-08-24 Thread Ralf Treinen
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

2023-08-23 Thread Ralf Treinen
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

2023-08-23 Thread Ralf Treinen
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"

2023-08-21 Thread Ralf Treinen
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

2023-08-21 Thread Ralf Treinen
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"

2023-07-15 Thread Ralf Treinen
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

2023-07-15 Thread Ralf Treinen
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

2023-07-15 Thread Ralf Treinen
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

2023-07-04 Thread Ralf Treinen
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"

2023-01-21 Thread Ralf Treinen
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

2023-01-16 Thread Ralf Treinen
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?

2022-12-25 Thread Ralf Treinen
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

2022-12-08 Thread Ralf Treinen
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

2022-12-07 Thread Ralf Treinen
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)

2022-11-02 Thread Ralf Treinen
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

2022-11-02 Thread Ralf Treinen
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

2022-11-02 Thread Ralf Treinen
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

2022-10-31 Thread Ralf Treinen
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

2022-10-31 Thread Ralf Treinen
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

2022-10-31 Thread Ralf Treinen
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

2022-10-30 Thread Ralf Treinen
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

2022-10-30 Thread Ralf Treinen
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

2022-10-27 Thread Ralf Treinen
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

2022-10-27 Thread Ralf Treinen
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

2022-10-26 Thread Ralf Treinen
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

2022-10-26 Thread Ralf Treinen
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

2022-10-26 Thread Ralf Treinen
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

2022-10-26 Thread Ralf Treinen
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

2022-10-25 Thread Ralf Treinen
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

2022-10-25 Thread Ralf Treinen
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

2022-10-25 Thread Ralf Treinen
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)

2022-10-25 Thread Ralf Treinen
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

2022-10-25 Thread Ralf Treinen
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

2022-06-07 Thread Ralf Treinen
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

2022-06-04 Thread Ralf Treinen
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

2022-06-03 Thread Ralf Treinen
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)

2021-11-15 Thread Ralf Treinen
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

2021-11-09 Thread Ralf Treinen
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

2021-11-09 Thread Ralf Treinen
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

2021-11-09 Thread Ralf Treinen
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

2021-11-09 Thread Ralf Treinen
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

2021-11-09 Thread Ralf Treinen
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

2021-11-09 Thread Ralf Treinen
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

2021-10-28 Thread Ralf Treinen
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

2021-10-28 Thread Ralf Treinen
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

2021-10-07 Thread Ralf Treinen
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

2021-10-07 Thread Ralf Treinen
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

2021-10-06 Thread Ralf Treinen
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

2021-01-11 Thread Ralf Treinen
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

2021-01-10 Thread Ralf Treinen
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

2021-01-03 Thread Ralf Treinen
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

2021-01-01 Thread Ralf Treinen
Package: ftp.debian.org
Severity: normal

please remove src:checkbot which is obsolete. -Ralf.



Bug#976355: liquidsoap: FTBFS type error in stream/frame.ml

2020-12-03 Thread Ralf Treinen
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

2020-11-26 Thread Ralf Treinen
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

2020-11-16 Thread Ralf Treinen
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

2020-11-16 Thread Ralf Treinen
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

2020-11-16 Thread Ralf Treinen
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

2020-11-16 Thread Ralf Treinen
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

2020-11-16 Thread Ralf Treinen
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

2020-11-15 Thread Ralf Treinen
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

2020-11-15 Thread Ralf Treinen
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

2020-11-14 Thread Ralf Treinen
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

2020-11-14 Thread Ralf Treinen
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

2020-11-14 Thread Ralf Treinen
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

2020-11-14 Thread Ralf Treinen
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

2020-11-14 Thread Ralf Treinen
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

2020-11-14 Thread Ralf Treinen
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

2020-11-14 Thread Ralf Treinen
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

2020-11-12 Thread Ralf Treinen
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

2020-11-12 Thread Ralf Treinen
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

2020-11-12 Thread Ralf Treinen
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

2020-11-11 Thread Ralf Treinen
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

2020-11-11 Thread Ralf Treinen
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

2020-11-11 Thread Ralf Treinen
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

2020-11-10 Thread Ralf Treinen
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

2020-11-10 Thread Ralf Treinen
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

2020-11-10 Thread Ralf Treinen
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

2020-10-01 Thread Ralf Treinen
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

2020-09-23 Thread Ralf Treinen
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

2020-09-03 Thread Ralf Treinen
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

2020-08-24 Thread Ralf Treinen
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

2020-04-30 Thread Ralf Treinen
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

2020-04-10 Thread Ralf Treinen
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

2020-04-09 Thread Ralf Treinen
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

2020-04-07 Thread Ralf Treinen
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

2020-04-03 Thread Ralf Treinen
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

2020-04-02 Thread Ralf Treinen
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

2020-03-31 Thread Ralf Treinen
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

2020-03-19 Thread Ralf Treinen
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

2020-03-18 Thread Ralf Treinen
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

2020-03-13 Thread Ralf Treinen
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

2020-03-13 Thread Ralf Treinen
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)

2020-03-09 Thread Ralf Treinen
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

2020-03-06 Thread Ralf Treinen
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

2020-02-24 Thread Ralf Treinen
> 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

2020-02-19 Thread Ralf Treinen
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

2020-02-19 Thread Ralf Treinen
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

2020-02-19 Thread Ralf Treinen
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

2020-02-19 Thread Ralf Treinen
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.



  1   2   3   4   5   6   7   8   9   10   >