Bug#1065420: RFS: ocaml-linenoise/1.5-1 [ITP] -- Lightweight readline alternative with OCaml
Dear Bo, On Mon, 4 Mar 2024 16:40:29 +0800 Bo YU wrote: I am looking for a sponsor for my package "ocaml-linenoise": Here is my review of the packaging: - There is a comment about ocaml-parany in debian/salsa-ci.yml I don't understand. - In debian/liblinenoise-ocaml.install.in, the *.cma should not be prefixed by "OPT: " and the *.cmxs should be prefixed by "DYN: ". Cheers, -- Stéphane
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi, Le 15/04/2024 à 17:12, Bo YU a écrit : Again, I've seen this issue several times with OCaml packages, but I didn't bother to investigate. It looks like another toolchain issue, which should be fixed in a more central package, not in bisect-ppx itself. So just leave the lintian warnings as is. It seems the issue should be fixed on lintian side as your analyst. But unfortunately, this is one lintian error that will lead to ftp-master auto-rejected if uploaded: ``` E: libbisect-ppx-ocaml-dbgsym: stripped-library [usr/lib/debug/.dwz/x86_64-linux-gnu/libbisect-ppx-ocaml.debug] E: libbisect-ppx-ocaml-dev-dbgsym: stripped-library [usr/lib/debug/.dwz/x86_64-linux-gnu/libbisect-ppx-ocaml-dev.debug] ``` I tried many attempts but failed. One common workaround is shipping one lintian-override via dh_lintian, like[0] and [1]. Although the error was gone, but we will get another error: ``` libbisect-ppx-ocaml-dev-dbgsym: non-debug-file-in-debug-package [usr/share/lintian/overrides/libbisect-ppx-ocaml-dev-dbgsym] ``` Passing `--no-dwz-multifile` to dh_dwz maybe has side effects on the debug package but it seems this is a workaround if we can upload to upstable.And I agree. I've pushed two minor changes. Please review them. Then, I will upload the package. I will open two separate reportbugs to track these issues once the package unloaded to unstable. Thank you for your work. Cheers, -- Stéphane
Bug#1017530: lintian: dwz generated file false positive
Hi all, I bumped into this bug while investigating what seems like a stripped-library false positive... On Mon, 22 Aug 2022 15:12:24 +0200 Axel Beckert wrote: thanks for the bug report. Unfortunately I don't get what actually is the bug. Can you be a bit more verbose? Some questions below. Bastien Roucariès wrote: > I have an interesting interaction between dwz and lintian > https://salsa.debian.org/debian/isa-support/-/commits/lintianbug > > dh_dwz create a small technically without common debug file, "a small technically" what? File? And if so, where? > so without debug symbols Here also the relevant corollary seems missing. > It is a new variation of false positive #955752... Please describe the bug more detailed. Which file triggers it and why should it not trigger it? AFAIU, when a binary package contains multiple ELF files, dwz generates a so-called "multifile" object which is falsely flagged as "stripped-library" by lintian. The problem can be worked around by calling dh_dwz with --no-dwz-multifile, but doing this in all affected packages looks wrong. To reproduce, take one of the packages which calls dh_dwz with --no-dwz-multifile (see [1]), remove the override, build and run lintian on the resulting packages. [1] http://codesearch.debian.net/search?q=--no-dwz-multifile=1 I believe lintian should be fixed instead. Disclaimer: I have no idea of dwz. I just know that it is on the verge of being dropped from the default debhelper sequences because of too many problems for not much gain. As of today, dh_dwz is still called in the default debhelper sequence of compat 13... Cheers, -- Stéphane
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Dear Bo, Le 14/04/2024 à 16:30, Bo YU a écrit : I would not override dh_dwz nor dh_strip. My opinion is that what you are trying to fix are deficiencies of the toolchain that should be fixed there. First to address dh_strip issue. From what I've researched. The issue was raised by the static library generated from bisect_ppx did not obey the standard static library name scheme. The dh_strip[0] will strip the static library with `lib-*` prefix. But as we can observe the building: ``` I: libbisect-ppx-ocaml-dev: unstripped-static-library (bisect__Runtime.o) [usr/lib/ocaml/bisect_ppx/runtime/bisect.a] I: libbisect-ppx-ocaml-dev: unstripped-static-library (bisect_common.o) [usr/lib/ocaml/bisect_ppx/common/bisect_common.a] I: libbisect-ppx-ocaml-dev: unstripped-static-library (bisect_ppx__Exclude.o bisect_ppx__Exclude_lexer.o bisect_ppx__Exclude_parser.o bisect_ppx __Exclusions.o bisect_ppx__Instrument.o bisect_ppx__Register.o) [usr/lib/ocaml/bisect_ppx/bisect_ppx.a] ``` In fact, the original solution is that I refer to this[1]. But I am not sure if this is a toolchain issue or not, so I have reported this to upstream[2] also. The workaround for this issue I could think of: 1. Keep those lintian messages here and open a reportbug to track the issue until upstream fix the issue; 2. Use the solution like [1] as my previous post and open a reportbug to track the issue until upstream fix the issue; 3. Wait to upstream to fix this issue; 4. Persuading the maintainers of debhelper to strip static library with broader name scheme.But I think this is not a good wishlist.:) Personally I prefer to option 2 still. Thank you for looking into this, I wasn't expecting that! By a "toolchain issue", I meant an issue in debhelper or lintian (or maybe in dh-ocaml or ocaml itself). This is definitely not an upstream issue (of bisect-ppx), as all OCaml packages face it. One possible fix would be to change dh_strip, for example by telling it to strip $FOO.a if $FOO.cmxa exists, if this is correct (I'm not sure: I don't know why lib*.a are stripped in the first place). That would be your option 4. Or fix lintian to not issue the warning for $FOO.a if $FOO.cmxa exists. Right now, I don't know which option is correct. But this should not hinder bisect-ppx packaging, so I would go to option 1 first, then investigate which of my two options is the correct one. For dh_dwz issue. It seems that the issue will be fixed by passing `--no-dwz-multifile` arg. In my understanding, there is two ELF binaries on the debug package, so the no-mutlifile arg can assure dropping `../.dwz/../.debug`. Again, I've seen this issue several times with OCaml packages, but I didn't bother to investigate. It looks like another toolchain issue, which should be fixed in a more central package, not in bisect-ppx itself. So just leave the lintian warnings as is. Cheers, -- Stéphane
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Dear Bo, Le 08/04/2024 à 17:05, Bo YU a écrit : I am looking for a sponsor for my package "bisect-ppx": [...] I've reviewed the packaging and I have a few comments. Standards-Version is not the latest. Upstream copyright years are missing in debian/copyright. A .cma file is in a "OPT:" line in an .install.in file. I would not override dh_dwz nor dh_strip. My opinion is that what you are trying to fix are deficiencies of the toolchain that should be fixed there. It is not right to override source-contains-prebuilt-javascript-object in this case; you should filter the .js file out and make sure the package works without it. Or get the actual sources and build from them. Or find it in another Debian package. (These are just examples of how to tackle the issue.) I am wondering about long-term maintainability of the manpage. I suppose you've generated the manpage from running the command with --help? Please make a rule to automatically generate it. Thank you for your work, -- Stéphane
Bug#1064086: Acknowledgement (/usr/share/doc/libapache2-mod-netcgi-apache/changelog.gz: libapache2-mod-netcgi-apache break apache)
Hi,
Le 17/02/2024 à 05:09, Frédéric Loyer a écrit :
We can fix it changing the /etc/apache2/mods-available/netcgi_apache.load
Simply changing the first line
LoadModule netcgi_module /usr/lib/apache2/modules/mod_netcgi_apache.so
(netcgi_module instead of netcgi_apache_module)
Indeed.
However, I had a new error:
[Sat Feb 17 05:05:36 2024] [Netcgi_apache_mod] error loading shared library:
Sys_error("/usr/lib/ocaml/netcgi2-apache/netcgi_apache.cma: No such file or
directory")
Curiously the netcgi_apache.load has the line
NetcgiRequire netcgi2-apache
And it search a netcgi_apache.cma file.
I don't get this error... Did you customize something in your configuration?
Cheers,
--
Stéphane
Bug#1064002: ITP: ocaml-crunch -- convert a filesystem into a static OCaml module
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-crunch Version : 3.3.1 Upstream Contact: Anil Madhavapeddy * URL : https://github.com/mirage/ocaml-crunch * License : ISC Programming Lang: OCaml Description : convert a filesystem into a static OCaml module ocaml-crunch takes a directory of files and compiles them into a standalone OCaml module which serves the contents directly from memory. This can be convenient for libraries that need a few embedded files (such as a web server) and do not want to deal with all the trouble of file configuration. This package is a new dependency of ocaml-odoc. Il will be maintained in the OCaml team.
Bug#1061387: Assumes dark background
Package: debgpt Version: 0.4.94 Severity: wishlist Dear Maintainer, It seems that debgpt assumes a terminal with dark background: it prints stuff in yellow, which is barely readable with a light background. It would be nice if there were a light background mode (and/or a no-color mode). Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debgpt depends on: ii python3 3.11.4-5+b1 ii python3-bs4 4.12.2-2 ii python3-openai 1.6.1-2 ii python3-prompt-toolkit 3.0.43-1 ii python3-requests2.31.0+dfsg-1 ii python3-rich13.3.1-2 ii python3-tomli 2.0.1-2 Versions of packages debgpt recommends: ii git 1:2.43.0-1 ii man-db 2.12.0-3 ii python3-zmq 24.0.1-5+b1 pn tldr Versions of packages debgpt suggests: pn python3-torch | python3-torch-cuda | python3-torch-rocm pn python3-transformers -- no debconf information
Bug#1060654: AttributeError: 'dict' object has no attribute 'openai_api_key'
Package: debgpt Version: 0.4.93 Severity: important Dear Maintainer, Running `debgpt` with OPENAI_API_KEY set results in: > Traceback (most recent call last): > File "/usr/bin/debgpt", line 8, in > sys.exit(main()) > ^^ > File "/usr/lib/python3/dist-packages/debgpt/cli.py", line 401, in main > ag = parse_args(argv) > > File "/usr/lib/python3/dist-packages/debgpt/cli.py", line 67, in parse_args > conf = defaults.Config() >^ > File "/usr/lib/python3/dist-packages/debgpt/defaults.py", line 66, in > __init__ > self.toml.openai_api_key = openai_api_key > > AttributeError: 'dict' object has no attribute 'openai_api_key' Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debgpt depends on: ii python3 3.11.4-5+b1 ii python3-bs4 4.12.2-2 ii python3-openai 1.6.1-2 ii python3-prompt-toolkit 3.0.43-1 ii python3-requests2.31.0+dfsg-1 ii python3-rich13.3.1-2 ii python3-tomli 2.0.1-2 Versions of packages debgpt recommends: ii git 1:2.43.0-1 ii man-db 2.12.0-1 ii python3-zmq 24.0.1-5+b1 pn tldr Versions of packages debgpt suggests: pn python3-torch | python3-torch-cuda | python3-torch-rocm pn python3-transformers -- no debconf information
Bug#1055867: RM: ocaml-migrate-parsetree -- ROM; deprecated
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org, so...@tarides.com Dear Archive Team, Please remove ocaml-migrate-parsetree from unstable. It has been deprecated upstream and has no longer reverse dependencies: https://lists.debian.org/debian-ocaml-maint/2023/11/msg0.html Cheers, -- Stéphane
Bug#1055739: bson2json does not work
Package: reserialize
Version: 20220929-2
Severity: normal
Dear Maintainer,
The command
echo '{}' | json2bson | bson2json
fails with:
> Traceback (most recent call last):
> File "/usr/bin/bson2json", line 84, in
> data = fh_loaders[itype](ifh)
>^^
> File "/usr/bin/bson2json", line 24, in
> "bson": lambda fh: next(bson.decode_file_iter(fh)),
>^^^
> File "/usr/lib/python3/dist-packages/bson/__init__.py", line 1159, in
> decode_file_iter
> obj_size = _UNPACK_INT_FROM(size_data, 0)[0] - 4
>^^
> TypeError: a bytes-like object is required, not 'str'
Cheers,
--
Stéphane
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages reserialize depends on:
ii python3 3.11.4-5+b1
ii python3-yaml 6.0.1-1
Versions of packages reserialize recommends:
ii python3-bson 3.11.0-1+b5
pn python3-toml
reserialize suggests no packages.
-- no debconf information
Bug#1053297: RM: eliom [armhf] -- ROM; unreproducible FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: el...@packages.debian.org Control: affects -1 + src:eliom Dear FTP Team, eliom FTBFS on armhf buildds, and I cannot reproduce locally in a chroot (with pbuilder and sbuild) (using qemu-user-static), nor on a porterbox (abel). I've asked for help on the debian-arm mailing-list: https://lists.debian.org/debian-arm/2023/09/msg00030.html and nobody else can reproduce the failure. I've tried to patch out a possible problem, and now it fails even earlier on buildds but still, I cannot reproduce the failure locally. Meanwhile, eliom cannot migrate to testing because of out-of-date binaries. Therefore, I exceptionally request that the binaries are removed on armhf, until someone has a clue. Cheers, -- Stéphane
Bug#1052239: transition: ocaml
Le 23/09/2023 à 06:54, Stéphane Glondu a écrit : The following packages should be removed from testing for now: gmetadom otags xmlrpc-light mlpost ulex0.8 ocamlviz I think Britney needs a little more help: the following packages should also be removed from testing: ocaml-http ocaml-lastfm ocamldap pcre-ocaml (They are already flagged for autoremoval but that would complete in 3 weeks while everything else is ready.) And also, allow llvm-toolchain-13 (in particular, libllvm-13-ocaml-dev) to break. Cheers, -- Stéphane
Bug#1052493: ITP: ppx-string -- string interpolation
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ppx-string Version : 0.16.0 Upstream Contact: Jane Street Group, LLC * URL : https://github.com/janestreet/ppx_string * License : MIT Programming Lang: OCaml Description : string interpolation Ppx extension for string interpolation. Part of the Jane Street's PPX rewriters collection. This is a new dependency of liquidsoap and will be maintained in the OCaml team.
Bug#1052492: ITP: ppx-stable-witness -- stable witness derivation
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ppx-stable-witness Version : 0.16.0 Upstream Contact: Jane Street Group, LLC * URL : https://github.com/janestreet/ppx_stable_witness * License : MIT Programming Lang: OCaml Description : stable witness derivation Ppx extension for deriving a witness that a type is intended to be stable. In this context, stable means that the serialization format will never change. This allows programs running at different versions of the code to safely communicate. This is a new dependency of bin-prot and will be maintained in the OCaml team.
Bug#1052239: transition: ocaml
Hi all, Le 20/09/2023 à 09:44, Sebastian Ramacher a écrit : Good. Please go ahead I've uploaded ocaml 4.14.1-1 3 days ago, then uploaded camlp4, ocamlnet, a few other arch:all packages that could not be binNMUed, and binNMUed all the rest. All packages, except the ones I had already spotted during my test rebuild, built fine on all release architectures: https://release.debian.org/transitions/html/ocaml.html scilab's status is unrelated to this transition; there are open RC bugs for the other "bad" packages: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.14.1-transition;users=debian-ocaml-ma...@lists.debian.org The following packages should be removed from testing for now: gmetadom otags xmlrpc-light mlpost ulex0.8 ocamlviz There is also another issue I didn't foresee: the binary package libllvm-13-ocaml-dev would be broken in testing by the migration of ocaml 4.14.1. Its source package, llvm-toolchain-13, has been removed from unstable and cannot be removed from testing because of... Haskell! libllvm-13-ocaml-dev has no reverse dependencies, though... Is it possible to remove just this one from testing as well? Or to explicitly allow its breakage? The transition is also looking good on riscv64. For the convenience of riscv porters, I've set up a transition tracker for OCaml packages on this architecture: https://people.debian.org/~glondu/ben/ocaml.html Cheers, -- Stéphane
Bug#1052298: metafun.mp refers to inexistent metafun.mpii
Dear Hilmar, Le 22/09/2023 à 00:02, Preuße, Hilmar a écrit : While investigating why mlpost now FTBFS (#1052232), I realized that file /usr/share/texmf/metapost/context/base/mpiv/metafun.mpiv refers to a "metafun.mpii" which doesn't exist. I did a "grep -r metafun.mpii /home/hille/devel/TeXLive/github/context/texmf-dist" and the only relevant occurence of metafun.mpii is in /home/hille/devel/TeXLive/github/context/texmf-dist/metapost/context/base/common/metafun.mp , which reads: if known metafunversion : endinput ; fi ; if known mplib : input metafun.mpiv else : input metafun.mpii fi ; mlpost generates files (e.g. foo.mp) that start with: input metafun.mp ; and runs them with e.g. `mpost -interaction=nonstopmode foo.mp`. A file with only the line above exhibits the problem: mpost fails with the error: This is MetaPost, version 2.02 (TeX Live 2023/Debian) (kpathsea version 6.3.5) (/usr/share/texlive/texmf-dist/metapost/base/mpost.mp (/usr/share/texlive/texmf-dist/metapost/base/plain.mp Preloading the plain mem file, version 1.005) ) (./foo.mp (/usr/share/texmf/metapost/context/base/common/metafun.mp ! I can't open file `metafun.mpii'. l.6 input metafun.mpii Please type another input file name ! Emergency stop. l.6 input metafun.mpii Transcript written on foo.log. Note that the problem is new: mlpost compiled successfully on 2023-08-17. Context has been updated since them and the previous version did ship metafun.mpii that somehow got dropped in the new version. That's why I've submitted a bug here. I do not know anything about metafun, but my impression is that you need to load a lib to combine metafun and mkiv. Please try to figure that yourself, I can't help here and I don't think we look at a general bug here. Metafun documentation [1] says to use "input mp-tool" or "input metafun", but neither works. [1] http://www.pragma-ade.nl/general/manuals/metafun-p.pdf Using "input mp-tool.mpiv" seems to work, though (mlpost builds). Is that expected? Cheers, -- Stéphane
Bug#1052230: FTBFS with OCaml 4.14.1
Control: reassign -1 src:ocamlnet Control: retitle -1 "Missing build-dependency on pkg-config" Control: affects -1 src:caml-crush Le 20/09/2023 à 10:19, Stéphane Glondu a écrit : The failure seems to be unrelated to OCaml 4.14.1, as the failure is reproducible in current unstable with OCaml 4.13.1... Hence, raising severity to serious. All this boils down to missing -lgnutls in nettls-gnutls, which seems to be fixed by adding pkg-config to ocamlnet's Build-Depends. Cheers, -- Stéphane
Bug#1052230: FTBFS with OCaml 4.14.1
Control: severity -1 serious On Tue, 19 Sep 2023 12:45:45 +0200 Stéphane Glondu wrote: Source: caml-crush Version: 1.0.12-1.1 [...] Your package FTBFS with OCaml 4.14.1 with the following error: > [...] The failure seems to be unrelated to OCaml 4.14.1, as the failure is reproducible in current unstable with OCaml 4.13.1... Hence, raising severity to serious. Cheers, -- Stéphane
Bug#1052235: FTBFS with OCaml 4.14.1
Control: tags -1 + patch On Tue, 19 Sep 2023 13:02:43 Stéphane Glondu wrote: Your package FTBFS with OCaml 4.14.1 with the following error: > [...] This is due to dune defaulting to warnings-as-errors in non-release mode. A packaging fix is attached. Something should be done upstream to get rid of the warnings. Cheers, -- StéphaneFrom 1917876272c2e7de4a1f9d9a1fca4f6147b0b7dc Mon Sep 17 00:00:00 2001 From: Stephane Glondu Date: Wed, 20 Sep 2023 09:48:58 +0200 Subject: [PATCH] Fix FTBFS with OCaml 4.14.1 (Closes: #1052235) --- debian/changelog | 7 +++ debian/rules | 3 +++ 2 files changed, 10 insertions(+) diff --git a/debian/changelog b/debian/changelog index 1e3a62b..18c8dd8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +orpie (1.6.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with OCaml 4.14.1 (Closes: #1052235) + + -- Stéphane Glondu Wed, 20 Sep 2023 09:48:47 +0200 + orpie (1.6.1-1) unstable; urgency=medium * New upstream release. diff --git a/debian/rules b/debian/rules index cf9b5d6..b3fdfa9 100755 --- a/debian/rules +++ b/debian/rules @@ -6,6 +6,9 @@ export DESTDIR=$(CURDIR)/debian/orpie %: dh $@ +override_dh_auto_build: + dune build -p orpie + override_dh_auto_install: dh_auto_install mv $(CURDIR)/debian/orpie/usr/man $(CURDIR)/debian/orpie/usr/share/man -- 2.40.1
Bug#1052239: transition: ocaml
Le 20/09/2023 à 09:27, Sebastian Ramacher a écrit : Based on https://release.debian.org/transitions/html/ocaml.html, diffoscope is involved in both the ocaml and the uncoordinated haskell transitions. Do we need rebuilds of diffoscope for ocaml? Why does it matter? If we would need them, diffoscope would entangle both transitions. As haskell is currently showing no progress, both transitions would be stuck in unstable indefinitely. diffoscope doesn't seem really affected by the haskell transition either... Maybe it is related in the same way as ocaml? It does appear in the permanent transition trackers because the "affected" criteria is very broad there, but my guess is that it wouldn't appear in more targeted trackers. As far as progress is concerned, I guess haskell and/or ocaml support can be (temporarily) removed from diffoscope, if a "stuck" condition arises, de-entangling everything. Cheers, -- Stéphane
Bug#1052239: transition: ocaml
Dear Sebastian, Le 20/09/2023 à 08:48, Sebastian Ramacher a écrit : I recompiled the OCaml world with it: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Based on https://release.debian.org/transitions/html/ocaml.html, diffoscope is involved in both the ocaml and the uncoordinated haskell transitions. Do we need rebuilds of diffoscope for ocaml? Why does it matter? diffoscope uses ocaml tools to look into ocaml objects, it doesn't depend on ocaml ABI AFAIK. Although there indeed was #1002678 last time, I test-compiled diffoscope with the new ocaml version and it built fine. Therefore, I don't think we need rebuilds of diffoscope. Cheers, -- Stéphane
Bug#1052298: metafun.mp refers to inexistent metafun.mpii
Package: context Version: 2023.05.05.20230730+dfsg-2 Severity: important Control: block 1052232 by -1 Dear Maintainer, While investigating why mlpost now FTBFS (#1052232), I realized that file /usr/share/texmf/metapost/context/base/mpiv/metafun.mpiv refers to a "metafun.mpii" which doesn't exist. Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages context depends on: ii lmodern 2.005-1 ii luametatex2.10.08+ds-1+b1 ii ruby 1:3.1 ii tex-common6.18 ii tex-gyre 20180621-6 ii texlive-base 2023.20230613-3 ii texlive-binaries 2023.20230311.66589-6 ii texlive-metapost 2023.20230613-3 Versions of packages context recommends: pn context-modules ii fonts-freefont-otf20211204+svn4273-2 ii fonts-gfs-artemisia 1.1-6 ii fonts-gfs-baskerville 1.1-6 pn fonts-gfs-bodoni-classic ii fonts-gfs-didot 1.1-7 pn fonts-gfs-didot-classic pn fonts-gfs-gazis ii fonts-gfs-neohellenic 1.1-7 ii fonts-gfs-olga1.1-6 ii fonts-gfs-porson 1.1-7 ii fonts-gfs-solomos 1.1-6 pn fonts-gfs-theokritos ii fonts-sil-gentium 20081126:1.03-4 Versions of packages context suggests: pn context-nonfree pn fontforge ii libxml-parser-perl 2.46-4 ii perl-tk 1:804.036-1+b2 -- no debconf information
Bug#1052232: FTBFS with OCaml 4.14.1
Control: severity -1 serious Le 19/09/2023 à 12:53, Stéphane Glondu a écrit : Your package FTBFS with OCaml 4.14.1 with the following error: [...] The package currently FTBFS in unstable (with OCaml 4.13.1) as well, I suspect because of an update in Metapost. Raising severity. Cheers, -- Stéphane
Bug#1052295: RM: xmlrpc-light -- RoQA; dead upstream; low popcon; FTBFS with OCaml 4.14.1
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: xmlrpc-li...@packages.debian.org Control: affects -1 + src:xmlrpc-light Dear FTP Team, The last upstream release of xmlrpc-light dates back to 2009 and it seems that upstream did not bother to move elsewhere since the demise of code.google.com. Patches accumulate in Debian packaging to keep it compilable as Debian evolves. It now fails to build from source with OCaml 4.14.1. It does not make sense to me to fix it now. I think it's time to remove it from Debian. Cheers, -- Stéphane
Bug#1052294: RM: otags -- RoQA; based on ancient OCaml version; dead upstream; low popcon
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ot...@packages.debian.org Control: affects -1 + src:otags Dear FTP Team, The last upstream release of otags dates back to 2017 and OCaml 4.05.0 (which is the version from oldoldstable). Even though I "ported" it to more recent OCaml versions thanks to ocaml-migrate-parsetree, new syntax introduced since then is not supported to the point that I wonder if it makes sense to port it to 4.14.1, whose transition is being prepared. Besides, ocaml-merlin is a better replacement (although not drop-in). I think it's time to remove otags from Debian. Cheers, -- Stéphane
Bug#1052293: RM: gmetadom -- RoQA; unmaintained; low popcon; FTBFS with OCaml 4.14.1
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: gmeta...@packages.debian.org Control: affects -1 + src:gmetadom Dear FTP Team, The gmetadom package has had no human maintainers since 2011. Its last upstream release dates back to 2006. It has low popcom, no reverse dependencies, and seems absent from OPAM, and now fails to build from source with OCaml 4.14.1. I think it's time to remove it from Debian. Cheers, -- Stéphane
Bug#1052239: transition: ocaml
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: oc...@packages.debian.org
Control: affects -1 + src:ocaml
Dear Release Team,
I uploaded ocaml 4.14.1 to experimental, and it built successfully on
all release architectures.
I recompiled the OCaml world with it:
http://ocaml.debian.net/transitions/ocaml-4.14.1/
Note that I excluded scilab, llvm-toolchain-{14,15,16}, coq-unimath
and guestfs-tools, because they take too much time (and I don't expect
particular breakage there).
Not counting those, only 8 packages in testing FTBFS and one more has
a missing dependency. All of them could be removed from testing. Bugs
have been filed:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.14.1-transition;users=debian-ocaml-ma...@lists.debian.org
I hereby request a transition slot.
Ben file:
title = "ocaml";
is_affected = .depends ~ /ocaml(-base)?-4\.13\.1/ | .depends ~
/ocaml(-base)?-4\.14\.1/;
is_good = .depends ~ /ocaml(-base)?-4\.14\.1/;
is_bad = .depends ~ /ocaml(-base)?-4\.13\.1/;
Cheers,
--
Stéphane
Bug#1052237: FTBFS with OCaml 4.14.1
Source: xmlrpc-light Version: 0.6.1-6 Severity: important Tags: ftbfs User: debian-ocaml-ma...@lists.debian.org Usertags: ocaml-4.14.1-transition Dear Maintainer, Your package FTBFS with OCaml 4.14.1 with the following error: [...] dh_auto_test make -j1 test make[1]: Entering directory '/tmp/build/xmlrpc-light-0.6.1' make[2]: Entering directory '/tmp/build/xmlrpc-light-0.6.1' make[2]: 'xmlrpc-light.cma' is up to date. make[2]: Leaving directory '/tmp/build/xmlrpc-light-0.6.1' ocaml -I . test/test.ml Exception: Failure "int_of_string". make[1]: *** [Makefile:19: test] Error 125 make[1]: Leaving directory '/tmp/build/xmlrpc-light-0.6.1' dh_auto_test: error: make -j1 test returned exit code 2 make: *** [debian/rules:22: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Packages rebuilt with OCaml 4.14.1 are available at: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Cheers, -- Stéphane
Bug#1052235: FTBFS with OCaml 4.14.1
Source: orpie Version: 1.6.1-1 Severity: important Tags: ftbfs User: debian-ocaml-ma...@lists.debian.org Usertags: ocaml-4.14.1-transition Dear Maintainer, Your package FTBFS with OCaml 4.14.1 with the following error: [...] File "src/orpie/rcfile.ml", line 976, characters 16-30: 976 ||Stream.Failure -> ^^ Error (alert deprecated): module Stdlib.Stream Use the camlp-streams library instead. make[1]: *** [Makefile:3: _build/install/default/bin/orpie] Error 1 make[1]: Leaving directory '/tmp/build/orpie-1.6.1' dh_auto_build: error: make -j1 returned exit code 2 make: *** [debian/rules:7: build] Error 25 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Packages rebuilt with OCaml 4.14.1 are available at: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Cheers, -- Stéphane
Bug#1052236: FTBFS with OCaml 4.14.1
Source: otags Version: 4.05.1-4 Severity: important Tags: ftbfs User: debian-ocaml-ma...@lists.debian.org Usertags: ocaml-4.14.1-transition Dear Maintainer, Your package FTBFS with OCaml 4.14.1 with the following error: [...] ocamlopt.opt -c -w A-44 -safe-string -g -I +compiler-libs -I +ocaml-migrate-parsetree otags.ml File "otags.ml", line 40, characters 4-23: 40 | Parse.interface lex ^^^ Error: This expression has type Parsetree.signature = Parsetree.signature_item list but an expression was expected of type Migrate_parsetree__.Ast_413.Parsetree.signature = Migrate_parsetree__.Ast_413.Parsetree.signature_item list Type Parsetree.signature_item is not compatible with type Migrate_parsetree__.Ast_413.Parsetree.signature_item = Migrate_parsetree.Ast_413.Parsetree.signature_item make[1]: *** [Makefile:120: otags.cmx] Error 2 make[1]: Leaving directory '/tmp/build/otags-4.05.1' dh_auto_build: error: make -j1 returned exit code 2 make: *** [debian/rules:10: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Packages rebuilt with OCaml 4.14.1 are available at: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Cheers, -- Stéphane
Bug#1052234: FTBFS with OCaml 4.14.1
Source: ocaml-merlin Version: 4.7-413-4 Severity: important Tags: ftbfs User: debian-ocaml-ma...@lists.debian.org Usertags: ocaml-4.14.1-transition Dear Maintainer, Your package FTBFS with OCaml 4.14.1 with the following error: [...] dune build @all File "src/config/my_config.ml", line 7, characters 70-83: 7 | | `OCaml_4_10_0 | `OCaml_4_11_0 | `OCaml_4_12_0 | `OCaml_4_13_0 ] = `OCaml_4_14_0 ^ Error: This expression has type [> `OCaml_4_14_0 ] but an expression was expected of type [ `OCaml_4_02_0 | `OCaml_4_02_1 | `OCaml_4_02_2 | `OCaml_4_02_3 | `OCaml_4_03_0 | `OCaml_4_04_0 | `OCaml_4_05_0 | `OCaml_4_06_0 | `OCaml_4_07_0 | `OCaml_4_07_1 | `OCaml_4_08_0 | `OCaml_4_09_0 | `OCaml_4_10_0 | `OCaml_4_11_0 | `OCaml_4_12_0 | `OCaml_4_13_0 ] The second variant type does not allow tag(s) `OCaml_4_14_0 File "src/ocaml/preprocess/parser_raw.mly", line 846, characters 29-36: Warning: the token COMMENT is unused. File "src/ocaml/preprocess/parser_raw.mly", line 847, characters 30-39: Warning: the token DOCSTRING is unused. File "src/ocaml/preprocess/parser_raw.mly", line 849, characters 7-10: Warning: the token EOL is unused. File "src/ocaml/preprocess/parser_raw.mly", line 759, characters 7-22: Warning: the token GREATERRBRACKET is unused. ocamlmerlin.c: In function 'connect_socket.constprop': ocamlmerlin.c:262:40: warning: '%s' directive output may be truncated writing up to 4096 bytes into a region of size 102 [-Wformat-truncation=] 262 | snprintf(address.sun_path, 104, "./%s", socketname); |^~ ocamlmerlin.c:262:5: note: 'snprintf' output between 3 and 4099 bytes into a destination of size 104 262 | snprintf(address.sun_path, 104, "./%s", socketname); | ^~~ ocamlmerlin.c: In function 'start_server.constprop': ocamlmerlin.c:353:40: warning: '%s' directive output may be truncated writing up to 4096 bytes into a region of size 102 [-Wformat-truncation=] 353 | snprintf(address.sun_path, 104, "./%s", socketname); |^~ ocamlmerlin.c:353:5: note: 'snprintf' output between 3 and 4099 bytes into a destination of size 104 353 | snprintf(address.sun_path, 104, "./%s", socketname); | ^~~ ocamlmerlin.c:377:41: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] 377 | snprintf(socket_path, PATHSZ, "%s/%s", path_socketdir(), socketname); | ^ ocamlmerlin.c:377:5: note: 'snprintf' output 2 or more bytes (assuming 4098) into a destination of size 4097 377 | snprintf(socket_path, PATHSZ, "%s/%s", path_socketdir(), socketname); | ^~~~ make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1 make[1]: Leaving directory '/tmp/build/ocaml-merlin-4.7-413' make: *** [debian/rules:6: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Packages rebuilt with OCaml 4.14.1 are available at: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Cheers, -- Stéphane
Bug#1052233: FTBFS with OCaml 4.14.1
Source: nss-passwords Version: 0.3-2 Severity: important Tags: ftbfs User: debian-ocaml-ma...@lists.debian.org Usertags: ocaml-4.14.1-transition Dear Maintainer, Your package FTBFS with OCaml 4.14.1 with the following error: [...] nss_stubs.c:121:13: warning: "callback" is deprecated: use "caml_callback" instead 121 | Store_field(cb_data, 0, callback); | ^~~~ /usr/lib/ocaml/caml/mlvalues.h:290:24: warning: passing argument 1 of 'memcpy' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 290 | #define String_val(x) ((const char *) Bp_val(x)) | ~^ nss_stubs.c:128:12: note: in expansion of macro 'String_val' 128 | memcpy(String_val(res), result.data, result.len); |^~ In file included from /usr/include/features.h:490, from /usr/include/x86_64-linux-gnu/sys/types.h:25, from /usr/include/nspr/prinet.h:36, from /usr/include/nspr/nspr.h:17, from nss_stubs.c:41: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:26:1: note: expected 'void * restrict' but argument is of type 'const char *' 26 | __NTH (memcpy (void *__restrict __dest, const void *__restrict __src, | ^ make[1]: *** [Makefile:27: nss_stubs.o] Error 2 make[1]: Leaving directory '/tmp/build/nss-passwords-0.3' dh_auto_build: error: make -j1 "INSTALL=install --strip-program=true" returned exit code 2 make: *** [debian/rules:7: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Packages rebuilt with OCaml 4.14.1 are available at: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Cheers, -- Stéphane
Bug#1052232: FTBFS with OCaml 4.14.1
Source: mlpost Version: 0.9-4 Severity: important Tags: ftbfs User: debian-ocaml-ma...@lists.debian.org Usertags: ocaml-4.14.1-transition Dear Maintainer, Your package FTBFS with OCaml 4.14.1 with the following error: > [...] > File "examples/dune.boxes.inc", line 2, characters 0-205: > 2 | (rule (targets ps_boxes1.mps ps_boxes2.mps ps_boxes3.mps ps_boxes4.mps > ps_boxes5.mps ps_boxes6.mps ps_boxes7.mps ps_boxes8.mps ps_boxes9.mps) (deps > boxes.exe) (action (run ./boxes.exe -ps -prefix "ps_"))) > > ^ > (cd _build/default/examples && ./boxes.exe -ps -prefix ps_) > Fatal error: exception Unix.Unix_error(Unix.ENOENT, "rename", "boxes.1") > File "examples/dune.tree.inc", line 2, characters 0-264: > 2 | (rule (targets ps_tree1.mps ps_tree2.mps ps_tree3.mps ps_tree4.mps > ps_tree5.mps ps_tree6.mps ps_tree7.mps ps_tree8.mps ps_tree9.mps > ps_tree10.mps ps_tree11.mps ps_tree12.mps ps_tree13.mps ps_tree14.mps) (deps > tree.exe) (action (run ./tree.exe -ps -prefix "ps_"))) > > > (cd _build/default/examples && ./tree.exe -ps -prefix ps_) > Fatal error: exception Unix.Unix_error(Unix.ENOENT, "rename", "tree.1") > dh_auto_test: error: dune runtest -j 8 -p mlpost returned exit code 1 > make: *** [debian/rules:7: binary] Error 25 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 Packages rebuilt with OCaml 4.14.1 are available at: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1052231: FTBFS with OCaml 4.14.1
Source: gmetadom Version: 0.2.6-8 Severity: important Tags: ftbfs User: debian-ocaml-ma...@lists.debian.org Usertags: ocaml-4.14.1-transition Dear Maintainer, Your package FTBFS with OCaml 4.14.1 with the following error: > [...] > ml_EventListener.c:99:13: warning: "callback" is deprecated: use > "caml_callback" instead >99 | *cb = callback; > | ^ > > ml_EventListener.c:100:13: warning: "register_global_root" is deprecated: use > "caml_register_global_root" instead > 100 | register_global_root(cb); > | ^~~ > > make[6]: *** [Makefile:473: ml_EventListener.lo] Error 1 > make[6]: Leaving directory '/tmp/build/gmetadom-0.2.6/src/gdome_caml/events' > make[5]: *** [Makefile:388: all] Error 2 > make[5]: Leaving directory '/tmp/build/gmetadom-0.2.6/src/gdome_caml/events' > make[4]: *** [Makefile:523: all-recursive] Error 1 > make[4]: Leaving directory '/tmp/build/gmetadom-0.2.6/src/gdome_caml' > make[3]: *** [Makefile:387: all-recursive] Error 1 > make[3]: Leaving directory '/tmp/build/gmetadom-0.2.6/src' > make[2]: *** [Makefile:490: all-recursive] Error 1 > make[2]: Leaving directory '/tmp/build/gmetadom-0.2.6' > make[1]: *** [Makefile:397: all] Error 2 > make[1]: Leaving directory '/tmp/build/gmetadom-0.2.6' > dh_auto_build: error: make -j1 returned exit code 2 > make: *** [debian/rules:4: binary] Error 25 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 Packages rebuilt with OCaml 4.14.1 are available at: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1052230: FTBFS with OCaml 4.14.1
Source: caml-crush Version: 1.0.12-1.1 Severity: important Tags: ftbfs User: debian-ocaml-ma...@lists.debian.org Usertags: ocaml-4.14.1-transition Dear Maintainer, Your package FTBFS with OCaml 4.14.1 with the following error: > [...] > collect2: error: ld returned 1 exit status > File "caml_startup", line 1: > Error: Error during linking (exit code 1) > make[3]: *** [Makefile:15: all] Error 2 > make[3]: Leaving directory > '/tmp/build/caml-crush-1.0.12/build-SERVER/src/pkcs11proxyd' > make[2]: *** [Makefile:18: server] Error 2 > make[2]: Leaving directory '/tmp/build/caml-crush-1.0.12/build-SERVER' > dh_auto_build: error: cd build-SERVER && make -j1 > CUSTOM_SONAME=libp11clienttcpssl.so returned exit code 2 > make[1]: *** [debian/rules:45: override_dh_auto_build-SERVER] Error 25 > make[1]: Leaving directory '/tmp/build/caml-crush-1.0.12' > make: *** [debian/rules:53: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 Packages rebuilt with OCaml 4.14.1 are available at: http://ocaml.debian.net/transitions/ocaml-4.14.1/ Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1043252: Next OCaml transition: 4.14.x
Hi, OCaml 5.1.0 has just been released, and a version 4.14.2 will soon be released. Current version in unstable is 4.13.1. I played a bit with opam-debian-switch, and it turns out that (at least) 35 packages are broken (at the moment) with OCaml 5.1.0 whereas only 1 seems broken with 4.14.1. Therefore, I am planning to migrate to 4.14.x first. Cheers, -- Stéphane
Bug#1052035: ulex0.8: FTBFS: Error: This expression has type char Stream.t -> (MLast.str_item * MLast.loc) list * Pcaml.status but an expression was expected of type 'a ref
Hi, Le 16/09/2023 à 12:54, Sebastian Ramacher a écrit : Source: ulex0.8 Version: 1.2-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org [...] See https://bugs.debian.org/1051377 Cheers, -- Stéphane
Bug#1051524: frama-c: please update to v27.1 Cobalt
Source: frama-c Version: 20220511-manganese-4 Severity: important Tags: upstream Control: block -1 by 1001893 Dear Maintainer, frama-c in Debian is two versions behind upstream, which starts to cause problems (see #1051485). Setting Severity to important, since the current situation has a major effect on the usability of the package (no Why3 support). Note that the new version depends on ocaml-yaml, hence the block relationship. Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1051475: ledit: can't be built with arch:all+any
Le 08/09/2023 à 15:53, Gianfranco Costamagna a écrit :
Hello, for some reasons, building ledit with arch:all + arch:any
produces a ledit binary with an additional dependency
on libstdlib-ocaml-lqmb5
This makes the arch:all package not binNMU safe, and then RC buggy.
I think, for an arch:all package binary depending on shlibs:Depends and
ocaml:Depends is a little bit strange
Package: ledit
Architecture: all
Depends:
${ocaml:Depends},
${misc:Depends},
${shlibs:Depends}
I don't honestly know if we have to convert ledit into an arch:all
package, or to stop adding ocaml:Depends on it.
dh_ocaml + arch:all has always been shaky, I think it's better to make
ledit an arch:any package (I did it for ocamlwc recently).
Cheers,
--
Stéphane
Bug#1051440: RM: lablgtk2 -- ROM; depends on obsolete library
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: lablg...@packages.debian.org, debian-ocaml-ma...@lists.debian.org Control: affects -1 + src:lablgtk2 Dear FTP team, With unison-2.52 removal (#1050381), lablgtk2 will no longer have reverse dependencies. It is time to remove it. Cheers, -- Stéphane
Bug#1051377: RM: ulex0.8 -- ROM; no more rdeps; FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ulex...@packages.debian.org, debian-ocaml-ma...@lists.debian.org Control: affects -1 + src:ulex0.8 Dear FTP team, ulex0.8 was kind of a transitional package (cf #436982) that has no more reverse dependencies. Moreover, it fails to build from source with camlp5 8.02.x. I think it's time to remove it. Note that it is known as ulex-camlp5 in opam, and it has no reverse dependencies there. Cheers, -- Stéphane
Bug#1050381: Bug#1041789: RM: unison-2.51+4.13.1 -- RoQA; newer version packaged
Le 29/07/2023 à 22:57, Vincent Lefevre a écrit : Is this version really needed? /usr/share/doc/unison-2.52/NEWS.md.gz says: ## Changes in 2.52.0 Released 2022-03-12 * Feature negotiation, compatible with 2.51. * New archive format (independent of ocaml version, based on umarshal) Upgrade is automatic. * New wire protocol (independent of ocaml version, based on umarshal) New protocol is used if both sides are >= 2.52.0. [...] But you could check and decide later. I wanted to check that unison-2.53 is indeed compatible with unison-2.52, which seems to be the case. I'll wait for unison-2.53 and meta-unison to migrate to testing, and then I'll ask for the removal of unison-2.52. Cheers, -- Stéphane
Bug#1050490: Uses ~/.icedove and ~/.thunderbird
Package: thunderbird Version: 1:115.1.1-1 Severity: normal Dear Maintainer, While cleaning up my dot files and dirs, I've noticed that Thunderbird uses both ~/.icedove and ~/.thunderbird. The ~/.icedove looks Debian-specific, and Icedove is long gone, why is it still used? Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 5.8-1 ii fontconfig 2.14.2-4 ii libasound2 1.2.9-1 ii libatk1.0-0 2.48.3-1 ii libc62.37-7 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libdbus-1-3 1.14.8-2 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-1 ii libfontconfig1 2.14.2-4 ii libfreetype6 2.13.1+dfsg-1 ii libgcc-s113.2.0-2 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.77.2-1 ii libgtk-3-0 3.24.38-2 ii libnspr4 2:4.35-1.1 ii libnss3 2:3.92-1 ii libotr5 4.1.1-5 ii libpango-1.0-0 1.51.0+ds-2 ii librnp0 0.17.0-3 ii libstdc++6 13.2.0-2 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.6-1 ii libx11-xcb1 2:1.8.6-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxext6 2:1.3.4-1+b1 ii libxrandr2 2:1.5.2-2+b1 ii psmisc 23.6-1 ii x11-utils7.7+5 ii zenity 3.44.2-1 ii zlib1g 1:1.2.13.dfsg-3 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2 ii hunspell-fr-classical [hunspell-dictionary] 1:7.0-1 Versions of packages thunderbird suggests: ii apparmor 3.0.8-3 ii fonts-lyx 2.3.7-1 ii libgssapi-krb5-2 1.20.1-3 -- no debconf information
Bug#1050027: blocking migration of other OCaml packages to testing
Dear Julien, Le 19/08/2023 à 20:58, Helmut Grohne a écrit : Control: reopen -1 Control: found -1 mathcomp-analysis/0.6.4-2 On Sat, Aug 19, 2023 at 05:33:11PM +, Debian Bug Tracking System wrote: It has been closed by Debian FTP Masters (reply to Julien Puydt ). I'm sorry. Adding Breaks is necessary but insufficient. You also need Replaces. Can you fix this quickly, please? This is preventing (at least) 7 packages to migrate to testing: js-of-ocaml-ocamlbuild, ocaml-alcotest, ocaml-re, ocaml-stdio, ocaml-stringext, ocaml-time-now, pgocaml. With dh-ocaml (which will be old enough tomorrow) and mathcomp-analysis, they are all the OCaml packages that are not in sync between unstable and testing... You can argue later and elsewhere (debian-devel or a bug report against the policy). Cheers, -- Stéphane
Bug#1050027: closed by Debian FTP Masters (reply to Julien Puydt ) (Bug#1050027: fixed in mathcomp-analysis 0.6.4-2)
Le 19/08/2023 à 21:25, julien.pu...@gmail.com a écrit : I'm sorry. Adding Breaks is necessary but insufficient. You also need Replaces. What is in libcoq-mathcomp-analysis << 0.6.4 is now in two packages: - libcoq-mathcomp-classical (a small part) ; - libcoq-mathcomp-analysis (the most part -- and that binary package depends on libcoq-mathcomp-classical with a strong version constraint). This situation is explicitly covered in Policy 7.3 and 7.6.1. The problem you pointed was that a user with an old libcoq-mathcomp- analysis asking to install libcoq-mathcomp-classical would lead dpkg to a conflict of files. The breaks I added prevents that, and in fact a user with an old licoq-mathcomp-analysis should have no issue in those situations: (1) try to install a newer libcoq-mathcomp-classical -- with my Breaks dpkg will refuse because of the conflict which is a sane answer : system not broken, features not broken ; (2) try to upgrade - dpkg will see the new libcoq-mathcomp-analysis needs libcoq-mathcomp-classical and that it breaks the outgoing libcoq- mathcomp-analysis, but it's able to handle the situation ; If I declare libcoq-mathcomp-classical Replaces libcoq-mathcomp- analysis << 0.6.4, then in situation (1), dpkg will install libcoq- mathcomp-classical and drop that old libcoq-mathcomp-analysis. The system is not broken, but the user just lost most of the functionality, and that is bad. So I think the change I made is sound. Although it might be sound, my understanding is that it make upgrades unnecessarily difficult: without the Replaces, one has to completely deconfigure the old libcoq-mathcomp-analysis (and its reverse-dependencies) before installing the new one. Do you have another problem in mind? Or a better fix? The better fix is to add Breaks *and* Replaces, as instructed by Helmut and Policy. Cheers, -- Stéphane
Bug#1050003: Dune sometimes changes *.opam files in release mode
Package: ocaml-dune Version: 3.9.1-1 Severity: minor Tags: upstream Forwarded: https://github.com/ocaml/dune/issues/8417 X-Debbugs-Cc: lu...@debian.org Hi, Many of the recent "Fails to build source after successful build" are due to Dune changing *.opam files, which IMHO should not happen, especially since we call it in release mode. It seems that it's possible to ignore changes in *.opam files per package [1], but it sounds more sensible to fix Dune. [1] https://lists.debian.org/msgid-search/znuruonpfy0rs...@argenau.bebt.de I've opened an upstream issue for this. Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ocaml-dune depends on: ii libc6 2.37-7 ocaml-dune recommends no packages. ocaml-dune suggests no packages. -- no debconf information
Bug#1000004: pcre-ocaml: depends on obsolete pcre3 library
Hi, Status update : I've started migrating reverse-dependencies to use the pure-OCaml re library, which has a (imperfect) compatibility layer. However, camlp5's upstream has expressed reluctance [1] to this move. [1] https://github.com/camlp5/camlp5/issues/101#issuecomment-1678163219 > Besides, I'm not sure it makes sense to port pcre-ocaml to pcre2 while > keeping the same OCaml API, which mimics the PCRE one. Moreover, > pcre-ocaml is widely used and has many reverse dependencies in Debian: I don't know how tricky it will be to port pcre-ocaml to pcre2; I know a number of languages have successfully ported their PCRE bindings to PCRE2 (e.g. PHP who wrote about it https://wiki.php.net/rfc/pcre2-migration ). The regex syntax itself hasn't changed. Someone did the port of pcre-ocaml to pcre2 [2], which I've packaged as pcre2-ocaml. [2] https://github.com/mmottl/pcre-ocaml/issues/25#issuecomment-1483806201 Cheers, -- Stéphane
Bug#1049405: ITP: pcre2-ocaml -- OCaml bindings for PCRE2
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: pcre2-ocaml Version : 0.0.0~git20230408 * URL : https://github.com/tobil4sk/pcre2-ocaml * License : LGPL-2.1+ Programming Lang: C, OCaml Description : OCaml bindings for PCRE2 This OCaml-library interfaces the PCRE2 (Perl-compatibility regular expressions) C library. it can be used for matching regular expressions which are written in Perl style. This is basically pcre-ocaml, which is threatened to be removed from Debian because of #104 (depends on obsolete pcre), ported to pcre2 by tobil4sk. Neither pcre-ocaml original author [1], nor tobil4sk [2] seem to want to maintain the new bindings upstream, but Chet Murthy has offerred [3] to take this role. Since some upstreams of reverse-dependencies of pcre-ocaml (liquidsoap [4], camlp5 [5]) have expressed interest to switch to these new bindings nonetheless, I decided to package them for Debian. The package will be maintained in the OCaml team. [1] https://github.com/mmottl/pcre-ocaml/issues/25#issuecomment-1014792185 [2] https://github.com/mmottl/pcre-ocaml/issues/25#issuecomment-1483806201 [3] https://github.com/mmottl/pcre-ocaml/issues/25#issuecomment-1676463732 [4] https://github.com/savonet/liquidsoap/pull/3277 [5] https://github.com/camlp5/camlp5/issues/101#issuecomment-1678163219 -- Stéphane
Bug#1043427: src:utop: fails to migrate to testing for too long: blocked by ocaml-logs rebuild
Le 11/08/2023 à 20:53, Paul Gevers a écrit : One current blocker is xmlrpc-light, which I mistakenly uploaded with urgency low 2 days ago, which therefore should not migrate before 8 days from now. It seems the connection is hidden. It would be nice if you could show how that works. Look for "(not considered)" implicit dependencies with grep-excuses: utop -> ocaml-logs/ppc64el -> ocaml-x509/ppc64el -> ocaml-zarith -> ocsigenserver/s390x -> xml-light -> xmlrpc-light AFAIU, these 7 items (at least) need to migrate to testing together. I am wondering: Couldn't the required age for xmlrpc-light be lowered? Or should I upload a new package with a higher urgency? I have added an age hint and dropped required age to 5. Thank you. Cheers, -- Stéphane
Bug#1043427: src:utop: fails to migrate to testing for too long: blocked by ocaml-logs rebuild
Dear Paul, On Thu, 10 Aug 2023 21:44:23 +0200 Paul Gevers wrote: [...]¨ Your package src:utop has been trying to migrate for 37 days [2]. [...] > If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. One current blocker is xmlrpc-light, which I mistakenly uploaded with urgency low 2 days ago, which therefore should not migrate before 8 days from now. I am wondering: Couldn't the required age for xmlrpc-light be lowered? Or should I upload a new package with a higher urgency? Cheers, -- Stéphane
Bug#1025221: Work around abseil test failures on riscv64
Hi, In the attached patch, I propose to make test failures non-fatal on riscv64. Cheers, -- StéphaneFrom 0b75b77441aeb3bcca5695e4bd17dc2732e86432 Mon Sep 17 00:00:00 2001 From: Stephane Glondu Date: Tue, 8 Aug 2023 15:07:23 +0200 Subject: [PATCH] Backport fix to #1025221 --- debian/changelog | 8 debian/rules | 8 +++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 0a2de86..22dc86d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +abseil (20220623.1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Run tests serially on riscv64 to avoid hitting Debian build hardware +limits, and do not fail the build on failures. (Closes: #1025221) + + -- Stéphane Glondu Tue, 08 Aug 2023 15:06:55 +0200 + abseil (20220623.1-2) unstable; urgency=medium * Constrain build to GCC 12, since this version of Abseil doesn’t build diff --git a/debian/rules b/debian/rules index d609759..2497135 100755 --- a/debian/rules +++ b/debian/rules @@ -30,6 +30,12 @@ else ABSL_RUN_TESTS=ON endif +# Debian's RISC-V builders don't have enough resources to run tests in parallel. +# See https://bugs.debian.org/1025221. +ifneq ($(filter $(DEB_HOST_ARCH),riscv64),) +ABSL_TEST_EXTRA_ARGS=--no-parallel || true +endif + %: dh $@ @@ -51,7 +57,7 @@ override_dh_auto_build: ifeq ($(ABSL_RUN_TESTS),ON) override_dh_auto_test: - dh_auto_test -Bshared + dh_auto_test -Bshared $(ABSL_TEST_EXTRA_ARGS) endif override_dh_auto_install: -- 2.40.1
Bug#1043252: Ocaml 5.0.0
Le 08/08/2023 à 12:03, Yuri D'Elia a écrit : Thanks! There's no plan to make 4.x and 5.x co-exist right? Right. -- Stéphane
Bug#1043252: Ocaml 5.0.0
Control: block -1 by 1042958 Hi, Le 07/08/2023 à 23:40, Yuri D'Elia a écrit : Is there any plan to eventually package ocaml 5.0.0? I'm planning to switch directly to 5.1.0. Meanwhile, there are things to do: - generalize the use of ocaml_dune DH buildsystem (~60 packages) - replace dependencies on ocaml-nox by ocaml, to eventually remove the transitional package (~174 packages) - wait for camlp5-buildscripts to pass NEW, so that camlp5 can be updated (probably required for a new OCaml version) - wait for OCaml packages to migrate to testing (~65 packages at the moment) Cheers, -- Stéphane
Bug#1043110: ITP: ocaml-randomconv -- convert from random byte vectors to random native numbers
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-randomconv Version : 0.1.3 Upstream Contact: Hannes Mehnert * URL : https://github.com/hannesm/randomconv * License : ISC Programming Lang: OCaml Description : convert from random byte vectors to random native numbers Given a function which produces random byte vectors, convert it to a number of your choice (int8/int16/int32/int64/int/float). This package is needed to run all ocaml-mirage-crypto tests. It will be maintained in the OCaml team.
Bug#1042958: ITP: camlp5-buildscripts -- Camlp5 build scripts
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: camlp5-buildscripts Version : 0.02 Upstream Contact: Chet Murthy * URL : https://github.com/camlp5/camlp5-buildscripts * License : MIT Programming Lang: OCaml Description : Camlp5 build scripts These are build-scripts that are helpful in building Camlp5 and packages based on Camlp5. As such, they need to not depend on Camlp5. The command are not installed in a bin-directory, but in the package-directory, hence invoked via the "ocamlfind package/exe" method. This is a new dependency of camlp5 and will be maintained in the OCaml team.
Bug#1042501: Depends on obsolete pcre
Source: ocsigenserver Severity: serious Tags: upstream Dear Maintainer, ocsigenserver depends on obsolete libpcre-ocaml-dev. Please move away to another regexp library. Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1042499: Depends on obsolete pcre
Source: ocaml-duppy Severity: serious Tags: upstream Dear Maintainer, ocaml-duppy depends on obsolete libpcre-ocaml-dev. Please move away to another regexp library. Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1037757: llvm-toolchain-13: ftbfs with GCC-13
Hi,
Le 29/07/2023 à 08:57, Stéphane Glondu a écrit :
Therefore, I am going to submit a NMU forcing usage of g++-12.
It FTBFS with an error about missing asm/errno.h (among others).
Exporting CPATH=/usr/include/x86_64-linux-gnu, the build goes a bit
further, but fails at linking libomp.so.5.
I attach the (non-working) patch for reference.
I don't know how to make progress on this matter at the moment.
Cheers,
--
StéphaneFrom 01afffd4666c7b0d3a890d6104d7d4a8f60f8f8e Mon Sep 17 00:00:00 2001
From: Stephane Glondu
Date: Sat, 29 Jul 2023 08:00:21 +0200
Subject: [PATCH] Use g++-12 (Closes: #1037757)
---
debian/changelog | 7 +++
debian/control | 3 ++-
debian/rules | 4 +---
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index edce89dcf..1e1215a17 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+llvm-toolchain-13 (1:13.0.1-11.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Use g++-12 (Closes: #1037757)
+
+ -- Stéphane Glondu Sat, 29 Jul 2023 09:39:11 +0200
+
llvm-toolchain-13 (1:13.0.1-11) unstable; urgency=medium
* link-grpc.diff: add the detection of other libs necessary for
diff --git a/debian/control b/debian/control
index 9af8137c5..dcb26c715 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,8 @@ Build-Depends: debhelper (>= 10.0), cmake, ninja-build,
libxml2-dev,
libjsoncpp-dev, pkg-config,
lcov, procps, help2man, zlib1g-dev,
-g++-multilib [amd64 i386 kfreebsd-amd64 mips64 mips64el mipsel powerpc ppc64 s390 s390x sparc sparc64 x32],
+g++-12,
+g++-12-multilib [amd64 i386 kfreebsd-amd64 mips64 mips64el mipsel powerpc ppc64 s390 s390x sparc sparc64 x32],
libjs-mathjax, python3-recommonmark,
doxygen, gfortran,
ocaml-base [amd64 arm64 armhf ppc64el riscv64 s390x] | ocaml-nox [amd64 arm64 armhf ppc64el riscv64 s390x],
diff --git a/debian/rules b/debian/rules
index 0ae7f947e..48e30bbec 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,9 +9,7 @@ TARGET_BUILD := build-llvm
TARGET_BUILD_STAGE2:= $(TARGET_BUILD)/tools/clang/stage2-bins
DEB_INST := $(CURDIR)/debian/tmp/
-GXX_VERSIONED_PACKAGE:= $(shell dpkg-query -W -f '$${Depends}' g++ | grep -o 'g++-[0-9][0-9.]*' | tail -n1 )
-GXX_VERSIONED_EXECUTABLE := $(shell dpkg -L $(GXX_VERSIONED_PACKAGE) | grep '/usr/bin/g++-[0-9][0-9.]*' | xargs ls -d | tail -n1 )
-GCC_VERSION := $(subst /usr/bin/g++-,,$(GXX_VERSIONED_EXECUTABLE))
+GCC_VERSION := 12
LLVM_VERSION := $(shell dpkg-parsechangelog | sed -rne "s,^Version: 1:([0-9]+).*,\1,p")
LLVM_VERSION_FULL := $(shell dpkg-parsechangelog | sed -rne "s,^Version: 1:([0-9.]+)(~|-)(.*),\1,p")
--
2.40.1
Bug#1037757: llvm-toolchain-13: ftbfs with GCC-13
On Wed, 14 Jun 2023 09:27:51 + Matthias Klose wrote: Package: src:llvm-toolchain-13 Version: 1:13.0.1-11 Severity: normal Tags: sid trixie User: debian-...@lists.debian.org Usertags: ftbfs-gcc-13 [...] The package fails to build in a test rebuild on at least amd64 with gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The severity of this report will be raised before the trixie release. Now, this build failure happens in unstable as well. It prevents ocaml-ctypes (and maybe other OCaml-related packages) from migrating to testing. llvm-toolchain-13 has been requested to be removed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017679 This is blocked by ghc, which has no fix at the moment: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017663 The OCaml situation makes it urgent that llvm-toolchain-13 builds again. Therefore, I am going to submit a NMU forcing usage of g++-12. Cheers, -- Stéphane
Bug#1041789: RM: unison-2.51+4.13.1 -- RoQA; newer version packaged
Control: reassign -1 ftp.debian.org Le 23/07/2023 à 18:49, Bastian Germann a écrit : Source: unison-2.51+4.13.1 Version: 2.51.5-1 Severity: serious Why is unison-2.51+4.13.1 not removed yet when unison-2.52 is available? It is OK to remove unison-2.51+4.13.1 from unstable now. Note that I would like to keep unison-2.52 (even if a newer version is packaged) at least in trixie, to allow synchronizing between bookworm and trixie. Cheers, -- Stéphane
Bug#1017663: ghc: Please upgrade to llvm-toolchain-14
On Mon, 19 Dec 2022 16:03:13 +0100 Bastian Germann wrote: ghc is really the last non-trivial blocker for llvm-toolchain-13 to be removed from bookworm. There is no indication in upstream's bug tracker that ghc will be LLVM 14 compatible soon. Is anyone up for addressing this? Any news on that? I see that there are versions of ghc in experimental that seem to build with more recent LLVM. When will you upload one to unstable? llvm-toolchain-13 does no longer build in unstable and is preventing packages to migrate to testing. Cheers, -- Stéphane
Bug#1017677: autofdo: Please upgrade to llvm-toolchain-14
Hi, On Mon, 19 Dec 2022 15:25:43 +0100 Bastian Germann wrote: On Thu, 18 Aug 2022 23:43:14 +0200 Sylvestre Ledru wrote: > As part of the effort to limit the number of llvm packages in the > archive, it would be great if you could upgrade to -14. > > We are trying NOT to ship Bookworm with llvm-toolchain-13. > > llvm-defaults is now pointing to -14. The package builds with llvm-dev. Please update. Just replacing "llvm-13-dev" with "llvm-dev", the package indeed builds but without LLVM support. One also needs to adapt debian/rules, and doing so makes the package fail to build. With LLVM 14, 15 and 16. llvm-toolchain-13 has become problematic: it fails to build in unstable, and will soon start preventing packages from migrating to testing. It's time to get rid of it. I propose to upload a version of autofdo without LLVM support. To make progress on this, I will make a NMU to DELAYED/5. Cheers, -- Stéphane
Bug#1041684: ITP: not-ocamlfind -- front-end to ocamlfind to add a few new commands
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: not-ocamlfind Version : 0.10 Upstream Contact: Chet Murthy * URL : https://github.com/chetmurthy/not-ocamlfind * License : MIT Programming Lang: OCaml Description : front-end to ocamlfind to add a few new commands The command not-ocamlfind is a pass-thru to ocamlfind, but adds three new commands: preprocess, reinstall-if-diff and package-graph. This package is a new dependency of camlp5. It will be maintained in the OCaml team.
Bug#1041036: dh-ocaml: An ocaml-dune helper might make sense?
Control: tags -1 + confirmed Le 14/07/2023 à 10:37, Adrian Bunk a écrit : I am not sure whether the new ocaml-dune broke the build of all 192 reverse build dependencies, but it seems to be a majority of them. I have no clue about OCaml, but what breaks looks like template code pasted around so you might consider factoring it out into an ocaml-dune debhelper sequence? Indeed. There seems to be 80 remaining packages that are affected by this issue. Factoring out the common code is indeed a good idea. But this needs some thought. On the other hand, fixing the existing packages is simple enough, and looks more urgent. Are you going to submit a bug for each broken package? I think I can automate things, but it depends on whether there is a bug to close each time. Cheers, -- Stéphane
Bug#1039878: gnome-shell: Many zombie xprop processes
Control: reassign -1 gnome-shell-extension-pixelsaver Control: tags -1 - moreinfo Le 29/06/2023 à 11:25, Simon McVittie a écrit : I noticed there are many zombie "xprop" processes on my system, whose parent is gnome-shell. They disappear when I restart the session, but then start reappearing progressively. gnome-shell doesn't have any mentions of xprop in its source code, so this is probably a Shell extension (which run as part of the gnome-shell process and are just as powerful as Shell itself, but with less experienced upstream maintainers). Please disable all extensions and see whether the problem persists. Based on codesearch.debian.net I'm going to guess that you probably use gnome-shell-extension-pixelsaver, which is documented as "depends on Xorg's `xprop` and `xwininfo` utilities", and contains at least one suspicious use of GLib.SpawnFlags.DO_NOT_REAP_CHILD which seems likely to cause zombie processes. Indeed, you seem to be right: after disabling this extension, xprop zombies are gone. (I don't know why pixelsaver is using xprop to communicate "please don't draw a titlebar", rather than making use of its ability to execute arbitrary code in gnome-shell to not draw the titlebar even if the app asked for one.) -- Stéphane
Bug#1040821: RM: ocaml-melt -- ROM; FTBFS; dead upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ocaml-m...@packages.debian.org Control: affects -1 + src:ocaml-melt Dear FTP Team, Please remove ocaml-melt from unstable. It has been FTBFS since 2020 and upstream seems dead. Cheers, -- Stéphane
Bug#1039878: gnome-shell: Many zombie xprop processes
Package: gnome-shell Version: 43.6-1 Severity: normal Dear Maintainer, I noticed there are many zombie "xprop" processes on my system, whose parent is gnome-shell. They disappear when I restart the session, but then start reappearing progressively. Cheers, -- Stéphane -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-accountsservice-1.0 22.08.8-6 ii gir1.2-adw-1 1.2.4-1 ii gir1.2-atk-1.0 2.48.3-1 ii gir1.2-atspi-2.0 2.48.3-1 ii gir1.2-freedesktop 1.74.0-3 ii gir1.2-gcr-3 3.41.1-3 ii gir1.2-gdesktopenums-3.0 43.0-1 ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii gir1.2-gdm-1.0 43.0-3 ii gir1.2-geoclue-2.0 2.6.0-3 ii gir1.2-glib-2.0 1.74.0-3 ii gir1.2-gnomebluetooth-3.042.5-3 ii gir1.2-gnomedesktop-3.0 43.2-2 ii gir1.2-graphene-1.0 1.10.8-1 ii gir1.2-gstreamer-1.0 1.22.3-2 ii gir1.2-gtk-3.0 3.24.37-2 ii gir1.2-gtk-4.0 4.8.3+ds-2 ii gir1.2-gweather-4.0 4.2.0-2 ii gir1.2-ibus-1.0 1.5.28-5 ii gir1.2-mutter-11 43.6-1 ii gir1.2-nm-1.01.42.6-2 ii gir1.2-nma-1.0 1.10.6-1 ii gir1.2-pango-1.0 1.50.14+ds-1 ii gir1.2-polkit-1.0122-4 ii gir1.2-rsvg-2.0 2.54.5+dfsg-1 ii gir1.2-soup-3.0 3.2.2-2 ii gir1.2-upowerglib-1.00.99.20-2 ii gir1.2-webkit2-4.1 2.40.2-1 ii gnome-backgrounds44.0-2 ii gnome-settings-daemon43.0-4 ii gnome-shell-common 43.6-1 ii gsettings-desktop-schemas43.0-1 ii gstreamer1.0-pipewire0.3.71-2+b1 ii libatk-bridge2.0-0 2.48.3-1 ii libatk1.0-0 2.48.3-1 ii libc62.36-9 ii libcairo21.16.0-7 ii libecal-2.0-23.48.3-1 ii libedataserver-1.2-273.48.3-1 ii libgcr-base-3-1 3.41.1-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgirepository-1.0-11.74.0-3 ii libgjs0g 1.74.2-1 ii libgles2 1.6.0-1 ii libglib2.0-0 2.74.6-2 ii libglib2.0-bin 2.74.6-2 ii libgnome-autoar-0-0 0.4.4-2 ii libgnome-desktop-3-2043.2-2 ii libgraphene-1.0-01.10.8-1 ii libgtk-3-0 3.24.37-2 ii libgtk-4-1 4.8.3+ds-2 ii libical3 3.0.16-1+b1 ii libjson-glib-1.0-0 1.6.6-1 ii libmutter-11-0 43.6-1 ii libnm0 1.42.6-2 ii libpango-1.0-0 1.50.14+ds-1 ii libpangocairo-1.0-0 1.50.14+ds-1 ii libpolkit-agent-1-0 122-4 ii libpolkit-gobject-1-0122-4 ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1 ii libpulse016.1+dfsg1-2+b1 ii libsecret-1-00.20.5-3 ii libsystemd0 252.11-1 ii libwayland-server0 1.21.0-1 ii libx11-6 2:1.8.6-1 ii libxfixes3 1:6.0.0-2 ii python3 3.11.2-1+b1 Versions of packages gnome-shell recommends: ii bolt 0.9.5-1 ii chrome-gnome-shell 42.1-3 ii evolution-data-server 3.48.3-1 ii gdm3 43.0-3 ii gkbd-capplet 3.28.1-1 ii
Bug#1035849: opam: `opam init` fails. Missing ca-certificates dependency, only listed as recommended
Le 10/05/2023 à 11:15, Cuihtlauac Alvarado a écrit : I agree you have a valid point, your reasoning makes sense. However, it seems to me that by the same reasoning bubblewrap should be turned into a recommended dependency too. Your command opam init --bare --disable-sandboxing default /path/to/repository also works if bubblewrap is forcefully removed (and the dependencies broken, for the sake of the example). Therefore, there exists a way to use opam without bubblewrap, it could be recommended only. I agree, and I am more willing to demote bubblewrap to Recommends than promote ca-certificates to Depends. Cheers, -- Stéphane
Bug#1035849: opam: `opam init` fails. Missing ca-certificates dependency, only listed as recommended
Hi, Le 10/05/2023 à 09:04, Cuihtlauac ALVARADO a écrit : Once installed, to be usable, opam needs to be initialized. Here is the command: opam init Indeed, the default repository is on HTTPS. However, if you have a local copy of the repository, opam init --bare --disable-sandboxing default /path/to/repository works without ca-certificates. So there exists a way to use opam without this package, hence the Recommends (I suppose, I didn't make the initial packaging myself). And by default, Recommends are installed, so opam with default settings works in Debian with default settings. Similarly, git only recommends ca-certificates, and fails when cloning from HTTPS without it. Cheers, -- Stéphane
Bug#1035728: unblock: ocsigenserver/5.0.1-1+b12
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ocsigenser...@packages.debian.org,
debian-ocaml-ma...@lists.debian.org
Control: affects -1 + src:ocsigenserver
Dear Release Team,
Please unblock package ocsigenserver
The change is the addition of a missing Breaks+Replaces and should be
trivial.
unblock ocsigenserver/5.0.1-1+b12
Cheers,
--
Stéphane
diff -Nru ocsigenserver-5.0.1/debian/changelog
ocsigenserver-5.0.1/debian/changelog
--- ocsigenserver-5.0.1/debian/changelog2022-01-23 12:54:32.0
+0100
+++ ocsigenserver-5.0.1/debian/changelog2023-05-05 13:38:30.0
+0200
@@ -1,3 +1,10 @@
+ocsigenserver (5.0.1-2) unstable; urgency=medium
+
+ * Add missing Breaks+Replaces for libocsigenserver-ocaml-dev
+(Closes: #1034938)
+
+ -- Stéphane Glondu Fri, 05 May 2023 13:38:30 +0200
+
ocsigenserver (5.0.1-1) unstable; urgency=medium
* New upstream release
diff -Nru ocsigenserver-5.0.1/debian/control ocsigenserver-5.0.1/debian/control
--- ocsigenserver-5.0.1/debian/control 2022-01-23 12:54:32.0 +0100
+++ ocsigenserver-5.0.1/debian/control 2023-05-05 13:38:30.0 +0200
@@ -53,6 +53,8 @@
${ocaml:Depends},
${shlibs:Depends},
${misc:Depends}
+Breaks: libocsigenserver-ocaml-dev (<< 5)
+Replaces: libocsigenserver-ocaml-dev (<< 5)
Provides: ${ocaml:Provides}
Suggests: ocaml-findlib
Description: web server of the Ocsigen project (runtime libraries)
Bug#1034938: libocsigenserver-ocaml: missing Breaks+Replaces for libocsigenserver-ocaml-dev when upgrading from bullseye
Hi, Le 27/04/2023 à 14:59, Helmut Grohne a écrit : Attempting to unpack libocsigenserver-ocaml/5.0.1-1+b12 from Debian bookworm on a minimal Debian bullseye with libocsigenserver-ocaml-dev/2.16.1-1+b3 installed, causes an unpack error from dpkg due to /usr/lib/ocaml/ocsigenserver/ocsigenserver.cma being contained in both packages. | (Reading database ... 12625 files and directories currently installed.) | Preparing to unpack .../libocsigenserver-ocaml_5.0.1-1+b12_amd64.deb ... | Unpacking libocsigenserver-ocaml (5.0.1-1+b12) over (2.16.1-1+b3) ... | dpkg: error processing archive ./libocsigenserver-ocaml_5.0.1-1+b12_amd64.deb (--unpack): | trying to overwrite '/usr/lib/ocaml/ocsigenserver/ocsigenserver.cma', which is also in package libocsigenserver-ocaml-dev 2.16.1-1+b3 | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) | Errors were encountered while processing: | ./libocsigenserver-ocaml_5.0.1-1+b12_amd64.deb Please ensure that libocsigenserver-ocaml has sufficient Breaks and Replaces declarations. I agree that doctrine says Breaks+Replaces are missing here, and I will fix that. However, I wonder how one would get the aforementioned error in practice. In a minimal bullseye chroot with libocsigenserver-ocaml-dev installed, after adding bookworm to sources.list: - "apt upgrade" does not attempt to upgrade libocsigenserver-ocaml - "apt dist-upgrade" upgrades libocsigenserver-ocaml along with libocsigenserver-ocaml-dev, with no errors This is the same outcome with the "fixed" libocsigenserver-ocaml. Installing with "dpkg -i" does produce the error, but installing the fixed package with "dpkg -i" also produces an error. Cheers, -- Stéphane
Bug#1034691: nmu: why3_1.5.1-1+b1 frama-c_20220511-manganese-3-10
Dear Sebastian, Le 23/04/2023 à 11:36, Sebastian Ramacher a écrit : ocaml 4.13.1-4 causes the ABI to change for at least why3. Do you expect that the ABI of ther ocaml packages also changes? If so, we should rebuild the ocaml world before the release to not get any surprises if a ocaml package gets a stable update. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030785 The ABI of ocaml-compiler-libs changed (only on native architectures), with no visible changes in virtual packages, so anything using that is potentially broken. I (thought I) binNMUed all affected packages (there were a lot of them), but missed why3 for some reason. IMHO, the cleanest way to fix the issue for sure is to change the OCaml ABI advertised in the virtual package name. But that means an amount of work similar to an OCaml transition. Do we really work this kind of move at this stage of the freeze? I don't think so. A pretty good approximation to checking that everything is fine is to mass-rebuild everything (as Lucas Nussbaum does regularly), identify the (few, I expect) packages that FTBFS, and binNMU them (+ maybe some of their dependencies). I suspect why3 is special because it embeds modules provided by ocaml in a plugin (dh_ocaml's --nodefined-map is suspicious in this context) but this situation should be rare. Cheers, -- Stéphane
Bug#1032257: alt-ergo free and non-free
Dear Jean-Christophe, Le 02/03/2023 à 13:08, Jean-Christophe Léchenet a écrit : We were surprised to see that the last version of alt-ergo (2.4.2) is in Debian testing, while it is non-free. At the moment, the latest free version is 2.3.0. Is there some mechanism to extract the free subset of alt-ergo or something like that? I was not aware of that. I've opened a bug report: https://bugs.debian.org/1032257 to track this issue. Cheers, -- Stéphane
Bug#1032257: Non-free (non-commercial) license
Source: alt-ergo Version: 2.4.2-2 Severity: serious Dear Maintainers, It has been brought to my attention [1] that the version of alt-ergo currently in testing has a non-free license [2]. According to [3], the latest free version is Alt-Ergo-Free version 2.3.3, which is the version which should be (IMHO) in Debian. [1] https://lists.debian.org/debian-ocaml-maint/2023/03/msg2.html [2] https://ocamlpro.github.io/alt-ergo/About/license.html [3] https://alt-ergo.ocamlpro.com/ Cheers, -- Stéphane -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1030785: -ffile-prefix-map option and reproducibility
Thank you all for your answers! Using: DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath makes the package unreproducible in another way that seems difficult to fix. Le 07/02/2023 à 19:12, Mattia Rizzolo a écrit : I actually propose to you to filter out the whole option from being saved. [...] I've gone this way, and managed to make the package reproducible, at least with the build path variation. I will upload the fixed ocaml package when the current batch of related packages waiting in unstable migrates to testing, hopefully in 4 days. Cheers, -- Stéphane
Bug#1030785: Reproducibility of ocaml...
Hi Chris, Le 07/02/2023 à 17:13, Chris Lamb a écrit : I appreciate this info is difficult to find (!), but for a bunch of historical reasons, there are actually a different set of variations tested when we test sid compared to when we test bookworm. In other words, the differences between the two builds is not just the package version and Debian distribution. We try to canonically document the differences on this page: https://tests.reproducible-builds.org/debian/index_variations.html And almost certainly the difference is down to the build path. :) Indeed. Does that help? We've had a series of build path variations in the OCaml stack, so maybe some patch got reverted, or…? In this specific case, the variation comes from -ffile-prefix-map being injected automatically into CFLAGS. Cheers, -- Stéphane
Bug#1030785: -ffile-prefix-map option and reproducibility
Hi, When building packages, a -ffile-prefix-map option is automatically injected into CFLAGS. Where does it come from? Since when? I suspect this was added to improve reproducibility. Ironically, it makes packages that capture this variable non reproducible, since the build path seems to be randomized (has it always been the case? since when?). It is the case of OCaml (see #1030785), and seemingly of R as well (found by grepping in my /etc). I wouldn't be surprised other packages are affected as well. Is there a way to not get this option? More elegant than explicitly filtering it out of CFLAGS in debian/rules... Cheers, -- Stéphane
Bug#1030785: Reproducibility of ocaml...
Hi, I just discovered a reproducibility issue [1,2] in ocaml, which can have dire consequences. Looking at [3], it seems only unstable is affected. Are you aware of a change that could explain that? In particular, I don't understand why the bookworm version is reported as reproducible whereas the version is the same as unstable. [1] https://lists.debian.org/debian-ocaml-maint/2023/02/msg00240.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030785 [3] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ocaml.html Cheers, -- Stéphane
Bug#1030785: Build path embedded in config.cmx
Source: ocaml
Severity: important
Dear Maintainers,
diff-ing <(ocamlobjinfo usr/lib/ocaml/compiler-libs/config.cmx)
between ocaml-compiler-libs_4.13.1-3_riscv64.deb and
ocaml-compiler-libs_4.13.1-3+b1_riscv64.deb yields:
--- /proc/self/fd/112023-02-07 15:18:31.648448695 +0100
+++ /proc/self/fd/172023-02-07 15:18:31.648448695 +0100
@@ -1,6 +1,6 @@
-File 4.13.1-3/usr/lib/ocaml/compiler-libs/config.cmx
+File 4.13.1-3+b1/usr/lib/ocaml/compiler-libs/config.cmx
Name: Config
-CRC of implementation: 4523bf9c28d8f9514c7362c8be3ff60e
+CRC of implementation: 08928cce36c4bc73deeeda713226b80f
Globals defined:
Config
Interfaces imported:
@@ -29,12 +29,12 @@
3: const("camlConfig__5"="cc");
4: const("camlConfig__6"="riscv64-linux-gnu-gcc");
5: const("camlConfig__7"="-o "); 6: const(1); 7: const(1);
- 8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread -fPIC
-g -O2 -ffile-prefix-map=/build/ocaml-Vq2uKK/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
+ 8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread -fPIC
-g -O2 -ffile-prefix-map=/build/ocaml-xz3WL7/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
9: const("camlConfig__9"="-D_FILE_OFFSET_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2");
- 10: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread -fPIC
-g -O2 -ffile-prefix-map=/build/ocaml-Vq2uKK/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
+ 10: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread -fPIC
-g -O2 -ffile-prefix-map=/build/ocaml-xz3WL7/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
11: const("camlConfig__9"="-D_FILE_OFFSET_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2");
- 12: const("camlConfig__10"="-lm -ldl -lpthread");
- 13: const("camlConfig__12"="-lm -ldl ");
+ 12: const("camlConfig__10"="-lm -lpthread");
+ 13: const("camlConfig__12"="-lm ");
14: const("camlConfig__13"="riscv64-linux-gnu-ld -r -o ");
15: global(camlConfig,15); 16: global(camlConfig,16);
17: global(camlConfig,17);
/build/ocaml-X should not be there as it changes in every build!
This means the ABI of compiler-libs changes at every build,
effectively breaking all reverse-dependencies! To add more to the
pain, the ABI being defined as the OCaml version for OCaml itself, the
breakage cannot be seen in dependencies.
Cheers,
--
Stéphane
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
Bug#1030690: RM: mldonkey -- ROM; dead upstream; FTBFS beyond repair
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: mldon...@packages.debian.org, debian-ocaml-ma...@lists.debian.org Control: affects -1 + src:mldonkey Dear FTP Team, The mldonkey package has been broken since October 2020 (#972211). Two years later, the package seems dead upstream and fixing it looks difficult. Therefore, I request its removal. Cheers, -- Stéphane
Bug#1030622: tex-common package post-installation script subprocess returned error exit status 1
Hello, Le 05/02/2023 à 20:52, Hilmar Preuße a écrit : Today the new texlive-base & texlive-extra did migrate to testing and hence were upgraded on your system. The texlive-lang did not migrate yet, this will happen soon. Once texlive-lang-japanese is upgraded, please repeat the test. Is suspect an incompatibility in these packages, as I'm not able to reproduce the issue using unstable. Then, a dependency (Breaks and/or Conflicts) is missing somewhere... I just upgraded texlive-lang-* and indeed the problem seems to have disappeared. Cheers, -- Stéphane
Bug#1030622: tex-common package post-installation script subprocess returned error exit status 1
Package: tex-common Version: 6.18 Severity: serious Dear Maintainer, I got this when upgrading texlive today in testing: > Paramétrage de tex-common (6.18) ... > Running mktexlsr. This may take some time... done. > Running mtxrun --generate. This may take some time... done. > Running updmap-sys. This may take some time... done. > Running mktexlsr /var/lib/texmf ... done. > Building format(s) --all. > This may take some time... > fmtutil failed. Output has been stored in > /tmp/fmtutil.RDPxpv93 > Please include this file if you report a bug. > > dpkg: erreur de traitement du paquet tex-common (--configure) : > installed tex-common package post-installation script subprocess returned > error exit status 1 > Des erreurs ont été rencontrées pendant l'exécution : > tex-common Attached is the file, as instructed. Cheers, -- Stéphane -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tex-common depends on: ii ucf 3.0043 tex-common recommends no packages. Versions of packages tex-common suggests: ii debhelper 13.11.4 Versions of packages texlive-base depends on: ii debconf [debconf-2.0] 1.5.82 ii libpaper-utils 1.1.28+b1 ii sensible-utils 0.0.17+nmu1 ii texlive-binaries 2022.20220321.62855-5 ii ucf3.0043 ii xdg-utils 1.1.3-4.1 Versions of packages texlive-base recommends: ii lmodern 2.005-1 Versions of packages texlive-base suggests: ii evince [postscript-viewer] 43.1-2+b1 ii ghostscript [postscript-viewer] 10.0.0~dfsg-9+b1 ii perl-tk 1:804.036-1+b1 ii xpdf [pdf-viewer]3.04+git20220601-1+b2 pn xzdec Versions of packages texlive-binaries depends on: ii libc6 2.36-8 ii libcairo2 1.16.0-7 ii libfontconfig1 2.14.1-3 ii libfreetype62.12.1+dfsg-4 ii libgcc-s1 12.2.0-14 ii libgraphite2-3 1.3.14-1 ii libharfbuzz0b 6.0.0-1 ii libicu7272.1-3 ii libkpathsea62022.20220321.62855-5 ii libmpfr64.2.0-1 ii libpaper1 1.1.28+b1 ii libpixman-1-0 0.42.2-1 ii libpng16-16 1.6.39-2 ii libptexenc1 2022.20220321.62855-5 ii libstdc++6 12.2.0-14 ii libsynctex2 2022.20220321.62855-5 ii libteckit0 2.5.11+ds1-1+b1 ii libtexlua53-5 2022.20220321.62855-5 ii libtexluajit2 2022.20220321.62855-5 ii libx11-62:1.8.3-3 ii libxaw7 2:1.0.14-1 ii libxi6 2:1.8-1+b1 ii libxmu6 2:1.1.3-3 ii libxpm4 1:3.5.12-1.1 ii libxt6 1:1.2.1-1 ii libzzip-0-130.13.72+dfsg.1-1.1 ii perl5.36.0-7 ii t1utils 1.41-4 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages texlive-binaries recommends: pn dvisvgm ii texlive-base 2022.20221123-1 -- debconf information excluded fmtutil.RDPxpv93.xz Description: application/xz
Bug#1030564: ITP: ocaml-uuseg -- unicode text segmentation for OCaml
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-uuseg Version : 15.0.0 Upstream Contact: The uuseg programmers * URL : https://erratique.ch/software/uuseg * License : ISC Programming Lang: OCaml Description : unicode text segmentation for OCaml Uuseg is an OCaml library for segmenting Unicode text. It implements the locale independent Unicode text segmentation algorithms to detect grapheme cluster, word and sentence boundaries and the Unicode line breaking algorithm to detect line break opportunities. . The library is independent from any IO mechanism or Unicode text data structure and it can process text without a complete in-memory representation. This package is a new dependency of zed. It will be maintained in the OCaml Team.
Bug#1030401: Many bugs about unsatisfiable build-dependencies
Hello, These unsatisfiable build-dependencies are temporary and will be solved by properly sequenced binNMUs or sourceful uploads that I am currently dealing with. I do not see the value of such bug reports. Packages with unsatisfiable build-dependencies do not migrate to testing nor are picked up by buildd daemons (so no actual FTBFS). They add burden and look like noise to me. Cheers, -- Stéphane
Bug#1029538: RM: coq-theories -- NBS; cruft
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: c...@packages.debian.org, debian-ocaml-ma...@lists.debian.org Control: affects -1 + src:coq Dear FTP Team, Please remove all coq-theories (binary) packages from unstable. They correspond to an old coq source package, but coq has stopped building them for 4 months. Their presence makes noise in the permanent OCaml transition tracker [1]. [1] https://release.debian.org/transitions/html/ocaml.html Cheers, -- Stéphane
Bug#1028324: RM: cduce -- RoQA, unmaintained, FTBFS, zero popcon
Control: reassign -1 ftp.debian.org Le 09/01/2023 à 16:37, Tobias Frost a écrit : This makes me wonder if we should retire this package. Yes, absolutely. If you also think that it shoulw be removed, just reassign it to the ftp.debian.org pseudo package. Cheers, -- Stéphane
Bug#1029398: ben: "tracker --archs" is not honoured
Le 22/01/2023 à 14:21, Adrian Bunk a écrit : I see two approches to solving this bug: - make the command-line options override the configuration specified in global.conf - reject command-line options when they are read in global.conf What do you think? ... The behaviour of "ben download" of having some sane defaults[1] or configuration file that can be overridden on the command line is IMHO pretty good, and I'd expect "ben tracker" to behave the same way. I'll see what I can do. Thanks! Actually, my initial understanding of what was happening was wrong. No default global.conf is read. I've pushed a tentative fix: https://salsa.debian.org/debian/ben/-/commit/7b882e6c090828babb677b258f1e64f287d631e8 Can you check that it does what you want? Cheers, -- Stéphane
Bug#1029398: ben: "tracker --archs" is not honoured
Le 22/01/2023 à 13:48, Adrian Bunk a écrit : I'm afraid the default one is the Realase Team's one [1], which doesn't seem useful elsewhere... Usually they are pretty useful for me since usually I am just using this for sending new/changed trackers as MRs to the release team. Is your attempt to use "ben tracker" with debian-ports new? I am trying to understand why we get this bug report only now... I see two approches to solving this bug: - make the command-line options override the configuration specified in global.conf - reject command-line options when they are read in global.conf What do you think? ... The behaviour of "ben download" of having some sane defaults[1] or configuration file that can be overridden on the command line is IMHO pretty good, and I'd expect "ben tracker" to behave the same way. I'll see what I can do. [2] https://salsa.debian.org/debian/ben/-/merge_requests/2 Sorry for taking so much time to merge such a trivial change, but I didn't see the MR until now... There is so much noise in Salsa notifications that I ended up ignoring them altogether. Cheers, -- Stéphane
Bug#1029398: ben: "tracker --archs" is not honoured
Dear Adrian, Le 22/01/2023 à 12:33, Adrian Bunk a écrit : $ ben download --archs alpha --preferred-compression-format xz --mirror-binaries http://ftp.de.debian.org/debian-ports Downloading /tmp/Sources... Downloading /tmp/Packages_alpha... $ ben tracker --archs alpha -cd tracker Parsing /tmp/Sources... Parsing /tmp/Packages_amd64... Parsing /tmp/Packages_arm64... Parsing /tmp/Packages_armel... Parsing /tmp/Packages_armhf... Parsing /tmp/Packages_i386... Parsing /tmp/Packages_mips64el... Parsing /tmp/Packages_mipsel... Parsing /tmp/Packages_s390x... Parsing /tmp/Packages_ppc64el.. "ben tracker" indeed seems to ignore its "--archs" option... and probably most of the options common to all ben frontends! Actually, it takes its configuration from the so-called "global" configuration file. Did you specify one (I see you've specified "-cd tracker", does it refer to something you wrote yourself)? I'm afraid the default one is the Realase Team's one [1], which doesn't seem useful elsewhere... [1] /usr/share/doc/ben/examples/tracker/global.conf By writing a custom global.conf (see comments in [1]), I can make "ben tracker" work with debian-ports and only alpha... I see two approches to solving this bug: - make the command-line options override the configuration specified in global.conf - reject command-line options when they are read in global.conf What do you think? In all cases, you should be able to do what you want by providing a custom global.conf. Sorry for being hesitant, I am not familiar with this part of the codebase... Cheers, -- Stéphane
Bug#1028370: Connection to server failed
Le 10/01/2023 à 07:56, Stéphane Glondu a écrit : Today, cssh does not work: $ cssh a b c d Connection to server failed -- (version 11.0) Authorization required, but no authorization protocol specified at /usr/share/perl5/App/ClusterSSH/Window/Tk.pm line 57. I'm pretty sure it was working 3 weeks ago or so. However, with 4.16-3 I still get the issue. More info: the error was with the default GNOME (on Wayland) session. With GNOME on Xorg, cssh works. I also tried, xterm itself works with Wayland session. Cheers, -- Stéphane
Bug#1028370: Connection to server failed
Package: clusterssh Version: 4.16-4 Severity: grave Dear Maintainer, Today, cssh does not work: $ cssh a b c d Connection to server failed -- (version 11.0) Authorization required, but no authorization protocol specified at /usr/share/perl5/App/ClusterSSH/Window/Tk.pm line 57. I'm pretty sure it was working 3 weeks ago or so. However, with 4.16-3 I still get the issue. Cheers, -- Stéphane -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clusterssh depends on: ii libexception-class-perl 1.45-1 ii libtry-tiny-perl0.31-2 ii libx11-protocol-other-perl 31-1 ii libx11-protocol-perl0.56-9 ii openssh-client 1:9.1p1-1 ii perl5.36.0-6 ii perl-tk 1:804.036-1+b1 ii xterm 377-1 clusterssh recommends no packages. clusterssh suggests no packages. -- no debconf information
Bug#991060: reopen for bullseye
Hi, Le 04/12/2022 à 20:51, Santiago Vila a écrit : Please, let us fix this for stable. I would gladly backport the fix from unstable but since the fix was included in a new upstream release I'm in doubt about what would have to be done and would definitely need help. Did you try the supplied patch? Cheers, -- Stéphane
Bug#1024543: json2bson fails with AttributeError: module 'bson' has no attribute 'dumps'
Package: reserialize
Version: 20210909-3
Severity: important
Dear Maintainer,
json2bson seems unusable:
$ echo '{}' | json2bson
Traceback (most recent call last):
File "/usr/bin/json2bson", line 79, in
print(str_dumpers[otype](data))
File "/usr/bin/json2bson", line 43, in
"bson": lambda arg: bson.dumps(arg),
AttributeError: module 'bson' has no attribute 'dumps'
Cheers,
--
Stéphane
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages reserialize depends on:
ii python3 3.10.6-1
ii python3-yaml 6.0-3+b1
Versions of packages reserialize recommends:
ii python3-bson 3.11.0-1+b4
ii python3-toml 0.10.2-1
reserialize suggests no packages.
-- no debconf information
Bug#1015179: Please update ppxlib to latest upstream
Hi, Le 11/10/2022 à 08:26, julien.pu...@gmail.com a écrit : Could you package the latest upstream? I did as much as I could and I think I nailed it: Thank you for taking care of this. ** packaging: ocaml-sexplib0 (protected on salsa) [...] ** packaging: janest-base (protected on salsa) [...] new version 0.15.0 (protected on salsa) I've set you as Maintainer in the ocaml-team group on salsa. It should allow you to push to all packages. Now how does one manage transition within the OCaml team? It depends on the transition... For "small" transitions (i.e. not involving OCaml itself), I just upload the new base package and wait for the reverse-dependencies to be broken in: https://release.debian.org/transitions/html/ocaml.html Then, I upload or binNMU the broken packages, level by level. Sometimes, when I suspect big breakage, I prepare the transition by recompiling on my own machine reverse-dependencies, as you seem to have done. For OCaml itself, I've documented how I prepare transitions: https://salsa.debian.org/debian/ben/-/tree/master/examples/ocaml-transition-scripts Cheers, -- Stéphane
Bug#1015179: Please update ppxlib to latest upstream
Hi, Le 17/07/2022 à 10:17, julien.pu...@gmail.com a écrit : Could you package the latest upstream? I tried to do a team upload to experimental so britney could tell us what would break, but apparently there are protected branches so I can't push to git. I've changed the settings in salsa. Can you push, now? Cheers, -- Stéphane
Bug#1005765: dgit doesn't handle upstream files with CRLF well
Hello, Le 03/09/2022 à 18:43, Ian Jackson a écrit : I wrote: I think that if - your upstream files have CRLF in the orig - your upstream files have CRLF in your git tree - you do not expect (or enable) line ending conversions in git then - dgit will not complain - the source package you produce will have files with CRLF - everything should work If you have a repro that demonstrates the contrary, please let us know. Typically a repro would consist of the following elements: * The precise git commit that you had as HEAD in your working tree We need the git hash; hopefully I can obtain the data from salsa. * The precise contents of all relevant .origs If they were already previously uploaded, we can get them from the archive or snapshot.d.o. Otherwise please supply their sha256sums, as well as instructions for download or creation (eg pristine-tar branch). * The precise dgit command line, and any configuration settings applied to any of the relevant tools. I had trouble uploading opam/2.1.2-1 with dgit. Eventually, I gave up and did a regular upload. The commit id is 225dd4102cfd4391fab166d7cc220d020efedafd on: https://salsa.debian.org/ocaml-team/opam Ideally, a run with dgit -D would be helpful. I will try when I update the package. If you have a situation that doesn't match the criteria above, but you think should be able to work, and currently doesn't, please also let us know. I'm not sure whether my situation matches the criteria above, but I guess dgit should be able to do any upload to the official Debian archive, shouldn't it? Thanks for all your work on dgit! Cheers, -- Stéphane
Bug#1008080: Some sites do not work
Package: chromium Version: 99.0.4844.74-1 Severity: grave Dear Maintainer, On two different, up-to-date Debian testing machines, at least the following sites: https://framatalk.org https://replit.com do not work properly (but not all sites are broken). I get spurious "Your connection was interrupted" (ERR_NETWORK_CHANGED). For replit, sometimes the home page loads, but trying to log in does not work. With one of the two machines, I tried on two different networks, with the same result. Everything works with Firefox ESR. This behaviour is recent. Unfortunately, as I do not use Chromium often, I cannot tell since when this happens. Less than a month, I think. Cheers, -- Stéphane -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common99.0.4844.74-1 ii libasound2 1.2.6.1-2 ii libatk-bridge2.0-0 2.38.0-3 ii libatk1.0-02.36.0-3 ii libatomic1 12-20220313-1 ii libatspi2.0-0 2.42.0-2 ii libc6 2.33-7 ii libcairo2 1.16.0-5 ii libcups2 2.4.1op1-2 ii libdbus-1-31.14.0-1 ii libdrm22.4.110-1 ii libevent-2.1-7 2.1.12-stable-1 ii libexpat1 2.4.7-1 ii libflac8 1.3.4-1 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.11.1+dfsg-1 ii libgbm121.3.7-1 ii libgcc-s1 12-20220313-1 ii libglib2.0-0 2.70.4-1 ii libgtk-3-0 3.24.33-1 ii libicu67 67.1-7 ii libjpeg62-turbo1:2.1.2-1 ii libjsoncpp25 1.9.5-3 ii liblcms2-2 2.12~rc1-2 ii libminizip11.1-8+b1 ii libnspr4 2:4.32-3 ii libnss32:3.75-1 ii libopenjp2-7 2.4.0-6 ii libopus0 1.3.1-0.1 ii libpango-1.0-0 1.50.4+ds-1 ii libpng16-161.6.37-3 ii libpulse0 15.0+dfsg1-4 ii libre2-9 20220201+dfsg-1 ii libsnappy1v5 1.1.8-1 ii libstdc++6 12-20220313-1 ii libwayland-client0 1.20.0-1 ii libwebp7 1.2.2-2+b1 ii libwebpdemux2 1.2.2-2+b1 ii libwebpmux31.2.2-2+b1 ii libx11-6 2:1.7.2-2+b1 ii libxcb11.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage11:1.1.5-2 ii libxext6 2:1.3.4-1 ii libxfixes3 1:6.0.0-1 ii libxkbcommon0 1.4.0-1 ii libxml22.9.13+dfsg-1 ii libxrandr2 2:1.5.2-1 ii libxslt1.1 1.1.34-4 ii xdg-desktop-portal-gnome [xdg-desktop-portal-backend] 42~rc-1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.12.0-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages chromium recommends: ii chromium-sandbox 99.0.4844.74-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of
Bug#1006711: ITP: js-of-ocaml-ocamlbuild -- compiler from OCaml bytecode to JavaScript (ocamlbuild plugin)
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: js-of-ocaml-ocamlbuild Version : git Upstream Author : Jacques-Pascal Deplaix * URL : https://github.com/ocsigen/js_of_ocaml-ocamlbuild * License : LGPL 2.1 with OCaml linking exception Programming Lang: OCaml Description : compiler from OCaml bytecode to JavaScript (ocamlbuild plugin) Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes it possible to run pure OCaml programs in JavaScript environment like browsers and Node.js. . This package contains the ocamlbuild plugin. This package was part of js-of-ocaml, but has been split out in the latest version. Eliom depends on it. It will be maintained in the OCaml team.
Bug#1006356: RM: ppxfind -- ROM; obsolete
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org Dear FTP Team, ppxfind is an old library/tool that does no longer compile with current OCaml, and it seems that it never will. Please remove it from unstable. Cheers, -- Stéphane
