Bug#1064404: snapd: please make the build reproducible.
Followup-For: Bug #1064404 Control: fixed -1 2.62-3 Control: close -1 The snapd package has been building reproducibly since 2.62-4. I'm tagging this bug as resolved from 2.62-3 because the patch here landed in that version. Thank you, Zygmunt!
Bug#1076932: webdis: FTBFS: src/client.h:6:10: fatal error: http_parser.h: No such file or directory
On Fri, Jul 26, 2024 at 08:45:49PM GMT, Johannes Schauer Marin Rodrigues wrote: > Hi James, > > Quoting James McCoy (2024-07-26 19:48:52) > > Nothing has changed in the packaging since it last successfully built, so I > > used debbisect to narrow down the problem to the dpkg 1.22.7 upload. > > you are now (to my knowledge) the second user of debbisect. Could you share > your debbisect invocation? I'm interested in hearing how others are using it > to > potentially improve on its interface. In this case, I just used the debbisect_buildsrc.sh example from the man page. I do have some fixes I'm planning to put up an MR for, though. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1077005: CFLAGS+=foo etc stopped working
Control: reassign -1 1076932 dpkg-dev Control: forcemerge -1 1076932 Control: affects -1 src:webdis On Fri, Jul 26, 2024 at 01:20:28PM GMT, Nicolas Boulenguez wrote: > The fact that the previous lazy evaluation mechanism, in which the > $(evals VAR=$(VAR)) trick is already present, did what you expect in > some contexts does not make CFLAGS+= a supported interface, and your > code could break in other contexts. > > Replacing > CFLAGS+= foo > with > DEB_CFLAGS_MAINT_APPEND := foo > in the broken packages seems more fruitful to me, and I would prefer > to help with that. I'm running into a similar problem with webdis (#1076932), however in that case we're doing CFLAGS += $(CPPFLAGS) I'm not sure how to do that with the DEB_CFLAGS_MAINT_APPEND. My naïve attempt at DEB_CFLAGS_MAINT_APPEND = $(CPPFLAGS) results in /usr/share/dpkg/buildflags.mk:51: *** Recursive variable 'dpkg_buildflags_run' references itself (eventually). Stop. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1076932: webdis: FTBFS: src/client.h:6:10: fatal error: http_parser.h: No such file or directory
On Wed, Jul 24, 2024 at 12:50:20PM GMT, Santiago Vila wrote: > During a rebuild of all packages in unstable, your package failed to build: > > > [...] > debian/rules binary > dh binary >dh_update_autotools_config >dh_autoreconf >dh_auto_configure >debian/rules override_dh_auto_build > make[1]: Entering directory '/<>' > dh_auto_build > make -j2 "INSTALL=install --strip-program=true" > make[2]: Entering directory '/<>' > cc -c -g -O2 -Werror=implicit-function-declaration > -ffile-prefix-map=/<>=. -fstack-protector-strong > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > -DMSGPACK=1 -o src/webdis.o src/webdis.c > cc -c -g -O2 -Werror=implicit-function-declaration > -ffile-prefix-map=/<>=. -fstack-protector-strong > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > -DMSGPACK=1 -o src/cmd.o src/cmd.c > In file included from src/cmd.c:4: > src/client.h:6:10: fatal error: http_parser.h: No such file or directory > 6 | #include "http_parser.h" > | ^~~ Nothing has changed in the packaging since it last successfully built, so I used debbisect to narrow down the problem to the dpkg 1.22.7 upload. With dpkg 1.22.6, webdis builds fine because the CFLAGS that are defined in debian/rules (in particular the -I options) are picked up by the upstream build: make -j6 "INSTALL=install --strip-program=true" make[2]: Entering directory '/<>' cc -c -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -Isrc -Isrc/http-parser -DMSGPACK=1 -o src/webdis.o src/webdis.c However, with dpkg 1.22.7 we see a very different command being used to compile: make -j2 "INSTALL=install --strip-program=true" make[2]: Entering directory '/<>' cc -c -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -DMSGPACK=1 -o src/webdis.o src/webdis.c It's missing "-Wdate-time -D_FORTIFY_SOURCE=2" and the include directories. The relevant lines from debian/rules are export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow include /usr/share/dpkg/buildflags.mk CFLAGS += $(CPPFLAGS) export CFLAGS += -Isrc -Isrc/http-parser Maybe this package is trying to use the dpkg-provided build flags incorrectly, but I've seen this pattern in a number of places. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1073425: php-oscarotero-gettext: FTBFS: make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1
The build is working in testing, so this regression is due to a recent change. I've narrowed down the cause of the issue to a change in one of the following packages: - libxml2: - build works with 2.9.14+dfsg-1.3+b3 - build fails with 2.12.7+dfsg-3+b1 - libxml2-utils: - build works with 2.9.14+dfsg-1.3+b3 - build fails with 2.12.7+dfsg-3+b1 - libxml-libxml-perl: - build works with 2.0207+dfsg+really+2.0134-1+b3 - build fails with 2.0207+dfsg+really+2.0134-4
Bug#1065923: python-certbot: Please drop dependencies on python3-distutils
tags 1065923 patch thanks On Sun, 10 Mar 2024 18:15:58 -0100 Graham Inggs wrote: In fact, there is no module for Python 3.12 in python3-distutils, so these dependencies may already be unnecessary. Searching through the code shows that distutils is not used, and is only mentioned in comments. So the dependency can simply be dropped. I opened a merge request: https://salsa.debian.org/letsencrypt-team/certbot/certbot/-/merge_requests/8
Bug#1076545: websockify: Make optional token plugins actually optional
Package: websockify
Version: 0.12.0+dfsg1-2
Severity: normal
Tags: patch
X-Debbugs-Cc: james.p...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* d/control,d/p/optional-runtime-depends.patch:
Drop python3-{redis,jwcrypto} from Depends to Suggests as these
features are optional, patch setup.py to reflect this.
I've submitted this change to the upstream project as well.
I also dropped a duplicated dependency on python3-numpy -
python3-websockify depends on this already so no need to also do
it for websockify itself.
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers oracular
APT policy: (500, 'oracular'), (100, 'oracular-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.8.0-31-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru websockify-0.12.0+dfsg1/debian/control
websockify-0.12.0+dfsg1/debian/control
--- websockify-0.12.0+dfsg1/debian/control 2024-07-16 02:31:21.0
+0100
+++ websockify-0.12.0+dfsg1/debian/control 2024-07-18 11:04:29.0
+0100
@@ -60,12 +60,13 @@
Package: websockify
Architecture: any
Depends:
- python3-jwcrypto,
- python3-numpy,
python3-websockify (>= ${source:Version}),
${misc:Depends},
${python3:Depends},
${shlibs:Depends},
+Suggests:
+ python3-jwcrypto,
+ python3-redis,
Description: WebSockets support for any application/server
websockify was formerly named wsproxy and was part of the noVNC project.
.
diff -Nru websockify-0.12.0+dfsg1/debian/patches/optional-runtime-depends.patch
websockify-0.12.0+dfsg1/debian/patches/optional-runtime-depends.patch
--- websockify-0.12.0+dfsg1/debian/patches/optional-runtime-depends.patch
1970-01-01 01:00:00.0 +0100
+++ websockify-0.12.0+dfsg1/debian/patches/optional-runtime-depends.patch
2024-07-18 10:47:28.0 +0100
@@ -0,0 +1,22 @@
+Description: Make optional depends optional
+ Redis and JWCryto are both optional dependencies;
+ update setuptools configuration to this effect.
+Author: James Page
+Forwarded: https://github.com/novnc/websockify/pull/582
+
+--- a/setup.py
b/setup.py
+@@ -31,9 +31,11 @@
+ include_package_data=True,
+ install_requires=[
+ 'numpy', 'requests',
+-'jwcrypto',
+-'redis',
+ ],
++ extras_requires={
++'redis': ['redis'],
++'jwt': ['jwcrypto'],
++},
+ zip_safe=False,
+ entry_points={
+ 'console_scripts': [
diff -Nru websockify-0.12.0+dfsg1/debian/patches/series
websockify-0.12.0+dfsg1/debian/patches/series
--- websockify-0.12.0+dfsg1/debian/patches/series 2024-07-16
02:31:21.0 +0100
+++ websockify-0.12.0+dfsg1/debian/patches/series 2024-07-18
10:47:40.0 +0100
@@ -3,3 +3,4 @@
remove-testing-RSA1_5-now-deprecated-in-jwcrypto.patch
workaround-using-too-much-resource.patch
py3.12-avoid-raw-string-warning.patch
+optional-runtime-depends.patch
Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer
On Sun, Jul 14, 2024 at 11:07 PM Otto Kekäläinen wrote: > Yes, using Salsa or CI is not required, but I was curious is there > particular reason this package is not using Salsa-CI to validate > that all easily testable things are correct? > > Hi Otto, Thank you for your review of mango. I was not aware that pipelines were available for Debian packages, so I did not look in to setting one up. If there are any suggested standard/starter build templates I can reference for implementation please let me know. kind regards, James Montgomery
Bug#119911: RFP: alephone -- marathon engine for related data games
Package: wnpp Followup-For: Bug #119911 Control: reopen -1
Bug#1076341: RFP: cinecred -- Cinecred produces credit sequences for film, TV and animations from spreadsheet input.
Package: wnpp Severity: wishlist X-Debbugs-Cc: j...@jp-hosting.net * Package name: cinecred Version : 1.5.1 Upstream Contact: Felix Mujkanovic * URL : https://cinecred.com/ * License : GPL-3 Programming Lang: Java Description : Cinecred produces credit sequences for film, TV and animations from spreadsheet input. Using a semi-structured spreadsheet format as input, Cinecred renders video files that can contain a mixture of title fade-in/outs and smooth-scrolling grouped role credits, with internationalization support. It is configurable and the website provides an accompanying user guide and informational screencast.
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
On Sun, 14 Jul 2024 at 11:58, James Addison wrote: > > On Fri, 12 Jul 2024 at 19:10, James Addison wrote: > > [ ... snip ... ] > > Adding the patch would unnecessarily add the event handler to _all_ menu > > items; > > now it seems to me that that's not what we want. We only need the event > > handler for links that refer to the same '.html' file. But: that is all of > > them in the 'singlehtml' build output. > > I'll have to check whether this works and is supported in most browsers, but > there is a CSS anchor:local-link pseudo-selector[1] that might allow filtering > to exactly these links. In combination with omitting the '.current' filter, > that would achieve the intended logical effect, I think. > > [1] - https://developer.mozilla.org/en-US/docs/Web/CSS/:local-link No, the local-link CSS pseudo-selector doesn't seem suitable: 1. It is not yet supported in many (any?) browsers. 2. As per the current draft CSS Working Group specification[1], the comparison of the hyperlink target URL against the current URL _includes_ the fragment (the part after the '#' symbol after the filename in the URL) in the comparison: [draft quote] "If the hyperlink's target includes a fragment URL, then the fragment URL of the current URL must also match; ..." [end draft quote] I've considered attaching the event handler to any menu hyperlinks whose href attribute starts with a '#' character (CSS queries can prefix-match[2]). However, currently some singlehtml menu hyperlinks contain the '.html' filename part. That may change if https://github.com/sphinx-doc/sphinx/pull/12551 is merged upstream. The next alternative would be to use some JQuery logic to dynamically attach to hyperlinks that are the same-document based on some custom logic. [1] - https://drafts.csswg.org/selectors/#the-local-link-pseudo [2] - https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors#links
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
On Fri, 12 Jul 2024 at 19:10, James Addison wrote: > [ ... snip ... ] > Adding the patch would unnecessarily add the event handler to _all_ menu > items; > now it seems to me that that's not what we want. We only need the event > handler for links that refer to the same '.html' file. But: that is all of > them in the 'singlehtml' build output. I'll have to check whether this works and is supported in most browsers, but there is a CSS anchor:local-link pseudo-selector[1] that might allow filtering to exactly these links. In combination with omitting the '.current' filter, that would achieve the intended logical effect, I think. [1] - https://developer.mozilla.org/en-US/docs/Web/CSS/:local-link
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
Control: tags -1 - patch My patch seemed too simple; I now think it's somewhat flawed, after learning more about what is going on here. On Wed, 10 Jul 2024 at 23:52, James Addison wrote: > [ ... snip ... ] > > In my opinion we should try to get this into src:sphinx-rtd-theme as a Debian > patch, and also to try to send it upstream. Let's *not* do this yet (explanation follows). I was trying to figure out the logic of the original CSS query: why only add the close-menu event handler to 'current' links in the (multi)HTML build? I think the explanation is that those are -- surprise surprise -- links to the current '.html' file; each link is an anchor, but no inter-webpage navigation is required for them. That means that the browser may _not_ reload the page entirely when following _those_ links in the multi-page HTML build -- and so the event is required to close the menu for accessibility/usability purposes - but only for that subset of hyperlinks. Adding the patch would unnecessarily add the event handler to _all_ menu items; now it seems to me that that's not what we want. We only need the event handler for links that refer to the same '.html' file. But: that is all of them in the 'singlehtml' build output. So, in fact I'm wondering about a different question: should the menu link tree (table of contents) be entirely expanded in 'singlehtml' format? And should the top-level item in the tree have the 'current' CSS class applied to it? Or, alternatively -- should 'sphinx_rtd_theme' somehow figure out that the page is a 'singlehtml' build, and omit '.current' from the CSS query in that case?
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
Hi Holger, On Tue, 9 Jul 2024 at 21:30, Holger Wansing wrote: > [ ... snip ... ] > > Your patch works for me (tested on laptop with Firefox in a small window > and on my smartphone). Thank you for testing it! I found that it was annoying to have to scroll all the way to the top of the page again with the fix in place - but I suppose that is a separate problem. > So the point is, how to integrate this in the manual... > > I think you know that this theme.js file is taken from sphinx-rtd-theme-common > package and the manual is just placing a symlink to that file. > So the correct fix long-term would be, to get it fixed in that package (thus > on > sphinx upstream), but how long would that take? > And will it ever happen? Or will upstream not change this, because it > conflicts > with other circumstances? In my opinion we should try to get this into src:sphinx-rtd-theme as a Debian patch, and also to try to send it upstream. Upstream in this case is not Sphinx itself, but the ReadTheDocs project; I've added a comment on the forwarded bugthread to let them know about the patch here, in the hope of offering it to them too, or being told about a better way to fix the same problem. > So, should we fix it for the meantime via a little hack in our Makefile > resp. debian/rules? I'd prefer to patch the 'theme.js' file directly. Although upstream minifies the JavaScript code from that file, we copy it nearly-unmodified: https://sources.debian.org/src/sphinx-rtd-theme/2.0.0%2Bdfsg-1/debian/rules/#L23 > > It would be nice to figure out whether the CSS query worked in the past; > > perhaps this bug is a regression. > > I don't know exactly what you mean by "the CSS query worked". > I can reproduce this issue here on Debian bookworm, which has sphinx > version 5.3.0 included, while the developers-reference package is getting > built on unstable with sphinx version 7.3.x. > I guess, this does not confirm the thesis of a regression? Browsing the code history, that CSS query appears in sphinx_rtd_theme.git (the upstream sources) as far back as v0.1.8 (Y2015) and earlier: https://github.com/readthedocs/sphinx_rtd_theme/blob/b5b633a8415de721b18e79bdf5d72a4973496fec/sphinx_rtd_theme/static/js/theme.js#L16 So although it may not be a recent regression, it's possible that it functioned correctly at the time it was written. If it did, then my suggested patch -- although it may seem to work -- could be a sidetrack. Regards, James
Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer
Control: tags -1 - moreinfo On Wed, Jul 10, 2024 at 07:29:18PM +0100, Phil Wyett wrote: > 3. Licenses (lrc): Issue > > philwyett@ks-windu:~/Development/builder/debian/mentoring/mangl-1.1.5$ lrc > en: Versions: recon 1.11 check 3.3.9-1 > > Parsing Source Tree > Reading copyright > Invalid DEP-5 header in debian/copyright > Failed to process debian/copyright > > Hint: Format 1.0 not 2.0 on line 1. > [FIXED] lintian --pedantic and standard licensecheck didn't even catch > 4. Watch file (uscan --force-download): Good > > 5. Build Twice (sudo pbuilder build --twice .dsc): Good > > 6. Reproducible builds (reporotest)[1]: Good > > 7. Install (No previous installs): Good > > 8. Upgrade (Over previous installs if any): N/A > > Additional... > > A. Update 'Standards-Version' to latest 4.7.0 as per Debian policy[2]. > [FIXED] Learned that I must install the latest debian-policy package... > Summary... > > I believe 'mangl' is not yet ready for sponsorship/upload. Could the > contributor > rectify one of more of the rasied issues. Once updated to your satisfaction > and > a new upload done, please remove the 'moreinfo' on the Request For Sponsorship > (RFS) bug report. > I agree :) Long day of 'rookie mistakes' and manual reading for me. > [1] https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method > [2] https://www.debian.org/doc/debian-policy/ > > Regards > > Phil > >
Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer
On Fri, Jul 05, 2024 at 09:18:39AM +0100, Phil Wyett wrote: > Review... > > 1. Build: Good > > 2. Lintian: Issue > > I: mangl source: unused-license-paragraph-in-dep5-copyright bsd-3-clause > [debian/copyright:83] > N: > N: The license paragraph in the machine-readable copyright file is not > N: referenced by any files paragraph. It could be a typo in the license name > N: or the license paragraph is simply not needed and can be removed. > N: > N: Please refer to > N: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for > N: details. > N: > N: Visibility: info > N: Show-Always: no > N: Check: debian/copyright/dep5 > > Can be removed. [DONE] Updated copyright in latest mentors.d.o upload > I: mangl: desktop-entry-contains-encoding-key Encoding > [usr/share/applications/mangl.desktop:2] > N: > N: The Encoding key is deprecated in the FreeDesktop standard. Instead, all > N: strings must now be encoded in UTF-8. This desktop entry specifies an > N: Encoding of UTF-8. It is harmless but can be dropped. > N: > N: The desktop-file-validate tool in the desktop-file-utils package may be > N: useful for checking the syntax of desktop entries. > N: > N: Please refer to > N: https://specifications.freedesktop.org/desktop-entry-spec/latest/apc.html > N: for details. > N: > N: Visibility: info > N: Show-Always: no > N: Check: menu-format > > Keywords is an upstream thing and you can suggest adding them. The benefits > for certain types of > software such as software centres etc. is known. Do not be downhearted if > they will not add them, > just one of those things. > [SUBMITTED] Submitted issue upstream with patch[1]. [1]: https://github.com/zigalenarcic/mangl/issues/20 > 3. Licenses: Issue > > philwyett@ks-windu:~/Development/builder/debian/mentoring/mangl-1.1.5$ lrc > en: Versions: recon 1.11 check 3.3.9-1 > > Parsing Source Tree > Reading copyright > Running licensecheck > > d/copyright | licensecheck > > ISC | BSD-3-clause mandoc/compat_err.c > ISC | BSD-3-clause mandoc/compat_fts.c > ISC | BSD-3-clause mandoc/compat_fts.h > ISC | BSD-3-clause mandoc/compat_getsubopt.c > ISC | BSD-3-clause mandoc/compat_strcasestr.c > BSD-2-Clause-NetBSD| BSD-2-Clause-NetBSD and/or BSD-2-clause > mandoc/compat_stringlist.c > BSD-2-Clause-NetBSD| BSD-2-Clause-NetBSD and/or BSD-2-clause > mandoc/compat_stringlist.h > ISC | BSD-3-clause mandoc/compat_strsep.c > ISC | BSD-3-clause mandoc/man.1 > Unlicense | Expat and/or Unlicense stretchy_buffer.h > > The one I am curious about is the ISC. Looking at the files and other > packages that have this "The > Regents of the University of California. All rights reserved." these tend to > fall under a BSD > license. I would be happy for Andrey or another DD to offer advice here, as > they know more than I. > [DONE] Corrected to BSD-4-clause-UC copyright in latest mentors.d.o upload I validated reprotest and sbuild output; clean :) Thanks for your time and investement on my first package. I've learned a *ton* along the way. At this time I believe the package is ready for review and potential sponsorship. Kind regards, James signature.asc Description: PGP signature
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
Followup-For: Bug #1075914
X-Debbugs-Cc: hwans...@mailbox.org
Control: reassign -1 src:sphinx-rtd-theme
Control: affects -1 developers-reference
Control: tags -1 patch
This seems to relate to the Sphinx ReadTheDocs theme, and when I went digging
around in the code there, it seemed that there is already a JavaScript event
handler[1] in 'theme.js' that is intended to close the sidebar menu when a
hyperlink is clicked. It seems that that handler isn't being called.
For multi-page HTML projects, that's generally not a problem because the
browser opens the requested link page and rebuilds the DOM, applies CSS etc
from scratch - and the sidebar is closed by default, so it appears to the user
that the click/navigation closed it.
The root cause seems to be something to do with the CSS select query that is
used to attach the event handler. I'm attaching a patch that resolved the
issue when I tested it locally -- and should be compatible with the Debian
package build.
It would be nice to figure out whether the CSS query worked in the past;
perhaps this bug is a regression.
[1] -
https://sources.debian.org/src/sphinx-rtd-theme/2.0.0%2Bdfsg-1/src/theme.js/#L88-L97
commit c34a308ef0afe4882d27498593028e94c7d58578
Author: James Addison
Date: Tue Jul 9 13:35:16 2024 +0100
JavaScript: attach sidebar close-on-click handler to all menu hyperlinks.
diff --git a/src/theme.js b/src/theme.js
index db546b4..b66a54e 100644
--- a/src/theme.js
+++ b/src/theme.js
@@ -86,7 +86,7 @@ function ThemeNav () {
})
// Nav menu link click operations
-.on('click', ".wy-menu-vertical .current ul li a", function() {
+.on('click', ".wy-menu-vertical ul li a", function() {
var target = $(this);
// Close menu when you click a link.
$("[data-toggle='wy-nav-shift']").removeClass("shift");
Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error
Package: python3-django-hyperkitty Followup-For: Bug #1031928 X-Debbugs-Cc: p...@debian.org Control: forwarded -1 https://gitlab.com/mailman/hyperkitty/-/issues/503 Thanks Pierre-Elliott for opening the bugreport (forwarded) for this upstream.
Bug#998059: sphinx: LANGUAGE environment variable inconsistently affects output of objects.inv
Followup-For: Bug #998059 Control: forwarded -1 https://github.com/sphinx-doc/sphinx/pull/10067 Control: close -1 This variance in Sphinx project 'objects.inv' output files was resolved by a change within Sphinx that added a default config language code. That change stabilized the output of gettext-based translation resource loading, removing variance based on the build host's LANGUAGE environment variable.
Bug#1042955: zzzeeksphinx: please make the output reproducible
Source: zzzeeksphinx Followup-For: Bug #1042955 Control: tags -1 - pending Control: fixed -1 1.5.0-1 Control: close -1 I think this can be closed; the reproducibility fix here was included in the upload of 1.5.0-1 and appears to be working well: mako is building reproducibly. There may be other nondeterminism issue(s) to track down in sqlalchemy but those do not appear to be related to this bug. If I'm mistaken and/or there's another reason to keep this active, please feel free to re-open the bug.
Bug#1029843: Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)
Package: firmware-brcm80211 Followup-For: Bug #1029843 X-Debbugs-Cc: b...@decadent.org.uk, didi.deb...@cknow.org, k...@debian.org, p...@akeo.ie Thanks all for figuring this out and providing fixes - the updated contents of the firmware-brcm80211 20230625-3~exp3 package look good to me.
Bug#1075725: UDD/dmd: Make the header row of tables sticky/fixed
On Fri, Jul 05, 2024 at 10:53:04PM GMT, James McCoy wrote:
> Rather than go through all that mess, I poked around some more with some
> CSS adjustments and was able to put something together that didn't
> require updating anything related to datatables.
>
> https://salsa.debian.org/qa/udd/-/merge_requests/53
>
> I've also attached the patch.
Actually attached this time.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
>From 95b8c26ff0012f08ad86cf2d6b4bc7e18b0b578f Mon Sep 17 00:00:00 2001
From: James McCoy
Date: Fri, 5 Jul 2024 22:24:08 -0400
Subject: [PATCH] dmd: Make the first row/column of dmddetails table sticky
When dmddetails has many rows, it can be easy to lose track of what each
column represents. Similarly, since the table is wide, one can lose
track of what package a row corresponds to when scrolling to columns on
the right.
In order to keep them visible, a few more css rules are needed.
To keep the headers visible, the entire thead, rather than just the th,
needs to be sticky to the top of the viewport. This ensures both rows of
the table header are visible.
To keep the first column visible, change the first column in the tbody
to a th and mark it sticky to the left of the viewport. Since debian.css
makes th bold, also set these th back to normal font-weight.
In addition, the th in the first row of the table head needs to be
sticky to the left. We can't simply select the first th of the table
head because there are two rows and a rowspan involved.
Closes: #1075725
Signed-off-by: James McCoy
---
web/css/dmd.css | 21 +
web/templates/dmd.erb | 2 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/web/css/dmd.css b/web/css/dmd.css
index 40dafef..c0829fd 100644
--- a/web/css/dmd.css
+++ b/web/css/dmd.css
@@ -26,3 +26,24 @@ table#todolist tbody td {
font-size: 14px;
overflow-wrap: anywhere;
}
+
+table#dmddetails thead {
+ position: sticky;
+ z-index: 1;
+ top: 0;
+ background: white;
+}
+
+table#dmddetails thead tr:first-child>th:first-child {
+ position: sticky;
+ z-index: 2;
+ left: 0;
+ background: white;
+}
+
+table#dmddetails tbody th {
+ position: sticky;
+ left: 0;
+ background: white;
+ font-weight: normal;
+}
diff --git a/web/templates/dmd.erb b/web/templates/dmd.erb
index 44997c0..329b605 100644
--- a/web/templates/dmd.erb
+++ b/web/templates/dmd.erb
@@ -185,7 +185,7 @@
%>
<% next if not uddd.versions.include?(src) %>
<% next if not uddd.versions[src].include?('debian') %>
-https://tracker.debian.org/<%= ERB::Util::url_encode(src) %>" title="<%= h[:reason] %>"><%= src %>
+https://tracker.debian.org/<%= ERB::Util::url_encode(src) %>" title="<%= h[:reason] %>"><%= src %>
<% h[:versions].each do |v| %>
<%= v %>
--
2.45.2
Bug#1075725: UDD/dmd: Make the header row of tables sticky/fixed
Control: tag -1 patch On Wed, Jul 03, 2024 at 03:40:23PM GMT, James McCoy wrote: > The todolist and dmddetails tables can be quite long, which makes it > difficult to keep track of what data each column is displaying. It would > be useful if the header row could be made sticky so it stays visible > when scrolling through the table. The todolist table is much more self-describing, so I left that as is. > The tables are using datatables[0] to format the data. It has an > extension called FixedHeader[1] which supports adding this > functionality. > > [0]: https://datatables.net/ > [1]: https://datatables.net/extensions/fixedheader/ > > I tested locally by downloading a new bundled datatables.css / > datatables.jss with fixedheader included and adjusting the dmd template > and javascript with the attached patch. Rather than go through all that mess, I poked around some more with some CSS adjustments and was able to put something together that didn't require updating anything related to datatables. https://salsa.debian.org/qa/udd/-/merge_requests/53 I've also attached the patch. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer
Control: tags -1 - moreinfo Hi Phil, Thank you for taking the time to review my package and for your invaluable feedback.I've gone through and updated the copyright, switched to sbuild, and incorporated reprotest. I've included a snippet of the output sbuild -d unstable mangl_1.1.5-1.dsc +--+ | Summary | +--+ Build Architecture: amd64 Build Type: binary Build-Space: 15948 Build-Time: 6 Distribution: unstable Host Architecture: amd64 Install-Time: 17 Job: /home/montj2/git/mangl_1.1.5-1.dsc Lintian: pass Machine Architecture: amd64 Package: mangl Package-Time: 28 Source-Version: 1.1.5-1 Space: 15948 Status: successful Version: 1.1.5-1 Finished at 2024-07-05T05:27:04Z Build needed 00:00:28, 15948k disk space reprotest --vary=-build_path,domain_host.use_sudo=1 mangl_1.1.5-1.dsc === Reproduction successful === No differences in ./*.*deb 85919d375a6d4425ecfb0dbda9c78cdc8485ee5a3f6bf8bf22de689bb6274725 ./mangl-dbgsym_1.1.5-1_amd64.deb 5cef64a4b5cbbf971298618747fe389ea6f2fbdcc0a17fb09505e60c7df2324b ./mangl_1.1.5-1_amd64.deb Please let me know if there are any additional changes or improvements required.Additionally, if you're willing and able to share your review process as it would be helpful as a readiness check my next time around :) Kind regards, James
Bug#1070171: ITP: mangl -- An enhanced man page viewer
> Please file a Request For Sponsorship (RFS) bug. > > https://mentors.debian.net/sponsors/rfs-howto/ > > I will review here for now, but you must do the above. Thanks, Phil! I've opened RFS bug #1075734 as advised. > [SNIP] > > Regards > > Phil > > -- > > Internet Relay Chat (IRC): kathenas > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg
Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "mangl": * Package name: mangl Version : 1.1.5-1 Upstream Author : Ziga Lenarcic * URL : https://github.com/zigalenarcic/mangl * License : BSD-2-Clause * Vcs : https://salsa.debian.org/monty/mangl Section : utils The source builds the following binary packages: mangl - Graphical man page viewer based on the mandoc library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mangl/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mangl/mangl_1.1.5-1.dsc Changes for the initial release: mangl (1.1.5-1) unstable; urgency=medium . * Initial packaging (Closes: #1070171 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070171>) * Change distribution to unstable for upload. Regards, -- James Montgomery
Bug#1075725: UDD/dmd: Make the header row of tables sticky/fixed
Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: udd
The todolist and dmddetails tables can be quite long, which makes it
difficult to keep track of what data each column is displaying. It would
be useful if the header row could be made sticky so it stays visible
when scrolling through the table.
The tables are using datatables[0] to format the data. It has an
extension called FixedHeader[1] which supports adding this
functionality.
[0]: https://datatables.net/
[1]: https://datatables.net/extensions/fixedheader/
I tested locally by downloading a new bundled datatables.css /
datatables.jss with fixedheader included and adjusting the dmd template
and javascript with the attached patch.
It does work nicely with the todolist table, but I think the colspan /
rowspan in the dmddetails table throws off the sizing of the header when
it becomes sticky. The header cells become larger and then don't align
with the actual columns of the table.
It would be nice if someone who understands web stuff better could turn
this a functional patch.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
diff --git i/web/js/dmd.js w/web/js/dmd.js
index 4925098..2fb12bf 100644
--- i/web/js/dmd.js
+++ w/web/js/dmd.js
@@ -32,7 +32,8 @@ $(document).ready(function() {
$('#todolist').DataTable( {
"paging": false,
-"info": false
+"info": false,
+ fixedHeader: true,
});
var dmddetails = $('#dmddetails').DataTable( {
@@ -40,6 +41,7 @@ var dmddetails = $('#dmddetails').DataTable( {
"paging": false,
"info": false,
"autoWidth": false,
+ fixedHeader: true,
stateSave: true,
buttons: [ {
extend: 'colvis',
diff --git i/web/templates/dmd.erb w/web/templates/dmd.erb
index 44997c0..45519b3 100644
--- i/web/templates/dmd.erb
+++ w/web/templates/dmd.erb
@@ -2,9 +2,7 @@
-
-
-
+
Debian Maintainer Dashboard
@@ -382,14 +380,10 @@
-
-
-
+
-
-
Bug#1070171: RFS: mangl/1.1.5-1 [ITP: #1070171] -- Graphical man page viewer
Dear mentors, After cleaning up some novice duplicate bug mistakes ... I am looking for a sponsor for my package "mangl": * Package name: mangl Version : 1.1.5-1 Upstream Author : Ziga Lenarcic * URL : https://github.com/zigalenarcic/mangl * License : BSD-2-Clause * Vcs : https://salsa.debian.org/monty/mangl Section : utils The source builds the following binary packages: mangl - Graphical man page viewer based on the mandoc library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mangl/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mangl/mangl_1.1.5-1.dsc Changes for the initial release: mangl (1.1.5-1) unstable; urgency=medium . * Initial packaging (Closes: #1070171) * Change distribution to unstable for upload. Regards, -- James Montgomery >
Bug#1070171: RFS: mangl/1.1.5-1 [ITP: #1070171] -- Graphical man page viewer
Dear mentors, After cleaning up some novice duplicate bug mistakes ... I am looking for a sponsor for my package "mangl": * Package name: mangl Version : 1.1.5-1 Upstream Author : Ziga Lenarcic * URL : https://github.com/zigalenarcic/mangl * License : BSD-2-Clause * Vcs : https://salsa.debian.org/monty/mangl Section : utils The source builds the following binary packages: mangl - Graphical man page viewer based on the mandoc library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mangl/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mangl/mangl_1.1.5-1.dsc Changes for the initial release: mangl (1.1.5-1) unstable; urgency=medium . * Initial packaging (Closes: #1070171) * Change distribution to unstable for upload. Regards, -- James Montgomery
Bug#1074777: RFS: mangl/1.1.5-1 [ITP: #1074594] -- Graphical man page viewer
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "mangl": * Package name: mangl Version : 1.1.5-1 Upstream Author : Ziga Lenarcic * URL : https://github.com/zigalenarcic/mangl * License : BSD-2-Clause * Vcs : https://salsa.debian.org/monty/mangl Section : utils The source builds the following binary packages: mangl - Graphical man page viewer based on the mandoc library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mangl/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mangl/mangl_1.1.5-1.dsc Changes for the initial release: mangl (1.1.5-1) unstable; urgency=medium . * Initial packaging (Closes: #1070171) * Change distribution to unstable for upload. Regards, -- James Montgomery
Bug#1074594: Info received (Bug#1074594: Acknowledgement (ITP: mangl - a graphical man page viewer that uses OpenGL with GLFW to display man pages with clickable hyperlinks and smooth scrolling.))
Hi there, please disregard my previous inquiry; I see how this works now. Done status is an acknowledgment and keeps the house tidy. :)
Bug#1074594: Acknowledgement (ITP: mangl - a graphical man page viewer that uses OpenGL with GLFW to display man pages with clickable hyperlinks and smooth scrolling.)
Hi, Just wondering why this was marked as closed when 1070171 <1070...@bugs.debian.org> RFP is still open. I’ve got the packaging work underway on Salsa. Accidental? Kind regards, James On Mon, Jul 1, 2024 at 2:27 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1074594: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074594. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > w...@debian.org > Your Name > > If you wish to submit further information on this problem, please > send it to 1074...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1074594: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074594 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#1074594: ITP: mangl - a graphical man page viewer that uses OpenGL with GLFW to display man pages with clickable hyperlinks and smooth scrolling.
Package: wnpp Severity: wishlist Owner: Your Name * Package name: mangl Version : 0.1 Upstream Author : Ziga Lenarcic * URL : https://github.com/zigalenarcic/mangl * License : BSD 2-Clause Programming Lang: C Description : Graphical man page viewer based on the mandoc library Mangl is a graphical man page viewer that uses OpenGL with GLFW to display man pages with clickable hyperlinks and smooth scrolling. Features include searching of man pages, hyperlinks to other man pages, colored text, truetype support, draggable scrollbar, and keyboard and mouse interaction. The package includes: - Searching of man pages - Hyperlinks to other man pages - Search within a man page - Browsing history - Colored text - Truetype support - Draggable scrollbar - Keyboard and mouse interaction This ITP is related to the original bug request for packaging mangl: #1070171.
Bug#1074520: libuchardet-dev: Newer upstream version (version number unchanged) available
Control: tags -1 moreinfo Hi, On 30/06/2024 11:51, Urs Janßen wrote: > Package: libuchardet-dev > Version: 0.0.8-1 > Severity: wishlist > > A new "upstream version" is available with a new API > deprecating uchardet_get_charset() in favour of > chardet_get_n_candidates() and uchardet_get_encoding() > > The version number was not yet increased :( > > See > https://gitlab.freedesktop.org/uchardet/uchardet/-/commit/8118133e0017c4e1b3ddc9fad104c0ba19692cd7 > https://gitlab.freedesktop.org/uchardet/uchardet/-/commit/5a949265d577ccfbaef7bca01ad875b2aa84eace > https://gitlab.freedesktop.org/uchardet/uchardet/-/commit/669ede73a3473bab7fea4d01f093bb273a5430af > https://gitlab.freedesktop.org/uchardet/uchardet/-/commit/908f9b8ba776d21cd6e0b0b836014dd212f9a12f I don't think these count as a new upstream version. They are commits applied to the development branch but no tag or any "release" has been made. I don't think it's a good idea to upload these to Debian until there's a release - especially when there are API changes that upstream could potentially revert before a release. If you want to see these changes in Debian then the best way is try to persuade upstream to do a proper "0.0.9" release, then I will happily update the package. James
Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package
Thank you Matthijs!
Bug#1074281: netavark: Drop unnecessary librust-simple-error-dev Build-Depends
Source: netavark Version: 1.4.0-4.1 Severity: normal Netavark added their own error handling in https://salsa.debian.org/debian/netavark/-/commit/6b42eb36ce3c05d17ab88601391e0c9d90be08d6 so this Build-Depends is obsolete. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT) 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) LSM: AppArmor: enabled -- no debconf information
Bug#1074092: vim: Annoying visual bell in insert mode when pageing after upgrade to trixie
On Sun, Jun 23, 2024 at 08:37:59AM GMT, Helge Kreutzmann wrote: > Up until bookworm no visual bell was shown in vim on the console > with my configuration. Now in insert mode (only), when paging an annoying > visual > bell is shown. > > This is *not* occuring with --clean but from the Debian changes I > could not derive which settings fault it is. I would suggest first comparing the output of ":set" with "vim --clean" and "vim". That should help narrow down which options differ from the defaults and may affect this behavior. > As this is a (minor) regression, I'm reporting this. And if you have > any suggestion how to find out which setting this causes (except for > bisecting) I would be happy :-)) You could bisect your config by placing the "finish" command in your vimrc at various points to see what introduces the behavior. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1073451: wlgreet: FTBFS: unsatisfiable build-dependency: librust-smithay-client-toolkit-dev (< 0.17~) but 0.18.1-1 is to be installed
On Sun, Jun 16, 2024 at 03:17:54PM GMT, Lucas Nussbaum wrote: > Relevant part (hopefully): > > +--+ > > | Install package build dependencies > >| > > +--+ > > > > > > Setup apt archive > > - > > > > Merged Build-Depends: debhelper-compat (= 13), dh-cargo, > > librust-smithay-client-toolkit-dev (>= 0.16.1~), > > librust-smithay-client-toolkit-dev (<< 0.17~), librust-rusttype-dev (>= > > 0.9.2), librust-chrono-dev (>= 0.4), librust-nix-dev (>= 0.15), > > librust-memmap2-dev (>= 0.3), librust-os-pipe-dev (>= 0.8), > > librust-wayland-client-0.29-dev, librust-wayland-protocols-0.29-dev, > > librust-lazy-static-dev (>= 1.4), librust-serde-derive-dev (>= 1.0), > > librust-greetd-ipc+thiserror-dev (>= 0.10), librust-getopts-dev (>= 0.2), > > librust-toml-dev (>= 0.5), pkgconf, dh-exec, build-essential, fakeroot > > Filtered Build-Depends: debhelper-compat (= 13), dh-cargo, > > librust-smithay-client-toolkit-dev (>= 0.16.1~), > > librust-smithay-client-toolkit-dev (<< 0.17~), librust-rusttype-dev (>= > > 0.9.2), librust-chrono-dev (>= 0.4), librust-nix-dev (>= 0.15), > > librust-memmap2-dev (>= 0.3), librust-os-pipe-dev (>= 0.8), > > librust-wayland-client-0.29-dev, librust-wayland-protocols-0.29-dev, > > librust-lazy-static-dev (>= 1.4), librust-serde-derive-dev (>= 1.0), > > librust-greetd-ipc+thiserror-dev (>= 0.10), librust-getopts-dev (>= 0.2), > > librust-toml-dev (>= 0.5), pkgconf, dh-exec, build-essential, fakeroot > > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in > > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. > > Ign:1 copy:/<>/apt_archive ./ InRelease > > Get:2 copy:/<>/apt_archive ./ Release [615 B] > > Ign:3 copy:/<>/apt_archive ./ Release.gpg > > Get:4 copy:/<>/apt_archive ./ Sources [1129 B] > > Get:5 copy:/<>/apt_archive ./ Packages [1162 B] > > Fetched 2906 B in 0s (0 B/s) > > Reading package lists... > > Reading package lists... > > > > Install main build dependencies (apt-based resolver) > > > > > > Installing build dependencies > > Reading package lists... > > Building dependency tree... > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > sbuild-build-depends-main-dummy : Depends: > > librust-smithay-client-toolkit-dev (< 0.17~) but 0.18.1-1 is to be installed > > E: Unable to correct problems, you have held broken packages. > > apt-get failed. I've uploaded rust-smithay-client-toolkit-0.16 to NEW, which will address this until wlgreet can be ported to newer versions. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1073039: transition: libqalculate
Package: release.debian.org Severity: normal X-Debbugs-Cc: libqalcul...@packages.debian.org, j...@debian.org Control: affects -1 + src:libqalculate User: release.debian@packages.debian.org Usertags: transition Hello release team, I'm requesting a slot for the libqalculate 5.x transition. This upstream major release bumps the SONAME from 22 to 23. I've rebuilt all reverse dependencies in a chroot locally. These all work fine: - cantor 4:22.12.3-1.1 - plasma-workspace 4:5.27.11.1-1 - step 4:22.12.3-1 qalculate-gtk (from the same upstream) needs to be updated to the latest v5.1.0 to build correctly. I can upload this to experimental as well if it's helpful, or upload the new libqalculate + qalculate-gtk to unstable together - let me know what you prefer. Ben file: title = "libqalculate"; is_affected = .depends ~ "libqalculate22t64" | .depends ~ "libqalculate23"; is_good = .depends ~ "libqalculate23"; is_bad = .depends ~ "libqalculate22t64"; (This is my first library transition, please let me know if I've missed anything!) Best, James
Bug#1072766: rust-alacritty: FTBFS: unsatisfiable build-dependencies
On Fri, Jun 07, 2024 at 05:23:32PM GMT, Santiago Vila wrote: > > [...] > Install main build dependencies (apt-based resolver) > > > Installing build dependencies > Reading package lists... > Building dependency tree... > Reading state information... > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > sbuild-build-depends-main-dummy : Depends: librust-copypasta-0.8+wayland-dev > (>= 0.8.1-~~) but it is not installable >Depends: librust-copypasta-0.8+x11-dev (>= > 0.8.1-~~) but it is not installable >Depends: librust-copypasta-0.8-dev (>= > 0.8.1-~~) but it is not installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. > E: Package installation failed > Not removing build depends: cloned chroot in use > > I missed this relationship when updating copypasta. Rather than fix this directly in unstable's current alacritty package, I'm going to finish the work to get the version in experimental uploaded to unstable. This will address the issue, since experimental's alacritty uses copypasta 0.10. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1072839: rust-linemux: Upcoming rust-notify transition (5.x -> 6.x)
Source: rust-linemux Version: 0.3.0-5 Severity: normal rust-notify 6.x is in experimental. I plan on uploading it to unstable soon. Upstream made a no-change bump to 6.x, so it looks like debian/control just needs to be adjusted to accept a broader version range. https://github.com/jmagnuson/linemux/pull/68 -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT) 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) LSM: AppArmor: enabled
Bug#1072834: between: Game no longer works due to server error
Package: between Version: 6+dfsg1-4 Severity: grave Tags: upstream Justification: renders package unusable X-Debbugs-Cc: jvalle...@mailbox.org Dear Maintainer, * What led up to the situation? I installed between and tried to run it. * What exactly did you do (or not do) that was effective (or ineffective)? Run the "between" program. * What was the outcome of this action? The following is printed in the terminal: Screen dimensions for fullscreen mode: 640x480 L4 | Sat Jun 8 11:19:18 2024 (506 ms) | general | Checking if requested video mode (640x480) is available L4 | Sat Jun 8 11:19:18 2024 (506 ms) | general | All resolutions available Max note length in song = 16 Response: 301 Moved Permanently 301 Moved Permanently cloudflare The game window opens and shows the title screen. When I press spacebar, it shows "Locating server..." for a second, and then shows the message "ERROR: Badly formatted response from server." (see attachment). There is no way to continue after this point, except to close the window. * What outcome did you expect instead? The game would be playable. It seems to depend on a server that no longer exists. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (100, 'bookworm-fasttrack') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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) LSM: AppArmor: enabled Versions of packages between depends on: ii libc6 2.36-9+deb12u7 ii libgcc-s1 12.2.0-14 ii libgl1 1.6.0-1 ii libglu1-mesa [libglu1] 9.0.2-1.1 ii libsdl1.2debian 1.2.15+dfsg2-8 ii libstdc++6 12.2.0-14 between recommends no packages. between suggests no packages. -- no debconf information OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#963688: neovim-qt: please make the build reproducible
On Thu, Jun 06, 2024 at 11:16:10AM -0700, Vagrant Cascadian wrote: > On 2020-06-25, Chris Lamb wrote: > > This is because it embeds the CFLAGS (via CMAKE_CXX_FLAGS) in an > > "About" dialogue, and this environment variable contains the build > > path via -ffile-prefix-map etc. > > This is still relevent, although tests.reproducible-builds.org no longer > tests varied build paths. I've raised the issue with upstream. I'd prefer not to carry a patch, especially if it's not actually affecting reproducible testing. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1072659: Please update snac2 to the latest upstream version
Hi, On 6/5/24 8:31 PM, Sergio Durigan Junior wrote: Source: snac2 Version: 2.51-1 Severity: wishlist Hi! First of all, thanks for packaging snac2. Upstream has recently released version 2.53, which implements some new and interesting features like search by content. If you're OK with it, I'd like to start helping with the package and as such I could prepare an update and upload it. Otherwise, I'd be happy to file an MR. Sounds good! Feel free to add yourself as an uploader, and push your changes directly to the Salsa repo. -- James
Bug#1070689: transition: msgpack-c
On Tue, Jun 04, 2024 at 06:44:36AM -0400, James McCoy wrote: > On Tue, Jun 04, 2024 at 09:27:28AM +0200, Emilio Pozuelo Monfort wrote: > > On 03/06/2024 03:25, James McCoy wrote: > > > On Sun, Jun 02, 2024 at 07:23:39PM -0400, James McCoy wrote: > > > > I know libdata-messagepack-stream-perl and tmate already have fixes > > > > sitting in the Vcs. The other two are straight forward fixes that I > > > > should be able to NMU in the next couple days. > > > > > > Also, binNMUs should use "--add-depends 'libmsgpack-c-dev (>= 6)'" to > > > ensure they rebuild with the new package. > > > > Can you instead provide a transitional package? That will help with the > > rdeps and especially with the reverse build-depends. Effectively once > > libmsgpack-dev is decrufted, those rdeps will be RC-buggy as they > > build-depend on a virtual package. > > ACK. Will do that ASAP. New msgpack-c with the transitional package is uploaded, as well as fixes for all the rdeps that FTBFS. Just binNMUs should be left. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1069527: libchdr: FTBFS on armhf: libchdr_chd.c:3001:39: error: implicit declaration of function ‘ftello64’; did you mean ‘ftello’? [-Werror=implicit-function-declaration]
Upstream is currently working on this. For the time being adding -D_LARGEFILE64_SOURCE fixes this bug David JamesFrom 9b718bbf7f94899e7643563e9f30a6665d1e8b39 Mon Sep 17 00:00:00 2001 From: Castor216 Date: Tue, 4 Jun 2024 19:22:49 +0100 Subject: [PATCH] add -D_LARGEFILE64_SOURCE to CFLAGS --- debian/rules | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/rules b/debian/rules index 6a8b36d..841dca3 100755 --- a/debian/rules +++ b/debian/rules @@ -1,5 +1,6 @@ #!/usr/bin/make -f export DEB_BUILD_MAINT_OPTIONS = hardening=+all +export DEB_CFLAGS_MAINT_APPEND = -D_LARGEFILE64_SOURCE %: dh $@ -- 2.43.0
Bug#1070689: transition: msgpack-c
On Tue, Jun 04, 2024 at 09:27:28AM +0200, Emilio Pozuelo Monfort wrote: > On 03/06/2024 03:25, James McCoy wrote: > > On Sun, Jun 02, 2024 at 07:23:39PM -0400, James McCoy wrote: > > > I know libdata-messagepack-stream-perl and tmate already have fixes > > > sitting in the Vcs. The other two are straight forward fixes that I > > > should be able to NMU in the next couple days. > > > > Also, binNMUs should use "--add-depends 'libmsgpack-c-dev (>= 6)'" to > > ensure they rebuild with the new package. > > Can you instead provide a transitional package? That will help with the > rdeps and especially with the reverse build-depends. Effectively once > libmsgpack-dev is decrufted, those rdeps will be RC-buggy as they > build-depend on a virtual package. ACK. Will do that ASAP. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1070689: transition: msgpack-c
On Sun, Jun 02, 2024 at 07:23:39PM -0400, James McCoy wrote: > I know libdata-messagepack-stream-perl and tmate already have fixes > sitting in the Vcs. The other two are straight forward fixes that I > should be able to NMU in the next couple days. Also, binNMUs should use "--add-depends 'libmsgpack-c-dev (>= 6)'" to ensure they rebuild with the new package. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1070689: transition: msgpack-c
On Sun, Jun 02, 2024 at 01:11:06PM +0200, Sebastian Ramacher wrote: > On 2024-05-07 06:26:04 -0400, James McCoy wrote: > > The following build dependencies will need fixes to build against the > > new msgpack-c version: > > > > * libdata-messagepack-stream-perl > > * tmate > > * tmate-ssh-server > > * webdis > > > > This is just related to how the packages detect whether msgpack is > > available, since the APIs/ABIs themselves did not change. > > Assuming that bugs have been filed for those packages, please go ahead. Yes, the bugs were filed and marked as blocking this bug. I've uploaded and upgraded the severity of those bugs to serious. I know libdata-messagepack-stream-perl and tmate already have fixes sitting in the Vcs. The other two are straight forward fixes that I should be able to NMU in the next couple days. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1072117: /usr/bin/keepassxc: KeePassXC stores its .lock/.socket file in /tmp
On Tue, May 28, 2024 at 04:25:54PM -0400, James McCoy wrote: > Especially given the recent change to have automated cleaning of /tmp at > runtime, keepassxc shouldn't be using /tmp to store these files. > > They should probably be under $XDG_RUNTIME_DIR. Until/unless this is resolved upstream, maybe it's a good idea to add a tmpfiles.d drop-in config x /tmp/keepassxc-*.lock x /tmp/keepassxc-*.socket Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1072225: nut-server.service fails to start if host is on DHCP
Package: nut-server Version: 2.8.0-7 Severity: normal I was puzzled that nut-server.service was not starting on my workstation. I had installed it to use with HomeAssistant. I tracked it down to the service file not requiring network-online.target, but only network.target. I replaced all the instances of network.target with network-online.target and now the nut server starts correctly every time. I checked nut-server_2.8.1-3.1+b1_amd64.deb and nut-server.service still only uses network-online.target This may slow some installations that have static IP assignments. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nut-server depends on: ii adduser 3.134 ii init-system-helpers 1.65.2 ii libc6 2.36-9+deb12u7 ii libnspr4 2:4.35-1 ii libnss3 2:3.87.1-1 ii libnutscan2 2.8.0-7 ii libupsclient6 2.8.0-7 ii libusb-1.0-0 2:1.0.26-1 ii libwrap0 7.6.q-32 ii lsb-base 11.6 ii nut-client 2.8.0-7 ii sysvinit-utils [lsb-base] 3.06-4 ii udev 252.22-1~deb12u1 nut-server recommends no packages. Versions of packages nut-server suggests: pn nut-cgi pn nut-i2c pn nut-ipmi pn nut-modbus pn nut-snmp pn nut-xml -- Configuration Files: /etc/nut/ups.conf [Errno 13] Permission denied: '/etc/nut/ups.conf' /etc/nut/upsd.conf [Errno 13] Permission denied: '/etc/nut/upsd.conf' /etc/nut/upsd.users [Errno 13] Permission denied: '/etc/nut/upsd.users' -- no debconf information
Bug#1072117: /usr/bin/keepassxc: KeePassXC stores its .lock/.socket file in /tmp
Package: keepassxc-full Version: 2.7.7+dfsg.1-3 Severity: important File: /usr/bin/keepassxc Especially given the recent change to have automated cleaning of /tmp at runtime, keepassxc shouldn't be using /tmp to store these files. They should probably be under $XDG_RUNTIME_DIR. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT) 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) LSM: AppArmor: enabled Versions of packages keepassxc-full depends on: ii libargon2-1 0~20190702+dfsg-4+b1 ii libbotan-2-19 2.19.4+dfsg-1 ii libc6 2.38-11 ii libgcc-s1 14.1.0-1 ii libminizip1t641:1.3.dfsg+really1.3.1-1 ii libpcsclite1 2.2.3-1 ii libqrencode4 4.1.1-1+b2 ii libqt5concurrent5t64 5.15.13+dfsg-2 ii libqt5core5t645.15.13+dfsg-2 ii libqt5dbus5t645.15.13+dfsg-2 ii libqt5gui5t64 5.15.13+dfsg-2 ii libqt5network5t64 5.15.13+dfsg-2 ii libqt5svg55.15.13-2 ii libqt5widgets5t64 5.15.13+dfsg-2 ii libqt5x11extras5 5.15.13-2 ii libreadline8t64 8.2-4 ii libstdc++614.1.0-1 ii libusb-1.0-0 2:1.0.27-1 ii libx11-6 2:1.8.7-1+b1 ii libxtst6 2:1.2.3-1.1+b1 ii libzxcvbn02.5+dfsg-2 ii zlib1g1:1.3.dfsg+really1.3.1-1 Versions of packages keepassxc-full recommends: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 Versions of packages keepassxc-full suggests: ii webext-keepassxc-browser 1.9.0.5+repack1-1 ii xclip 0.13-4 -- no debconf information
Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.
> Please talk to us, how we can help in making DOSBox Staging packaged > on Debian? > Cheers, > Patryk Obara Dear Patryk, I am not an expert on Debian Policy, or a Debian Developer, just a passerby who is also interested in getting dosbox-staging into Debian. One issue I can see with porting this package to Debian is that there are a lot of binary blobs in contrib/resources. Debug.com, deltree.com and xcopy.exe are the worst offenders. What are these executables? I see that they are legally redistributable but they also need to be open source and that source needs to be distributed with dosbox and compiled alongside it. I'm also concerned about the CPX/CPI files in freedos-cpi and the SYS files in freedos-keyboard. What are these files? Is there any way to distribute them as source files? Like I said, I am not an expert, so take this with a pinch of salt. I believe that if dosbox-staging was packaged as it is now, it would have to go into the contrib or non-free sections. Of course, it could be packaged without these files present, but I don't know if dosbox will just break without them. Regards, David James
Bug#1072003: ITP: tree-sitter-markdown -- Markdown parser for tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-de...@lists.debian.org Control: block 1071572 by -1 * Package name: tree-sitter-markdown Version : 0.2.3 Upstream Contact: Matthias Deiml * URL : https://github.com/MDeiml/tree-sitter-markdown/ * License : MIT Programming Lang: JavaScript, C, Rust Description : Markdown parser for tree-sitter This package provides a markdown parser for tree-sitter. It's required for the new upstream release of neovim and will be maintained in the tree-sitter team.
Bug#1072002: ITP: tree-sitter-bash -- Bash parser for Tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-de...@lists.debian.org Control: block 1071572 by -1 * Package name: tree-sitter-bash Version : 0.21.0 Upstream Contact: Max Brunsfeld * URL : https://github.com/tree-sitter/tree-sitter-bash/ * License : MIT Programming Lang: JavaScript, C, Rust Description : Bash parser for Tree-sitter This package provides a bash parser for tree-sitter. It's required for the new upstream release of neovim and will be maintained in the tree-sitter team.
Bug#1072001: ITP: tree-sitter-python -- Python parser for Tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-de...@lists.debian.org Control: block 1071572 by -1 * Package name: tree-sitter-python Version : 0.21.0 Upstream Contact: Max Brunsfeld * URL : https://github.com/tree-sitter/tree-sitter-python/ * License : MIT Programming Lang: JavaScript, C, Rust Description : Python parser for Tree-sitter This package provides a Python 2/3 parser for tree-sitter. It's required for the new upstream release of neovim and will be maintained in the tree-sitter team.
Bug#1070691: tmate-ssh-server: FTBFS with msgpack-c 6.x
Control: tag -1 patch
On Tue, May 07, 2024 at 06:28:00AM -0400, James McCoy wrote:
> tmate-ssh-server FTBFS with the 6.x version of the msgpack C library.
> Upstream renamed the library from libmsgpackc to libmsgpack-c and the
> pkg-config file from msgpack.pc to msgpack-c.pc, so any checks for
> the presence of the library at build time should handle both names.
Attached patch, ported from tmate, enables building against either
version of msgpack-c.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Description: Fix building with msgpack-c 6.x
The msgpack-c project changed the library name from msgpackc to msgpack-c
in the 6.0.0 release. Update configure.ac to detect the library both
pre- and post-rename.
Bug: https://github.com/tmate-io/tmate-ssh-server/issues/108
Forwarded: not-needed
---
--- a/configure.ac
+++ b/configure.ac
@@ -199,7 +199,18 @@ PKG_CHECK_MODULES(
LIBS="$MSGPACK_LIBS $LIBS"
found_msgpack=yes
],
- found_msgpack=no
+ [
+PKG_CHECK_MODULES(
+ MSGPACKC,
+ msgpack-c >= 6.0.0,
+ [
+CPPFLAGS="$MSGPACKC_CFLAGS $CPPFLAGS"
+LIBS="$MSGPACKC_LIBS $LIBS"
+found_msgpack=yes
+ ],
+ found_msgpack=no
+)
+ ]
)
if test "x$found_msgpack" = xno; then
AC_MSG_ERROR("msgpack >= 1.2.0 not found")
Bug#1071573: Status of libnet-ssl-expiredate-perl
On 27/05/24 5:23 pm, Andrius Merkys wrote: Control: owner -1 ! Hello, It is quite important to me to get libnet-ssl-expiredate-perl done ASAP. Thus if you do not have any objections, I am going to finalize it. Andrius hi Andrius sorry for my late reply and no objections from me!
Bug#1071335: upstream commits
You may be interested in these upstream commits;
b01478d ("Fix some parts of macro expansion are not guarded")
0194b80 ("strerror and memset require string.h")
Bug#1069693: ppp >=2.5.0 breaks network-manager-fortisslvpn
Control: tags -1 patch upstream
Hi,
On Sat, 11 May 2024 00:58:03 +0200 Maurizio Avogadro
wrote:
> Some more info gathered this afternoon.
>
> It seems that network-manager-fortisslvpn also makes a mess with the routing
> table after the connection has been established.
>
> I could easily get a working VPN by adding
>
> ipcp-accept-remote
>
> to /etc/ppp/options and manually launching openfortivpn; such setting also
> allowed NetworkManager to accept the IP address supplied by the counterpart
> (it
> was the default until ppp v2.4.9), but in this case the connection didn't
> work
> until I deleted a rule in the routing table which routed the IP address of
> the
> remote gateway through the ppp0 interface (!).
>
> A duplicate default route through the main physical network interface was
> created too and the spawned pppd process didn't exit after the connection has
> been terminated and had to be killed manually: none of these issues happened
> when openfortivpn was launched manually.
I also did a little investigation yesterday on this as well as #1070343.
There are many upstream issues in both the openfortivpn GitHub and
network-manager Gitlab instances related to this.
To sum up what I think is happening (gathered from various issues):
* During PPP IPCP negotiation the Fortinet server requests it's link IP
address to be the same as it's public IP address. This doesn't make any
sense to me - the link address inside the PPP session should be a
private 10.x address. Maybe there's some reason it does this that I
don't understand...
* pppd configures this address on the ppp device using the
SIOCSIFDSTADDR ioctl. The kernel internally adds a route to the routing
table because it knows it can use this link to get to that IP (lol).
* Pre ppp-2.4 this didn't matter because pppd forcefully used the
address supplied on the command line which is a 169.x address. In this
case the kernel adds a route to a dummy IP which didn't affect anything.
* ppp-2.5 started enforcing the remote IP on the command line matched
the IP sent over IPCP. This initially broke negotiation until
"ipcp-accept-remote" was added, but this option breaks things in another
way by allowing pppd to configure the server supplied IP as the peer
address in the kernel and create a bad route.
* openfortivpn has a hack to workaround this - after pppd is up it
manually removes the route from the routing table. The network-manager
plugin doesn't do this.
I ended up writing a patch which does something similar in the
network-manager plugin - it manually invokes the SIOCSIFDSTADDR ioctl on
the ppp device to switch the peer address to a new fake address. This
seems to work to remove the bad route. Doing this feels really hacky
though and I'm kind of hesitant to upload it unless approved by upstream!
Note if you're testing this patch, you also need the fix for #1070343 in
openfortivpn as well to make it work (or manually set ipcp-accept-remote).
Having done this I'm very tempted to just switch to OpenConnect which
seems to work ok. It has its own ppp implementation which doesn't seem
to set the peer address in the kernel at all (and may just ignore the
server's IPCP requests - I have not checked) and so avoids these issues.
JamesFrom 416b65c3f23d795707ed122f06c54eebd515bc3b Mon Sep 17 00:00:00 2001
From: James Cowgill
Date: Sat, 11 May 2024 13:59:17 +0100
Subject: [PATCH] Modify PPP peer address to avoid wrong route
---
src/nm-fortisslvpn-service.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/nm-fortisslvpn-service.c b/src/nm-fortisslvpn-service.c
index e4433d5..cdfada4 100644
--- a/src/nm-fortisslvpn-service.c
+++ b/src/nm-fortisslvpn-service.c
@@ -37,6 +37,11 @@
#include
#include
+#include
+#include
+#include
+#include
+
#include
#include "nm-fortissl-properties.h"
@@ -313,14 +318,39 @@ handle_set_state (NMDBusFortisslvpnPpp *object,
return TRUE;
}
+static void
+hack_ppp_peer(const char *tundev)
+{
+ struct ifreq req;
+ int fd, ret;
+
+ _LOGI ("FORTISSLVPN Modifying PPP peer address to avoid incorrect host route");
+
+ memset(, 0, sizeof(req));
+ strlcpy(req.ifr_name, tundev, sizeof(req.ifr_name));
+ req.ifr_dstaddr.sa_family = AF_INET;
+ inet_aton("169.254.0.1", &((struct sockaddr_in*)(_dstaddr))->sin_addr);
+
+ fd = socket(AF_INET, SOCK_STREAM, 0);
+ ret = ioctl(fd, SIOCSIFDSTADDR, );
+ if (ret)
+ _LOGW ("FORTISSLVPN Failed to set PPP peer address, errno = %d", errno);
+ close(fd);
+}
+
static gboolean
handle_set_ip4_config (NMDBusFortisslvpnPpp *object,
GDBusMethodInvocation *invocation,
GVariant *arg_config,
gpointer user_data)
{
+ const char *tundev;
+
_LOGI ("FORTISSLVPN service (IP Config Get) reply received.");
+ if (g_variant_lookup(arg_config, NM_
Bug#1069743: Removal of features from default keepassxc package
Hi, Chiming in as another regular keepassxc user. When I first saw the keepassxc / keepassxc-full split I did not think much of it. But reading the comments on the upstream issue has gotten me frustrated. Please consider resolving this in a way that doesn't break existing installations. It's easy to catch these changes when they're presented one-by-one when upgrading e.g. a system running testing regularly, but they're far more likely to miss when dozens of packages update all at once with the next stable release. Either the minimal package should only be applied as default for new installations, or the minimal package should explicitly warn when attempting to use a feature that's unavailable. The second part I take issue with is the wording with which this is being communicated. There is no need to use charged terminology like "feature creep"[1], "crappy version"[2], or "use at your own risk"[3] when describing variants. This reads as disrespectful to both upstream and the userbase at large - let people decide for themselves what features are useful instead of dismissing their use-case outright. [1]: https://salsa.debian.org/debian/keepassxc/-/blob/main/debian/NEWS?ref_type=heads [2]: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817 [3]: https://salsa.debian.org/debian/keepassxc/-/blob/main/debian/control?ref_type=heads#L76-78 Best, James OpenPGP_0x2EC3F60DE71C0B9D.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064648: allegro5-doc: please make the build reproducible.
Hi Andreas, On Thu, 9 May 2024 at 11:17, Andreas Rönnquist wrote: > > Those fixes was obviously not enough, just see the repro reports. Ok, yep - thanks for checking those. When I check the reports, most of the remaining problems seem to relate to duplicate definitions appearing in the documentation (for example, a definition for "al_color_cmyk" appearing twice). > The strange thing is that it according to the tests does seem to build > reproducible on arm64... Puzzling indeed. I'll have another read through the codebase soon. > One other detail is that on armhf the only change seems to be the > architecture which is included in the ALLEGRO_PKG_HOST_SYSTEM variable. > > Is there some magic like SOURCE_DATE_EPOCH to use that would avoid this > problem in this case? Not as far as I'm aware, no - for SOURCE_DATE_EPOCH, there is a range of possible integer values that are all equally valid, so it's straightforward to select one to make a package build reproducible. Specifiying an arbitrary but static architecture could be at-least challenging, and at-worst misleading or potentially compatibility-breaking. In this kind of situation I'd generally recommend working backwards to figure out whether -- and if so, how -- the nondeterministic value is used. I didn't find any search results for ALLEGRO_PKG_HOST_SYSTEM in Debian codesearch[1], so I'd recommend a reprotest build after removing it to see whether that succeeds (I'll try this soon). Regards, James [1] - https://codesearch.debian.net/search?q=ALLEGRO_PKG_HOST_SYSTEM [2] - https://salsa.debian.org/reproducible-builds/reprotest
Bug#1070343: openfortivpn: Should not be built with --enable-legacy-pppd with ppp 2.5
Control: retitle -1 openfortivpn: Should not be built with --enable-legacy-pppd with ppp 2.5 Hi, I also encountered this bug as relating to pppd-accept-remote. It happens because the Debian package is built with --enable-legacy-pppd which was needed with ppp 2.4 but now needs removing since ppp has been updated to 2.5 in Debian. Also adding Depends: ppp (>= 2.5) for good measure seems like a good idea after. After doing both of those and rebuilding openfortivpn my existing config works again. James
Bug#1070785: libsnappy-dev: Ambiguity in Compress method signatures causes FTBFS in ceph
Package: libsnappy-dev Version: 1.2.0-2 Severity: important Tags: ftbfs X-Debbugs-Cc: james.p...@ubuntu.com Dear Maintainer, The patch added to restore older API signatures to resolve Bug 1070217 creates ambiguity in the method signatures resulting in FTBFS in at least the ceph package: In file included from /<>/src/compressor/snappy/CompressionPluginSnappy.h:20, from /<>/src/compressor/snappy/CompressionPluginSnappy.cc:20: /<>/src/compressor/snappy/SnappyCompressor.h: In member function ‘virtual int SnappyCompressor::compress(const ceph::bufferlist&, ceph::bufferlist&, std::optional&)’: /<>/src/compressor/snappy/SnappyCompressor.h:68:21: error: call of overloaded ‘Compress(BufferlistSource*, snappy::UncheckedByteArraySink*)’ is ambiguous 68 | snappy::Compress(, ); | ^~~~ In file included from /<>/src/compressor/snappy/SnappyCompressor.h:18: /usr/include/snappy.h:81:10: note: candidate: ‘size_t snappy::Compress(Source*, Sink*)’ 81 | size_t Compress(Source* reader, Sink* writer); | ^~~~ /usr/include/snappy.h:82:10: note: candidate: ‘size_t snappy::Compress(Source*, Sink*, CompressionOptions)’ 82 | size_t Compress(Source* reader, Sink* writer, | ^~~~ make[3]: *** [src/compressor/snappy/CMakeFiles/ceph_snappy.dir/build.make:79: src/compressor/snappy/CMakeFiles/ceph_snappy.dir/CompressionPluginSnappy.cc.o] Error 1 make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:7668: src/compressor/snappy/CMakeFiles/ceph_snappy.dir/all] Error 2 The compression options parameter which was added for >= 1.2 of snappy provides a default, so the added method with no options creates this ambiguity. Thanks! -- System Information: Debian Release: trixie/sid APT prefers oracular APT policy: (500, 'oracular') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.0-31-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsnappy-dev depends on: ii libsnappy1v5 1.2.0-2 libsnappy-dev recommends no packages. libsnappy-dev suggests no packages. -- no debconf information
Bug#1070689: transition: msgpack-c
Package: release.debian.org Severity: normal X-Debbugs-Cc: msgpac...@packages.debian.org Control: affects -1 + src:msgpack-c User: release.debian@packages.debian.org Usertags: transition The msgpack-c upstream renamed their C library from libmsgpackc.so to libmsgpack-c.so. I've renamed the binary packages accordingly (libmsgpack-dev -> libmsgpack-c-dev, libmsgpackc2 -> libmsgpack-c2) and the former "Provides: libmsgpack-dev" to help ease the transition. The following build dependencies will need fixes to build against the new msgpack-c version: * libdata-messagepack-stream-perl * tmate * tmate-ssh-server * webdis This is just related to how the packages detect whether msgpack is available, since the APIs/ABIs themselves did not change. Ben file: title = "msgpack-c"; is_affected = .depends ~ "libmsgpackc2" | .depends ~ "libmsgpack-c2"; is_good = .depends ~ "libmsgpack-c2"; is_bad = .depends ~ "libmsgpackc2";
Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package
Source: openttd Version: 14.0-1 Severity: serious Tags: upstream Justification: Policy 12.5 Control: forwarded -1 https://github.com/OpenTTD/OpenTTD/pull/12603 Dear Maintainer, The build scripts for the initial version 14.0 release of OpenTTD include a CMake file that determines whether and how to add compile-time flags to request that libatomic should be linked. The relevant CMake file addition was sourced[1] from the LLVM codebase, which is licensed under a variant of the Apache 2.0 license with some exception clauses added for the LLVM project. This is not yet documented in the source package. I'm reporting this bug with severity 'serious' because I feel that there is a potential licensing concern here; until that is confirmed one way or the other, I've offered what I believe is a possible resolution (adding the LLVM license -- slightly confusingly _also_ referred to as v14, because that is the version of LLVM where it was introduced, despite v18 being LLVM-current), to upstream[2]. To explain my reasoning: On balance I'd prefer opening a serious-severity bug to prevent migration (that could later be reduced in severity) than to allow the package transition while being aware of a potential problem. Thanks, James [1] - https://github.com/OpenTTD/OpenTTD/pull/10513 [2] - https://github.com/OpenTTD/OpenTTD/pull/12603
Bug#1069996: d2x-rebirth: Static audio during audio playback with SDL_Mixer in Descent 2
I've build the upstream version of the package and can confirm that this issue has been fixed upstream. Can we cut a new package for Debian Trixie?
Bug#1069996: d2x-rebirth: Static audio during audio playback with SDL_Mixer in Descent 2
Package: d2x-rebirth Version: 0.58.1-1.3 Severity: important X-Debbugs-Cc: jcart...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** Installed D2X-XL in /usr/share/games/d2x-rebirth Ran the game normally, get static sounds during mve playback and after each sound effect plays ingame. E.g when shooting weapons. Audio should play without static noise. Using Pipewire for audio. This looks like it might be fixed in upstream. The Debian packages are out of date. 0.61 is the current version in the upstream github repository. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 d2x-rebirth depends on: ii libc6 2.37-18 ii libgl1 1.7.0-1+b1 ii libglu1-mesa [libglu1] 9.0.2-1.1+b1 ii libphysfs1 3.0.2-6+b1 ii libsdl-mixer1.2 1.2.12-17+b3 ii libsdl1.2debian 1.2.68-2 Versions of packages d2x-rebirth recommends: ii freepats 20060219-4 ii timidity 2.14.0-8.1 d2x-rebirth suggests no packages. -- no debconf information
Bug#1069907: dh_apache2: please output reproducible module package pre/post scripts.
Package: apache2-dev Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Control: affects -1 mod-mono Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and noticed recently that an Apache webserver module, mod-mono, that depends[2] on the dh_apache2 debhelper utility from apache2-dev at build-time, failed an automated Debian reproducibility test[3]. The problem appears to be related to the substitution of a NAMES variable that appears in the templated pre/post scripts evaluated by dh_apache2; the templates[4][5][6] are found in the 'apache2' source package. I don't yet know exactly how the non-deterministic ordering of entries in the NAMES variable occurs; however the replacement parameters[7] in the dh_apache2.in script seem relevant, and tracing the creation of those may help. Producing a value for the NAMES variable deterministically should I believe allow the mod-mono package -- and any other Debian Apache module packages that contain more than one named module -- to build reproducibily, in turn enabling consumers of Debian to reliably rebuild a bit-for-bit identical .deb package from source. Regards, James [1] - https://reproducible-builds.org/ [2] - https://sources.debian.org/src/mod-mono/3.8-3/debian/control/#L9 [3] - https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/mod-mono.html [4] - https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/postinst-apache2/ [5] - https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/postrm-apache2/ [6] - https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/prerm-apache2/ [7] - https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/dh_apache2.in/#L551
Bug#1069774: sphinx: tests: skip_tests_network.diff patch can be dropped from v7.3.0 onwards.
Source: sphinx Severity: wishlist Dear Maintainer, The Sphinx v7.3.0 release included a pull request[1] to make the test suite behave more consistently when the network conditions (online/offline) vary between test suite evaluations. One of the changes introduced by that is to replace some remote hyperlinks referenced in the 'tests.test_builders.test_build_latex.test_latex_images' test case with hyperlinks to localhost instead. I believe that this should make it possible to drop 'skip_tests_network.diff' from the Debian sphinx patch series. Thank you, James [1] - https://github.com/sphinx-doc/sphinx/pull/12095
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Ok, that's reasonable. Re: content-negotation: the www FAQ[1] makes me think that, at least currently, it's not worth attempting anything more advanced than language negotiation. Re: file suffixes: after re-reading the Sphinx code and experimenting with a few builds: I'm convinced that the html_file_suffix setting does _not_ help. I couldn't think of a better near-term alternative than using the cron script to adjust the searchindex.js src attribute, similar to the HTML hrefs. I don't really like that, though. And finally, re: other Sphinx-built documentation, I noticed some JavaScript errors for the language chooser in the online HTML developers-reference[2], so I've opened a merge request[3] related to that. It's not directly related here, but I'm mentioning it because the documentation projects share some similarities. [1] - https://www.debian.org/devel/website/desc.en.html#faq [2] - https://www.debian.org/doc/manuals/developers-reference/ [3] - https://salsa.debian.org/debian/developers-reference/-/merge_requests/48
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Wed, 17 Apr 2024 at 21:46, Holger Wansing wrote:
> James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100):
> > The _other_ hyperlinks in the static content are replaced as part of the
> > cronjob[1] - but that doesn't work for items in the searchindex.js file.
> >
> > Fortunately I think there might be a better way to do this. Sphinx itself
> > has
> > an HTML builder option 'html_file_suffix' and I think we could use that
> > instead
> > to define the filenames. That option is respected by the search JavaScript
> > using a template variable[3] in the documentation_options.js file.
>
> I fear I have no idea what to do with these options:
>
> add 'html_file_suffix' in the conf.py: the default value is html here, what
> should I insert here?
A possibility would be to configure it during make, by using something like:
-D html_file_suffix=$*
> in documentation_options.js I have FILE_SUFFIX: '{{ file_suffix }}'; what
> to do with this?
With an html_file_suffix config option, that becomes: FILE_SUFFIX: 'es-ES' (for
example).
> An idea came to mind:
> if we could change the search results, so that they no longer have a file
> extension (say: the link points to 'installing' instead of 'installing.html')
> everything would work fine I guess, since the browser delivers the correct
> language page due to content negotiation according to browser lang settings.
>
>
> I don't know if you thought about such thing, when writing about above html
> build / file suffix options???
> (as already said: I have no clue how the above could change something)
I hadn't considered that approach, but it could make sense since there are
other file formats that we build (text, PDF) and those could also be negotiated
by an HTTP user-agent.
> > We should be careful of other side-effects if making that change, but it
> > would remove a deployment transformation step on the static content, and I
> > think that's beneficial.
> >
> > [1] -
> > https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70
> >
> > [2] -
> > https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix
> >
> > [3] -
> > https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6
> >
>
>
> --
> Holger Wansing
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Wed, 17 Apr 2024 at 19:36, Holger Wansing wrote: > Am 16. April 2024 23:47:05 MESZ schrieb James Addison : > >> I have tried to deal with this by some adaptions in the cronjob - see the > >> first two additions in my patch: change all links to search.html into > >> search.§lang.html, and rename the language-specific searchindex files into > >> searchindex.$lang.js. > >> However, that does not seem to be enough. > > > >When you say it is not enough: could I check what you mean by that? > > I could guess that changings on the Search box are needed, to use > the language-wise correct searchindex. > > But that's too much corrections on the Sphinx-generated result > if you ask me... Some .js files remain static when the source is rebuilt in different languages; however searchindex.js is not one of those files. So it seems that the content to retrieve for it should be negotiated between the client and server too, like the html-suffix files. > And out of my skills, sorry. Identifying and describing the problem is part of the fix; I'll think about it some more but I reckon there's already some relevant information from this discussion to take upstream to Sphinx issue thread(s).
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Tue, 16 Apr 2024 at 22:47, James Addison wrote:> > Thanks Holger, > > On Mon, 15 Apr 2024 at 20:43, Holger Wansing wrote: > > > > Hi, > > > > James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100): > > > From some testing of these: the search results have a problem that they > > > hyperlink to a language-less .html URL, meaning that clicking a result > > > link in > > > the DE-language search results takes the user to a EN-language page. > > > > Yes, good catch. > > However it's even worse: if you view a German page and use the Search > > function, > > the search index for English is used. > > Wait, I'm confused. Not on your site, though. There you have the > per-language > search indices. > > And in fact, when deployed to the debian.org website, requested-language > search > (mapping of the browser language to an appropriate searchindex.*.js > file) could be > (and is already) a better user experience. If you hypothetically send > me a hyperlink > to a policy section auf Deutsch, that's fine, but when I search for > 'configuration' > after reading that, I might want my browser settings to have been respected, > in > terms of what is searched. > > > I have tried to deal with this by some adaptions in the cronjob - see the > > first two additions in my patch: change all links to search.html into > > search.§lang.html, and rename the language-specific searchindex files into > > searchindex.$lang.js. > > However, that does not seem to be enough. > > When you say it is not enough: could I check what you mean by that? > > > > The _other_ hyperlinks in the static content are replaced as part of the > > > cronjob[1] - but that doesn't work for items in the searchindex.js file. > > > > Why is that a problem at all (maybe you know this already): > > since we use content negotiation at Debian website (so the pages are > > delivered in the correct language according to user's browser setting), we > > change the directory structure away from the default how it's build by > > Sphinx: > > after Sphinx' make there are separate directories for every language, > > and they contain everything for that language, including the searchindex.js > > file. And in that structure it works fine. > > On Debian website we put everything in one directory, adding the language > > code into the filename in front of the .html extension. > > While this works fine for static content, it does not for the search > > function here. > > I think this is a reasonable solution; serving the content from a > single directory > is simple and logical because the permissions and content should be the same; > the latter only differs as a result of locale and therefore translation. > > > > Fortunately I think there might be a better way to do this. Sphinx > > > itself has > > > an HTML builder option 'html_file_suffix' and I think we could use that > > > instead > > > to define the filenames. That option is respected by the search > > > JavaScript > > > using a template variable[3] in the documentation_options.js file. > > > > > > We should be careful of other side-effects if making that change, but it > > > would remove a deployment transformation step on the static content, and I > > > think that's beneficial. > > > > I don't understand how that could affect our search function problem, > > but I could give it a try. > > The main change that it would introduce is that the dynamic search results > that > appear in the search results (as gathered by the JavaScript) have > hyperlinks that > include the build-time suffix in the filename. So in the example > above, you have > linked me to a German-language dokumentation page, and when I search from > that page, I find (based on a DE search index) and am linked to (based on DE > file suffixes) Deutsch results; foo.de.html instead of foo.html for example. > > I'm in two minds about this: if my browser settings say that my locale is > en-150 > and I land on a de-DE page, what language should search be performed in, and > what language should the results link to? > > An answer that I find straightforward is that if the page is de-DE -- which > your > hypothetical link to me was -- then because everything on that page _should_ > (with sufficient translation availability) be in German, then I would expect > to > search and be linked to pages accordingly. If you'd linked to a language-less > URL, then that would (a) have been thoughtful if you suspected that I did not > comprehend Deutsch, and (b) a
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Thanks Holger, On Mon, 15 Apr 2024 at 20:43, Holger Wansing wrote: > > Hi, > > James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100): > > From some testing of these: the search results have a problem that they > > hyperlink to a language-less .html URL, meaning that clicking a result link > > in > > the DE-language search results takes the user to a EN-language page. > > Yes, good catch. > However it's even worse: if you view a German page and use the Search > function, > the search index for English is used. Wait, I'm confused. Not on your site, though. There you have the per-language search indices. And in fact, when deployed to the debian.org website, requested-language search (mapping of the browser language to an appropriate searchindex.*.js file) could be (and is already) a better user experience. If you hypothetically send me a hyperlink to a policy section auf Deutsch, that's fine, but when I search for 'configuration' after reading that, I might want my browser settings to have been respected, in terms of what is searched. > I have tried to deal with this by some adaptions in the cronjob - see the > first two additions in my patch: change all links to search.html into > search.§lang.html, and rename the language-specific searchindex files into > searchindex.$lang.js. > However, that does not seem to be enough. When you say it is not enough: could I check what you mean by that? > > The _other_ hyperlinks in the static content are replaced as part of the > > cronjob[1] - but that doesn't work for items in the searchindex.js file. > > Why is that a problem at all (maybe you know this already): > since we use content negotiation at Debian website (so the pages are > delivered in the correct language according to user's browser setting), we > change the directory structure away from the default how it's build by Sphinx: > after Sphinx' make there are separate directories for every language, > and they contain everything for that language, including the searchindex.js > file. And in that structure it works fine. > On Debian website we put everything in one directory, adding the language > code into the filename in front of the .html extension. > While this works fine for static content, it does not for the search > function here. I think this is a reasonable solution; serving the content from a single directory is simple and logical because the permissions and content should be the same; the latter only differs as a result of locale and therefore translation. > > Fortunately I think there might be a better way to do this. Sphinx itself > > has > > an HTML builder option 'html_file_suffix' and I think we could use that > > instead > > to define the filenames. That option is respected by the search JavaScript > > using a template variable[3] in the documentation_options.js file. > > > > We should be careful of other side-effects if making that change, but it > > would remove a deployment transformation step on the static content, and I > > think that's beneficial. > > I don't understand how that could affect our search function problem, > but I could give it a try. The main change that it would introduce is that the dynamic search results that appear in the search results (as gathered by the JavaScript) have hyperlinks that include the build-time suffix in the filename. So in the example above, you have linked me to a German-language dokumentation page, and when I search from that page, I find (based on a DE search index) and am linked to (based on DE file suffixes) Deutsch results; foo.de.html instead of foo.html for example. I'm in two minds about this: if my browser settings say that my locale is en-150 and I land on a de-DE page, what language should search be performed in, and what language should the results link to? An answer that I find straightforward is that if the page is de-DE -- which your hypothetical link to me was -- then because everything on that page _should_ (with sufficient translation availability) be in German, then I would expect to search and be linked to pages accordingly. If you'd linked to a language-less URL, then that would (a) have been thoughtful if you suspected that I did not comprehend Deutsch, and (b) also be provided in my default locale, with search and results taking place accordingly, and without any specific locale in the result hyperlinks (because the server will select a resource to serve). Note also: there does _not_ appear to be an equivalent to the 'html_file_suffix' config setting to adjust the search index filename. Regards, James
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi Holger, On Sun, 14 Apr 2024 22:40:36 +0200, Holger wrote: > I forgot to mention, that I have pushed a release-notes variant with this theme to > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.en.html > (English) > > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.de.html > (German) > > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.ca.html > (Catalan) >From some testing of these: the search results have a problem that they hyperlink to a language-less .html URL, meaning that clicking a result link in the DE-language search results takes the user to a EN-language page. The _other_ hyperlinks in the static content are replaced as part of the cronjob[1] - but that doesn't work for items in the searchindex.js file. Fortunately I think there might be a better way to do this. Sphinx itself has an HTML builder option 'html_file_suffix' and I think we could use that instead to define the filenames. That option is respected by the search JavaScript using a template variable[3] in the documentation_options.js file. We should be careful of other side-effects if making that change, but it would remove a deployment transformation step on the static content, and I think that's beneficial. [1] - https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70 [2] - https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix [3] - https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6
Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)
On Sat, 13 Apr 2024 at 06:48, Holger Wansing wrote: > Am 11. April 2024 23:52:52 MESZ schrieb James Addison : > >On Sun, 7 Apr 2024 13:00:43 +0200, Holger wrote: > >> The only thing which is not working currently, is the search functionality, > >> but since that's not theme-specific I guess (please correct me, if I'm > >> wrong), I close this bug. > > > >The theme looks great, and I agree with closing this bug. However, so that > >we don't overlook another potential python3-sphinx bug: could you report the > >problem that you encountered? (I contribute to upstream and may be able to > >help with investigating that) > > It's not a bug in sphinx or something like that. > The issue was in the build process for the website, what lead to some missing > files in the manuals' tree (javascript script files and the searchindex.js). > > Everything fine for now. Ok; thank you! > I'm currently working on switching the Debian release-notes to the new theme, > and that might bring some issues, since the release-notes have translations as > well (this was not the case for the debian-policy). > > So maybe I come back to you in such case, if that's ok? I'm less knowledgeable about the translation logic than the JavaScript search functionality, however yes, feel free to include me on cc for Sphinx bugreports and I'll help if-and-when possible. James
Bug#1068927: ITP: rust-event-listener-strategy -- block or poll on event_listener easily
On Sat, Apr 13, 2024 at 04:10:31PM +0200, Jonas Smedegaard wrote: > event-listener-strategy provides a strategy > for using the event-listener crate > in both blocking and non-blocking contexts. Matthias already packaged this and it's sitting in NEW. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)
Hi Holger, On Sun, 7 Apr 2024 13:00:43 +0200, Holger wrote: > The only thing which is not working currently, is the search functionality, > but since that's not theme-specific I guess (please correct me, if I'm > wrong), I close this bug. The theme looks great, and I agree with closing this bug. However, so that we don't overlook another potential python3-sphinx bug: could you report the problem that you encountered? (I contribute to upstream and may be able to help with investigating that) Thanks, James
Bug#1031928: [Pkg-mailman-hackers] Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error
Control: reopen -1 Hi Pierre, On Sun, 17 Mar 2024 at 22:14, Pierre-Elliott Bécue wrote: > > Considering the version of django-compressor in bookworm, I think this > bug can be closed. > > [ .. snip .. ] Unfortunately I do not believe that this problem is resolved yet; my understanding is that the issue appears when DEBUG mode is enabled, meaning that compression is _disabled_, and so the dependency on django-compressor is not directly relevant. The problem originates from some non-well-formed HTML in the hyperkitty templates. Regards, James
Bug#1064593: issue with Debian-style html theme for sphinx-based documents
Brilliant - yep, the fonts, CSS and JS now load as expected. Thank you Holger.
Bug#1068645: RM: rust-lazy-regex-proc-macros -- ROM; content already present in rust-lazy-regex package
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: rust-lazy-regex-proc-mac...@packages.debian.org Control: affects -1 + src:rust-lazy-regex-proc-macros User: ftp.debian@packages.debian.org Usertags: remove rust-lazy-regex-proc-macros should not have been packaged, since it was already provided by the rust-lazy-regex package.
Bug#1058552: [Pkg-javascript-devel] Bug#1058552: science.js: FTBFS: SyntaxError: Error parsing /<>/package.json: Unexpected end of JSON input
On Thu, 04 Apr 2024 19:01:58 +0200 Jonas Smedegaard wrote: Quoting James Valleroy (2024-04-04 16:13:07) > On 3/28/24 4:08 AM, Petter Reinholdtsen wrote: > > [James Valleroy 2024-02-12] > >> Here is a patch that fixes the build: > > > > Btw, did you mean TEMPFILE=$(shell mktemp) to get a random temp file > > name? > > > > I'm not sure. It may also work, but there is a difference in when a > shell command runs. Some people recommend not to use shell in a > makefile: https://stackoverflow.com/a/76121578 Each make target (i.e. each line indended by a tab) is executed within a shell. The point in the SO answer you reference is that calling the make function $(shell ...) *inside* a make target effectively spawns a shell within another shell, and *that* you rarely really want. What Petter is talking about above is that "TEMPFILE=mktemp", because it is a make target (i.e. on a TAB-indented line) is passed to a shell, which will *not* set TEMPFILE to the output of the shell command mktemp, but simply set TEMPFILE to the _string_ "mktemp" which is unlikely that you want. I see, thanks for pointing that out. I think there isn't a need to use mktemp here, so the patch can be simplified to this: diff --git a/Makefile b/Makefile index c9e03c2..f5a954b 100644 --- a/Makefile +++ b/Makefile @@ -77,7 +77,8 @@ install: package.json: src/package.js @rm -f $@ - node src/package.js > $@ + node src/package.js > package.json.temp + mv package.json.temp $@ @chmod a-w $@ clean: OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058552: science.js: FTBFS: SyntaxError: Error parsing /<>/package.json: Unexpected end of JSON input
On 3/28/24 4:08 AM, Petter Reinholdtsen wrote: [James Valleroy 2024-02-12] Here is a patch that fixes the build: Thank you. Can you explain why changing the output from package.json to mktemp and then moving the result to package.json will solve the build problem? I fail to understand how this could change anything. The makefile receipe uses node to produce the content that will be written to package.json. It seems that node is also trying to read in and parse the contents of package.json. Apparently, writing the file is not an atomic operation, so node is reading it before the write operation has completed. So it reads some partially-written package.json file, which is not yet valid JSON, and produces an error when trying to parse it. I don't know enough about node to say why it does this (reading in package.json after it has started running the src/package.js script). Btw, did you mean TEMPFILE=$(shell mktemp) to get a random temp file name? I'm not sure. It may also work, but there is a difference in when a shell command runs. Some people recommend not to use shell in a makefile: https://stackoverflow.com/a/76121578 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1026877: opari2: please make the build reproducible
Source: opari2 Followup-For: Bug #1026877 Control: forwarded -1 https://salsa.debian.org/debian/opari2/-/commit/1cc9b96544cdf1e8cbc733584b3ff1a4109b89e6 https://salsa.debian.org/debian/opari2/-/commit/15155c97944b7c17bc481ff91261d8191f81ae6f
Bug#1026877: opari2: please make the build reproducible
Source: opari2 Followup-For: Bug #1026877 Control: close -1 2.0.7-2
Bug#1064404: snapd: please make the build reproducible.
Control: forwarded -1 https://salsa.debian.org/debian/snapd/-/merge_requests/8 On Thu, 28 Mar 2024 at 16:15, Zygmunt Krynicki wrote: > > > > > Wiadomość napisana przez James Addison w dniu > > 28.03.2024, o godz. 15:51: > > > > On Thu, 28 Mar 2024 at 12:43, Zygmunt Krynicki wrote: > >> > >> Thank You for pursuing this! Please let me know when you have the patch > >> and I will gladly apply it. > >> > >> Personally I think the simple solution is fine. No need to go overboard. > > > > Ok, agreed - I'll test and then provide a patch to use a fixed offset for > > the > > timezone. > > > > Could you confirm your current preferred timezone to derive that value? > > (the > > selection should be fairly arbitrary, but I'd prefer to ask) > > > Perhaps just UTC? > > ZK Yep, that seems reasonable. Please find a merge request linked, with testing results to confirm the problem and fix in the description.
Bug#1067901: jh_installjavadoc: should not write duplicative doc-base files.
Package: javahelper Version: 0.79 Severity: normal User: reproducible-bui...@lists.alioth.debian.org Usertags: fileordering Control: affects -1 libpixels-java Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and noticed that the 'libpixels-java' package, which build-depends on javahelper (src:javatools) and uses jh_installjavadoc, failed[2] an automated build test on the Reproducible Builds test infrastructure for Debian. In particular, the /usr/share/doc-base/libpixels-java.libpixels-java file varied between a control and experimental package build. The cause seems to relate to logic that writes[3] a '$package.doc-base.javadoc' file into the 'debian' directory during build. In the case of libpixels-java, that template file is written alongside an existing 'debian/doc-base' file[4] contained in the source package. Both of the files then contain an identical doc-id statement[5], and it's unpredictable which of them will be read[6] from the directory by dh_installdocs - it depends on the ordering returned by the filesystem. If it seems like a reasonable solution to you, perhaps jh_installjavadoc could be modified so that it does not write a templated doc-base file for a package when it detects an existing doc-base file that contains the same doc-id? Thank you, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libpixels-java.html [3] - https://sources.debian.org/src/javatools/0.79/jh_installjavadoc/?hl=86#L105-L118 [4] - https://sources.debian.org/src/libpixels-java/2.1.3%2Bsvn.42-3/debian/doc-base/ [5] - https://sources.debian.org/src/libpixels-java/2.1.3%2Bsvn.42-3/debian/doc-base/#L1 [6] - https://sources.debian.org/src/debhelper/13.14.1/dh_installdocs/#L406
Bug#1064404: snapd: please make the build reproducible.
On Thu, 28 Mar 2024 at 12:43, Zygmunt Krynicki wrote: > > Thank You for pursuing this! Please let me know when you have the patch and I > will gladly apply it. > > Personally I think the simple solution is fine. No need to go overboard. Ok, agreed - I'll test and then provide a patch to use a fixed offset for the timezone. Could you confirm your current preferred timezone to derive that value? (the selection should be fairly arbitrary, but I'd prefer to ask)
Bug#1064404: snapd: please make the build reproducible.
Hi Zygmunt, On Sun, 25 Feb 2024 at 12:12, James Addison wrote: > > On Wed, 21 Feb 2024 at 15:52, Zygmunt Krynicki wrote: > > > > > > > Wiadomość napisana przez James Addison w dniu > > > 21.02.2024, o godz. 15:49: > > > > > > Source: snapd > > > Version: 2.61.1-1 > > > Severity: wishlist > > > > > > ... [snip] ... > > > > > > One cause of non-reproducibility for the package appears to be that the > > > snap.8 manual page (compressed as snap.8.gz) contains a timestamp in the > > > header that becomes timezone-localized, meaning that the Debian binary > > > packages > > > built may vary based on the timezone they're built in. > > > > > > Although one way to fix this could be to request and display a UTC > > > timestamp, > > > there's a comment[3] in the debian/rules file that hints at a better > > > solution: > > > from version 1.4.0-2 of golang-go-flags there is in-built support[4] for > > > the > > > SOURCE_DATE_EPOCH variable, a time-in-seconds since the Unix epoch > > > (interpreted > > > in UTC[5]). > > > > > > ... [ snip ] ... > > > > > > Thank you for bringing this to my attention and for offering a patch. I was > > aware of numerous TODOs in the packaging but have not yet managed to come > > up with a solution that would work both upstream and downstream (snapd CI > > system uses a copy of the debian packaging to check that a package can > > indeed be built), so any iteration on this is rather tedious. > > > > ... [ snip ] ... > > > > Thanks, Zygmunt - > https://salsa.debian.org/debian/snapd/-/merge_requests/7 contains a > minimal change that I believe should make the package reproducible on > Debian - it does not alter any build-time dependencies, and does not > affect the rules files for any other distros/releases (the debian-sid > (experimental) rules file in the packaging dir is _not_ updated). > > The change updates the packaging to remove customization of > golangs-go-flags manual-page-generation timestamping. That library > previously lacked support for reproducible build timestamping, that > was subsequently patched[1] into Debian in v1.4.0-2 and merged > upstream[2] into v1.5.0. Thanks for applying the patch - however it seems that there is a snag: although golang-go-flags does correctly read the SOURCE_DATE_EPOCH value, and fixes a build-time documentation-creation-timestamp based on that, the output manual page displays a date that is timezone-localized, and therefore may vary. In particular, if documentation is built from the source package in two different timezones, and particularly when the distance between their latitudes is significant, then a different date may be written to the header of the manual page(s). A straightforward fix could be to configure a static UTC timezone during the construction of documentation. However, there would be a small drawback to that: since the SOURCE_DATE_EPOCH value read by Debian's build processes is taken from the 'debian/changelog' file, using UTC could have the unusual effect of meaning that the date on the documentation differs from the actual current local calendar date when the maintained stamped their changelog entry. An alternative could be to parse the changelog to read the timezone of the most recent changelog entry, and use that during each build. A repeat build elsewhere in the world with the same dependencies (including same tzdata) would then parse the same timezone, localize to where the _maintainer_ was located (not to the current build host timezone), and the output date value should become identical. It's possible that that would be an overcomplicated solution but it could also be more comprehensible to maintainers themselves (thought process: 'my calendar date was X when I finished the packaging for release Y, and that is why date X exactly appears in the corresponding documentation'). I'll continue to consider the implications before offering a follow-up patch. Thank you again, James > ... [ snip ] ... > > [1] - > https://salsa.debian.org/go-team/packages/golang-go-flags/-/commit/3015faf7a972cb074e65f8c210476937698a492b > > [2] - https://github.com/jessevdk/go-flags/pull/285
Bug#1003923: soundkonverter: reproducible-builds: BuildId differences triggered by RPATH
Followup-For: Bug #1003923 Control: forwarded -1 https://salsa.debian.org/qt-kde-team/extras/soundkonverter/-/merge_requests/2 Dear Maintainer, Please find a Debian Salsa merge request, added by this message as the forwarded URL for this bug, that applies the patch from this bugreport and confirms that it reduces buildpath variance for soundkonverter. Two commits in the merge request are particularly relevant: * 099c4dcc4d038727e57b380e219d5512059a9615 - enables build-path variance testing, _without_ the patch applied; the 'reprotest' pipeline fails. * c5d0d82ff446333768b201e729773064c5fe33de - after a few false starts, correctly applies the patch; the 'reprotest' pipeline succeeds. The other commits included in the merge request are me gradually and sometimes mistakenly working towards those checkpoints. Thank you, James
Bug#1066045: maven-bundle-plugin: produces nondeterministic ordering in MANIFEST.MF headers
Followup-For: Bug #1066045 Control: forwarded -1 https://salsa.debian.org/java-team/maven-bundle-plugin/-/merge_requests/1 Control: tags -1 pending This change has recently been uploaded to DELAYED/15 by Mattia from the Reproducible Builds team after I requested that; in addition I'm providing the same change as a merge request on Salsa (adding this as the forwarded-to URL for reference, although in this case the change itself is a backport from upstream).
Bug#1003922: recastnavigation: reproducible-builds: BuildId differences triggered by RPATH
Followup-For: Bug #1003922 Control: tags -1 pending
Bug#1067850: src:kget: possible Salsa-CI reprotest misconfiguration.
Source: kget Severity: wishlist X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath Dear Maintainer, The Salsa CI configuration for kget sets customized[1] command-line options for 'reprotest'[2], a utility used to find package reproducibility problems. Unfortunately, I think that the configured SALSA_CI_REPROTEST_ARGS arguments may be incorrect; the provided arguments _appear_ intended to disable build-path variance, but I believe that they unintentionally disable _all_ forms of reprotest variance testing. Please refer to this Reproducible Builds mailing list thread for more information: https://lists.reproducible-builds.org/pipermail/rb-general/2024-February/003247.html I'd recommend removing the SALSA_CI_REPROTEST_ARGS line entirely -- which in isolation could cause Salsa-CI reprotest to fail, due to a build-path bug reported in #1003914 -- but also then applying the patch from that bugreport to confirm and solve the problem. If that is undesirable, then as an alternative I could suggest configuring: SALSA_CI_REPROTEST_ARGS: '--variations=all,-build_path' (please note that there are _two_ changes in this line; the insertion of 'all' and adjustment of 'build-path' to 'build_path') ...to enable all forms of variation, with the exception of buildpath. Thank you, James [1] - https://salsa.debian.org/qt-kde-team/kde/kget/-/blob/c3b261bd0d740cdd89c8d06e05eb238cb746fe3d/debian/salsa-ci.yml#L7 [2] - https://salsa.debian.org/reproducible-builds/reprotest
Bug#1001870: meshlab: reproducible-builds: BuildId differences triggered by RPATH
Source: meshlab Followup-For: Bug #1001870 Control: tags -1 pending
Bug#1061264: ocrmypdf: Uses deprecated/to be removed pypdf2 in autopkgtest
Upstream here. ocrmypdf does not actually require pypdf2 or pypdf for its test suite anymore. That dependency was removed long before v15.2.0, so it should be safe to remove the offending line from debian/tests/control. -James Barlow On Mon, Mar 25, 2024 at 6:06 AM Scott Kitterman wrote: > On Sun, 21 Jan 2024 13:14:34 -0500 Scott Kitterman > wrote: > > Source: ocrmypdf > > Version: 15.2.0+dfsg1-1 > > Severity: wishlist > > > > I've recently adopted pypdf and pypdf2 into the Debian Python Team in > response to an RFA for both packages. As these are somewhat security > sensitive packages (among my first acts after adopting the packages was to > upload proposed updates for both to address minor security issues in > Bookworm > in the next point release - same bug in both), I do not think we should > release pypdf2 in Trixie and have filed an RC bug to that effect. > > > > ocrmypdf uses the package in debian/tests/control. Please update to use > > python3-pypdf insteadm. > > Pypdf2 has been removed from testing, so this is now serious. > > Scott K
Bug#1001586: vim-gtk3: GVim sometimes freezes when receiving focus due to switching workspaces on Gnome (Wayland)
On Sun, Dec 12, 2021 at 04:03:21PM +0100, Mladen Mijatov wrote: > GVim will sometimes freeze when switching between workspaces fast and in the > midst of that main window receives focus. Just the interface will freeze but > changes in mouse cursor would indicate that process beneath it is working as > expected. > > Issue is reproducible but it doesn't happen every time making it very annoying > because it will randomly crash working environment causing loss of data. Has this still been an issue? If so, maybe the latest upload (9.1.0199-1) will help, since it has some native wayland support. See ":help gui-wayland". Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1067543: RFS: miniflux/2.1.1-1 -- minimalist and opinionated feed reader
Hi Maytham, On 3/23/24 8:19 AM, Maytham Alsudany wrote: Package: sponsorship-requests Severity: normal X-Debbugs-Cc: jvalle...@mailbox.org Dear mentors, I am looking for a sponsor for my package "miniflux": * Package name : miniflux Version : 2.1.1-1 Upstream contact : https://github.com/miniflux/v2/issues * URL : https://miniflux.app * License : Expat, Apache-2.0 * Vcs : https://salsa.debian.org/go-team/packages/miniflux Section : web The source builds the following binary packages: miniflux - minimalist and opinionated feed reader To access further information about this package, please visit the following URL: https://mentors.debian.net/package/miniflux/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/miniflux/miniflux_2.1.1-1.dsc Changes since the last upload: miniflux (2.1.1-1) UNRELEASED; urgency=medium . * New upstream version 2.1.1 * Fixup scripts, use debconf to prompt user for new admin account credentials * Override lintian source-is-missing error for testdata Regards, I have uploaded this package. Regards, James OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1001788: neovim: undoing changes results in a mix of old and new text
On Sat, Jul 16, 2022 at 10:53:01PM -0400, James McCoy wrote: > On Tue, Mar 01, 2022 at 05:45:35PM +0100, Nicolas Évrard wrote: > > * James McCoy [2021-12-17 22:31 +0100]: > > > On Thu, Dec 16, 2021 at 10:28:18AM +0100, Nicolas Évrard wrote: > > > > I am sorry for this bug report because it occurs on some rare occurence > > > > and I > > > > don't have a scenario to reproduce it. Yet it's annoying enough to > > > > deserve a > > > > bug report. Feel free to close it as unreproduceable ;). > > > > > > > > With the arrival of LSP I switched my configuration from ALE to the > > > > builtin LSP > > > > for linting and so on. I made this switch some days after the release > > > > of neovim > > > > 0.5.0 ; since that time I have remarked that sometimes (I'd say 2 or 3 > > > > times a > > > > month), when I undo my changes (not just one press of 'u' multiple > > > > presses), it > > > > results in a mix of old and new changes. > > > > > > There were a number of fixes in the LSP stuff for 0.6.0, so can you let > > > me know if you see this again after upgrading to that? > > > > Hello, > > > > So after a while I thought that it had indeed disappeared but I had it twice > > today :(. It seems to be a problem with the virtual text and treesitter. > > > > Here's a screenshot of the error in action. > > If you encounter this again, can you see if running ":redraw!" fixes it? > That would help confirm whether it's just a display issue or the buffer > is actually in a bad state. Is this something you're still running into? Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1067496: Vertical splits no longer delineated by default
On Fri, Mar 22, 2024 at 01:42:41PM +, Josh Triplett wrote: > After upgrading to the new version of neovim, the highlight > `WinSeparator` (which links to `VertSplit`) no longer has any visible > setting by default. In previous versions, there was an inverse-video bar > between windows; now there's only a black bar the same color as normal > text background, which makes the windows blend together. Do you see the same issue if you run "nvim --clean"? Could you include some screenshots to help show what you're seeing? Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
