Bug#1069135: org-bullets: please consider switching to a more up-to-date upstream
Hi Lev, Hi Nicholas, If you are looking for replacements for org-bullets, there is also org-modern (https://github.com/minad/org-modern), from Daniel Mendler. I've been using it happily for quite some time now. Generally, Daniel Mendler's projects are very well implemented and maintained. I maintain 4 or 5 of his projects in Debian and I have very little work. Best, Aymeric Le mercredi 17 avril 2024 à 13:02, Léon Lamberov a écrit : Hi Nicholas, Вт 16 апр 2024 @ 18:13 Nicholas D Steeves : Source: org-bullets Version: 0.2.4-3 Severity: normal I noticed some deprecation warnings in org-bullets' native-compilation log, so searched for an upstream fix. What I found was that our current upstream source is a decade old: https://github.com/sabof/org-bullets and that MELPA provides their users with a package from this fork, which has activity from four years ago: https://github.com/integral-dw/org-bullets It looks like integral-dw's fork might now the defacto upstream, because sabof's project looks dead. Maybe a PR/MR for some of those compilation warnings could be a useful way to test for a living and responsive upstream? Thanks for your investigation! As I can see, org-super-star-mode (also from integral-dw) has more features than org-bullets and better support (last commit was in Jan 2023). So, I guess, we could update org-bullets to integral-dw's version and also package org-super-star-mode, and then, probably, deprecate org-bullets in favor of org-super-star-mode. What do you think of the proposal? [super-star] https://github.com/integral-dw/org-superstar-mode Cheers! Lev
Bug#1068042: elpa-magit-forge: forge-pull fails to get issues from salsa.debian.org
Hello, I had noticed in December of 2023 that forge was basically incapable of pulling anything (from github that time). I had solved the issue by updating it to a newer upstream snapshot. Now, for various reasons, this update has not been pushed to the archive yet, but it should be soon (the relevant commits have now been pushed to salsa). I would be curious whether you can still reproduce the problem after updating to 0.3.2+git20231227.1.299bbaa-1, once it gets uploaded. Sorry for the inconvenience. Best, Aymeric, of the debian-emacsen team Le vendredi 29 mars 2024 à 18:12, Daniel Kahn Gillmor a écrit : [[PGP Signed Part:Undecided]] Package: elpa-magit-forge Version: 0.3.2-1 Severity: normal X-Debbugs-Cc: Daniel Kahn Gillmor I'm trying to do some work on impass, which is publicly hosted on salsa.debian.org. From emacs, i'm using forge in my working copy of the impass git repo, and i've configured ~/.gitconfig to have: ``` [gitlab "salsa.debian.org/api/v4"] user = dkg ``` In my local working copy's .git/config i have: ``` [remote "salsa"] url = https://salsa.debian.org/debian/impass.git fetch = +refs/heads/*:refs/remotes/salsa/* pushurl = g...@salsa.debian.org:debian/impass.git fetch = +refs/merge-requests/*/head:refs/pullreqs/* [forge] remote = salsa ``` However, when i try to do M-x forge-pull, i end up with this error message: ``` Pulling debian/impass... Pulling debian/impass issues... error in process filter: ghub--errorback: HTTP Error: 400, "Bad Request", "/api/v4/projects/debian%2Fimpass/issues?per_page=100_by=updated_at_after=false", ((error . "updated_after is invalid")) error in process filter: HTTP Error: 400, "Bad Request", "/api/v4/projects/debian%2Fimpass/issues?per_page=100_by=updated_at_after=false", ((error . "updated_after is invalid")) ``` If this is a bug on the salsa.debian.org side, feel free to reassign to the appropriate metapackage. --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages elpa-magit-forge depends on: ii dh-elpa-helper 2.0.17 ii elpa-closql 1.2.1-3 ii elpa-dash2.19.1+git20220608.1.0ac1ecf+dfsg-1 ii elpa-emacsql-sqlite 3.1.1+git20230417.6401226+ds-1 ii elpa-ghub3.6.0-4 ii elpa-let-alist 1.0.6-2 ii elpa-magit 3.3.0-3 ii elpa-markdown-mode 2.6-1 ii elpa-yaml0.5.5-1 ii emacsen-common 3.0.5 Versions of packages elpa-magit-forge recommends: ii emacs 1:29.2+1-2 ii emacs-pgtk [emacs] 1:29.2+1-2 elpa-magit-forge suggests no packages. -- no debconf information [[End of PGP Signed Part]]
Bug#1052967: emacsql-sqlite3: FTBFS: make: *** [debian/rules:4: build] Error 25
Le mardi 10 octobre 2023 à 09:08, Sean Whitton a écrit : Cool, would you like to file the RM bug? Sure, but I have a few questions first : - Should I file the bug against release.debian.org or ftp.debian.org ? I've seen examples doing either (1036144 and 963750, for instance). - Such bug reports sometimes provide the output of "dak rm -Rn ". I don't think I have the necessary rights to do that (this command must be executed on the machine hosting the archive, I assume...). I can provide the output "apt-cache rdepends emacsql-sqlite3". - What does "RoM" (or "ROM", I've seen both) mean ? Best, Aymeric
Bug#1052967: emacsql-sqlite3: FTBFS: make: *** [debian/rules:4: build] Error 25
Hello Sean, Le lundi 9 octobre 2023 à 18:16, Sean Whitton a écrit : Given that you maintain emacsql, would you be interested in taking over emacsql-sqlite3 as well? No. In fact, I think we should not be packaging emacsql-sqlite3 anymore, and we should use the occasion to remove it. The upstream maintainers themselves contend that package developers should not use it, and rely on emacsql instead : https://github.com/cireu/emacsql-sqlite3#important-note. It has no reverse dependencies, and I fail to see how it could be useful to anyone if not as a dependency for another package. The next release of emacsql will not support it, and will make it obsolete, a point of view the upstream maintainers of emacsql-sqlite3 themselves seem to accept : https://github.com/cireu/emacsql-sqlite3/issues/38. It was removed from MELPA last April for this reason. Best, Aymeric
Bug#1051219: ITA: gumbo-parser -- pure-C HTML5 parser
We got the green light. Le mardi 19 septembre 2023 à 00:06, Sebastian Ramacher a écrit : Please go ahead Cheers -- Sebastian Ramacher Should I change the latest d/changelog entry to make an unstable upload, or create a new d/changelog entry ?
Bug#1051219: ITA: gumbo-parser -- pure-C HTML5 parser
Le dimanche 17 septembre 2023 à 21:18, Bastian Germann a écrit : That will not be needed. Next step for you is to file the transition bug. Youcan see already filed ones at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org Done, bug #1052174.
Bug#1052174: release.debian.org: transition: gumbo-parser
Package: release.debian.org Severity: normal X-Debbugs-Cc: none, Aymeric Agon-Rambosson User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:gumbo-parser Control: forwarded -1 https://release.debian.org/transitions/html/auto-gumbo-parser.html Hello, I am looking for the transition from libgumbo1 to libgumbo2 due to an upstream SONAME bump in the new release. The reverse dependencies are the following : - gumbo-parser ok - bibledit-cloud ok - claws-mail ok - httpdirfs-fuse ok - kristall ok - libhtml-gumbo-perl ok - litehtml ok - mupdf ok - tdom ok - zim-tools ok - pymupdf ok - sioyek ok All of them build fine with the experimental gumbo-parser. Ben file: Affected: .depends ~ /\b(libgumbo2|libgumbo1)\b/ Good: .depends ~ /\b(libgumbo2)\b/ Bad: .depends ~ /\b(libgumbo1)\b/ Best, Aymeric Agon-Rambosson
Bug#1051219: ITA: gumbo-parser -- pure-C HTML5 parser
Le dimanche 17 septembre 2023 à 21:18, Bastian Germann a écrit : All of the listed packages build fine with the experimental gubo-parser. Out of curiosity, how did you establish this ? I am currently running a loop of sbuild commands over the listed packages and the architectures, but I wonder whether there are some simpler ways. That will not be needed. Next step for you is to file the transition bug. Youcan see already filed ones at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org In the bug you should tell them that there are no build failures with the experimental version in the reverse dependencies. Will do, I'll keep you posted.
Bug#1051219: ITA: gumbo-parser -- pure-C HTML5 parser
Le samedi 16 septembre 2023 à 16:59, Bastian Germann a écrit : Please push your changes and make it an experimental upload. When that is done, please ping me again so that I can upload the pkg. Please do not forget to push an upstream/... tag. Done, you can upload. The upstream tag is upstream/0.12.0+dfsg. Oh, and please make the CI pipeline run by adding repacksuffix=+dfsg to d/watch's opts. You can also get rid of the filenamemangle. Done. The pipeline is fixed, thanks for the indication. After the experimental version is uploaded, you will have to request a transition slot from the release team. I'm currently reviewing https://wiki.debian.org/Teams/ReleaseTeam/Transitions. I am reading that I will have to test build the reverse dependencies (stage 4), and report about it in the release.debian.org bug. This part should be fine. But it also says that I will maybe have to make uploads to reverse dependencies (stage 10). I will probably need your help for this, since I'm not authorised to. Thank you for your help and explanations. Best, Aymeric
Bug#1051219: ITA: gumbo-parser -- pure-C HTML5 parser
Hello Mr. Germann, It turns out I use gumbo-parser, and I am willing to maintain it. I have forked the salsa repo to https://salsa.debian.org/ricorambo/gumbo-parser, where my changes are (new upstream versions and minor packaging improvements). I have decided to import another upstream (https://codeberg.org/grisha/gumbo-parser) according to the recommendation of Mr. Kirillov (the upstream maintainer), which I preferred to the idea of Mr. Lefevre to follow sigil-gumbo. However, it turns out that Mr. Kirillov bumped the shared library version in the last release. I changed the binary package name accordingly (libgumbo1 to libgumbo2), along with the symbols file, but since I am only Debian Maintainer (DC184C7074DC4FD338D86CF97E32B4D596D6F8F6), I don't think I will be able to upload (If I'm not mistaken, the package will have to go through NEW because of the new libgumbo2 binary package). Would it be possible for you to upload my changes to the archive (if you agree with them, of course) ? If you grant me access to the salsa repo, I'll push my changes to it. And if you give me upload rights to the package as well, I'll be able to push future upstream releases to the archive without having to bother you again (except if the shared library gets renamed again, ofc). Thank you very much in advance. Best, Aymeric Agon-Rambosson
Bug#1040787: dh-elpa: Lots of missing eln files
Le dimanche 16 juillet 2023 à 19:39, "Nikolaus Rath" a écrit : Afraid not. With the current elpa-async package, the files are correctly removed on purge. That's good. That leaves me with a different question though - how do I clean up my system? It seems I have a lot of directories and files in /usr/share/emacs/site-lisp/elpa that should not be there, and dpkg -S can't be used to identify what should and shouldn't be there. Is there a way to find out what should not be there? I would say that any directory in /usr/share/emacs/site-lisp/elpa that has no namesake in /usr/share/emacs/site-lisp/elpa-src, AND that is not provided itself by a package, should not be there. Sean, does that seem right to you, or is that too violent a predicate ? Best, Aymeric
Bug#1040787: dh-elpa: Lots of missing eln files
Hello, Le dimanche 16 juillet 2023 à 08:22, Sean Whitton a écrit : async 1.9.3 is from buster. You have /usr/share/emacs/site-lisp/elpa-async-1.9.7 on your system, right? The directory you're supposed to have is /usr/share/emacs/site-lisp/elpa/async-1.9.7 Le dimanche 16 juillet 2023 à 10:52, Nikolaus Rath a écrit : No. It seems these files got orphaned during the upgrade: # dpkg -S /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc dpkg-query: no path found matching pattern /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc They did not. dpkg -S only shows the files that are present in the .deb file, and the byte-compiled files (elc) are not. The real file list of the elpa-async package can be queried with : - dpkg -L elpa-async - apt-file list elpa-async (same as previous one, but without prefix directories) - Or directly on https://packages.debian.org/bookworm/all/elpa-async/filelist It is normal that files in /usr/share/emacs/site-lisp/elpa do not show up in any file list. It is because those files are generated during the installation process, from the content of /usr/share/emacs/site-lisp/elpa-src (note the -src suffix). And indeed, those files in /usr/share/emacs/site-lisp/elpa are either symbolic links to elisp source files in /usr/share/emacs/site-lisp/elpa-src, or the byte-compiled version of those same files. Looking at one randomly there seems to be a broken symlink for the .el file: nikratio@vostro /u/s/e/s/elpa> dir /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.* lrwxrwxrwx 1 root 57 Feb 24 10:49 /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.el -> /usr/share/emacs/site-lisp/elpa-src/async-1.9.3//async.el -rw-r--r-- 1 root 12K Feb 24 10:49 /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc I am not sure what you mean by broken symlink. My output of dir(1) does not show the target of symlinks. Do you mean that the target of the symbolic link is not present on your system ? This is not supposed to be the case after a successful installation of an elpa-* package : they are part of it. Try to reinstall elpa-async from stable, you should have /usr/share/emacs/site-lisp/elpa-src/async-1.9.7 and the elisp source files therein, and the corresponding symlinks and byte-compiled files in /usr/share/emacs/site-lisp/elpa/async-1.9.7. Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc Disable showing Disable logging Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/transient-0.2.0.30/transient.elc Disable showing Disable logging Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/async-1.9.3/async-bytecomp.elc Disable showing Disable logging Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc Disable showing Disable logging Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc Disable showing Disable logging Those warnings can safely be ignored. The new native compiler is looking for the source file of each loaded byte-compiled file, and because of our specific file architecture, it does not find it in the same directory. However, in my case, I do have the corresponding native-compiled files in my ~/.emacs.d/eln-cache directory. You could check if you have it, it is supposed to be named ~/.emacs.d/eln-cache/-xx/async--x.eln. My point is that if there is a native-compiled version of some elisp source file on my system, and emacs is capable of loading the native-compiled file, then it means that the native compiler found the source file. So the warnings can be ignored, because some time after the issuing of those warnings, the native compiler will look for the source file in the right place. So it seems to me there are two different things here : - The broken symlink, which should be resolved after a reinstallation of the corresponding package (do tell us if that's not the case) - The native compiler warnings, which can be ignored. Best, Aymeric
Bug#1036912: pipewire-pulse: same bug but with lightdm
Package: pipewire-pulse Version: 0.3.65-3 Followup-For: Bug #1036912 Dear Maintainer, I can confirm this bug as well, with lightdm instead of gdm or sddm. "lsof -n -i :4713" produces similar output to what Messrs. Moskovic and Chaparro report, with lightdm (or Debian-lightdm, not sure) as user. Restarting pipewire-pulse manually with systemctl works, but only when done manually after login is completed. Trying to do it automatically as part of the login process (in .xsessionrc, for instance) does not work : lightdm probably keeps listening long enough for it not to work. Best, Aymeric -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/16 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 pipewire-pulse depends on: ii init-system-helpers 1.65.2 ii pipewire 0.3.65-3 Versions of packages pipewire-pulse recommends: ii wireplumber 0.4.13-1 Versions of packages pipewire-pulse suggests: pn libspa-0.2-bluetooth ii pulseaudio-utils 16.1+dfsg1-2+b1 -- no debconf information
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.
Le samedi 25 mars 2023 à 12:40, Sean Whitton a écrit : Hello, We can't make either of these metadata changes now the freeze has begun. After the freeze, the correct fix is to just update elpa-org to the latest release. It's unfortunate that we didn't update elpa-org in time. Sorry about that. In the meantime, if you want your emacs to load the org provided with emacs-el, and not the one provided with elpa-org, you may modify the `load-path` variable. It should contain both : - "/usr/share/emacs/site-lisp/elpa/org-9.5.2" - "/usr/share/emacs/28.2/lisp/org" Since the first one comes before the other in the list, it is the one loaded when you do "(require 'org)". You'll need to make sure to have the one you want coming before the other *at the moment you require the package*. Best, Aymeric
Bug#826918: ITA : qcomicbook -- viewer for comic books
Hello everyone, I would like to maintain this package, since I use it and it seems pretty stable. There haven't been any release from upstream (https://github.com/stolowski/QComicBook) in 6 years now, but the package is perfectly usable. There is a fork at https://github.com/plntyk/QComicBook, that implements some fixes that were asked for and offered on the other upstream. I am tempted to follow that new upstream, but feel free to tell me what you think. Other than that, I was thinking of a few packaging improvements. There doesn't seem to be any repository on salsa for this package. Mr. Martens, please do tell me if I have missed it. If not, I would create the repository. Is there any git history any of you (Mr. Martens, or the previous uploaders from the QA team) would like me to fetch from anywhere, or am I free to restart history ? I have a salsa account and have access to a few repositories, but I am not a Debian Maintainer. I would need one of you (Mr. Martens or anyone from the QA team) to sponsor my (probably rare) uploads. Best, Aymeric Agon-Rambosson
Bug#984038: [PATCH] drawtiming : ftbfs with GCC-11
Someone (Thomas Sailer) offered upstream a patch that resolves the
FTBFS error.
I tested it and it works.
However, applying this patch uncovers some other (I would assume
unrelated ?) errors :
- Some compiler compiler seems to be required by the upstream
makefile, so I added bison to the build dependencies
- The automatic tests made after the compilation fail because
ImageMagick triggers a segmentation fault. I overrode auto test
and tested manually the binary, which seems to work.
I have included the patch, the new control and rules files, and I
am tagging this bug as having a patch.
Let me know if you have any questions.
Best,
Aymeric Agon-Rambosson
Description: Fix compile failures for newer g++ release
Author: Thomas Sailer
Forwarded: yes
Comment: Found on https://sourceforge.net/p/drawtiming/patches/12/
--- a/src/parser.yy
+++ b/src/parser.yy
@@ -42,13 +42,13 @@ statements:
statement { $$ = $1; deps.push_back ($1); }
| statements ',' statement { $$ = $3; deps.push_back ($3); }
| statements ';' statement { $$ = $3; deps.clear (); deps.push_back ($3); }
-| statements CAUSE statement { $$ = $3; data.add_dependencies ($3, deps);
+| statements CAUSE statement { $$ = $3; data_.add_dependencies ($3, deps);
deps.clear (); deps.push_back ($3); }
-| statements DELAY statement { $$ = $3; data.add_delay ($3, $1, $2); }
+| statements DELAY statement { $$ = $3; data_.add_delay ($3, $1, $2); }
statement:
-SYMBOL '=' SYMBOL { $$ = $1; data.set_value ($1, n, timing::sigvalue ($3)); }
-| SYMBOL '=' STRING { $$ = $1; data.set_value ($1, n, timing::sigvalue ($3, timing::STATE)); }
+SYMBOL '=' SYMBOL { $$ = $1; data_.set_value ($1, n, timing::sigvalue ($3)); }
+| SYMBOL '=' STRING { $$ = $1; data_.set_value ($1, n, timing::sigvalue ($3, timing::STATE)); }
| SYMBOL { $$ = $1; };
%%
--- a/src/globals.h
+++ b/src/globals.h
@@ -22,7 +22,7 @@
#define YYSTYPE std::string
extern unsigned n;
-extern timing::data data;
+extern timing::data data_;
extern timing::signal_sequence deps;
#endif
--- a/src/timing.cc
+++ b/src/timing.cc
@@ -113,16 +113,16 @@ sigdata ::operator= (const sigda
//
-data::data (void) : maxlen (0) {
+timing::data::data (void) : maxlen (0) {
}
-data::data (const data ) {
+timing::data::data (const timing::data ) {
*this = d;
}
//
-data ::operator= (const data ) {
+timing::data ::data::operator= (const timing::data ) {
maxlen = d.maxlen;
signals = d.signals;
sequence = d.sequence;
@@ -132,7 +132,7 @@ data ::operator= (const data ) {
//
-sigdata ::find_signal (const signame ) {
+sigdata ::data::find_signal (const signame ) {
signal_database::iterator i = signals.find (name);
if (i == signals.end ()) {
i = signals.insert (signal_database::value_type (name, sigdata ())).first;
@@ -143,7 +143,7 @@ sigdata ::find_signal (const signam
//
-const sigdata ::find_signal (const signame ) const {
+const sigdata ::data::find_signal (const signame ) const {
signal_database::const_iterator i = signals.find (name);
if (i == signals.end ())
throw not_found (name);
@@ -152,7 +152,7 @@ const sigdata ::find_signal (const
//
-void data::add_dependency (const signame , const signame ) {
+void timing::data::add_dependency (const signame , const signame ) {
// find the signal
sigdata = find_signal (name);
sigdata = find_signal (dep);
@@ -168,14 +168,14 @@ void data::add_dependency (const signame
//
-void data::add_dependencies (const signame , const signal_sequence ) {
+void timing::data::add_dependencies (const signame , const signal_sequence ) {
for (signal_sequence::const_iterator j = deps.begin (); j != deps.end (); ++ j)
add_dependency (name, *j);
}
//
-void data::add_delay (const signame , const signame , const string ) {
+void timing::data::add_delay (const signame , const signame , const string ) {
// a delay always indicates a dependency
// (but would require a way to select which is rendered)
// add_dependency (name, dep);
@@ -206,7 +206,7 @@ void data::add_delay (const signame
//
-void data::set_value (const signame , unsigned n, const sigvalue ) {
+void timing::data::set_value (const signame , unsigned n, const sigvalue ) {
// find the signal
sigdata = find_signal (name);
@@ -228,7 +228,7 @@ void data::set_value (const signame
//
-void data::pad (unsigned n) {
+void timing::data::pad (unsigned n) {
// pad all
Bug#1020851: elpa-ement: fails to install along emacs
Hello, Le vendredi 25 novembre 2022 à 10:31, Sean Whitton a écrit : It would? The highest version is meant to take precedence. That's a feature of package.el. I run some version of emacs 28.1, which ships xref 1.3.0. I installed elpa-eglot, which depends on elpa-xref version 1.0.2. Since then, I have had the following : (find-library-name "xref") "/usr/share/emacs/site-lisp/elpa-src/xref-1.0.2/xref.el" (locate-library "xref") "/usr/share/emacs/site-lisp/elpa/xref-1.0.2/xref.el" I do have /usr/share/emacs/28.1/lisp/progmodes in my load-path, which is the directory containing xref.el.gz. From what I can see, it would seem that /usr/share/emacs/site-lisp takes precedence over /usr/share/emacs/, rather than the highest library version. I'm not sure whether that is intended or not. Best, Aymeric
Bug#1020851: elpa-ement: fails to install along emacs
Hello, Le mercredi 23 novembre 2022 à 14:00, Sean Whitton a écrit : elpa-transient isn't a transitional package -- we'll keep it in Debian even after Emacs 28 is the only Emacs we have. This is because we might need a newer version of transient available for another package. So far our strategy has been to handle this in the code in dh_elpa that generates dependencies, and also not worry about it too much, unless we get a combination that results in something not having its dependency available. I don't think we should be adding Provides/Breaks anywhere without considering corresponding changes in dh_elpa. The change we have used previously was to add the package in question (then org, in the present case transient) to the list of separately packaged libraries in the dhelpa-filter-deps-for-debian. This would create a hard dependency on elpa-transient, regardless of the available version of the same library in the bundled version of emacs. This would solve the problem of elpa-ement and elpa-snakemake. However, this packaged version of elpa-transient would also shadow the transient shipped with emacs, regardless of their respective versions. The use of the Provides: mechanism proposed by Mr. Beckmann on the emacs-common package (which is independent from the changes made in dh-elpa that would need to be done anyway) would prevent that, and also allow apt to save installing a package (elpa-transient) only when the emacs-common version is high enough. This would only require computing, for each elisp libraries shipped with emacs that we also package separately, the version provided by the current version of emacs. A corresponding versioned Provides: field would be then added to emacs-common. I.E. a loop around something like this : (package-desc-version (cadr (assq 'transient package-alist))) This is in fact a simpler and more elegant solution than the one I proposed in 87h6zai8qp.fsf@EBx360. Best, Aymeric
Bug#1022212: ITP: pulsar -- Emacs package to pulse the current line after running select functions.
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: pulsar Version : 0.50 Upstream Author : Protesilaos Stavrou * URL or Web page : https://git.sr.ht/~protesilaos/pulsar * License : GPL-3+ Description : Emacs package to pulse the current line after running select functions. This is a small package that temporarily highlights the current line after a given function is invoked. Best, Aymeric
Bug#1021462: ITP: eglot -- Emacs client for Language Server Protocol servers
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: eglot Version : 1.9 Upstream Author : João Tavora * URL or Web page : https://github.com/joaotavora/eglot * License : GPL-3+ Description : Emacs client for Language Server Protocol servers This is a minimalist emacs client for LSP servers. It is very well integrated with other IDE features within core emacs.
Bug#1017733: emacs: Newest version makes elisp packages builts fail
Package: emacs Version: 1:28.1+1-0.1 Severity: serious X-Debbugs-Cc: none, Aymeric Agon-Rambosson Dear Maintainer, Since emacs 1:28.1+1-1 hit unstable today, all elisp packages builts fail. Here I join a log file for an attempt to build a new elpa package against unstable using sbuild : elpa-eglot_1.8-1_amd64-2022-08-19T12:12:11Z.build Description: Binary data The problem appears at line 593, just after or during the execution of the script /usr/lib/emacsen-common/packages/install/emacsen-common. This information is corroborated by the fact that every elisp package that had defined an autopkgtest test suite reports a regression (https://tracker.debian.org/pkg/emacs), this regression being the same segmentation fault as reported here. Best, Aymeric Agon-Rambosson
Bug#1017683: ITP: elpa-citar -- Find and act on bibliographic references within Emacs
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-citar Version : 1.0 Upstream Author : Bruce D'Arcus * URL or Web page : https://github.com/emacs-citar/citar * License : GPL-3+ Description : Find and act on bibliographic references within Emacs This package allows to find Bibtex and Biblatex bibliographic references from a source, provide completion on it with the help of a completion framework, and provide various contextual actions on these references, in org-mode, latex and markdown files. Aymeric Agon-Rambosson
Bug#1017639: ITP: elpa-orderless -- Emacs completion style that matches multiple regexps in any order
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-orderless Version : 0.7 Upstream Author : Omar Antolín Camarena * URL or Web page : https://github.com/oantolin/orderless * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs completion style that matches multiple regexps in any order This Emacs package offers a completion style, that is an completion matching engine, capable of matching multiple regexps, each following different regexp syntax, in any order. Aymeric Agon-Rambosson
Bug#1017602: ITP: elpa-embark -- Emacs Mini-Buffer Actions Rooted in Keymaps
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-embark Version : 0.17 Upstream Author : Omar Antolín Camarena * URL or Web page : https://github.com/oantolin/embark * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs Mini-Buffer Actions Rooted in Keymaps This Emacs package provides contextual minibuffer or regular buffer actions based on keymaps. Aymeric Agon-Rambosson
Bug#1017567: ITP: elpa-marginalia -- Marginalia in the Emacs minibuffer
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-marginalia Version : 0.13 Upstream Author : Daniel Mendler, Omar Antolín Camarena * URL or Web page : https://github.com/minad/marginalia * License : GPL-3+ Programming Lang: Emacs Lisp Description : Marginalia in the Emacs minibuffer This is a package providing useful annotations in the minibuffer based on the completion category. Aymeric Agon-Rambosson
Bug#1017566: ITP: elpa-marginalia -- Marginalia in the Emacs minibuffer
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-marginalia Version : 0.13 Upstream Author : Daniel Mendler, Omar Antolín Camarena * URL or Web page : https://github.com/minad/marginalia * License : GPL-3+ Programming Lang: Emacs Lisp Description : Marginalia in the Emacs minibuffer This is a package that provides useful annotations in the Emacs minibuffer. Aymeric Agon-Rambosson
Bug#1016948: ITP: elpa-compat -- COMPATibility Library for Emacs
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-compat Version : 28.1.2.0 Upstream Author : Philip Kaludercic * URL or Web page : https://sr.ht/~pkal/compat/ * License : GPL-3+ Description : COMPATibility Library for Emacs This package is a dependency of another ITP of mine, elpa-consult (1016946). The goal is to provide emacs package developers with symbols that have not yet been implemented in an emacs version they are targeting.
Bug#1016946: ITP: elpa-consult -- Useful commands based on completing-read for Emacs
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-consult Version : 0.18 Upstream Author : Daniel Mendler * URL or Web page : https://github.com/minad/consult * License : GPL-3+ Description : Useful commands based on completing-read for Emacs This is a set of improved practical commands using completing-read. Aymeric Agon-Rambosson
Bug#1016902: ITP: elpa-vertico -- VERTical Interactive COmpletion for Emacs
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-vertico Version : 0.25 Upstream Author : Daniel Mendler * URL or Web page : https://github.com/minad/vertico * License : GPL-3+ Programming Lang: Emacs Lisp Description : VERTical Interactive COmpletion for Emacs This is a performant and minimalistic vertical completion user interface for emacs. Aymeric Agon-Rambosson
Bug#981118: O: elpa-undo-tree -- Emacs minor mode for handling undo history as tree
control: retitle 981118 ITA: elpa-undo-tree control: owner 981118 aymeric.a...@yandex.com I wish to adopt the package. I already have a lintian clean package up to date with upstream at https://gitlab.com/aagonrambosson/undo-tree. Best, Aymeric Agon-Rambosson
Bug#952810: Intent to adopt ebib
Hello Mr. Whitton, First of all, thank you for your work as maintainer of ebib. I use ebib regularly, and I am ready to adopt it. In fact, I already have a completely debian-compliant and lintian-clean package of the last upstream version in my private debian archive, that I have been using for the past week without errors so far. I am no debian maintainer or developer. This would be my first package to maintain (with parsebib, for which I have applied earlier). I have no preference whatsoever between joining the emacsen team or taking the package out of the team's hand. I could however be interested later in helping maintain other emacs packages, and even adding new ones. Would joining the emacsen team be the best course of action for this purpose ? What should I do next ? Aymeric Agon-Rambosson
Bug#1007867: O: parsebib
Hello Mr. Whitton, First of all, thank you for your work as maintainer of parsebib. I use parsebib regularly, and I am ready to adopt it. In fact, I already have a completely debian-compliant and lintian-clean package of the last upstream version in my private debian archive, that I have been using for the past week without errors so far. I am no debian maintainer or developer. This would be my first package to maintain. I have no preference whatsoever between joining the emacsen team or taking the package out of the team's hand. I could however be interested later in helping maintain other emacs packages, and even adding new ones. Would joining the emacsen team be the best course of action for this purpose ? What should I do next ? Aymeric Agon-Rambosson
Bug#987652: surf does not start
Hello Herr Sprickerhof,
First of all thank you for your quick answer. Your last remark
gave me the hint I needed :
It turns out I had a stale libsurf-webext.so in the directory
/usr/local/lib/surf, removing it solved the problem. This is due
to the fact that upstream changed the name of the library from
libsurf-webext.c to webext-surf.c between debian/2.0+git20181009
and debian/2.0+git20201107, which means that a not careful enough
direct use of the Makefile (make install once in each branch, not
separated with a make uninstall) would mean that two versions of
the shared object library (the stale one libsurf-webext.so, and
the new one webext-surf.so) would cohabit in the same directory
/usr/local/lib/surf.
These two shared object libraries would have competing versions of
each symbol, and more specifically two versions of the culprit
symbol webkit_web_initialize_with_user_data() :
- one (libsurf-webext.so) that would have g_variant_get(gv,
"(ii)", , )
- the other (webext-surf.so) that would have g_variant_get(gv,
"i", )
Since in the new version (debian/2.0+git20201107), gv would be
created like this :
gv = g_variant_new("i", spair[1])
surf would work correctly only if the dynamic linking would use
webext-surf.so, and crash if the dynamic linking had chosen
libsurf-webext.so. I have no idea how the choice is made
(alphabetic order of each shared object file maybe ??), but it
seems the dynamic linking systematically chose the stale file
before we removed it.
So the problem was entirely my fault, and a more careful direct
use of the Makefile solved the problem. So I am sorry for having
wasted your time.
However, the stuff I do on my own patched version of surf (that
goes in /usr/local/bin, with the shared object going in
/usr/local/lib/surf/) should have no influence on the Debian
version of surf living in /usr/bin : even when I launched
/usr/bin/surf, the stale library
/usr/local/lib/surf/libsurf-webext.so would be used over
/usr/lib/surf/webext-surf.so ! So a user-compiled shared object
(in /usr/local) would take precedence over a Debian-compiled
version (in /usr), even when the binary is itself in /usr ?
This, in my opinion, is still a bug (albeit a lot less severe and
a lot more subtle, and arguably a different one). What is the next
course of action ?
The symbol webkit_web_initialize_with_user_data() is not called
from surf, but from webkit. So the bug lies not with the surf
package, but probably with the libwebkit2gtk-4.0-37.
So the original bug (surf not starting) can be closed (I have no
idea how to do that). I'll let you tell me whether you agree with
my opinion that webkit should try to resolve
webkit_web_initialize_with_user_data() from /usr/lib/surf and not
from /usr/local/lib/surf when the binary is /usr/bin/surf, and
whether this warrants another bug report (and in which package ) ?
Thank you again for your time reading this long message,
Best regards,
Aymeric Agon-Rambosson
Jochen Sprickerhof writes:
* Aymeric Agon-Rambosson [2021-04-27
03:18]:
$ /usr/bin/surf
output :
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: the
GVariant format string '(ii)' has a type of '(ii)' but the given
value has a type of 'i'
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728:
g_variant_get: assertion 'valid_format_string (format_string,
TRUE, value)' failed
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: the
GVariant format string '(ii)' has a type of '(ii)' but the given
value has a type of 'i'
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729:
g_variant_get: assertion 'valid_format_string (format_string,
TRUE, value)' failed
web process terminated: crashed
Also, can you check if you have a custom webext-surf.so in your
~/.surf or elsewhere in your ld path?
Bug#987652: surf does not start
Package: surf
Version: 2.0+git20201107-2
Severity: grave
Tags: upstream
Justification: renders package unusable
Dear Maintainer,
surf does not start anymore since version 2.0+git20201107.
Expected behaviour : surf should start.
Steps to reproduce :
$ /usr/bin/surf
output :
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: the GVariant format
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: g_variant_get:
assertion 'valid_format_string (format_string, TRUE, value)' failed
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: the GVariant format
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: g_variant_get:
assertion 'valid_format_string (format_string, TRUE, value)' failed
web process terminated: crashed
And surf crashes.
The problem can be traced back to this specific upstream commit :
e92fd1aa5f38c399f8fc5d263026fbd9d34ddfbb
Which can be found at
https://git.suckless.org/surf/commit/e92fd1aa5f38c399f8fc5d263026fbd9d34ddfbb.html
One possible fix/workaround is the following :
diff --git a/surf.c b/surf.c
index ac832ff..e84a538 100644
--- a/surf.c
+++ b/surf.c
@@ -1269,7 +1269,7 @@ initwebextensions(WebKitWebContext *wc, Client *c)
if (spair[1] < 0)
return;
- gv = g_variant_new("i", spair[1]);
+ gv = g_variant_new("(ii)", spair[1]);
webkit_web_context_set_web_extensions_initialization_user_data(wc, gv);
webkit_web_context_set_web_extensions_directory(wc, WEBEXTDIR);
diff --git a/webext-surf.c b/webext-surf.c
index d087219..da16ddf 100644
--- a/webext-surf.c
+++ b/webext-surf.c
@@ -95,7 +95,7 @@
webkit_web_extension_initialize_with_user_data(WebKitWebExtension *e,
webext = e;
- g_variant_get(gv, "i", );
+ g_variant_get(gv, "(ii)", );
gchansock = g_io_channel_unix_new(sock);
g_io_channel_set_encoding(gchansock, NULL, NULL);
But this workaround seems wrong when we look at the semantic of g_variant_new()
in
gvariant.c :
- sock and spair[1] are ints, and should work with "i".
- Similarly, "(ii)" should mean two extra arguments after the format, but only
works.
And I don't know whether this fix breaks surf in another way.
One other way would be to revert to 2.0+git20181009-4, or some other version
inbetween.
Thank you in advance for your time,
Aymeric Agon-Rambosson
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-6-amd64 (SMP w/16 CPU threads)
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 surf depends on:
ii libc62.31-11
ii libgcr-base-3-1 3.38.1-2
ii libgcr-ui-3-13.38.1-2
ii libglib2.0-0 2.66.8-1
ii libgtk-3-0 3.24.24-3
ii libjavascriptcoregtk-4.0-18 2.30.6-1
ii libwebkit2gtk-4.0-37 2.30.6-1
ii libx11-6 2:1.7.0-2
Versions of packages surf recommends:
ii curl 7.74.0-1.2
ii stterm [x-terminal-emulator] 0.8.4-1
ii suckless-tools46-1
ii x11-utils 7.7+5
Versions of packages surf suggests:
ii apparmor 2.13.6-10
-- Configuration Files:
/etc/apparmor.d/usr.bin.surf changed:
/usr/bin/surf flags=(complain) {
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
owner @{HOME}/.surf/ w,
owner @{HOME}/.surf/** rwkl,
owner @{HOME}/.cache/ rw,
@{PROC}/@{pid}/cmdline r,
@{PROC}/@{pid}/fd/ r,
@{PROC}/@{pid}/smaps r,
/dev/ r,
/sys/devices/pci[0-9]*/** r,
/sys/devices/platform/soc/soc:gpu/* r,
/usr/share/glib-2.0/schemas/gschemas.compiled r,
/usr/share/doc/** r,
# WebKit
/usr/lib/@{multiarch}/webkit2gtk-4.0/WebKit*Process ix,
/{dev,run}/shm/WK2SharedMemory.* rw,
/var/tmp/WebKit-Media-* rw,
/usr/share/publicsuffix/public_suffix_list.{dat,dafsa} r,
owner @{HOME}/.local/share/webkitgtk/ w,
owner @{HOME}/.local/share/webkitgtk/** rw,
owner @{HOME}/.cache/webkitgtk/ w,
owner @{HOME}/.cache/webkitgtk/** rwk,
# fontconfig
/usr/share/fontconfig/conf.avail/ r,
# dconf
owner @{HOME}/.cache/dconf/user rw,
owner /run/user/*/dconf/user rw,
/usr/bin/surf ix,
/{usr/,}bin/dash ix,
/{usr/,}bin/sed ix,
/usr/bin/dmenu ix,
/usr/bin/printf ix,
/usr/bin/xargs ix,
/usr/bin/xprop ix,
# for downloading files
/dev/ptmx rw,
/dev/pts/* rw,
/usr/bin/st ix,
# unconfined because it is call
