Redefinition of _Int (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
H again,
Am Sun, Apr 14, 2024 at 07:17:41AM +0200 schrieb Andreas Tille:
> Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden:
> >
> > The one after this looks like a GTK problem, and that's the point at
> > which I bow out.
I was able to fix some more missing declaration issues (which luckily did
not were connected to GTK) but I'm now stumbling upon:
...
In file included from disknew.c:85:
../whooks/systags.h:57:15: error: expected identifier before numeric constant
57 | #define _Int 24
| ^~
../wh/acetypes.h:36:16: note: in expansion of macro '_Int'
36 | typedef enum { _Int, _Text, _Float, _DateType, _Key, _Tag } AceType;
|^~~~
...
which is caused by whooks/systags.h[2]
...
#define _Int 24
#define _Unsigned 25
#define _Long 26 /* not supported */
#define _Long_Unsigned 27 /* not supported */
#define _Float 28
...
Is there any trick I could use here instead of replacing these
definitions by something else like _Int_acedb or so globally to get this
build by modern compilers?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/acedb/-/jobs/5586407#L1893
[2]
https://salsa.debian.org/med-team/acedb/-/blob/master/whooks/systags.h?ref_type=heads#L57-61
--
https://fam-tille.de
Bug#1068958: Xiyue Deng
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "elpa-snakemake": * Package name : elpa-snakemake Version : 2.0.0+git20231210.4ad41da-1 Upstream contact : Kyle Meyer * URL : https://git.kyleam.com/snakemake-mode/about * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/elpa-snakemake Section : editors The source builds the following binary packages: elpa-snakemake-mode - provides syntax highlighting for snakekmake files in emacs elpa-snakemake - Run Snakemake workflows from Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elpa-snakemake/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elpa-snakemake/elpa-snakemake_2.0.0+git20231210.4ad41da-1.dsc Changes since the last upload: elpa-snakemake (2.0.0+git20231210.4ad41da-1) unstable; urgency=medium . * Team upload * Sync to latest upstream snapshot (4ad41da) (Closes: #1068956) * Disable autopkgtest as the ERT tests require a writable $HOME * Modernize d/watch with substitute strings to be more robust * Add a version header in snakemake.el to workaround dh-elpa upstream version handling limitation * Commit Debian 3.0 (quilt) metadata * Trim trailing whitespace * Set upstream metadata fields: Repository * Update standards version to 4.7.0, no changes needed Regards, -- Xiyue Deng
Bug#1068958: RFS: elpa-snakemake/2.0.0+git20231210.4ad41da-1 [RC] [Team] -- Run Snakemake workflows from Emacs
Control: retitle -1 RFS: elpa-snakemake/2.0.0+git20231210.4ad41da-1 [RC] [Team] -- Run Snakemake workflows from Emacs Some obvious silly copy-and-paste error in the title. Now it should be fixed :P -- Xiyue Deng
Re: Bug#1066033: RFS: galvani/0.34-1 [ITP] -- reads data from a device with graphical plots and evaluation
Am Dienstag, dem 09.04.2024 um 03:11 + schrieb mentors.debian.net: > > A comment has been posted to a package you uploaded: > > From: Alex Myczko > Package: galvani > Url: https://mentors.debian.net/package/galvani/ > > --- > Vcs fields are easy to fix, do you already have an account on > salsa.debian.org ? > --- > > Thanks, I have an entry in debian/control: #Vcs-Git: https://salsa.debian.org/blutz/galvani.git #Vcs-Browser: https://salsa.debian.org/blutz/galvani But I forgot to delete the hashes. Thank you.
Re: Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Hello, Thanks for your help ! > I had a look. > > It's not called "SystemD". You're correct, I'll fix the typo :) > > Why is this line commented? > > #PrivateUsers=yes This should have been deleted. I will fix that. I was doing some experiments with PrivateUsers which turned out to make CGI scripts unusable, so it's off the table. > > > I think your patch presumes that the filesystem is utf-8 encoded and > would > break in other (admittedly rare) cases. Just FYI. This is fine; The utf8 charset encoding is sent when the client requests directory listings and error pages (that's what the patch does). This is standard, expected behaviour for a web server. (From the web: Because it is the default all modern browsers will use utf-8 without being explicitly told to do so. It remains in meta data as a common good practice) > > Commits on salsa introduce unrelated changes in 1 single commit. > > Did you submit the patches to upstream? Is upstream active? Upstream is sadly defunct for all intents and purposes. Patches have been forwarded long before I took over mini-httpd (a year ago) and no news were heard for a really long time. I think the last upstream release happened more than 5-6 years ago (1.30). That's the reason we're on 1.30-10 now :). I discussed these matters with other members in Debian as well; I could forward everything but sadly as far as I know, nobody would read them. We're the upstream for now. > > Your changes to the .service file might break CGI scripts that might > be having > access to all sort of things. I think a news file should be added to > warn users > of the possibly breaking changes. You're right, a news file is in order. I will start writing one today. The good part is that the systemd service is rather new (2 releases ago) so not many people adopted it yet. The chance of functioning setups just breaking is lower, then. I will write a news entry, anyway. > Thanks for your review, I'll have a better release ready in a bit. Have a great one, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi, On Tue, Apr 9, 2024 at 2:18 PM Stéphane Glondu wrote: > > 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. > Done. > 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. 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`. [0]: https://github.com/Debian/debhelper/blob/master/dh_strip#L239C2-L244C27 [1]: https://lists.debian.org/debian-mentors/2015/10/msg00027.html [2]: https://github.com/aantron/bisect_ppx/issues/439 > > 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.) Okay, I repacked it by removing the prebuilt javascript file and put its source code which pulled from upstream into debian/missing-sources and then to get the file during the building. > > 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. Done. All commits I have pushed into the salsa [3] and mentor[4]. Thanks for your time again and please let me know any issues. BR, Bo [3]: https://salsa.debian.org/ocaml-team/bisect-ppx [4]: https://mentors.debian.net/package/bisect-ppx/ > > > Thank you for your work, > > -- > Stéphane >
Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler
On Mon, Apr 15, 2024 at 01:25:05AM +0530, Alan M Varghese wrote: > > This FTBFS: "! LaTeX Error: File `lmodern.sty' not found." > > lmodern.sty comes from the package `lmodern`. This package should be > > installed (as a transitive dep) when 'texlive-fonts-extra' is installed. No, see below. But this also means you haven't tried building your package in a minimal sid chroot. > What is the process for installing build-deps? Manually on a host system? `apt build-dep` or `mk-build-deps -ir` > `apt install texlive-fonts-extra`, the lmodern package also > gets installed. Recommends are not installed when installing build-deps. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler
> This FTBFS: "! LaTeX Error: File `lmodern.sty' not found." lmodern.sty comes from the package `lmodern`. This package should be installed (as a transitive dep) when 'texlive-fonts-extra' is installed. What is the process for installing build-deps? When I run `apt install texlive-fonts-extra`, the lmodern package also gets installed.
Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler
> But this also means you haven't tried building your package in a minimal sid chroot I have been using podman containers based on sid instead. But, I think that should be fine? > Manually on a host system? `apt build-dep` or `mk-build-deps -ir` > Recommends are not installed when installing build-deps Ah... Makes sense. Thank you. I missed these commands somehow; I have been running the `apt install` command for getting the dependencies inside the container. I will update the package with lmodern also added as a dependency.
Bug#1068958: marked as done (RFS: elpa-snakemake/2.0.0+git20231210.4ad41da-1 [RC] [Team] -- Run Snakemake workflows from Emacs)
Your message dated Mon, 15 Apr 2024 08:54:21 +0800 with message-id <87r0f71m4i@melete.silentflame.com> and subject line Re: Bug#1068958: RFS elpa-snakemake has caused the Debian Bug report #1068958, regarding RFS: elpa-snakemake/2.0.0+git20231210.4ad41da-1 [RC] [Team] -- Run Snakemake workflows from Emacs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1068958: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068958 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "elpa-snakemake": * Package name : elpa-snakemake Version : 2.0.0+git20231210.4ad41da-1 Upstream contact : Kyle Meyer * URL : https://git.kyleam.com/snakemake-mode/about * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/elpa-snakemake Section : editors The source builds the following binary packages: elpa-snakemake-mode - provides syntax highlighting for snakekmake files in emacs elpa-snakemake - Run Snakemake workflows from Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elpa-snakemake/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elpa-snakemake/elpa-snakemake_2.0.0+git20231210.4ad41da-1.dsc Changes since the last upload: elpa-snakemake (2.0.0+git20231210.4ad41da-1) unstable; urgency=medium . * Team upload * Sync to latest upstream snapshot (4ad41da) (Closes: #1068956) * Disable autopkgtest as the ERT tests require a writable $HOME * Modernize d/watch with substitute strings to be more robust * Add a version header in snakemake.el to workaround dh-elpa upstream version handling limitation * Commit Debian 3.0 (quilt) metadata * Trim trailing whitespace * Set upstream metadata fields: Repository * Update standards version to 4.7.0, no changes needed Regards, -- Xiyue Deng --- End Message --- --- Begin Message --- Hello, It's better not to include dgit's automatic commits in the changelog -- they're covered by the entries describing what you patched. -- Sean Whitton signature.asc Description: PGP signature --- End Message ---
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
