Bug#1015936: forward patches
forwarded 1015936 https://nmbug.notmuchmail.org/nmweb/show/20240802211048.1840273-3-sten%40debian.org forwarded 1029190 https://nmbug.notmuchmail.org/nmweb/show/20240802211048.1840273-3-sten%40debian.org signature.asc Description: PGP signature
Bug#1077634: RFP: golang-github-maxmind-geoipupdate-v6 -- golang GeoIP update client and library
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian...@lists.debian.org Control: block 1073238 by -1 * Package name: golang-github-maxmind-geoipupdate-v6 Version : 7.0.1-1 Upstream Author : MaxMind * URL : https://github.com/maxmind/geoipupdate * License : Apache-2.0 Programming Lang: Go Description : GeoIP update client code The GeoIP Update program performs automatic updates of GeoIP2 and GeoLite2 binary databases. CSV databases are *not* supported. . This package also contains a golang library that enables programs to maintain their own up-to-date copy of a GeoIP2 or GeoLite2 database. This library is a new dependency of Syncthing and its absence in Debian is blocking progress to updating our Syncthing package. I'm not sure whether or not the standalone client should also be packaged. Regards, Nicholas
Bug#1077622: ITP: golang-github-willabides-kongplete -- Kongplete generates shell completions for command-line golang programs
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-willabides-kongplete Version : 0.4.0-1 Upstream Author : WillAbides * URL : https://github.com/willabides/kongplete * License : Expat Programming Lang: Go Description : Kongplete generates shell completions for command-line golang programs Kongplete generates shell completions for command-line programs using github.com/alecthomas/kong and github.com/posener/complete.
Bug#1077302: ITP: electrum-nmc -- Easy to use Namecoin client
Package: wnpp Severity: wishlist Owner: Nicholas Voyak * Package name: electrum-nmc Version : 4.0.6 Upstream Contact: Jeremy Rand * URL : https://www.namecoin.org/docs/electrum-nmc/ * License : MIT Programming Lang: Python Description : Easy to use Namecoin client This package provides a lightweight Namecoin client which protects you from losing your namecoins or names in a backup mistake or computer failure. Also, Electrum-NMC does not require waiting time because it does not download the Namecoin blockchain. . Features of Electrum-NMC: . * Instant on: Your client does not download the blockchain. It uses a network of specialized servers that index the blockchain. * Forgiving: Your wallet can be recovered from a secret seed. * Safe: Your seed and private keys are encrypted on your hard drive. They are never sent to the servers. * Low trust: Information received from the servers is verified using SPV. Servers are authenticated using SSL. * No downtimes: Your client is not tied to a particular server; it will switch instantly if your server is down. * Ubiquitous: You can use the same wallet on different computers, they will synchronize automatically. * Cold Storage: Sign transactions from a computer that is always offline. Broadcast them using a machine that does not have your keys. * Reachable: You can export your private keys into other Namecoin clients. * Electrum-NMC is open source and is a fork of Electrum, which was first released in November 2011. I plan to maintain this package with support provided by NLnet, and to contact the Debian Cryptocoin Team for review and sponsorship.
Bug#1072906: Processed: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Control: owner -1 s...@debian.org "Debian Bug Tracking System" writes: > Processing commands for cont...@bugs.debian.org: > >> close 1072906 > Bug #1072906 [sponsorship-requests] RFS: markdown-mode/2.6-2 [Team] -- mode > for editing Markdown-formatted text files in GNU Emacs > Marked Bug as done >> stop > Stopping processing here. > > Please contact me if you need assistance. Please deactivate your bug-closing script for this bug. Spwhitton uploaded an unrelated -2 that didn't include any of Xiyue Deng (manphiz)'s work. I'm working on a reply. Thanks, Nicholas signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Xiyue Deng writes: > Nicholas D Steeves writes: >> Xiyue Deng writes: >>> Nicholas D Steeves writes: > >> Also, do you use this package? >> > > Not on a regular basis, but I do use it a bit once in a while as I try > to learn a bit of new programming languages every few months. Putting yourself in Uploaders means you're going to take a special (and regular) interest in a package in the long term. Is that really what you intend? >> Meanwhile, compression type isn't the problem: >> >> gbp:info: Tarballs 'scala-mode-el_1.1.0+git20221025.5d7cf21.orig.tar.gz' >> not found at '/home/sten/devel/tarballs/' >> gbp:error: v1.1.0+git20221025.5d7cf21 is not a valid treeish >> > > This is because I didn't push the tag to the repo yet. Now this is > done. Thanks. When pushing upstream history, one needs to also push the upstream tag. >> and at the same time, the proposed switch to xz is also arguably a >> regression, because the actual upstream release tarballs of scala-mode >> are currently being used: >> >> $ apt source scala-mode-el >> $ md5sum scala-mode-el_1.1.0.orig.tar.gz >> 615b1f38ed083137fee99fa83fe452a1 scala-mode-el_1.1.0.orig.tar.gz >> # Download release tarball from github manually, or use uscan >> $ md5sum ~/Downloads/emacs-scala-mode-1.1.0.tar.gz >> 615b1f38ed083137fee99fa83fe452a1 >> /home/sten/Downloads/emacs-scala-mode-1.1.0.tar.gz >> >> This indicates that the human maintainer doesn't use "git deborig". >> Being able to reproduce the imports of official upstream tarballs is >> important to a number of developers, and some workflows depend on this >> assumption, so please don't break it. >> > > In this specific case as I'm targeting a snapshot so there is no > upstream tarball, so using xz provides the benefits of a smaller source > tarball that saves space for the Debian source repository. > > For the aspect of the consistency with upstream release tarball, I'm > trying to understand how to make this work. I believe "gbp import-orig > --uscan" should grab the upstream release tarball which follows your > suggestion. However IIUC the repository is configure using the > dgit-maint-merge workflow that uses upstream branch to target upstream > repo and hence uses the tagged version to generate upstream tarball, > which I believe is incompatible with "gbp import-orig --uscan" approach > which directly import the release tarball without the git history. What does "IIUC" mean? This repository doesn't use dgit workflow. Gbp can optionally merge git history. If upstream provides release tarballs in gz rather than xz, and the Debian Maintainer/Uploader uses those, then the repository needs to be configured for gz and not xz. Note that d/watch previously specified gz. Changing that configuration is working against the Maintainer/Uploader. Given this, it is more correct to configure gbp to use gz until upstream switches to xz. "Git deborig" should also be invoked to use gz. > I wonder whether there is a way for "git deborig" or "gbp > buildpackage" to grab upstream tarball automatically? I'm guessing > not, so someone has to do it manually, but please let me know if there > is a way. What do you mean? Just use uscan, or origtargz. Or do you mean accommodating the case where you think moving from a stable release to a snapshot is justified? Tell upstream that Debian highly values stable releases, and convince them to tag one. Problem solved. P.S. I read a message you wrote to an upstream about this, and that github issue didn't look like it would convince anyone of the value of tagged releases...please do better in the future. Nicholas signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Xiyue Deng writes: > With the release of the new policy version, I have done some more clean > up to the package and update team repo and mentors. PTAL. TIA! Please stop making copyright assertions for other people. We've discussed this before, and it's the actual copyright situation is what counts and not lintian's experimental "update-debian-copyright" tag. That tag is to remind contributors in the d/copyright file to check whether they've done any work that meets the https://en.wikipedia.org/wiki/Threshold_of_originality You also need to explain what "Drop old version on emacs in recommends." means, and *why* you made this change, because it's not self-evident. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1055431: Simpler fix for #1052917
Hi,
Jeremy Sowden writes:
> This error:
>
>> debian/rules clean
>> dh clean --with elpa
>>dh_auto_clean
>> make -j8 clean
>> make[1]: Entering directory '/<>'
>> End of file during parsing
>> rm -f *.elc .latest-* autoloads.el scala-mode- Error: end-of-file nil
>> mapbacktrace(#f(compiled-function (evald func args flags) #> 0x943b01ebae87e2>)) debug-early-backtrace() debug-early(error
>> (end-of-file)) read(#) (nth 2 (read (find-file
>> "./scala-mode-pkg.el"))) (format "%s\n" (nth 2 (read (find-file
>> "./scala-mode-pkg.el" (princ (format "%s\n" (nth 2 (read (find-file
>> "./scala-mode-pkg.el") command-line-1(("-L" "." "--eval" "(princ
>> (format \"%s\\n\" (nth 2 (read (find-file \"./scala-mode-pkg.el\")"))
>> command-line() normal-top-level().tar
>> /bin/sh: 1: Syntax error: "(" unexpected
>> make[1]: *** [Makefile:55: clean] Error 2
>
> occurs because the Makefile does this (trimmed):
>
> VERSION := $(shell ${ELISP_COMMAND} $(ELISP_OPTIONS) --eval
> '(princ (format "%s\n" (nth 2 (read (find-file "$(PKG_FILE)")')
> MODE_NAME_VERSION = $(MODE_NAME)-$(VERSION)
>
> clean:
> $(RM) *.elc .latest-* autoloads.el $(MODE_NAME_VERSION).tar
>
> It tries to use Emacs to get the version from the scala-mode-pkg.el
> file, but that doesn't exist, so the output from the `$(shell)` command
> is a stack-trace, not a version number.
>
> Make prefers variable definitions given as arguments at the command line
> to those defined in the Makefile, so if `VERSION=X.Y.Z` is passed to
> `make clean`:
>
> override_dh_autoclean:
> dh_auto_clean -- VERSION=X.Y.Z
>
> Emacs isn't called, and the error goes away.
Thank you, yes, this is one of the right ways to solve this issue, and I
hope it's evident to everyone following this thread why this is the
case. :)
Please use Xiyue Deng (manphiz)'s work on SUBSTVARS for "VERSION=X.Y.Z",
and feel free to apply any fixups; I seem to remember that there's
something like a fragile regex.
> I will push this change and review the rest of this (lengthy :))
> report.
Rather than reading this mentoring thread--long form for educational
value--it's probably faster to review d/changelog, diff
debian/20111005-2.1, and check for consistency.
P.S. did you forget to push?
Cheers,
Nicholas
signature.asc
Description: PGP signature
Bug#1076569: When called for dh-sequence-kf6 (or --with=kf6) CMAKE Qt6 should be enforced
Package: pkg-kde-tools Version: 0.17.4 Severity: serious I just started working towards updating one of my packages to Qt6 and KF6 and I was shocked to find that dh-sequence-kf6 doesn't append "-DQT_MAJOR_VERSION=6" to cmake configure arguments. KF6 + "-DQT_MAJOR_VERSION=5" is nonsensical, so the Qt6 variant should be enforced. Best, Nicholas
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Replying from my phone: On Wed, 3 Jul 2024, 22:40 Sean Whitton, wrote: > Hello, > > Sorry to keep asking for these minor changes, but it does help me > understand the change better. > > Why can't you just use debian/install to install the .nosearch? Are you > trying to avoid creating an empty .nosearch in the source package, or is > there some other reason? > While we're discussing interface, I'm curious about a "debian:rules:dh --with dh-elpa --nosearch, norecurse, flat, or similar". For the fine-grained approach, I'm curious about special handling for debian/foo.elpa: subdir/.nosearch. Like an autoload cookie, but a " do not recourse and do not load" cookie. Ie can't this problem be resolved such that it enables declarative style and doesn't require a debian/[foo.]install file? >
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
hout markdown and with > discount: > > With markdown dependency: > , > | Ran 543 tests, 540 results as expected, 0 unexpected, 3 skipped (2024-06-11 > 04:04:39+, 1.465706 sec) > | 1 expected failures > | > | 3 skipped results: > | SKIPPED test-markdown-flyspell/check-word-p > | SKIPPED test-markdown-flyspell/remove-overlay > | SKIPPED test-markdown-flyspell/yaml-metadata > ` > > Without markdown dependency: > , > | Ran 543 tests, 540 results as expected, 0 unexpected, 3 skipped (2024-06-11 > 03:56:33+, 1.504459 sec) > | 1 expected failures > | > | 3 skipped results: > | SKIPPED test-markdown-flyspell/check-word-p > | SKIPPED test-markdown-flyspell/remove-overlay > | SKIPPED test-markdown-flyspell/yaml-metadata > ` > > With discount replacing markdown: > , > | Ran 543 tests, 540 results as expected, 0 unexpected, 3 skipped (2024-06-11 > 04:55:59+, 1.410098 sec) > | 1 expected failures > | > | 3 skipped results: > | SKIPPED test-markdown-flyspell/check-word-p > | SKIPPED test-markdown-flyspell/remove-overlay > | SKIPPED test-markdown-flyspell/yaml-metadata > ` > > So regardless of dropping markdown or adding discount, the test behavior > did not change. I think now with discount replacing markdown it is in a > better state. Really? It looks to me like you proved this: (setq markdown-state 3) (setq without-markdown-state 3) (setq with-discount-state 3) (setq markdown-to-discount-diff 0) (setq markdown-state (/ markdown-state markdown-to-discount-diff)) I know this isn't idiomatically correct, but I want non-LISPers to be able to understand this gentle point. Please resolve this issue by completing the TODO item I put in the changelog. Best, Nicholas signature.asc Description: PGP signature
Bug#1074230: orgguide.info.gz is not visible in Emacs Info
Diane Trout writes: > What version of org-mode-doc do you currently have installed? > > It looks like the bug was fixed in 9.7.5-1 in there's now a > /usr/share/info/orgguide.info.gz file. > > But it was only accepted into unstable on 6-25, and may take a few days > to make it to testing. Yes, exactly, thank you for explaining this Diane. I was sleepy and forgot to set high-priority, so I'm seeing if I can find another bug to justify an upload with a slight bending of the rules, because it benefits our users. > Getting the fix into stable would take some > effort and time. (I think it has to first be stable enough to go into > testing, and then we could negotiate with the release team about adding > an update to stable. I don't think there is a release-team approved fix for stable. The src:org-mode in stable is older than the version bundled with src:emacs, so it was converted to an empty dependency package. For correctness bin:org-mode-doc in stable should probably also become and empty package that depends on emacs-common-non-dfsg. Making that change would resolve half of this bug for stable. That said, src:emacs-common-non-dfsg doesn't contain orgguide, so it wouldn't solve the requested purpose of this bug. Given this, does it sound worthwhile? > Org mode might also make sense to build a backports version to have the > close to the current release available to stable, though you'd have to > get it from https://backports.debian.org/ Yeah, anyone who wants to support an official solution is welcome to step forward and do this. You can also install the latest elpa-org-mode and org-mode-doc debs from sid/unstable onto a bookworm/stable system and everything should Just Work™ due to the magic of arch:all packages and dh-elpa. Best, Nicholas signature.asc Description: PGP signature
Bug#1074296: elpa-folding: update / installation of elpa-folding fails in dpkg configure
Hi Thomas, Thanks for the bug report, reply follows inline. Thomas Dorner writes: > Package: elpa-folding > Version: 0.0~git20220110.1ce338b-1 > Severity: important > X-Debbugs-Cc: debian-b...@th-dorner.de > > Dear Maintainer, > > today's stable update of Emacs GTK (1:28.2+1-15+deb12u3) failed with a > strange compilation error in elpa-folding. After removing elpa-folding > (and the dependent emacs-goodies-el) the update was successful. Trying > to reinstall emacs-goodies-el and elpa-folding still fails afterwards: I agree this is strange, because native-compilation shouldn't execute as part of dpkg configure. > # apt install emacs-goodies-el > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > The following additional packages will be installed: > elpa-folding > The following NEW packages will be installed: > elpa-folding emacs-goodies-el Out of curiosity, did you get root with "sudo -s"? Try this: su - # or if you don't have the root account enabled: sudo -i apt clean # mitigates the unlikely case the download was corrupted apt purge elpa-folding apt install elpa-folding [snip] > Unpacking emacs-goodies-el (42.4) ... > Setting up elpa-folding (0.0~git20220110.1ce338b-1) ... > Install emacsen-common for emacs > emacsen-common: Handling install of emacsen flavor emacs > Install elpa-folding for emacs > install/folding-20220110.1718: Handling install of emacsen flavor emacs > install/folding-20220110.1718: byte-compiling for emacs > > In toplevel form: > folding.el:1637:13: Warning: Package cl is deprecated > folding.el:1718:6: Error: Native elisp load failed: > "/tmp/comp-lambda-z2mAEN.eln", "/tmp/comp-lambda-z2mAEN.eln: failed to map > segment from shared object" /\ This is the strange part. I don't understand why native-compilation is being triggered. That said, have you mounted /tmp with "-o noexec"? I agree that that it's essential mount anything writeable with noexec; however, this breaks native-compilation. > ERROR: install script from elpa-folding package failed > dpkg: error processing package elpa-folding (--configure): > installed elpa-folding package post-installation script subprocess returned > error exit status 1 > dpkg: dependency problems prevent configuration of emacs-goodies-el: > emacs-goodies-el depends on elpa-folding; however: > Package elpa-folding is not configured yet. > This bug wasn't triggered when apt upgraded on my system, I couldn't trigger it with dpkg-reconfigure elpa-folding, and I wasn't able to reproduce this in a clean bookworm schroot. apt install emacs-goodies-el # enable bookworm-security apt update && apt upgrade # Successful update Looking forward to your findings! Nicholas signature.asc Description: PGP signature
Bug#1074230: orgguide.info.gz is not visible in Emacs Info
Hi Morten, Nice find! Thank you for filing this bug. Morten Kjeldgaard writes: > Package: org-mode-doc > > Version: 9.5.2-1 > > After installing org-mode-doc on bookworm, the Org Guide item is not > visible from inside Emacs after calling the Info system using C-h i. > Emacs simply says: > > Info file 'orgguide' does not exist; consider installing it. This will be resolved momentarily (in sid/unstable) > The problem can be solved by copying the orgguide.info.gz file to > /usr/share/info: > > sudo cp /usr/share/doc/org-mode-doc/orgguide.info.gz /usr/share/info but not with this method. This isn't a severe enough issue to make an update to stable/bookworm. Would you please try uninstalling elpa-org-mode as well as org-mode-doc? Then install emacs-common-non-dfsg and try to reproduce this bug, because it's possible that it is also present in src:emacs itself (Emacs contains a bundled copy of org-mode). If that's the case then we'll need to clone this bug. Please let me know :) > The maintainers of the package should consider creating a link to > orgguide.info.gz in /usr/share/info. Many other files in that directory > are links to /etc/alternatives, I don't know if that is necessary. Hmm. Please see the other org-mode and org-mode-doc bugs because your suggestion touches on this: new org-mode-doc doesn't shadow old Emacs-bundled copy of the info pages. signature.asc Description: PGP signature
Bug#1069744: btrfs-progs: btrfs dev usa as non-root is wrong in every way and should just give an error
Hi Russell, On Wed, 24 Apr 2024 08:03:59 +1000 Russell Coker wrote: > Package: btrfs-progs > Version: 6.6.3-1.1+b2 > Severity: normal > Tags: upstream > > Below is an example of comparing btrfs dev usa as root and non-root. When > run as non-root it is wrong in every way, there is not a single correct > value. I've done this on my laptop (single device) and on a server with 3 > devices and the results were similarly wrong. > > Instead of providing information that is wrong and misleading it should > just give an error and say that it needs root permissions. > > # btrfs dev usa / > /dev/mapper/root, ID: 1 >Device size: 476.37GiB >Device slack:1.50KiB >Data,single: 170.01GiB >Metadata,DUP:6.00GiB >System,DUP: 64.00MiB >Unallocated: 300.29GiB > > $ btrfs dev usa / > WARNING: cannot read detailed chunk info, per-device usage will not be shown, > run as root > /dev/mapper/root, ID: 1 >Device size: 952.73MiB >Device slack: 16.00EiB >Unallocated: 476.37GiB I agree 100%. Would you please forward this upstream? Regards, Nicholas signature.asc Description: PGP signature
Bug#1074237: Please update to v6.9.0
Package: btrfs-progs Version: 6.6.3-1.2 Severity: normal Hi Adam, Would you please update to 6.9.0 soon? Btrfs-repair fixes are the main justification, as far as I can tell. Also please watch out for this: Note: raid-stripe-tree has recently got a on-disk format update which is not backward compatible, until the patches are in kernel (ETA release 6.11) use v6.9 or lower, both need either DEBUG or experimental build (David Sterba, "Btrfs progs release 6.9.1") A user on debian-backports also requested a release newer than 6.6.3 for reasons that I'm not yet familiar with. Cheers, Nicholas
Bug#1024257: btrfs-progs: Backup fails with "multiple capabilities" at first, then "capability no data available"
Hi Leszek, On Wed, 16 Nov 2022 14:50:28 +0100 Leszek Dubiel wrote: > Package: btrfs-progs > Version: 5.10.1-2 > Severity: important > > > Hello :) :) > > I am doing regular backukps send/receive. > > I get a lot of messages like this: > > WARNING: capabilities set multiple times per file: /mnt/sda2/2022-11-11 > 23:58:02 169205882/ZK_83308/Documents/fk-2228.jpg > > WARNING: capabilities set multiple times per file: /mnt/sdc2/2022-11-11 > 23:58:02 169205882/ZK_83308/Documents/fk-2228.jpg > > WARNING: capabilities set multiple times per file: /mnt/sdc2/2022-11-12 > 08:57:01 386278919/ZK_83308/Documents/fk-2228.jpg > > > and after some time it completely fails with errors: > > ERROR: lremovexattr ZK_83308/Documents/fk-2228.jpg security.capability > failed: No data available > > ERROR: lremovexattr ZK_83308/Documents/fk-2228.jpg security.capability > failed: No data available > > ERROR: lremovexattr ZK_83308/Documents/fk-2228.jpg security.capability > failed: No data available > > > > I have found other people also have such problems: > > https://github.com/digint/btrbk/issues/416 > > https://www.kubuntuforums.net/forum/general/miscellaneous/btrfs/71629-strange-warning-on-incremental-backup > > > > and the problem is probably back again after 2014: > > https://bugzilla.kernel.org/show_bug.cgi?id=68891 > > > > > After getting warnings I have checksummed send and receiving subvolumes > with rsync and files are > identical. > > But I have once found that btrfs/send receive finished without any > errors (!), subvolumes were both > read-only, and file was missing on receiving side. > > > > If you're still on bullseye (Debian 11), then Debian Backports may solve this. Install btrfs-progs 6.2-1~bpo11+1. The kernel from backports may also be required. Note that backports support for Debian 11 (bullseye) will probably end within the next six months, so please consider upgrading to Debian 12 (bookworm) at your earliest convenience. Regards, Nicholas signature.asc Description: PGP signature
Bug#1060069: btrfs-progs: reiserfs support optional?
Hi Daniel and Adam, On Fri, 05 Jan 2024 16:09:32 +0100 Daniel Vacek wrote: > Package: btrfs-progs > Version: 6.6.3-1 > Severity: wishlist > X-Debbugs-Cc: neel...@gmail.com > > Hello, > > I was wondering if the reiserfs support could be split into a separate > optional > package. > > The reason is I don't really need any riserfs libraries installed on my system > when I never used this FS and I never will. > > Have a nice day :-) I think this should be tagged "trixie" because reiserfsprogs (1:3.6.27-7) unstable; urgency=medium * Remove udebs. Acked by Cyril Brulebois and Steve McIntyre on d-boot ReiserFS has been deprecated upstream and scheduled for removal 2025. -- Felix Zielcke Wed, 20 Sep 2023 18:33:40 +0200 So there's no need to make unnecessarily complicate btrfs-progs nor increase the workload of the ftpmasters (who have to manually review changes like this). It looks like reiserfs will not be part of trixie (Debian 13). Regards, Nicholas signature.asc Description: PGP signature
Bug#1073238: please package 1.27.8 or newer
The most high-priority upstream bugs resolved by the upload: Panic in ignore matching on invalid UTF-8 from filesystem watcher https://github.com/syncthing/syncthing/issues/9369 Different lengths used for short device IDs in UI https://github.com/syncthing/syncthing/issues/9313 Versions path does not honor tilde (~) shortcut https://github.com/syncthing/syncthing/issues/9241 IndexHandler can get stuck in an undesired loop https://github.com/syncthing/syncthing/issues/9407 An extra action might be required to enable these nice-to-haves: syncthing should be cgroup aware https://github.com/syncthing/syncthing/issues/9435 Add CLI completion https://github.com/syncthing/syncthing/issues/8616 signature.asc Description: PGP signature
Bug#1073238: please package 1.27.8 or newer
Package: syncthing Version: 1.27.2~ds4-1 Severity: normal Hi, We're starting to fall behind again, so I'm filing this bug in the hopes that another team member has a bit of free time to take care of it. There's been some more upstream dependency churn. Regards, Nicholas
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Xiyue Deng writes: You're incorrect about: >* Drop unused override_dh_auto_test in d/rules (dh_elpa_test is in > effect) override_dh_auto_test: @echo Using dh_elpa_test to run tests instead of upstream Makefile Used to be useful, because the Makefile tests used to run as well as the dh_elpa_test ones. Dh_elpa_test was also "in effect then"... >* Update debian copyright year in d/copyright -Copyright: 2015-2017 David Bremner +Copyright: 2015-2024 David Bremner In terms of copyright, please explain your understanding of copyright what you're doing here. This is not a mere 's/17/24/' symbol manipulation. > Note: this revision drops the dependency on markdown, which is important > so that itself and all its reverse dependencies are free from > bug#1063645 so that they are free from being removed from testing. This is premature. Also, does upstream skip functional tests if a $PATH/markdown binary cannot be called? If this is the case then the correct action is to configure a $PATH/compatible-markdown-replacement. signature.asc Description: PGP signature
Bug#832150: ITA: xmacro -- Record / Play keystrokes and mouse movements in X displays
On Fri, 19 Mar 2021 13:37:40 -0300 Francisco Demartino wrote: > retitle 832150 ITA: xmacro -- Record / Play keystrokes and mouse movements > in X displays > thanks > > (resent, now to control@) Francisco are you still intended to work on this package? I've been preparing an update, and wanted to see if you still intended to adopt the package or not. Happy to work together. Thanks!
Bug#1058697: fonts-fork-awesome: expected files missing?
Hi Paul, Paul Gevers writes: > For src:cacti (of which I'm de-facto the only maintainer) I received a > bug report in Ubuntu (#2046431) about missing files. As cacti doesn't > ship these files, but Depends on fonts-fork-awesome I was wondering if > cacti upstream is shipping "weird" files or if the files are reasonable > to be expected and are just missing to be build/shipped in > fonts-fork-awesome. > > We're at least talking about ./webfonts/fa-solid-900.woff2 and > ./css/all.css. As far as I can tell the above are copies of FontAwesome webfonts. apt-file list fonts-fork-awesome | grep css https://github.com/ForkAwesome/Fork-Awesome/tree/master/css It looks like we're not installing the "min" variant, which wouldn't solve this cacti bug. > See below for my reply to the Ubuntu bug report. > > Paul > > On 14-12-2023 10:13, Francis Greaves wrote: [snip] >> I setup everything, added the Gexport Plugin from here >> https://github.com/Cacti/plugin_gexport, but in the log I had 4 PHP >> errors relating to missing files: >> >> /usr/share/cacti/site/include/fa/webfonts/fa-solid-900.woff2 >> /usr/share/cacti/site/include/fa/css/all.css These look like FontAwesome assets to me. > Did this error only occur after you added the plugin? > >> Looking at the folder structure compared with the official download from >> the Cacti site: Here is the official download of ForkAwesome, which doesn't contain these files: https://github.com/ForkAwesome/Fork-Awesome/archive/1.2.0.zip > In Debian (and hence in Ubuntu) we try to depend on packages providing > functionality instead of embedding other projects in source packages. > For cacti in Ubuntu, the Awesome Font is delivered by the > fonts-fork-awesome package. You'll see that include/fa is a soft-link. > >> the include/fa/css folder only had two items fork-awesome.css and >> v5-compat.css when it should have 16 items >> >> the include/fa/ folder only has 5 items when it should have 10 and in >> particular has NO webfonts at all. >> >> Just as a test before moving to the official download I copied the >> include/fa/webfonts folder and the contents of the include/fa/css folder >> to the Ubuntu install I don't understand what fonts-fork-awesome is supposed to do about this. Isn't this a vendoring issue? > So, I wonder if we should request changes to the fonts-fork-awesome > package. Unfortunately, I'm not experience in how webfonts work. > I confess that I'm not either, but I suspect that src:cacti might need integration work to cope with unvendoring ForkAwesome--if that's the cause of this. My primary hypothesis is that this is upstream src:cacti FontAwesome cruft. Regards, Nicholas signature.asc Description: PGP signature
Bug#1069135: org-bullets: please consider switching to a more up-to-date upstream
Source: org-bullets Version: 0.2.4-3 Severity: normal Hi, I noticed some deprecation warnings in org-bullets' native-compilation log, so searched for an upstream fix. What I found was that our current upstream source is a decade old: https://github.com/sabof/org-bullets and that MELPA provides their users with a package from this fork, which has activity from four years ago: https://github.com/integral-dw/org-bullets It looks like integral-dw's fork might now the defacto upstream, because sabof's project looks dead. Maybe a PR/MR for some of those compilation warnings could be a useful way to test for a living and responsive upstream? Regards, Nicholas
Bug#1069045: Support for propose-updates package archives
Package: live-build Version: 1:20230502 Severity: wishlist live-build currently supports: backports, security and updates package archives with config options: --backports --security --updates It would be useful to also have a `--propose-updates` config option to support adding the proposed-updates archive. https://wiki.debian.org/StableProposedUpdates
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
reopen 1068605 owner 1068605 ! thanks Hi, Sorry I didn't ask this sooner, but would you prefer if I call you Deng, or Xiyue, or something else? Conventions and understanding vary a lot from place to place, after all. Xiyue Deng writes: > Thanks for pointing out #1019031! Totally missed it. I'll opt for > option 1 obviously. Updated team repo and mentors accordingly. You're welcome, and thank you. On a related note, have you read the definitions for source and binary packages? #1019031 was filed against src:web-mode, so was hidden from the bin:elpa-web-mode view. On the BTS the src:package view will display bugs that affect each binary package as well as the src:package. §4 of Policy has the definition, and here is another good resource: https://wiki.debian.org/Packaging/SourcePackage > Also, accordingly to this comment from Tobias[1] it looks like there are > opinions that prefer to reuse existing RFS bugs instead of filing new > ones. Do you think it's OK to reopen this one? There are also people who maintain the opposite position, but in the spirit of harmony I've reopened this bug. [edit: Be careful about only waiting a day and then going ahead and doing something without having received a reply, because when you "ask" for something, but then don't actually wait for a reply, it can make you look disingenuous and/or impatient and/or pushy.] Onto the review: * New upstream release Push the upstream tag to salsa, and find a way to mitigate this issue in the future. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Update standards version to 4.6.2; no changes needed Update this, since a new Policy version was recently released. Did you already work through the upgrade checklist stepwise, starting from 4.3.0? "debian-devel-announce" is a low traffic list that will keep you appraised of stuff like this. * Use https link of homepage in d/control * Modernize d/watch using special substitute strings to be more robust I'm happy to see this clear, concise, and useful phrasing. If you have any pending not-yet-uploaded work that doesn't use this, please update it. If you're interested in a nitpick, the key term is "substitution strings" and not "[special] substitute strings" (see the manpages for uscan and deb-substvars as well as codesearch.debian.net). * Fix issues in d/copyright - Clarify license to be GPL-3+ to be consistent with upstream This is unclear. Which licence was it before, and whose license are you talking about? Web-mode is a non-native package and debian/* is separate from the upstream source. Also, what does it mean to clarify a license? - Update copyright year info for upstream - Add copyright info for debian/* You added a license grant for debian/* where there was previously none with no explanation, notes, nor justification. Are you sure you have the right to do this? Contact debian-legal and ask them for a patch review of your intended changes. - Add Upstream-Contact Thanks for this and for all the other work I didn't comment on. Here are some things you can work on while waiting for a reply from debian-legal: * lintian-explain-tags prefer-uscan-symlink: if you're changing the watch file then this should be addressed * There's also a version qualifier in d/control that can be dropped. * Finally, have you installed and tested your updated package? * Extra/bonus: Which tags from the lintian output are candidates for an override, and why? -N signature.asc Description: PGP signature
Bug#1036799: sylpheed: unable to send or read email after upgrading to Debian 12
I am a long term gmail user and I have tried sylpheed in the past, long before Debian 12. I could not get it to work. From my investigations gmail works with relatively few email clients on Linux. It does however work with Thunderbird. From what I understand it takes a considerable amount of effort (and money) to get an email client to work with gmail. As such it is probably unreasonable to demand any specific email client to do that work. I suggest that the bug be renamed to change "email" to "gmail" and remove "after upgrading to Debian 12".
Bug#1068291: evolution: Spellcheck crashes evolution if a language installed in aspell, but missing in hunspell
Package: evolution Version: 3.46.4-2 Severity: normal Tags: l10n X-Debbugs-Cc: nick.dre...@centurylink.net Dear Maintainer, While aspell language packages installed show up for selection in "Edit -> Preferences -> Composer Preferences -> Spell Checking -> Languages", if one of those aspell languages is selected there and the corresponding hunspell language package has not been installed, evolution will crash with a "Segmentation fault" as soon as one tries to use that language for spell checking. Installing the required hunspell lanuage package resolved the issue. -- System Information: Debian Release: 12.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution depends on: ii dbus [default-dbus-system-bus] 1.14.10-1~deb12u1 ii evolution-common3.46.4-2 ii evolution-data-server 3.46.4-2 ii libc6 2.36-9+deb12u4 ii libcamel-1.2-64 3.46.4-2 ii libecal-2.0-2 3.46.4-2 ii libedataserver-1.2-27 3.46.4-2 ii libevolution3.46.4-2 ii libglib2.0-02.74.6-2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libical33.0.16-1+b1 ii libnotify4 0.8.1-1 ii libwebkit2gtk-4.1-0 2.42.2-1~deb12u1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii psmisc 23.6-1 Versions of packages evolution recommends: ii evolution-plugin-bogofilter 3.46.4-2 ii evolution-plugin-pstimport 3.46.4-2 ii evolution-plugins3.46.4-2 ii yelp 42.2-1 Versions of packages evolution suggests: pn evolution-ews pn evolution-plugins-experimental ii gnupg 2.2.40-1.1 ii network-manager 1.42.4-1 -- no debconf information
Bug#1067663: org-mode: Org mode 9.6.23 that fixes several critical
fixed 1067663 org-mode/9.5.2+dfsh-5 found 1067663 org-mode/9.6.7+dfsg-1 thanks 9.5.2+dfsh-5 in stable/bookworm is an empty package that depends on the org-mode bundled with stable/bookworm's Emacs, so I'm marking this CVE as fixed there. Elpa-org in stable/bookworm will be fixed by a security upload of Emacs. I'm skipping 9.6.6+dfsg-1~exp1, since it's not relevant anymore.
Bug#1067663: org-mode: Org mode 9.6.23 that fixes several critical
reopen 1067663 found org-mode/9.1.14+dfsg-3 found org-mode/9.1.14+dfsg-3+deb10u1 found org-mode/9.4.0+dfsg-1+deb11u1 found org-mode/9.5.2+dfsh-5 thanks Updating the affected versions from: https://security-tracker.debian.org/tracker/CVE-2024-30202 and https://security-tracker.debian.org/tracker/CVE-2024-30205
Bug#1067698: RFS: persist-el/0.6+dfsg-1 [Team] -- persist variables between Emacs Sessions
Control: owner -1 ! Xiyue Deng writes: >[ Xiyue Deng ] >* New upstream release. >* Re-export upstream signing key without extra signatures. $ uscan --download-current-version Newest version of persist-el on remote site is 0.6, specified download version is 0.6 gpgv: Signature made Sat 13 Jan 2024 05:05:03 EST gpgv:using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40 gpgv: Good signature from "GNU ELPA Signing Agent (2019) " gpgv: Signature made Sat 13 Jan 2024 05:05:03 EST gpgv:using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966 gpgv: Can't check signature: No public key uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 77.
Bug#694605: adopting
I guess am adopting this. Please don't expect any upload any time soon as I have too much too learn, and I see too many real issues as described in the bug reports. However if you would like to also work on it or a similar project please do contact me.
Bug#370126: (no subject)
I am trying to reproduce this (or work towards it) but quite frankly I am finding a more general problem. It occasionally dies and all the icons disappear. I assume it is the same problem although the description is not exactly the same.
Bug#1065001: streamdeck-ui: v1.1.2 is years out of date and unmaintained upstream, but here's the living fork
Source: streamdeck-ui Version: 1.1.2-2 Severity: normal X-Debbugs-Cc: Benjamin Drung Hi, When I investigated Debian support for a Streamdeck, I was happy to see we have a package for this. Unfortunately it's several years out of date, is now unmaintained upstream. Here's the relevant commit: https://github.com/streamdeck-linux-gui/streamdeck-linux-gui/compare/main...timothycrosley%3Astreamdeck-ui%3Amaster#diff-185833cb26d7ac66a4d39042fd576a820c2c2c6d05ad18973bb9c7dce77267c5R12 and here's the living fork that our package should probably soon be rebased on: https://github.com/streamdeck-linux-gui/streamdeck-linux-gui Regards, Nicholas
Bug#1064619: Please package v2.6
Package: markdown-mode Version: 2.5-1 Severity: normal X-Debbugs-Cc: s...@debian.org Please package markdown-mode v2.6. Upstream changelog is available here: https://github.com/jrblevin/markdown-mode/releases/tag/v2.6 Regards, Nicholas
Bug#1063752: custodian: Inappriate maintainer address
Might this have been a one-time glitch? The list receives mail from the ftpmaster role address routinely, before and after the bug report: https://alioth-lists.debian.net/pipermail/debichem-devel/2024-February/author.html#16139 If there are no other reported incidents, I'd suggest closing the bug. -- Nicholas Breen nbr...@debian.org
Bug#1063839: lwm: fixed bugs, lintian clean, cross compiles, please review
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: debian-cr...@lists.debian.org, s...@debian.org, np.bam...@gmail.com I have forked lwm so that my work can be reviewed: https://salsa.debian.org/npbamber/lwm If this is approved please grant me permission so I can keep the repository up to date. I am happy with my work here, but I can list somethings potential sponsors might appreciate being pointed out: #920091 - adoption: I have been through the Debian induction process about a decade ago. So I know what packaging involves even if I have things to learn or relearn. My life is more stable now than then, so I am not going to take on long term commitments I can't handle. I will review packages before trying to adopt them. If I don't feel comfortable with this commitment I will just do a QA upload, not touch the package or perhaps even discuss removal of a package. #1031650 - I fixed the trivial typo. However I strongly believe a minimalist window manager should strongly advertise how to start an xterm as it can be hard to get started otherwise. So I made this clear in the control description. #1051010 - I have done what I feel most appropriate here. The first part (systemd environment) is easy to test. The second part - portals - are a bit harder. My journey there is documented on the bug report. If this is not adequate I need some advice. Cross compilation: I had to undertake radical surgery here. The general strategy was to start with upstream's backup makefile and make it as debhelper compliant as possible. However on the opertaing table the patient went through numerous crises. Like flags not being passed onto the compiler (notably dropping hardening.) I checked the old build logs against the new build logs. There were decisions to be made. I was biased to caution but I sought strategiclaly not to get in debhelper's way. All these issues are now resolved. It was quite hard to know how to describe this in the changelog. Lintian: the only overrides are because upstream is inactive and I see no point in contacting them. Rules-Requires-Root: It clearly does not require root to build and I have marked it as such. However the Lintian explanation for this warning is a little bit scary. I did try it both before and after making the change and the only diffoscope difference appeared to be an 8 year difference in certain timestamps. I found this pretty odd. I really appreciate any time and effort you can put into this. Nicholas
Bug#1063649: maint-guide: synatx error in setup instructions for sbuild
Package: maint-guide Severity: important X-Debbugs-Cc: np.bam...@gmail.com Dear Maintainer, Hi Osamu, I think I found an error in section 3.6 (sbuild) of Guide for Debian Maintainers. I think > $ sudo usermod -a -G sbuild should be > $ sudo usermod -a -G sbuild yours Nicholas -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/2 CPU threads; PREEMPT) 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 maint-guide depends on no packages. maint-guide recommends no packages. Versions of packages maint-guide suggests: pn debian-policy pn developers-reference ii devscripts2.23.4+deb12u1 pn dh-make pn doc-base ii dput 1.1.3 ii fakeroot 1.31-1.2 ii lintian 2.116.3 pn pbuilder ii quilt 0.67+really0.66-1
Bug#1051002: dwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
I attach a diff that describes a proposed fix. The file dwm-portals.conf should go into debian/xdg-desktop-portal so as to be installed in /usr/share/xdg-desktop-portal diff -r debian-8/desktop/dwm.desktop debian-9/desktop/dwm.desktop 6a7,14 > X-GNOME-WMName=dwm > DesktopNames=dwm > X-LightDM-DesktopName=dwm > > [Window Manager] > Name=dwm > SessionManaged=true > StartupNotification=false diff -r debian-8/dwm.install debian-9/dwm.install 1a2 > debian/xdg-desktop-portal/* /usr/share/xdg-desktop-portal Only in debian-9/: xdg-desktop-portal [preferred] default=*
Bug#1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
So I have been reading up on flatpak documentation: https://docs.flatpak.org/en/latest/ Reading this it is clear that at least for the moment flatbox sandboxing is more of a line in the sand than the Berlin wall. This explains why the portals config is so hard to test. I attach the two necessary files. I don't know how to test any further and I cannot progress the bug report any more without salsa access. The idea behind the portal file is that lwm would try to use any portal available. I am very certain no new dependencies should be added. I would expect users of lwm are unlikely to be interested in portals and unlikely to have the the xdg-dekstop-portal process running. That said I do think the package should do its best to support users who do want to use flatpak so long as no extra cost to using the package is added. lwm.desktop Description: application/desktop [preferred] default=*
Bug#1063032: idesk: Please write script to convert dekstop files to idesk files
Package: idesk Version: 0.7.5-8 Severity: wishlist X-Debbugs-Cc: np.bam...@gmail.com Dear Maintainer, It would make it easier to switch from more modern desktops to idesk if such a utility script were available. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/1 CPU thread; PREEMPT) 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 idesk depends on: ii libc6 2.37-15 ii libgcc-s1 14-20240201-3 ii libimlib2 1.12.1-1 ii libstdc++6 14-20240201-3 ii libx11-62:1.8.7-1 ii libxft2 2.3.6-1 idesk recommends no packages. Versions of packages idesk suggests: ii x11-utils 7.7+6 -- no debconf information
Bug#1063030: (no subject)
Package: idesk Version: 0.7.5-8 Severity: wishlist X-Debbugs-Cc: np.bam...@gmail.com Dear Maintainer, The home page (https://idesk.sourceforge.net/html/usage.html) has adequate information. However there is almost known in the man page. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/1 CPU thread; PREEMPT) 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 idesk depends on: ii libc6 2.37-15 ii libgcc-s1 14-20240201-3 ii libimlib2 1.12.1-1 ii libstdc++6 14-20240201-3 ii libx11-62:1.8.7-1 ii libxft2 2.3.6-1 idesk recommends no packages. Versions of packages idesk suggests: ii x11-utils 7.7+6 -- no debconf information
Bug#1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
Firstly by copying, pasting and editing the xsessions desktop file from icewm to lwm I have been able to get XDG_CURRENT_DESKTOP=lwm into systemd, without any other files. I can see that this is the cleanest method. That said I infer from what I saw that every display manager is doing its own thing here and that is surely less than ideal. I have played a bit with setting up lwm-portals.conf but at the moment I more interested in trying to see if I can lock it down than write something I would expect to be in a default Debian config. I found the man page for portals.conf a bit confusing here. I have put the file in /usr/share/xdg-desktop-portal/lwm-portals.conf but there also seem to be implementation files in /usr/share/xdg-desktop-portal/portals and I find that a bit confusing. Secondly I saw a youtube video saying that discord totally ignores sandboxing so I won't be using that for testing. I have played about with GNOME recipes and ASHPD demo and I am still not seeing much difference. From what I can see they are just following UNIX permissions with no additional sandboxing. or the portal tests built by src:libportal (install libportal-tests-gtk3 and libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in the environment, or you can build them into Flatpak apps from the source package). Those are a lot more meaningfully sandboxed. I am still trying to understand what is being suggested here. Working on it. I can say that if I try to build xdg-desktop-portal I get some test failures: 9/28 xdg-desktop-portal:portals / test-portals-location ERROR 26.28s killed by signal 6 SIGABRT^M 12/28 xdg-desktop-portal:portals / test-portals-openuri TIMEOUT 30.01s 9 subtests passed but I don't think I had read the suggestion correctly when I tried this.
Bug#1051010: Bug #1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
Simon, Thanks for the hints. I will explore them. (and sorry about the email title.) Nicholas On 02/02/2024 14:42, Simon McVittie wrote: I've changed the subject line back to the one from the bug - I get a *lot* of bugmail, which I usually see out-of-context, so "Investigating" doesn't really work as a reminder of what bug and what package you're talking about. I hope that's compatible with your workflow. On Fri, 02 Feb 2024 at 12:11:13 +, Nicholas Bamber wrote: So far in order to investigate I have: 1. installed discord on a lwm desktop via flatpak. This works but is pretty ugly and the whole filesystem is exposed. Large proprietary apps containing an entire web browser engine tend not to be feasible to sandbox meaningfully, unfortunately, especially if their packagers want them to have full functionality for users who are unaware of the existence of sandboxing and want everything to "just work". My usual go-to test apps are GNOME Recipes https://flathub.org/apps/org.gnome.Recipes, ASHPD demo https://flathub.org/apps/com.belmoussaoui.ashpd.demo, or the portal tests built by src:libportal (install libportal-tests-gtk3 and libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in the environment, or you can build them into Flatpak apps from the source package). Those are a lot more meaningfully sandboxed. 2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user environment. In the original bug report, part of the solution I suggested was this: Add a sequence of semicolon-separated desktop environment names to /usr/share/xsessions/lwm.desktop, most likely just "Lwm": DesktopNames=Lwm; (For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in their equivalent xsessions file.) Most display managers take this into account and will convert it into setting the XDG_CURRENT_DESKTOP setting (for example, I know that gdm3, lightdm and sddm do this). This won't work for xdm, but at some point I think we have to start treating that sort of thing as an xdm limitation, rather than something that individual desktop environments are expected to address? Putting a script into the 55 priority in /etc/X11/Xsession.d. This works (and does not pollute other desktop environments since we can check at that point). However it depends on the the package dbus-x11 and I have concerns about the long term support for this package. Doesn't the combination of these two files dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime dbus-x11: /etc/X11/Xsession.d/95dbus_update-activation-env already do what's needed here? Those two packages represent the only two implementations of the dbus-session-bus virtual package that currently exist in Debian. xdg-desktop-portal already depends on default-dbus-session-bus | dbus-session-bus, so whenever xdg-desktop-portal is installed, so is at least one of those two packages; and they both pull in dbus-bin, which provides /usr/bin/dbus-update-activation-environment. If someone adds a third implementation of dbus-session-bus, I think it would be entirely reasonable for us to expect it to have similar handling of at least the most basic variables like DBUS_SESSION_BUS_ADDRESS, DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP. The other possible way to do this, which *would* work even for xdm, is to do like gnome-session does, and upload at least those few basic environment variables to the D-Bus activation environment during GUI session startup, either from the main executable (using libdbus or a similar library) or from a shell script wrapper (using dbus-update-activation-environment or equivalent). This wouldn't necessarily have to imply a hard dependency on d-u-a-e, it could be done conditionally. I realise that this is unappealing for a specifically lightweight desktop environment, so I'd be fine with the answer to this particular part being "wontfix, use a better display manager if you want this functionality". smcv
Bug#943917: some thoughts
I have come to believe this is not a bug. It may be that environment.d is very nice for systemd integration, but it is not very granular. Any environment entered via that route will end up in systemd user environments possibly even when it was not intended. Scripts in Xsession.d on the other hand may well write over environment variables but they are written in generic shell scripts and so can be tailored to only set environment variables in specific circumstances. I would guess (and I am guessing here) that environment.d gets processed before Xsession.d, and so scripts in Xsession.d could choose not override environment variables that have already been set if appropriate.
Bug#1051010: Investigating
So far in order to investigate I have: 1. installed discord on a lwm desktop via flatpak. This works but is pretty ugly and the whole filesystem is exposed. 2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user environment. Putting a script into the 55 priority in /etc/X11/Xsession.d. This works (and does not pollute other desktop environments since we can check at that point). However it depends on the the package dbus-x11 and I have concerns about the long term support for this package. Looking at bug #943917, I see these concerns over the dbus-x11 package and a suggestion that environment.d be used. However this is unacceptable because that will load the environment variables irrespective of what desktop environment is chosen. Specifically I have tested it shows up in "systemctl --user show-environment" but does not show up in "env" when you login to an openbox desktop. So the Xsession.d approach seems to be the way to go, but I also have concerns about how many dependencies (even at the suggests level) should be added to a package intended to be lightweight. Obviously this could all be documented.
Bug#940016: I can't reproduce
Control: tags 940016 + unreproducible + moreinfo I have a sddm set up with lwm as one of the options and it has not happened to me so far. Have you tried looking in your ~/.xsession-errors ? I guess you would need to reboot to be able to access given that you are dealing with a screen freeze. Anything relevant could be posted here. Nicholas
Bug#1061727: [Debichem-devel] Bug#1061727: gromacs: please add support for loong64
On Mon, Jan 29, 2024 at 07:51:04AM +, wuruilong wrote: > Source: gromacs > Severity: normal > X-Debbugs-Cc: wuruil...@loongson.cn > > Dear Maintainer, > > The attached patch fixes the compilation error problem in the loong64 > architecture, and the local compilation passes. Thank you for working on this! I think the patch would best be applied upstream, for the benefit of all distributions. They prefer to take gitlab merge requests. Is that something you'd be willing to submit (you're certainly in a better position to answer questions!), or would you like me to do so? https://manual.gromacs.org/current/dev-manual/contribute.html -- Nicholas Breen nbr...@debian.org
Bug#1061157: RFS: mini-httpd/1.30-7 -- Small HTTP server
Control: owner -1 ! Hi Alexandru, Happy New Year! I'll sponsor this one. In the future please use "reportbug sponsorship-requests" and enter my email at the "Enter any additional addresses this report should be sent to; press ENTER after each address. Press ENTER on a blank line to continue" step, because the method you use doesn't let the additional recipient[s] reply to the bug. If you want to use another method, please add the following pseudoheader: X-Debbugs-Cc: additional@recipient addresses@list ie@me Gentle reminder not to push tags until the package has been accepted into the archive. It would also be nice to see you use end punctuation again. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1042364: closed by Debian FTP Masters (reply to Félix Sipma ) (Bug#1042364: fixed in syncthing 1.27.2~ds4-1)
"Debian Bug Tracking System" writes: > #1042364: syncthing: update to v1.23.6 at least [snip] > Source: syncthing > Source-Version: 1.27.2~ds4-1 > Done: Félix Sipma Thank you Félix! Your work is appreciated by many Debian users (and DDs!) who have been unhappy about having to use the 3rd party package, and I hope that you are considering adding yourself to Uploaders :) Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1019377: ERROR: cannot flip ro->rw with received_uuid set
Boris Kolpackov writes: > Thanks for the clarification. Interestingly, in my use case I do > want to be able to do incremental send/receive and the only reason > I am temporarily clearing the read-only property is to change the > subvolume's owner: Why don't you create of a normal rw snapshot of the received subvol, use it for whatever purposes you need to write to it for, and then delete the temporary rw snapshot subvol? This approach doesn't compromise the integrity of your replica. > sudo btrfs property set -f -ts ./subvol ro false > sudo chown user:user ./subvol > sudo chown user:user ./subvol/* > btrfs property set -ts ./subvol ro true > > I wonder if there is now a way to achieve this without clearing > received_uuid? What problem are you attempting to solve? Regards, Nicholas signature.asc Description: PGP signature
Bug#1060099: telegram-desktop: FTBFS on mips64el: ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:16435:(.text+0x1600a0): relocation truncated to fit: R_MI
Hello! On 06.01.2024 00:09:14 MSK you wrote: > CMakeFiles/td_scheme.dir/gen/scheme.cpp.o: in function `MTPDchannel::read(int > const*&, int const*)': > ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:16435:(.text+0x1600a0): > relocation truncated to fit: R_MIPS_GOT_PAGE against `.text' > CMakeFiles/td_scheme.dir/gen/scheme.cpp.o: in function `MTPDuser::read(int > const*&, int const*)': > ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:15827:(.text+0x16139c): > relocation truncated to fit: R_MIPS_GOT_PAGE against `.text' > collect2: error: ld returned 1 exit status Sorry, I have no idea how to properly fix this linker error. The aforementioned translation unit already uses compiler flags -mxgot -fPIC. They helped before. It seems the scheme.cpp has reached the limit of code size of single TU. Primary platform for Telegram Desktop is amd64; arm64 is also somewhat popular. This issue is platform specific. And I daresay it is not that serious to block release on unaffected architectures. signature.asc Description: This is a digitally signed message part.
Bug#1057687: telegram-desktop: calls broken due to old libsrtp not supporting openssl 3.0 on libtgowt (stable)
Control: tags -1 unreproducible Hello! I just retested in the current stable, bookworm, peer-to-peer calls and video chats (or group calls) and they work. Audio, video, and screenshare work okay. I checked both versions, 4.6.5+ds-2 and backported 4.8.1+ds-2~bpo12+1. These versions were built against libtgowt (= 0~git20230615.a45d8b8+dfsg-2) and depend on libsrtp2-1 (>= 2.0.0+20161214) as well as libssl3 (>= 3.0.0). I see these packages are installed on your system (as per your report). Version 0~git20230615.a45d8b8+dfsg-2 is the first where I unbundled the SRTP library, so I have no clue why calls are not working in your case. No camera or no microphone may be connected or Telegram Desktop does not detect the devices. If this issue is still relevant, can you please provide the log at path ~/.local/share/TelegramDesktop/log.txt ? signature.asc Description: This is a digitally signed message part.
Bug#1057559: emacs-wgrep: FTBFS: Error: error ("Test ‘wgrep-normal’ redefined")
Xiyue Deng writes: > Done. Also reuploaded to mentors just in case. > Thanks, I've sponsored your upload. Please push the release tag to git at your earliest convenience. signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Hi, Paul Wise writes: > On Mon, 2023-12-04 at 02:28 -0800, Xiyue Deng wrote: > >> I think dh_auto_clean is the right place, because the build failure is >> because that the clean target requires the existence of >> scala-mode-pkg.el, which is generated by Cask. As we don't have Cask, >> we need to provide this before dh_auto_clean runs. The generation of this metadata, and file, is one of dh_elpa's primary functions. See the section of the dh_elpa man page that discusses DEB_VERSION_UPSTREAM. Read Policy §4.9 closely; Cask cannot be used. Grep the buildlog for "dh_" and if you'd like to see a more comprehensive list of applicable entry points in the sequence, try $ dh binary-indep --no-act It's also worth reading the dh man page. > I think it is against ftp-master rules to have generated files > present that can't be built using only tools from Debian main. Yes, and thank you for bringing this up. > So I think you would need to package Cask first? Cask is not relevant nor needed, and dh_elpa is used. Whenever this topic comes up on IRC, new contributors are briefed and are additionally referred to the RFP for Cask, where the unsuitability of this type of tool for Debian packaging is discussed (#837922). It's also worth noting that dh_elpa was written by people by current and/or past members of the Debian TC. Xiyue Deng writes: > Cask and similar tools like Eask and Eldev are tools that automatically > install dependencies of an Emacs addon package, which doesn't use and > circumvents the system package management. I think the Emacsen team > chooses not to package those tools and prefers using dh-elpa for the > job, and may override build target to avoid using those tools. If you're familiar with the concept of "hats", then when you're working on debian/* you need to put on your Debian packaging hat, and when you're working on !(debian/*) you use your upstream development/debugging/packaging hat. These tools are not relevant to Debian packaging and referring to them is not useful for describing packaging problems or decisions; there will always be a more direct and useful description. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1057559: emacs-wgrep: FTBFS: Error: error ("Test ‘wgrep-normal’ redefined")
Xiyue Deng writes: > Control: tags -1 pending > > Hi, > > I have prepared a patch[1] that fixes this issue and also forwarded it > upstream[2]. I have also prepared the package on mentors[3]. Please > consider reviewing and sponsoring it. TIA! > > [1] > https://salsa.debian.org/emacsen-team/emacs-wgrep/-/commit/62bc99d768bcb290612b834c668f131e9f5b53f0 > [2] https://github.com/mhayashi1120/Emacs-wgrep/pull/93 > [3] https://mentors.debian.net/package/emacs-wgrep/ > -- > Xiyue Deng Looks good. Go ahead and finalise the package, and delete changelog:L4 whitespace at that time. --N signature.asc Description: PGP signature
Bug#1056998: cdrom: Installation media changes after booting it
On Mon, Dec 4, 2023, 3:30 AM Thomas Schmitt wrote: > . > This seems to indicate that the firmware has a stake in the problem ... > > > Both the Thinkpad E14 Gen 5s had the same specifications and type number, > > differing only in that the one with corruption of the installer has 24GB > of > > memory (16GB installed in the slot, 8GB soldered) and the other only has > 8GB > > soldered. They both have the same BIOS version, R2AET32W(1.07). > > ... but the trigger would have to be very subtle. > > > This seems to be really interesting because the corruption only happened > on > > certain computers, and it would stay that way on repeated attempts. > FWIW check the BIOS L[123] cache settings and consider changing them to more conservative "slower" values if possible. And you have different RAM models and configurations, could there be one DIMM in the mix that is running overclocked? Have a nice day :) > > Thomas > Grüß Gott :-)
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Xiyue Deng writes: > Nicholas D Steeves writes: >> Xiyue Deng writes: >>> Nicholas D Steeves writes: >>> > > There are about 3 years of newer commits since 1.1.0, and one of the > major changes is that it adds support of scala 3 syntax which is not yet > in a tagged release and would be good to have. Ok, you've convinced me :) Convey this information in your changelog (that's what it's for), because the human maintainer (and any interested users) of this package deserves to know why you made this change. > Also seeing the last commit is from the end of last year, I sense that > upstream may becoming a bit dormant for the time being, which is why I > prefer to package the latest snapshot instead of waiting for a stable > release. This can also mean that we run the risk of becoming defacto upstream if they quit at this point, but that said, I agree it's a good cut point as well as the right thing to do. >> Also, do you use this package? >> > > Not on a regular basis, but I do use it a bit once in a while as I try > to learn a bit of new programming languages every few months. Thanks for confirming! [snip] > And then I just realized: why not just host the scala-mode-pkg.el file > and substitute the version so that we don't need to update it manually > on each update? This is now implemented at [1]. Substvars make sense ;) Also, neat use of a makefile target called from within the dh sequence. Are you sure dh_auto_clean is the right place for this override? Skim its man page, as well as the one for dh_clean before replying. Also, whenever one overrides something in rules, one needs to document this in the changelog. Please use "cp -a" so timestamps between builds will be reproducible. What is the rationale for CURDIR? From what I can tell it isn't needed and should be dropped. >> Do you see what will happen when the package is updated to >> 1.1.1 or newer? Also, why did you choose to set the version to "0.23" >> rather than "1.1.0"? > > Well I didn't choose it (if I did I'd use 1.1.0 :) This is the version > specified in scala-mode.el[2]. I like your choice, and so what if upstream has that! Is it correct? >> Did you verify that elpa package version is consistent with the >> upstream version of the Debian package in bin:elpa-scala-mode that is >> consumed by users (the binary package)? >> > > I tried install it from stable.melpa.org and yeah it's being > installed as scala-mode-0.23 even if it's registered as version 1.1.0 > there[3]. So it's consistent in a sense :P Oh my! Sorry for the convoluted sentence I wrote, and I'm impressed that you were able to make sense of it. Yes, stable.melpa.org publishes a scala-mode version 1.1.0 elpa package, which contains a scala-mode.el file with "Package-Version: 0.23", and it also contains a scala-mode-pkg.el file that overrides the Package-Version to `1.1.0`. It is because of this pkg.el file that elpa/scala-mode-1.1.0 subdir. Meanwhile our elpa-scala-mode 1.1.0-* all declare 0.23, and install to a scala-mode-0.23 subdir. Thank you for your kind optimism, that's very gracious. Your work reveals that I missed this issue when reviewing 1.1.0-1, which I appreciate having pointed out. Lets fix it in the upload you've proposed. > Anyway, I have just made a pull request to update this upstream[4] so > hopefully the versioning will be sane. Thank you, and hopefully they'll agree. >>>>>* Modernize d/watch using special substitute strings. >>>> >>>> Ok, but why? >>>> >>> >>> I believe this provides a more robust way of detecting tags and should >>> be an encouraged practices. From my own experience, when I find a >>> d/watch file that doesn't work I may search for other packages to learn >>> from existing practices, and some may not work well as different >>> upstream may follow different conventions. The substitute strings use a >>> more robust and tested regexp that works most of the time, and promoting >>> its use may save people's time instead of working on an ad-hoc regexp. >> >> Sounds good! This is the kind of rationale that should be in the >> changelog, so please add it there :) From now on, read your changelog >> and patche desriptions, and imagine I'm asking you "ok, but why" for >> each point. Yes, rarely something is self-evident and/or an >> implementation detail, but most of the time you should say a few words >> explaining "why"--particularly when you want to find a sponsor quickly. >> My expectation is that you get better at this with each review, and that >> you will apply everything you learned to all pending sponsorship >>
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Xiyue Deng writes: > Nicholas D Steeves writes: > > >> Have you asked upstream to tag a release? >> > > Not before your review but done by now at [1] Thank you. You may have heard that Debian is a distribution that privileges the stable release model... When the human maintainer of a Debian package tracks stable releases, why is importing a snapshot justified? Also, do you use this package? >>>* Override clean rules in d/rules to fix building. (Closes: >>>#1052917) >> >> I believe you already know that >> >> override_dh_auto_clean: >>/bin/true >> >> is an incorrect approach. >> > > Indeed it was not ideal. Upstream depends on Cask to generated the > scala-mode-pkg.el file that is used in the clean target to get the name > of the generated tarball, and indeed using this lazy approach is > incorrect. I've now included the generated pkg file through a patch to > make this work in [2]. Consistency is essential between an explanation (in a comment or changelog) and the work that was done. Statically defining package metadata is fine, but in this case you can't claim that you're generating the pkg.el file. Either make the changelog and patch description consistent with what is actually happening, or change the implementation so that something is actually generated (there are multiple approaches here). I think I tend to use makefile substvars for this. Do you see what will happen when the package is updated to 1.1.1 or newer? Also, why did you choose to set the version to "0.23" rather than "1.1.0"? Did you verify that elpa package version is consistent with the upstream version of the Debian package in bin:elpa-scala-mode that is consumed by users (the binary package)? >>>* Modernize d/watch using special substitute strings. >> >> Ok, but why? >> > > I believe this provides a more robust way of detecting tags and should > be an encouraged practices. From my own experience, when I find a > d/watch file that doesn't work I may search for other packages to learn > from existing practices, and some may not work well as different > upstream may follow different conventions. The substitute strings use a > more robust and tested regexp that works most of the time, and promoting > its use may save people's time instead of working on an ad-hoc regexp. Sounds good! This is the kind of rationale that should be in the changelog, so please add it there :) From now on, read your changelog and patche desriptions, and imagine I'm asking you "ok, but why" for each point. Yes, rarely something is self-evident and/or an implementation detail, but most of the time you should say a few words explaining "why"--particularly when you want to find a sponsor quickly. My expectation is that you get better at this with each review, and that you will apply everything you learned to all pending sponsorship requests in addition to future ones. >>>* Add more metadata in d/upstream/metadata. >> >> https://github.com/hvesalai/emacs-scala-mode/commits/master >> >> is a git history log, not a changelog nor release notes. >> > > I thought the git history log may be considered an alternative form of a > Changelog. Looks like I was wrong except for projects that requires the > same format across changelog/git history/release notes. I've dropped > that line in [3]. Thank you. Re: "projects that requires the same format across changelog/git history/release notes": Changelogs, NEWS files, and release notes are three (or arguably two) distinct types of documentation that are also distinct from VCS history. This isn't a superficial formatting or style thing, because they have different audiences and purposes. I think that the kind of changelog that you're probably thinking of it when upstream takes git's shortlog history, puts it in a file, and edits it so that it makes sense. >>>* Update year and Upstream-Contact and add myself in d/copyright. >> >> Why did you add yourself? >> https://en.wikipedia.org/wiki/Threshold_of_originality >> >> I'm happy to support your claim, but you'll need to work for it in more >> than a "sweat of the brow"/mechanical sense. >> > > To be honest, the only reason I did this is to suppress the > "update-debian-copyright" lintian warning which is actually > experimental. I believe what I did was in the same nature as Sławomir > did in 2020 though admittedly not to the same extent, so I've reverted > this part in [4]. Cool. Yeah, lintian has these tags: error, warning, info, pedantic, experimental. Which ones do you think are suggestions, and which one[s] require a mandatory fix? Note that suggestions ar
Bug#1056951: ITP: elpa-lin -- Lin is a stylistic enhancement for Emacs’ built-in hl-line-mode
Hi Dhavan, Dhavan Vaidya writes: > I have begun packaging: > > https://salsa.debian.org/codingquark/elpa-lin > > Feedback welcome. The salsa project/git repo path shouldn't have an "elpa-" prefix (that prefix is used for the binary package[s]). This source package is currently named "lin". Did you read our package name policy? https://wiki.debian.org/Teams/DebianEmacsenTeam Read about what a source package is in Policy §4, and about what a binary package is in Policy §3. https://www.debian.org/doc/debian-policy/ The package FTBFS in a clean schroot (looks like missing build-depends). https://wiki.debian.org/FTBFS There are a couple issues that lintian can help you identify, and I recommend that you configure gbp and/or sbuild to run lintian by default. Best, Nicholas signature.asc Description: PGP signature
Bug#1037135: please update to latest upstream version (>> 4.2.0) and confirm intent to maintain package
Hi Dhavan, Dhavan writes: > On Monday, 10 July 2023 at 03:19, Nicholas D Steeves wrote: > >> You've got this! :) You're already using a gbp (git-buildpackage) style >> git repository so this is very easy. Just use the Files-Excluded >> feature of debian/control, and run "gbp import-orig --uscan". > > I have finally pushed the update! Hopefully the package is built properly. Yay! Hopefully you tested that the package builds ;) Yes, I confirm that it appears to build fine on my system, but did you run lintian? I didn't investigate more deeply due to errors. > I have verified that docs are indeed excluded. Thank you for double checking. > I can update `Uploader` section as well to reflect my new working email, but > haven't pushed the change yet. Is it recommended that I do this(it probably > is)? As discussed previously a package whose human maintainer can't be reached at the email address specified in Uploader (or Maintainer for non-team packages) effectively doesn't have a human maintainer, so yeah, this will need to be updated, but... If you're working towards DM or DD privileges, and you only want to use one GPG key for future non-sponsored uploads (ie: if you want upload privileges) then you might want to reconsider the use of Proton Mail. I've been notified of the issue a couple of times, so started a discussion here to see what other people think: RFC: advise against using Proton Mail for Debian work? https://lists.debian.org/debian-devel/2023/11/threads.html To be clear, yes, it's OK to use this email provider in Uploader for sponsored uploads, and it works fine on the mailing lists :) You can wait until later for the rest, if you want, or you can start What I mean is that it can't be used for DM or DD uploads nor for voting. Meanwhile, I now see that you have a third address: https://salsa.debian.org/codingquark/elpa-lin/-/blame/debian/debian/control#L5 > Any specific things I should consider? Running lintian... E: modus-themes source: license-problem-gfdl-invariants invariant part is: with no invariant sections, with the front-cover texts being â??a gnu manual,â?? and with the back-cover texts as in (a) below [doc/modus-themes.info] E: modus-themes source: license-problem-gfdl-invariants invariant part is: with no invariant sections, with the front-cover texts being â??a gnu manual,â?? and with the back-cover texts as in (a) below [doc/modus-themes.org] E: modus-themes source: source-ships-excluded-file doc/doclicense.texi [debian/copyright:5] E: modus-themes source: source-ships-excluded-file doc/modus-themes.info [debian/copyright:5] E: modus-themes source: source-ships-excluded-file doc/modus-themes.org [debian/copyright:5] To be fair, it looks like your updated work wasn't pushed to salsa. Do you know about "gbp push" which pushes upstream branch+tag and pristine-tar? I: modus-themes source: out-of-date-standards-version 4.5.0 (released 2020-01-20) (current is 4.6.2) I: modus-themes source: repackaged-source-not-advertised [debian/copyright] You can use "lintian-explain-tags repackaged-source-not-advertised" or run lintian with "-i" or "--info" to learn about any of these. https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F Also, don't forgot to fix up the watch file to handle the repacked suffix. The solution for this is in the Debian wiki. > Thanks for the hints, those helped me be super quick about the things. You're welcome. I didn't provide a complete solution the mentorship process is supposed to cultivate problem solving, rather than checklist-following (ie: robot work). Some work should to automated though. For example, you should learn how to make lintian run automatically when you build a package. Best, Nicholas
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- transitional dummy package, scala-mode-el to elpa-scala-mode
Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code Xiyue Deng writes: [snip] >[ Xiyue Deng ] >* Sync to latest upstream head (5d7cf21). Have you asked upstream to tag a release? >* Override clean rules in d/rules to fix building. (Closes: >#1052917) I believe you already know that override_dh_auto_clean: /bin/true is an incorrect approach. >* Modernize d/watch using special substitute strings. Ok, but why? >* Add more metadata in d/upstream/metadata. https://github.com/hvesalai/emacs-scala-mode/commits/master is a git history log, not a changelog nor release notes. >* Update year and Upstream-Contact and add myself in d/copyright. Why did you add yourself? https://en.wikipedia.org/wiki/Threshold_of_originality I'm happy to support your claim, but you'll need to work for it in more than a "sweat of the brow"/mechanical sense. >* Use xz compression in d/gbp.conf. Why is this useful when it has been the default since gbp 0.9.15? Best, Nicholas signature.asc Description: PGP signature
Bug#1054919: kaccounts-providers: google authentication hang after username entry
Hi Dmitry! Dmitry Shachnev writes: > Hi everyone! > > Sorry for the late reply, but let me try to answer the questions which remain > unanswered. Thank you for finding the time to reply and to explain the Qt side of things :) > On Sun, Oct 29, 2023 at 07:43:51PM +0100, Alexis Murzeau wrote: [snip background] > >> Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead. >> I guess signon-ui should move to QtWebEngine instead but sadly upstream >> seems rather dead :(, the previous signon-ui release was more than 5 >> years ago. > > Yes, Qt WebKit does not support Qt 6, so the only choice is to migrate to > Qt WebEngine which is supported much better. I would recommend doing that > even if you stay on Qt 5. I've filed #1055855 for this purpose, with a link to a breadcrumb trail from SUSE. > Unlike Qt WebKit which is based on Apple WebKit, Qt WebEngine is based on > Chromium codebase. > > Qt WebEngine user agents will look the following: > > Qt 5.15: > Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) > QtWebEngine/5.15.15 Chrome/87.0.4280.144 Safari/537.36 So if we backport signon-ui's future Webkit -> WebEngine fix to bookworm, Google might still blacklist bookworm kaccounts users for having a user agent string that advertises an ancient browser? Chrome/87.0.4280.144 is pretty old. That said, I assume there are security reasons why we should use WebEngine and not Webkit in bookworm? Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1055855: We need to switch to a version that uses Qt WebEngine
Source: signon-ui Version: 0.17+16.04.20151125-1 Severity: important Control: tag -1 trixie Continuing from Dmitry Shachnev (mitya57)'s message at the kaccounts-providers bug that is affected by this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054919#51 We need to switch to a signon-ui release that uses Qt WebEngine rather than the dead Qt WebKit, and we need to do this before trixie. Honestly, the sooner the better... When I was searching for a living upstream for signon-ui, I found that SUSE appears to use a version that has already switched to WebEngine: https://packagehub.suse.com/packages/signon-ui/0_17+20171022-bp155_3_16/ I didn't investigate more than that, but it looks like there is already a resolution. It might just be a question of switch to a more alive upstream, and/or replicating a SUSE patch series (I didn't check). Also, it might be a good idea import the changes as patches (whether from upstream, new upstream, and/or SUSE) so that we can backport them more easily to bookworm, because Google is not totally unreasonable to experimented with blacklisting a web browser user agent string that dates to 2016! Regards, Nicholas
Bug#1055656: bookworm-pu: package ms-gsl/4.0.0-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
[ Reason ]
The libmsgsl-dev package in stable is currently incompatible with std::variant
from GNU's libstdc++. To solve this issue, I propose a patch adding conditional
noexcept for the gsl::not_null template constructors.
[ Impact ]
My fix is necessary for backporting the newer versions of the telegram-desktop
package to the bookworm release. This is merely a bug fix so it should go to
stable-updates as per policy. https://backports.debian.org/Contribute/#index1h3
[ Tests ]
Manual. Published and viewed stories in Telegram Desktop.
[ Risks ]
Little. This header-only library has only one dependant, and for the changes to
be effective, the dependant package is need to be rebuilt.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Only single new patch with the fix and autotests. For convenience, you can
review the difference in our GitLab.
https://salsa.debian.org/debian/ms-gsl/-/compare/debian%2Fmaster...debian%2Fbookworm
[ Other info ]
Additional information can be obtained from the related bug reports here, in
Debian bug tracker, and on GitHub.
diffstat for ms-gsl-4.0.0 ms-gsl-4.0.0
changelog|6 +
patches/Mark-gsl-not_null-constructors-as-noexcept.patch | 60 +++
patches/series |1
3 files changed, 67 insertions(+)
diff -Nru ms-gsl-4.0.0/debian/changelog ms-gsl-4.0.0/debian/changelog
--- ms-gsl-4.0.0/debian/changelog 2022-02-05 23:19:23.0 +0300
+++ ms-gsl-4.0.0/debian/changelog 2023-11-09 20:07:33.0 +0300
@@ -1,3 +1,9 @@
+ms-gsl (4.0.0-2+deb12u1) bookworm; urgency=medium
+
+ * New Mark-gsl-not_null-constructors-as-noexcept.patch (Closes: #1051289)
+
+ -- Nicholas Guriev Thu, 09 Nov 2023 20:07:33 +0300
+
ms-gsl (4.0.0-2) unstable; urgency=medium
* Ignore -Wpsabi warnings on PowerPC.
diff -Nru ms-gsl-4.0.0/debian/patches/Mark-gsl-not_null-constructors-as-noexcept.patch ms-gsl-4.0.0/debian/patches/Mark-gsl-not_null-constructors-as-noexcept.patch
--- ms-gsl-4.0.0/debian/patches/Mark-gsl-not_null-constructors-as-noexcept.patch 1970-01-01 03:00:00.0 +0300
+++ ms-gsl-4.0.0/debian/patches/Mark-gsl-not_null-constructors-as-noexcept.patch 2023-11-08 17:00:49.0 +0300
@@ -0,0 +1,60 @@
+Description: Mark gsl::not_null constructors as noexcept when underlying type can be moved with no exception
+Bug-GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106547
+Bug-Debian: https://bugs.debian.org/1051289
+Forwarded: https://github.com/microsoft/GSL/pull/1135
+Author: Nicholas Guriev
+Last-Update: Tue, 05 Sep 2023 23:00:33 +0300
+
+--- a/include/gsl/pointers
b/include/gsl/pointers
+@@ -87,19 +87,19 @@ public:
+ static_assert(details::is_comparable_to_nullptr::value, "T cannot be compared to nullptr.");
+
+ template ::value>>
+-constexpr not_null(U&& u) : ptr_(std::forward(u))
++constexpr not_null(U&& u) noexcept(std::is_nothrow_move_constructible::value) : ptr_(std::forward(u))
+ {
+ Expects(ptr_ != nullptr);
+ }
+
+ template ::value>>
+-constexpr not_null(T u) : ptr_(std::move(u))
++constexpr not_null(T u) noexcept(std::is_nothrow_move_constructible::value) : ptr_(std::move(u))
+ {
+ Expects(ptr_ != nullptr);
+ }
+
+ template ::value>>
+-constexpr not_null(const not_null& other) : not_null(other.get())
++constexpr not_null(const not_null& other) noexcept(std::is_nothrow_move_constructible::value) : not_null(other.get())
+ {}
+
+ not_null(const not_null& other) = default;
+--- a/tests/notnull_tests.cpp
b/tests/notnull_tests.cpp
+@@ -24,6 +24,7 @@
+ #include // for uint16_t
+ #include // for basic_string, operator==, string, operator<<
+ #include // for type_info
++#include// for variant, monostate, get
+
+ #include "deathTestCommon.h"
+ using namespace gsl;
+@@ -489,6 +490,17 @@ TEST(notnull_tests, TestNotNullConstruct
+ }
+ #endif
+ }
++
++TEST(notnull_tests, TestVariantEmplace)
++{
++int i = 0;
++std::variant> v;
++v.emplace>();
++
++EXPECT_FALSE(v.valueless_by_exception());
++EXPECT_TRUE(v.index() == 1);
++EXPECT_TRUE(std::get<1>(v) == );
++}
+ #endif // #if defined(__cplusplus) && (__cplusplus >= 201703L)
+
+ TEST(notnull_tests, TestMakeNotNull)
diff -Nru ms-gsl-4.0.0/debian/patches/series ms-gsl-4.0.0/debian/patches/series
--- ms-gsl-4.0.0/debian/patches/series 2022-02-03 18:42:25.0 +0300
+++ ms-gsl-4.0.0/debian/patches/series 2023-11-08 17:00:49.0 +0300
@@ -1 +1,2 @@
+Mark-gsl-not_null-constructors-as-
Bug#1054919: kaccounts-providers: google authentication hang after username entry
Hi, I received a report from sney (in #debian-qt-kde on OFTC) that a workaround is no longer necessary in either kaccounts-providers or signon-ui. Thus it sounds like this was a case #1 problem (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054919#24) 1. Google refuses to talk to Qt webkit/QtWebEngine that identifies itself accurately. and it appears that they've reverted the action that broke everyone's access to their Google accounts. This is the most correct solution and the best possible outcome. Alexis and Peter, would you please confirm that the workaround is no longer necessary? And please leave the bug open even if Google accounts are working again, because the frequency of this breakage has been mounting. To everyone reading this: If user spoofing doesn't solve the next incidence of breakage then that would indicate a separate issue, and please file a separate bug in this case! Cheers, Nicholas signature.asc Description: PGP signature
Bug#1054919: kaccounts-providers: google authentication hang after username entry
Hi Alexis, and anyone else reading this, Alexis Murzeau writes: > I'm not sure how Qt webkit works, but I guess it behaves like a old > chrome browser. I don't know if it uses a different user agent, but > maybe Google doesn't recognize that it doesn't support newer web stuff. Exactly, that's what I'm wondering. In terms of cases, the possibilities I can think of are these cases (what you write above would be case #3): 1. Google refuses to talk to Qt webkit/QtWebEngine that identifies itself accurately. * Arguably the most correct thing to do here is for webkit and WebEngine to continue to accurate identify themselves, and only masquerade when absolutely necessary. Qt doesn't seem like the right place to maintain a huge list, so kaccounts-providers would override it with a sufficiently old enough Firefox version whose features it actually and functionally supports for the purposes of authenticating. Totally reasonable and with historical precedent. The ideal solution of course is a more open Web where Google stuff will continue to talk to non-Google, non-Apple, and non-Mozilla stuff. 2. Or Qt webkit self-identifies as a version of Firefox that is newer than what it can actually support. * In this case, there is a bug in Qt webkit that needs to be fixed. 3. Or Qt webkit masquerades as an old nonLTS version of Chrome, Chromium, or Firefox that Google has dropped support for. * As you note below, webkit appears dead upstream (replaced by QtWebEngine), and it would be wrong for it to masquerade as a browser whose features it can't actually support in the general case. Ie, probability of triggering bugs... I really hope this isn't where we find ourselves, but if this is where we are, then I guess we use kaccounts-providers to masquerade as a browser that webkit actually can't support...and we hope it doesn't break for a while. I believe that if we implement case #1 it will eventually become this case (#3). This workaround is definitely a "sweep the problem under the rug" type of hack. Yes, if it's the only solution then I think we'll have to implement it. > Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead. > I guess signon-ui should move to QtWebEngine instead but sadly upstream > seems rather dead :(, the previous signon-ui release was more than 5 > years ago. Yeah, signon-ui looks undermaintained/abandoned upstream... I'm adding the upstream maintainer to CC for notification about this nascent issue (Qt webkit removal), because it looks like signon-ui will break horribly at that time. As an aside, reading the copyright file makes it look like signon-ui may have originally been a Nokia project. > That's in fact why I've opened a report on this package, it seemed to be > the more feasible and realistic solution. Once again, thank you, much appreciated! And yes, I think that you have the right idea, and reported this bug in the right package. By the way, did you copy this solution from somewhere else (like Fedora's COPR or somewhere in Arch Linux), or is > It is a chance that google signon can still work :) > For sure! It's just a question of considering correctness as well as the long-term plan :) Regards, Nicholas signature.asc Description: PGP signature
Bug#903999: fixed in php-doc 20231017~git.cce6f7f+dfsg-1
On Fri, 03 Nov 2023 19:10:00 + Debian FTP Masters wrote: > Source: php-doc > Source-Version: 20231017~git.cce6f7f+dfsg-1 > Done: Athos Ribeiro > Thank you Athos :) signature.asc Description: PGP signature
Bug#1055461: configure support for local copy of php-doc
Package: php-elisp Severity: normal X-Debbugs-Cc: s...@debian.org Currently the elpa-php-mode connects to the internet to access php-doc; however, when I initially adopted the package, I had planned to configure support for a local copy of php-doc; however, I was blocked by #903999. Accessing the internet for the latest available documentation is a feature, but if the PHP versions don't match, then the docs will mislead. This is also arguably a generic privacy issue. Finally, in Debian we try to provide and operating system that is useful, and well-documented even when disconnected from a network. Progress has finally been unblocked, but I find myself short on free time/motivation, and suspect that I'll forget to implement this fix...thus the need for this bug. One thing I'm not sure about is if elpa-php-mode should default to the internet copy or the local copy of docs, because there are good arguments for each option.
Bug#1055027: Document workaround for potentially unusable pipewire-jack
Package: release-notes Severity: normal X-Debbugs-Cc: Utopia Maintenance Team Control: block 1054019 by -1 Hello, When I switched to Pipewire for bookworm I learned that pipewire-jack wasn't yet ready for general use due to broken sample rate pass-through, as well as frequent Ardour hangs. Thus I filed a bug (#1054019), tested the proposed workaround, and Dylan Aïssi gave me the ACK to document it. After all, it's nice when release notes answer "Is $new_technology ready to switch to, are there caveats, or do I need to wait for the next Debian stable release" :) I've prepared a draft in the following merge request, and I suspect it needs edits before it's ready to merge: https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/201 Thank you, Nicholas
Bug#1054919: kaccounts-providers: google authentication hang after username entry
Version: 4:22.12.3-1 Control: tag -1 upstream confirmed Hi, Thank you for reporting this bug. Alexis Murzeau writes: > To fix this, I've put this line in /etc/signon-ui/webkit- > options.d/accounts.google.com.conf: > UserAgent = Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 > Firefox/77.0 I've tested this proposal, and it fixes Google signon for me. This will transitively fix things like kio-gdrive that are broken in bookworm; For users of Google things, Bookworm's KDE is a poor user experience, or "bad story", compared to GNOME. > The webpage issue is maybe caused by the use of Qt webkit, using an older > UserAgent probably causes Google to offer an older login page that works with > Qt webkit. That sounds plausible to me. If that's the case then it seems like it may be better to patch Qt webkit. I wonder if this is a case where whatever UserAgent Qt webkit validated is the one the package declares (where it shouldn't be overridden for the general case), or if everybody involved just forgot to update it? > As the UserAgent is required to make the login work, can it be added to the > package ? Agreed, either Qt webkit should be fixed, or else kaccount-providers should begin overriding UserAgent. It's nice to see a Google issue that we can fix on our side! Best, Nicholas signature.asc Description: PGP signature
Bug#1054989: various tests: gpg: WARNING: "--secret-keyring" is an obsolete option - it has no effect
Package: devscripts Version: 2.23.6 Severity: normal Hi, While creating a local bpo of devscripts 2.23.6 I noticed many warnings like this: gpg: WARNING: "--secret-keyring" is an obsolete option - it has no effect in the build log. They are also visible on autobuilders https://buildd.debian.org/status/fetch.php?pkg=devscripts=all=2.23.6=1692766249=0 https://ci.debian.net/data/autopkgtest/unstable/amd64/d/devscripts/39069460/log.gz etc. >From what I've read this might be an old gpg2 migration bug; although, I seem to remember reading that it only affects >= gnupg 2.1. Either way, builds pass, it looks like we may have successfully released bookworm despite this issue, and so maybe we can just drop this argument (as well as the secret key identifier)? $ ag secret-keyring test/lib_test_uscan 89:--secret-keyring "$PRIVATE_KEYRING" --default-key \ test/test_mk-origtargz 99: --secret-keyring "$PRIVATE_KEYRING" test/test_package_lifecycle 73: --secret-keyring $PRIVATE_KEYRING --default-key 72543FAF \ test/test_uscan_ftp 184:--secret-keyring $PRIVATE_KEYRING --default-key 72543FAF \ 189: --secret-keyring $PRIVATE_KEYRING --default-key 72543FAF \ test/test_uscan_mangle 211:--secret-keyring $PRIVATE_KEYRING --default-key 72543FAF \ 216:--secret-keyring $PRIVATE_KEYRING --default-key 72543FAF \ 221:--secret-keyring $PRIVATE_KEYRING --default-key 72543FAF \ Does someone see a better solution, or would you like me to take care of deleting "--secret-keyring $PRIVATE_KEYRING"? Alternatively, is there someone whose is taking care of gnupg2 migration issues? This is the second bug I found, and I wonder if I should be CCing someone. No, I don't want to make gnupg2 migration a project of mine ;) Regards, Nicholas
Bug#1054019: broken sample rate passthrough
Hi Dylan, Oops! Yes, thank you, I forgot to test a newer pipewire after tiring and running out of time during the initial investigation. 0.3.82-1~bpo12+1 solves the bug :) Rather than close this bug as fixed right away, do you think it would be worthwhile to keep it open and/or add something to the bookworm release notes? I could write a few words if you'd prefer. There are always questions of "can I switch to $new_technology without regressions", and I think this would help answer them. It's also the case that pipewire-jack makes taking one's first steps in Linux music production much easier, but sample rate mismatches are RC for this use case...so at a minimum release notes should be provided. What you do you think? Regards, Nicholas signature.asc Description: PGP signature
Bug#1054009: RFS: runit-services/0.7.0 -- UNIX init scheme with service supervision (services)
Hi Lorenzo, Lorenzo writes: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "runit-services": > > > * Package name : runit-services >Version : 0.7.0 [snip] >* Import the runscript from mini-httpd-run package: > - change the runscript to use the default config file > - d/control: runit-services Provides mini-httpd-run I'm unfamiliar with runit, but does anything need to be done in the mini-httpd package to support your work in this upload? By the way, thank you for writing such nice commit messages! https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/commit/566393e02ab8010405d14e38c0e02f4bea51afc8 I appreciate the thought and the openness that went into that work. One minor comment here: I'd recommend filing a bug against mini-httpd-run shortly after the upload of runit-services_0.7.0, because otherwise someone might potentially see a neglected package and then adopt it. This bug would make the plan from your commit message more visible and official. It will also give the Quality Assurance team the opportunity to support your plan, and this seems like it will be required for a Request of QA Team (RoQA) removal--unless you adopt mini-httpd-run and file a Request of Maintainer (RoM). Maybe one of these approaches is already part of your plan? Also, thank you for thinking about smoothing the transition for users by using Provides; although, I wonder how this will actually function, because mini-httpd-run's version 1.0+nmu1 >> runit-services' 0.7.0. You're right, Conflicts isn't required and it doesn't seem like Breaks would be appropriate either. Have you considered using versioned Provides? This would make it more clear, in dependency resolution, that mini-httpd-run is now an obsolete cruft package. https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides Alternatively if the transition requires user/sysadmin intervention, then why wouldn't a debian/NEWS file be a good thing? Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1054019: broken sample rate passthrough
Package: pipewire Version: 0.3.65-3 Severity: normal Hi, Unfortunately using mpv's Pipewire driver results in audio being resampled, which introduces resampling artifacts. While I discovered this bug in bookworm's mpv_0.31.1-4, I've confirmed that it is still present in 0.36.0-1. That said, as a result of the investigation when filing this bug, I found what seems to be evidence that points to Pipewire as the true cause of the bug. Any software that uses Pipewire directly, or pipewire-jack appears to be affected. Steps to reproduce: 1. Uninstall and disable pulseaudio (if it's installed). 2. Install pipewire-pulse. 3. Cp /usr/share/pipewire/pipewire.conf /etc/pipewire/pipewire.conf 4. Set "default.clock.allowed-rates = [ 44100 48000 88200 96000 ]" 5. Restart pipewire's --user session. 6. mpv --ao=pipewire 01.ripped.from-CD.flac 7. cat /proc/asound/card0/pcm0p/sub0/hw_params | grep rate rate: 48000 (48000/1) When playing music with mpd (with Pulse audio backed) or with "mpv --ao=pulse", the sample rate is correctly passed through to Pipewire, and thus to the hardware: rate: 44100 (44100/1) Yes, I tested to see if the creation of a pipewire.conf with "default.clock.allowed-rates", and it appears to be for bookworm's Pipewire 0.3.65-3. The people who would probably be bothered the most by this bug are those who purchased "High-resolution audio" files (sample rates up to 192kHz, and usually 24bit), because playback will be limited to 48kHz due to this bug, as well as people who can hear 44.1khz to 48khz resampling artifacts. With the hypothesis that it was a Pipewire bug, I tried running Audacious with pipewire-jack (with JACK output configured), and a popup dialogue showed "Error" The JACK server requires a sample rate of 48000 Hz, but Audacious is playing at 44100 Hz. Please use the Sample rate Converter effect to correct the mismatch. And testing with "pw-jack mpv --ao=jack 01.ripped.from-CD.flac" shows AO: [jack] 48000Hz stereo 2ch floatp and of course cat /proc/asound/card0/pcm0p/sub0/hw_params | grep rate shows rate: 48000 (48000/1) So yeah, it looks like Pipewire's default sample rate is always applied when using pipewire or JACK sinks, despite "default.clock.allowed-rates" being set, except with using pulseaudio. I'm not sure why this is the case, but it seems wrong that everything is buggy except Pipewire and Pulseaudio...and that's why I'm reporting this bug against pipewire. Please feel free to reassign if this is a naive assessment. I hope this is enough to identify which package[s] is[are] affected as well as to forward the bug upstream. Please let me know if any more info is required. Thanks, Nicholas -- System Information: Debian Release: 12.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-rt-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mpv depends on: ii libarchive13 3.6.2-1 ii libasound2 1.2.8-1+b1 ii libass91:0.17.1-1 ii libavcodec-extra59 [libavcodec59] 7:5.1.3-1 ii libavdevice59 7:5.1.3-1 ii libavfilter8 7:5.1.3-1 ii libavformat59 7:5.1.3-1 ii libavutil577:5.1.3-1 ii libbluray2 1:1.3.4-1 ii libc6 2.36-9+deb12u3 ii libcaca0 0.99.beta20-3 ii libcdio-cdda2 10.2+2.0.1-1 ii libcdio-paranoia2 10.2+2.0.1-1 ii libcdio19 2.1.0-4 ii libdrm22.4.114-1+b1 ii libdvdnav4 6.1.1-1 ii libegl11.6.0-1 ii libgbm122.3.6-1+deb12u1 ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-3 ii libjpeg62-turbo1:2.1.5-2 ii liblcms2-2 2.14-2 ii liblua5.2-05.2.4-3 ii libmujs2 1.3.2-1 ii libpipewire-0.3-0 0.3.65-3 ii libplacebo208 4.208.0-3 ii libpulse0 16.1+dfsg1-2+b1 ii librubberband2 3.1.2+dfsg0-1 ii libsdl2-2.0-0 2.26.5+dfsg-1 ii libsixel1 1.10.3-3 ii libswresample4 7:5.1.3-1 ii libswscale67:5.1.3-1 ii libuchardet0 0.0.7-1 ii libva-drm2 2.17.0-1 ii libva-wayland2
Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required
Jonathan Hettwer writes: > Package: partman-crypto > Version: 121 > Severity: normal > Tags: d-i > X-Debbugs-Cc: j24...@gmail.com > > Dear Maintainer, > > The `crypto_check_mountpoints` script prevents you from setting up an > encrypted root filesystem without an additional unencrypted /boot > filesystem. > While this may be a requirement for e.g. grub2, it is not > necessarily required when not using grub2 but using UKIs to build EFI > executables that can directly mount the encrypted root filesystem. > While UKIs aren't currently supported, I would still expect partman-crypto > to let me partition an encrypted root filesystem without separate /boot > filesystem, at least after having ignored the warnings or in combination > with the `nobootloader` udeb. Quick note: systemd-boot works with kernel images + initramfs, without UKI. After the systemd-boot menu, the user is prompted for the master LUKS password, as usual, and I use the derived key script to then unlocks a couple LUKS volumes. No LVM, no /boot. It seems to work well, but yeah, it's not possible to do this with fresh install (I manually migrated an old installation to new hardware). Regards, Nicholas signature.asc Description: PGP signature
Bug#1052929: yasnippet: FTBFS: make: *** [debian/rules:4: binary] Error 25
Control: forwarded -1 https://github.com/joaotavora/yasnippet/issues/1173 Control: tag -1 upstream fixed-upstream Lucas Nussbaum writes: > Source: yasnippet > Version: 0.14.0+git20200603.5cbdbf0d-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230925 ftbfs-trixie This looks like it's probably fixed upstream, and I've requested a new tagged release there. Also, the last time either of the existing Uploaders worked on this package was 2016, so they should be dropped at this time. I've CCed everyone involved. Aymeric and Xiyue Deng, would you to take responsibility for this package? signature.asc Description: PGP signature
Bug#1052824: flycheck: FTBFS if gawk is installed
Xiyue Deng writes: > Indeed. I've refinalized, recompiled, and reuploaded it to mentors[1]. > PTAL. Will create tag once it's uploaded to unstable. There was some undocumented churn with python3-sphinx, but this release isn't at fault, and it solves an RC bug, so I went ahead and uploaded. Please consider double checking for stuff like this in the future. You can do this with something like cd $project_root git diff $latest_tagged_version_in_the_archive -- debian >> Alternatively, if you're looking for off-team sponsors, then you should >> file an RFS in addition to uploading to mentors. >> > > Still prefer to let you sponsor here ;) Fine with me, but if no one on the team (including myself) has time, then please keep this in mind. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1052824: flycheck: FTBFS if gawk is installed
Hi, Manphiz writes: > Finally got access from David. I have prepared a revision for the fix > and uploaded to mentors[1]. Now looking for sponsors :) > > [1] https://mentors.debian.net/package/flycheck/ If you'd like me to sponsor, please refinalise, because 9222c3db occurs after the 33~git20230824.e56e30d-2 release commit. Also, when following best practises, that full version will appear in the release commit message, so this is a good opportunity to dtrt and fix that. Alternatively, if you're looking for off-team sponsors, then you should file an RFS in addition to uploading to mentors. Thank you for comaintaining this package :) Regards, Nicholas signature.asc Description: PGP signature
Bug#999962: silversearcher-ag: diff for NMU version 2.2.0+git20200805-1.1
Manphiz writes: > Hi Nicholas, > > Thanks for sponsoring the NMU! I have pushed the release commit to > debian/2.2.0+git20200805-1.1 in my repo[1]. Let me know if the tag name > looks OK. > > [1] > https://salsa.debian.org/manphiz/silversearcher-ag/-/tags/debian%2F2.2.0+git20200805-1.1 > You're welcome! Looks good, so I merged it to the project. --N signature.asc Description: PGP signature
Bug#999962: silversearcher-ag: diff for NMU version 2.2.0+git20200805-1.1
Xiyue Deng writes: > Control: tags 62 + pending > > Dear maintainer, > > I've prepared an NMU for silversearcher-ag (versioned as > 2.2.0+git20200805-1.1) > and uploaded it to mentors.debian.net. Please feel free to tell me if I should > delay it longer. You may have noticed that the timer fired and that the upload was accepted :) Please push a release tag to you forked remote, and then I'll merge your work into the debian/collab-maint project. Best, Nicholas signature.asc Description: PGP signature
Bug#992739: fonts-courier-prime: Would it be possible to include Cyrillic?
Hi наб, Gürkan, and Димка, Reply follows inline. On Tue, 07 Sep 2021 13:45:35 +0200 =?UTF-8?Q?G=C3=BCrkan_Myczko?= wrote: > Hello > > I think it's absolutely possible, what's not clear about the user > contributions is > though the licensing. I'd guess same as upstream, however not sure. It looks like SIL Open Font License (OFL) to me. > Best would probably someone create a repo for it for github.com (or as > you > prefer somehwere else) and merge the user contributions to upstream > version, > then tag releases. > > If you feel like taking over the package and doing the work, please go > ahead. > I'm also in #debian-fonts I'm unable to evaluate the Cyrillic aspects of the font, but I'm currently prevented from using Courier Prime due to https://bugs.debian.org/1053133 . I'd also like to start shipping the new Courier Prime Fountain-mode theme, which this bug blocks. That said, as a new Debian Font Team member and Debian Developer I'd be happy to supervise any work or provide guidance into what is required to rebase Debian's Courier Prime onto this fork. Ideally it would also be nice to see Димка's project merged into https://github.com/quoteunquoteapps/CourierPrime Kind regards, Nicholas P.S. I sometimes miss emails, so if I seem to take too long to reply, please send a follow-up request :) signature.asc Description: PGP signature
Bug#1053133: Italic/slant variant is always used in Emacs, even when it shouldn't be
Package: fonts-courier-prime
Version: 0+git20190115-3
Severity: normal
Control: forwarded -1 https://github.com/quoteunquoteapps/CourierPrime/issues/9
Hi,
I'm currently investigating why the Italic/slant variant is always
used in Emacs, even when it shouldn't be. Thus far I've only found the
following with fontforge:
The PostScript font name "Courier Prime-Regular" is
invalid.
It should be printable ASCII,
must not contain (){}[]<>%/ or space
and must be shorter than 63 characters
Could that be why the slant/italics variant is matched?
I also found this:
The glyph named Delta is mapped to U+0394.
But its name indicates it should be mapped to U+2206.
The glyph named Omega is mapped to U+03A9.
But its name indicates it should be mapped to U+2126.
The glyph named Tcommaaccent is mapped to U+021A.
But its name indicates it should be mapped to U+0162.
The glyph named mu is mapped to U+03BC.
But its name indicates it should be mapped to U+00B5.
The glyph named tcommaaccent is mapped to U+021B.
But its name indicates it should be mapped to U+0163.
but the latter doesn't seem relevant to the italics/slant bug that I'm
reporting.
>From what I gathered on #emacs@LiberaChat, Emacs is very picky about even
>slightly out-of-spec fonts, but on the upside that makes it a great linter! :)
To reproduce the issue, install a GUI variant of emacs, install
fonts-courier-prime, and M-x set-frame-font to a non-italics,
non-Code, non-Sans variant of Courier Prime.
'hope someone who knows more about fonts can provide instructions/guidance to
take this further. Please CC me on all correspondences.
Regards,
Nicholas
Bug#1052935: bm-el: FTBFS: make: *** [debian/rules:4: binary] Error 25
Control: forwarded -1 https://github.com/joodland/bm/issues/46
Bug#1052955: irony-mode: FTBFS: make: *** [debian/rules:8: binary] Error 25
Control: forwarded -1 https://github.com/Sarcasm/irony-mode/issues/587
Bug#1023888: bts: `forwarded` has stopped working since the last few days
control: tag -1 moreinfo Hi Akbarkhon, Can you reproduce this bug on your system? I can't, and neither could Adam, so it looks like a transient issue to me https://bugs.debian.org/1023888 Best, Nicholas signature.asc Description: PGP signature
Bug#996968: bts: uses the deprecated 'close' control command
On Fri, 22 Oct 2021 10:21:56 +0800 Paul Wise wrote: > On Thu, 21 Oct 2021 19:47:21 +0200 Mattia Rizzolo wrote: > > > There are uses of closing a bug without notifying anybody, and I really > > want `bts` to retain that use. > > I suggest a new design for bug closing: [snip] > > Change the template for notified closings to mail -done instead of > control@ and place a Version pseudo-header into the template even when > a version isn't specified. Where should this version come from? I think the feature you're describing works like: 1. Install Debian. 2. Triage bugs, and find a bug. 3. Confirm that this bug does not exist in the version of the package that is installed. 4. Run this "bts" which basically means "close the bug, it's fixed on my installation". The main pitfall that I can think of is the case where the bug is fixed in an older package version, but present in the newer. I'm guessing you don't mean getting a fake version from rmadison. Alternatively, isn't there somewhat of a convention for tag +unreproducible bug-done@d.o? In this case, it also doesn't seem like you'd want a Version pseudo-header. Cheers, Nicholas signature.asc Description: PGP signature
Bug#487185: devscripts: [bts] Should use EMAIL / DEBEMAIL address in SMTP envelope
clone 487185 -1 retitle -1 devscripts: [bts] Uses the wrong email address by default (broken config by default) severity -1 normal thanks Justification: affects default configuration On Wed, 30 Dec 2015 19:35:13 -0500 James McCoy wrote: > On Thu, Dec 31, 2015 at 12:15:56AM +, Daniel Shahaf wrote: > > James McCoy wrote on Wed, Dec 30, 2015 at 07:00:17 -0500: > > > On Wed, Dec 30, 2015 at 10:23:51AM +, Daniel Shahaf wrote: > > > > This seems to have been fixed: with devscripts-2.15.3 from stable, the > > > > SMTP MAIL FROM address is taken from the $DEBEMAIL envvar. > > > > > > We haven't made any changes related to setting the SMTP envelope, so I > > > doubt it. Maybe your local MTA handles setting the envelope as you > > > expect. > > > > When I run 'DEBEMAIL=f...@bar.org bts', f...@bar.org is the value passed > > to $smtp->mail(). My MTA doesn't even come into play. > > Right, that's not what this bug is about. It's about when sendmail is > used, not Net::SMTP. > I'd like to report that today I was surprised to find that this [now these] bug[s] is[are] still an issue. The man page indicates that $DEBEMAIL will be respected, so the bts program is not functioning as designed. IIRC --mutt works correctly, --smtp-host works correctly, so this bug only exists in the default configuration. That is to say: sendmail. I've cloned this bug because there are two issues: A) Using the wrong email address, by default (New cloned bug) B) Not supporting sendmail smtp envelope from (Bug #487185) For A) 1. Use the bugs.debian.org SMTP submitter by default. 2. This takes the --smtp-host path, which has been confirmed to do the right thing when DEBEMAIL or EMAIL are set. Prefer DEBEMAIL when set, of course. For B) 1. Add support for sendmail's smtp envelope from. Prefer DEBEMAIL when set, of course. There's arguably a third option: change the documentation to say that the bts command will only do what you expect it to do when you use it with the non-default --mutt or --smtp-host arguments, but I think we'll all agree that this isn't a good solution ;) Kind regards, Nicholas signature.asc Description: PGP signature
Bug#999962: RFS to solve bug#999962 (silversearcher-ag: depends on obsolete pcre3 library)
control: tag -1 pending Manphiz writes: > Nicholas D Steeves writes: > >> Manphiz writes: >> >>> Nicholas D Steeves writes: >>>> Manphiz writes: >>>>> Manphiz writes: > >>> BTW, I'm not a DD or DMD yet so I'm probably not able to submit to >>> delayed queue yet, right? >> >> Right, the upload to the delayed queue using dput is something else, and >> any uploads you make to ftp-master will not succeed. I'm not sure if >> mentors.debian.net has a delayed queue, and I can't see how that would >> be useful--other than for practise. Did you find the relevant section >> in the Developer's Reference? >> > > Uploaded to mentors[1]. Tried to search for NMU and mentors related > contents in the Developer's Reference but didn't find much. I guess > mentors should be safer than the delayed queue. mentors.debian.net != ftp.upload.debian.org Each of those hosts has its own queue, naturally, because they're different hosts. Developers-reference §5.11 is the relevant section. >> Before we get to the upload you need to submit an nmudiff of the source >> package. On a related note, if you don't know about these yet, >> "msmtp-mta" and "apt-file" are really useful. Msmtp-mta is an >> alternative to other MTAs (useful for laptops, and Spwhitton told me >> about apt-file :) It's technically possible to use debdiff, but >> "nmudiff" is a tool like "reportbug", but I'm not sure if nmudiff will >> function without an mta, unlike reportbug. >> > > Also sent the nmudiff to this bug. Good thing that my postfix still > works :) Thank you, and oh good :) While technically it would be ok to upload directly (0 day), because we've given the maintainer a lot of time to react to this bug, I've chosen to upload to delayed=2. Congrats on your first (sponsored) nmu! Regards, Nicholas signature.asc Description: PGP signature
Bug#999962: RFS to solve bug#999962 (silversearcher-ag: depends on obsolete pcre3 library)
Manphiz writes: > Nicholas D Steeves writes: >> Manphiz writes: >>> Manphiz writes: [snip] >> Then finalise the changelog and build the package. >> > > Done as well. Thanks! >> Finally, learn about what an "nmudiff" is, and file one at the relevant >> bug. >> > > To be careful I'd like to have you take another look before doing so[1] > :) I pulled from your remote and noted the requested updates. It looks good to me :) > BTW, I'm not a DD or DMD yet so I'm probably not able to submit to > delayed queue yet, right? Right, the upload to the delayed queue using dput is something else, and any uploads you make to ftp-master will not succeed. I'm not sure if mentors.debian.net has a delayed queue, and I can't see how that would be useful--other than for practise. Did you find the relevant section in the Developer's Reference? Before we get to the upload you need to submit an nmudiff of the source package. On a related note, if you don't know about these yet, "msmtp-mta" and "apt-file" are really useful. Msmtp-mta is an alternative to other MTAs (useful for laptops, and Spwhitton told me about apt-file :) It's technically possible to use debdiff, but "nmudiff" is a tool like "reportbug", but I'm not sure if nmudiff will function without an mta, unlike reportbug. Best, Nicholas signature.asc Description: PGP signature
Bug#999962: RFS to solve bug#999962 (silversearcher-ag: depends on obsolete pcre3 library)
I've moved this discussion from debian-emacsen to the relevant bug. Please remove debian-emacsen from CC and add me to CC for all follow-ups. Manphiz writes: > Manphiz writes: > >> >> Thanks Nicholas! I used licensecheck and checked manually and updated >> d/copyright accordingly in my merge request[1]. PTAL, thanks! >> >> [1] https://salsa.debian.org/debian/silversearcher-ag/-/merge_requests/1 > > Friendly ping. haha @enable_pcre2_support.patch:L478 Thanks for adding some copyright info; this will cover a "patches applied" view, but doesn't cover the "patches unapplied" source package (orig.tar, debian.tar, dsc). If you manually evaluate the rules in d/copyright you'll see that this patch becomes misattributed to the debian/* holder, which gets even more confusing since you set yourself as the patch author ;) Yes, I understand you synthesised commits, and I'm fine with that, but please finish fixing up d/copyright. changelog: Please enclose "Closes: #62" in parentheses in order to follow the style that is already in use by this package's maintainer; it's technically still Majime Mizuno's package, after all. Then finalise the changelog and build the package. Finally, learn about what an "nmudiff" is, and file one at the relevant bug. Thanks, Nicholas signature.asc Description: PGP signature
Bug#1042911: (Still?) breaks Emacs 29.1 unattended-upgrade
On Fri, 15 Sep 2023 14:35:08 +0200 "Farblos" wrote: > Not sure whether this is still relevant or just bad luck or whatever ... my > unattended-upgrade failed today because of this issue. Logs available > on request. Work-around was to remove version 3.20+dfsg-7, retrigger > the unattended upgrade, install version 3.20+dfsg-8. So 3.20+dfsg-7 is broken by emacs29 such that it can only be uninstalled, and not upgraded. I'm confident that your logs will show that the -7 is unpacked but no longer configured. If you're curious about what the generated configuration scripts actually do, then check out this article on how to inspect debs: https://blog.packagecloud.io/inspect-extract-contents-debian-packages/ To be honest I'm not totally sure why this unconfigured (or not totally configured) package can't be upgraded, but it can be argued that an upgrade from an undefined state is an unsafe upgrade. I mean the "why", where your logs will show the "what" and the "how" ;) Also, as maintainers our responsibility is reliable oldstable -> stable upgrades, so this kind of transient breakage will sometimes occur in unstable/sid as well as testing. > Thanks for taking care of this package, BTW! Yes, thank you Manphiz! And Farblos, thank you for reaching out :) While it's unfortunate that it was for a bug, it's always nice to hear from real users of mature software. Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool
Thank you for working on this! One note: where is it documented how ipupdown and ipupdown-ng interact? For example using the alternatives system, or a different config file location, or some sort of tagging mechanism in network/interfaces. I would appreciate it if this was in the changelog, at a minimum, and maybe other people would too? A brief "...by using $method" seems like it would be enough. Kind regards, Nicholas P.s. sorry for the html part, I'm on my phone
Bug#1051719: markdown-mode.el produces excessive warnings
Hi Daniel and David, On Wed, 13 Sept 2023 at 04:17, Daniel Kahn Gillmor wrote: > thanks for the review! I poked around at > https://github.com/jrblevin/markdown-mode and it looks like > 518191bfd69130a6f788f7cea88033c183e43736 was intended to resolve these > issues (see the PR i've linked here too). Maybe we just need version 2.6 > packaged for debian? > Wow, thank you for your investigation! Yes, you're right, 2.6 contains commit:518191b, thus this is the correct action. > Thanks for maintaining elpa-markdown-mode in debian! > It's a team effort, so on behalf of the team, you're welcome! :) David, do you think you'll be able to find time for this or do you want me to come back to it in a week or so? Cheers, Nicholas P.S. I'm AFK at the moment, and I hope my phone doesn't do anything weird to the email.
Bug#1051819: fluidsynth: Consider building with pipewire support
Hi Gianfranco,
Oh my, yes, it seems I forgot to add the new pipewire -dev package to the
fluidsynth -dev package. 'not sure how that happened, but my mistake!
Isn't only waiting 48h a bit rushed for an NMU though? I can of course
import your fix and upload in the next 48h, and I'd like to improve your
changelog entry, because I think you'll agree that the concept of "runtime"
doesn't make sense for headers ;) If this is truly 0-day urgent, I'm
confident a team member (IIRC Josch is a multimedia-team member) will
upload.
Cheers,
Nicholas
('hope this isn't HTML email, since I'm currently AFK on a phone)
Bug#1051719: markdown-mode.el produces excessive warnings
Control: tag -1 upstream Thanks for reporting! Daniel Kahn Gillmor writes: > I get a lot of warnings from markdown-mode when i launch emacs. the > buffer contains the following: [snip] > I'm using emacs 1:29.1+1-5 with emacsen-common 3.0.5. > > This is well over 50% of all the warnings that are announced by emacs > for the set of elpa packages i have installed. > > Looks to me like most or all of these warnings should be cleaned up, > which would make it easier to see meaningful/substantive warnings if > they do appear. Agreed! Are you interested in forwarding this bug upstream to https://jblevins.org/projects/markdown-mode, or would you prefer to wait for someone else to do so? The reason this is important is because Emacs29 compatibility affects more than just Debian users, so the fix shouldn't be limited to just us. Regards, Nicholas signature.asc Description: PGP signature
Bug#1042450: elpa-org: #+LANGUAGE: de-de is not working in LaTeX export
Control: tag -1 = upstream fixed-upstream
Max Nikulin writes:
Hi Max, thank you for investigating this, and thank you for the links
confirming it was fixed :)
> Changes will be included into the next major Org mode release.
So 9.6.10 or possibly 9.7.0.
> #+language: de
> #+latex_header: \usepackage[AUTO]{babel}
>
> results in
>
> \usepackage[ngerman]{babel}
> \hypersetup{
> % ...
> pdflang={German}}
>
> It is a bit different from Org mode 9.5 however
I assume you mean 9.5.x, and that this will affect uses who upgrade from
Debian 12/bookworm (or older) to future 13/trixie.
> \usepackage[germanb]{babel}
> \hypersetup{
> % ...
> pdflang={Germanb}}
Hm, this looks like something that should probably be noted in upstream
org-mode release notes, which would also eventually trickle down to
Emacs release (due to its bundled copy of org-mode).
Regards,
Nicholas
signature.asc
Description: PGP signature
Bug#1050929: telegram-desktop: System window decorations disabled on Wayland after 4.9.3
Hello! On Mon, 4 Sep 2023 21:35:22 -0300 z411 wrote: > Telegram already used Wayland before this (as do all Qt5/Qt6 apps) and > it had the option for system decorations. The icon also worked, for some > reason it doesn't work now. Since version 4.8.3 Telegram Desktop needs Qt6 for complete Wayland integration. Although, our package is build against Qt5 yet. Some plugins that tdesktop relies on were not built against the latest Qt, and migration was postponed. > The latest official release (4.9.3) also works on Wayland with system > decorations, and the 4.8.1 Debian package works as well. Even with > QT_QPA_PLATFORM=wayland. It even shows some warnings related to Wayland > and xeyes shows me it's not running under XWayland. Please correct me if > I'm wrong. > > > In genuine Wayland there is no such thing as system decorations. > > As far as I understand, there is, there's the xdg-decoration-v1 protocol > supported by KWin and Sway which they use to draw system decorations on > Wayland windows. You are right but this protocol is an optional part of Wayland. KWin in KDE Plasma implements the protocol, Mutter in GNOME does not. For now, I will block the native Wayland integration and the coming update will prefer Xwayland because of unresolved glitches. The default window frame looks not as intended, it has no context menu, and it can double while switching the checkbox "Use system window frame" in the Settings. Of course, you always can force native Wayland but at your own risk. I will also add a patch restoring the checkbox in all modes.
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Hi manphiz, Manphiz writes: > Xiyue Deng writes: > > Hi sten, > > When trying to pick a new upstream to rebase, I found that pulling > either upstream repo will result in an incompatible git history versus > the current debian/master branch on salsa. This is expected, but please merge from upstream. > I wonder how I should handle this? The commit of the upstream source you import should be tagged. If upstream hasn't made a tagged release, then you'll need to: 1. With a the upstream of your choice set in the watch file, "gbp import-orig --uscan" will do the right thing in this repository. This is one reason why a functioning watch file that defines the correct upstream is useful. It should also save time to do this once, and then switch to a tag merging workflow for the next upstream import. OR I. Ask upstream to tag a stable release (probably NA to GNU ELPA's monorepo) II. Merge that tag to either the upstream branch, or directly to the Debian packaging branch. See the merge note at §i. III. Do fixup work to make "git diff tag -- !(debian)" clean. OR i. Merge new upstream commit to the upstream branch (which will also merge its history), because tags of detached HEADS behave unreliably through remotes; ie the tag needs to be of a commit on a branch. See git merge man page about what to about unrelated histories. ii. Create an annotated tag in the format you defined in debian/watch (note substitutions for special characters). I've always done this manually with a "Tag upstream snapshot for Debian use" annotation, but NOTE: There is probably a better way to create these tags by now. iii. Merge your annotated tag to the Debian packaging branch. iv. Do fixup work to make "git diff tag -- !(debian)" clean. In every case, you'll need to insure that the upstream tag is pushed to Salsa. > Is it OK to force push to master? No. Best, Nicholas signature.asc Description: PGP signature
Bug#1016558: ITA: muse-el
Manphiz writes: > Nicholas D Steeves writes: >> Manphiz writes: >>> Nicholas D Steeves writes: > >> Please create an annotated tag called "debian/3.20+dfsg-8", but don't >> push that tag until you receive the "ACCEPTED" email from >> ftp-masters/the archive. > > Also done and waiting for submitting. > >> It will most likely be less than 24h in >> between pushing the release commit and pushing the tag, during which >> time you'll be waiting for me to actually make the upload. >> > > BTW rebuilt and re-uploaded to mentors :) > >> As for why? Well, there's some ambiguity now about whether >> commit:02e95c1 was 3.20+dfsg-8, the fix is easy, and the delay is only >> another day or two. >> >> After this, the package is truly ready. > > =) Uploaded! Thank you for your work :) Cheers, Nicholas signature.asc Description: PGP signature
