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#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#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#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#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#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#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#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 2.17.0-1 ii libva-x11-22.17.0-1 ii libva2
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#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
Bug#1016558: ITA: muse-el
Manphiz writes: > Nicholas D Steeves writes: >> Manphiz writes: >>> Nicholas D Steeves writes: >>>> Manphiz writes: >> >> You're welcome. Yes, I agree that the github fork's structure has >> diverged less, and I vaguely remember that that may have been one of the >> reasons why I chose to watch it for future releases, but the then tag >> never materialised. As noted previously, I'm ok with switching to the >> fork if that's what you'd prefer to do long-term! As the maintainer you >> get to pick the most high-quality and well-maintained upstream for the >> Debian source, because you're the one who is responsible to our users. >> > > Sounds good. I'll give it a little more thoughts. Wonderful, there's no rush. As ever, in Debian, you don't need to do something you don't want to do. >> Do you mind if I enhance this significantly? Find proposal in-line, at >> the end of the email. > > No problem! Patch applied, rebuilt, and reuploaded to mentors[1]. > PTAL. LGTM! >> Also, I'd like this to be more visible, so I'll >> file a bug titled something like "Choose living upstream for muse-el, >> and merge updates" if you don't. I'm vaguely starting to remember that >> the issue about a future upstream was raised during my early >> contributions, but then I forgot all about it ;) Also, as the fixes for >> Emacs compat eventually start accumulating we'll end up becoming a >> second fork. >> > > Makes sense. Filed Bug#1051247 for tracking. Will probably get to it > in the next revision. Much obliged. Please refinalise with 'dch -r' and commit with something like "Actually release 3.20+dfsg-8 to unstable" (or sid, as you prefer!). Then push. 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. 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. 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. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Alexandru Mihail writes: >> # Fix git config email and gpg identity, then [snip] >> > I fixed my git config and redid the tag as discussed above Thanks! >> Sorry I only noticed this when I manually inspected and compared the >> tag > Yeah, sorry too :) > I'll be going on vacation for two weeks so I will be available via mail > but won't be able to push unless we coordinate that tomorrow (roughly > 14 Hrs from now would be when I have to leave. If not I'll happily push > afterwards (14th September). > Tag is in the usual spot: > https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4 I just uploaded and sent you an invitation that grants Maintainer permissions for this repository. You will receive two emails from the FTP Masters (Debian archive). The first will be a "processing" email that says the release was uploaded successfully, and the second will be that mini-httpd was accepted into Debian unstable/sid. Please wait until you receive the "accepted" email before pushing your tag to g...@salsa.debian.org:debian/mini-httpd.git, and please push the master branch there at your earliest convenience. Congratulations, and enjoy your holidays! :) Cheers, Nicholas signature.asc Description: PGP signature
Bug#1050350: flycheck: keep flycheck out of testing until it finds an uploader
Manphiz writes: > control: merge 1050404 -1 > control: block -1 by 1050459 > control: tags -1 patch > > Hi, > > I've prepared an MR[1] to handle this, which requires a newer > emacs-buttercup which is being prepared at [2]. PTAL. > > [1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/3 > [2] https://salsa.debian.org/emacsen-team/emacs-buttercup/-/merge_requests/1 Belated thank you! I think it's completely just that a package whose popularity is at the 99.86th percentile on MELPA and the 96.41th on MELPA stable blocks a transition, and that your work enabled a more ideal resolution of this situation. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1016558: ITA: muse-el
Thank you for the ping! Manphiz writes: > Nicholas D Steeves writes: >> Manphiz writes: >>> Nicholas D Steeves writes: >>>> Manphiz writes: >>>>> Nicholas D Steeves writes: >>>>>>> Nicholas D Steeves writes: > >>> However, as it turns out, the savannah repo has a completely different >>> layout compared to the current one we package (which is actually based >>> on github). >> > I see. Thanks for the background. I think I was meant to say that "the > repo structure is more like the github one" to be clear. Looking at the > git log on Savannah, it looks like they changed the directory structure > on the first commit when importing[2]. You're welcome. Yes, I agree that the github fork's structure has diverged less, and I vaguely remember that that may have been one of the reasons why I chose to watch it for future releases, but the then tag never materialised. As noted previously, I'm ok with switching to the fork if that's what you'd prefer to do long-term! As the maintainer you get to pick the most high-quality and well-maintained upstream for the Debian source, because you're the one who is responsible to our users. >>> In fact, the savannah one uses a Makefile that assumes the project >>> layout as the github one while some of the directories like "lisp" are >>> not even there (which makes me think whether targeting the savannah >>> repo is the correct choice). >> >> Some words appear to be missing, so I don't understand what you mean. >> Please consult d/rules to learn why an upstream Makefile is irrelevant >> by-design to this package. Also, consult the dh-elpa man page and >> perhaps also team documentation on our wiki. It's also worth consulting >> MELPA packages (and the source used by MELPA) to see how Makefile's >> aren't needed there either. > > I kinda know that an Emacs addon doesn't really require a Makefile to be > usable for melpa. Still, I still consider leaving a non-working > Makefile around a bad habit. Anyway, point taken. Agreed, it's technical debt at this point. As the new Debian maintainer, please consider sending this upstream a patch or a request to remove the unused file. >>> Therefore, I'd like to postpone the sync with savannah repo to a >>> future upload to avoid more immediate work for uploading if that's OK. >> >> That's OK with me! As noted previously, I'll support the decision you >> make in your choice of future upstream, but it needs to be a conscious >> and principled decision. If you don't want to decide at this time, >> please implement a method that will remind you (or a future maintainer) >> to investigate and fix this issue. Tldr, we don't want to switch back >> and forth between GNU source and fork source. >> > > Added a reminder in d/watch as a future work[3]. Do you mind if I enhance this significantly? Find proposal in-line, at the end of the email. Also, I'd like this to be more visible, so I'll file a bug titled something like "Choose living upstream for muse-el, and merge updates" if you don't. I'm vaguely starting to remember that the issue about a future upstream was raised during my early contributions, but then I forgot all about it ;) Also, as the fixes for Emacs compat eventually start accumulating we'll end up becoming a second fork. >>> Another hackier way I can think of is to build-deps on git and run "git >>> restore" in override_dh_auto_clean, but I felt requiring the repo to be >>> a git repo may fail buildd? Not sure though. Anyway, it seems using a >>> patch is a cleaner solution compared to this. >> >> Right, you cannot use git restore. If we used the upstream Makefile's >> "make clean" target, I would concede that patching the Makefile was the >> correct approach. >> > > Ah OK. I understand your reasoning. I've reverted the patch approach > and as an alternative implemented the approach in [4] in the spirit of > autoreconf. PTAL. LGTM. diff --git a/debian/changelog b/debian/changelog index b172159..725e7bd 100644 --- a/debian/changelog +++ b/debian/changelog @@ -19,11 +19,15 @@ muse-el (3.20+dfsg-8) unstable; urgency=medium workaround #1021502. * Drop section referencing non-existing file in debian/copyright to fix lintian warning superfluous-file-pattern. - * Fix d/watch to track the savannah git repo. * Drop lintian override of wrong-section-according-to-package-name. * Save and restore lisp/muse-autoloads.el to prevent it from changing when build-twice-in-a-row. Closes: #1048114. + [ Xiyue Deng & Nicholas D Steeves ] + * Correct watch file so that it tracks the
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Alexandru, Thank you for the ping :) Alexandru Mihail writes: > I've commited and pushed the changes to the remote I was using for the > MR so far: > commit: > https://salsa.debian.org/alexandru_mihail/mini-httpd/-/commit/fc7c4f664dc1369b1bf5d46c8c9b7aa11de68407 > > > But I think I may have not commited where I was supposed to, granted > you've already closed the MR. You committed in the right place, and yes, as requested pushed to the remote in your personal namespace rather than to the collaborative space where mini-httpd is maintained. Yes, this is what I asked for, because I wanted to make sure everything was in good order before uploading to the archive and asking you to push to the actual project (thus making it permanent). I'm pulling from your remote directly rather than using the gitlab now. Tags on the actual project are immutable (or should be treated thus), and should only be pushed after an upload has been accepted, and this is why I wanted to check that everything was 100% good. Yes, I had already merged your MR, and MRs are automatically closed when they're merged. > I've already created a GPG signed tag accessible at: > https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4 Thanks! > The commit is not visible in the previous MR: > https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2? This is because the MR was merged already (and thus already closed and not open for updates). > Is there something I've glanced over here ? Did you realise that you're still committing using your protonmail.ch address (and presumably GPG identity)? Early in this process you switched to a gmail address, and I understood that that was the one that you would be using for for your Debian work. You'll need to update your git config to use the new gmail address and gpg identity (try #debian-mentors on irc.oftc.net if you can't make sense of the docs). Also, at this time please base your work on debian/mini-httpd.git rather than alexandru_mihail/mini-httpd.git. # Fix git config email and gpg identity, then git clone g...@salsa.debian.org:debian/mini-httpd.git cd mini-httpd git remote add alex g...@salsa.debian.org:alexandru_mihail/mini-httpd.git git fetch alex # just so you have another backup dch -r git commit debian/changelog -m "Release 1.30-4 to unstable." # do your tagging procedure git push --delete alex debian/1.30-4 git push -f alex master debian/1.30-4 Sorry I only noticed this when I manually inspected and compared the tag and release commit on the CLI...I feel like the web-thing hid this information from me, and that might be confirmation bias, but it seems like the same thing happened to you ;) Cheers, Nicholas P.S. FYI, to get Salsa's Gitlab instance to show green verified commits and tags you may also need to update your email address and gpg key there. I don't care about this so long as the actual git data is correct, but you (and/or others) might. signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Control: block -1 by 1016558 Hi, I'm just updating this bug to note the adopted muse-el package is just about ready to upload (the ITA is also a pseudo-RFS bug), and I plan to upload in the next few days. If this update isn't enough to prevent autoremoval...well, at least the package will be fixed very soon. Regards, Nicholas signature.asc Description: PGP signature
Bug#1050603: syncthing: Reenable QUIC feature
Control: reopen -1 Control: notfixed -1 syncthing/1.19.2~ds1-3 Control: fixed -1 syncthing/1.19.2~ds1-2 I've created this bug as a TODO for Syncthing 1.24, and cloned 1049983 for context rather than resubmitting.
Bug#1050546: bookworm-pu: package vorta/0.8.10-1+deb12u1
Control: tags -1 - moreinfo "Adam D. Barratt" writes: > On Fri, 2023-08-25 at 21:17 -0400, Nicholas D Steeves wrote: >> >> <#part type="application/octet-stream" >> filename="/home/sten/Dropbox/tmp/0.8.10-1_to_0.8.10- >> 1+deb12u1.debdiff" disposition=attachment> >> <#/part> >> > That seems to have been missed. Ah, I see I failed to use reportbug's special attachment method. My bad. Thanks for letting me know, and this should now be fixed! diff -Nru vorta-0.8.10/debian/changelog vorta-0.8.10/debian/changelog --- vorta-0.8.10/debian/changelog 2023-01-23 15:06:42.0 -0500 +++ vorta-0.8.10/debian/changelog 2023-07-31 11:10:53.0 -0400 @@ -1,3 +1,11 @@ +vorta (0.8.10-1+deb12u1) bookworm; urgency=medium + + * Add 0006-Handle-ctime-and-mtime-diff-changes-1675.patch, which is a +cherry-picked fix from upstream that adapts Vorta 0.8.10 to Borg 1.2.4 +(Closes: #1042671). + + -- Nicholas D Steeves Mon, 31 Jul 2023 11:10:53 -0400 + vorta (0.8.10-1) unstable; urgency=medium * New upstream release. diff -Nru vorta-0.8.10/debian/patches/0006-Handle-ctime-and-mtime-diff-changes-1675.patch vorta-0.8.10/debian/patches/0006-Handle-ctime-and-mtime-diff-changes-1675.patch --- vorta-0.8.10/debian/patches/0006-Handle-ctime-and-mtime-diff-changes-1675.patch 1969-12-31 19:00:00.0 -0500 +++ vorta-0.8.10/debian/patches/0006-Handle-ctime-and-mtime-diff-changes-1675.patch 2023-07-31 11:10:53.0 -0400 @@ -0,0 +1,452 @@ +From: Henry Spanka +Date: Sat, 1 Apr 2023 21:10:56 +0200 +Subject: Handle ctime and mtime diff changes (#1675) + +Bug: https://github.com/borgbase/vorta/issues/1672 +Bug-Debian: https://bugs.debian.org/1042671 +Applied-Upstream: 0.8.11, https://github.com/borgbase/vorta/commit/e3451ed49e4a760d2a0d037ef45f22155eeb2ed9 + +Borg v1.2.4 added new change types called `mtime` and `ctime` for the modification and the creation time of a file. +Our diff json parser doesn't support these changes yet. +The plain text parser doesn't need to be updated since it is only used for earlier versions of borg. +This also extends the tooltip in the diff view to show changes in `ctime` or `mtime` in a localised manner. + +* src/vorta/views/diff_result.py (ChangeType): Add `CTIME` and `MTIME` linking to `MODIFIED`. + +* src/vorta/views/diff_result.py (DiffData): Add fields `ctime_change` and `mtime_change`. + +* src/vorta/views/diff_result.py (parse_diff_json): Parse the new change types. + +* src/vorta/views/diff_result.py (DiffTree.data): Add time changes to tooltip in a human readable format. + +* tests/test_diff.py : Update test data to include new change types. Add additional test cases for unittesting the new change types. +--- + src/vorta/views/diff_result.py | 55 - + tests/test_diff.py | 176 ++--- + 2 files changed, 217 insertions(+), 14 deletions(-) + +diff --git a/src/vorta/views/diff_result.py b/src/vorta/views/diff_result.py +index 6a8e5ba..cf8b936 100644 +--- a/src/vorta/views/diff_result.py b/src/vorta/views/diff_result.py +@@ -6,7 +6,7 @@ + from pathlib import PurePath + from typing import List, Optional, Tuple + from PyQt5 import uic +-from PyQt5.QtCore import QMimeData, QModelIndex, QPoint, Qt, QThread, QUrl ++from PyQt5.QtCore import QDateTime, QLocale, QMimeData, QModelIndex, QPoint, Qt, QThread, QUrl + from PyQt5.QtGui import QColor, QKeySequence + from PyQt5.QtWidgets import QApplication, QHeaderView, QMenu, QShortcut, QTreeView + from vorta.utils import get_asset, pretty_bytes, uses_dark_mode +@@ -206,6 +206,8 @@ def parse_diff_json(diffs: List[dict], model: 'DiffTree'): + change_type: ChangeType = None + mode_change: Optional[Tuple[str, str]] = None + owner_change: Optional[Tuple[str, str, str, str]] = None ++ctime_change: Optional[Tuple[QDateTime, QDateTime]] = None ++mtime_change: Optional[Tuple[QDateTime, QDateTime]] = None + modified: Optional[Tuple[int, int]] = None + + # added link, removed link, changed link +@@ -213,6 +215,8 @@ def parse_diff_json(diffs: List[dict], model: 'DiffTree'): + # added directory, removed directory + # owner (old_user, new_user, old_group, new_group)) + # mode (old_mode, new_mode) ++# ctime (old_ctime, new_ctime) ++# mtime (old_mtime, new_mtime) + for change in item['changes']: + # if more than one type of change has happened for this file/dir/link, then report the most important + # (higher priority) +@@ -269,6 +273,22 @@ def parse_diff_json(diffs: List[dict], model: 'DiffTree'): + change['new_user'], + change['new_group'], + ) ++ ++elif change['type'] == 'ctime': ++# ctime change can occur along with previous changes ++change_type = ChangeType.MODIFIED
Bug#1050387: debsign: please run with --no-auto-check-trustdb (or allow it to be set)
Hi Mattia, Mattia Rizzolo writes: > On Wed, Aug 23, 2023 at 04:44:58PM -0400, Nicholas D Steeves wrote: >> An up-to-date trustdb isn't needed to sign a changes file, so I think >> --no-auto-check-trustdb should be debsign's default. Alternatively, please >> allow it to be set as a config option. >> >> It looks like this would be a trivial patch, but I'd like to confirm with >> others that this would be a good idea, and that I'm not just biased! > > > It sounds like a very sensible flag also to me, yes. :) > In fact, isn't this something that changed between gpg1 and gpg2? Yes, I think you're right. > I reckon it simply didn't bother others enough to do something about > it… in my system it only takes roughtly 20-30 seconds, and I can wait > that much. Agreed, 20-30 seconds isn't bad at all. I wish my laptop was that fast! > For what I'm concerned, you can directly push such change to git, > provided it's only this much :) Done! See commit f8bccd1b4c9feb0bd71b48a5668837174f1dfb1b Cheers, Nicholas signature.asc Description: PGP signature
Bug#1050546: bookworm-pu: package vorta/0.8.10-1+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: vo...@packages.debian.org, s...@debian.org Control: affects -1 + src:vorta [ Reason ] The upload of borgbackup/1.2.4-1 broke vorta/0.8.10-1, because that release of borg breaking changes (during the soft freeze), and no one noticed until bookworm was released as stable. [ Impact ] Some core functionality in Vorta is broken in bookworm; specifically, the ability to diff between backups. This issue was discovered and reported by a user at Bug #1042671. Additionally, I think this issue must be fixed because we are proud of how well our stable release process works; Our freeze, and stable updates, exist to prevent this sort of bug from impacting users in stable releases. [ Tests ] This packages has build-time tests as well as both types of autopkgtests for Python packages. Autopkgtests run with xvfb-run to be as close to real-world usage as possible. Finally, Lutz Lübbert confirms that the targeted fix proposed in this upload works correctly: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042671#31 [ Risks ] Insignificant. The changes introduced in the fix this upload cherry picked from upstream have already been tested in vorta/0.8.12-1 for over two months, as well by users of upstream's 0.8.11 release in April. The changes are found in 0006-Handle-ctime-and-mtime-diff-changes-1675.patch, they look like to obvious and correct solution to me. It would be possible to fix this from the borgbackup side, but I think we will agree that fixing this in a vorta p-u is the correct approach. [ 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 (old)stable [x] the issue is verified as fixed in unstable [ Changes ] This upload adds 0006-Handle-ctime-and-mtime-diff-changes-1675.patch, which adapts vorta to the ctime and mtime tracking introduced in borgbackup/1.2.4-1. It also adds test coverage for this change. <#part type="application/octet-stream" filename="/home/sten/Dropbox/tmp/0.8.10-1_to_0.8.10-1+deb12u1.debdiff" disposition=attachment> <#/part> Thank you for your consideration, Nicholas
Bug#1016558: ITA: muse-el
Manphiz writes: > Nicholas D Steeves writes: > >> Manphiz writes: >> >>> Nicholas D Steeves writes: >>>>> Nicholas D Steeves writes: > > Hmm, indeed I also cannot search it through my email. However, directly > search the fingerprint works: [snip] > I wonder what I could have done wrong that it doesn't index my email > address? gpg --search-keys 88A41F77AA3CD668C8F8B5802DE965ED63825C93 gpg: data source: https://keys.openpgp.org:443 (1) 4096 bit RSA key 2DE965ED63825C93, created: 2015-11-20 Keys 1-1 of 1 for "88A41F77AA3CD668C8F8B5802DE965ED63825C93". Enter number(s), N)ext, or Q)uit > 1 gpg: key 2DE965ED63825C93: new key but contains no user ID - skipped gpg: Total number processed: 1 gpg: w/o user IDs: 1 It appears that all identities were deleted. Since you agree this can be defer this for later, this is just an FYI :) I think the way your QA page will work is that all identities attached to 88A41F77AA3CD668C8F8B5802DE965ED63825C93 will appear, so we can introduce it later, but to be honest I've never tested this approach. https://qa.debian.org/developer.php https://contributors.debian.org/ > However, as it turns out, the savannah repo has a completely different > layout compared to the current one we package (which is actually based > on github). I'm partially to blame for this confusion; just now, I used git-timemachine to step back through the watch history until I found d7dea867b86c. My mistake was thinking it was ok to use the github tag/release service as a notification mechanism, when the true source of this release (not git snapshot) was git://repo.or.cz; if I remember correctly, the fork was just a mirror back then, and/or it was still in the "wait and see what GNU does" period of this software's maturation. See the changelog entry for 3.20+dfsg-1. The github fork of course replicates the history of repo.or.cz, and at the time I set the watch file to track github, uscan didn't yet have mode=git (or it was experimental and/or we didn't have lightweight clones yet). In other words, that was an inaccurate hack of mine, and I should have written a comment in the watch file...sorry about that, I didn't know better at the time. No, our source is not "actually based on github". Did you notice that we don't have upstream git history in this repository? 3.20 was never imported from git. Tldr: I created this repo with 'gbp import-dsc'. v3.20 from the official source at the time 3.20 was imported: https://repo.or.cz/muse-el.git/snapshot/caaa41cbf959afb379516e88776ec374160b8a94.tar.gz which is identical to https://github.com/alexott/muse/archive/refs/tags/v3.20.tar.gz > In fact, the savannah one uses a Makefile that assumes the project > layout as the github one while some of the directories like "lisp" are > not even there (which makes me think whether targeting the savannah > repo is the correct choice). Some words appear to be missing, so I don't understand what you mean. Please consult d/rules to learn why an upstream Makefile is irrelevant by-design to this package. Also, consult the dh-elpa man page and perhaps also team documentation on our wiki. It's also worth consulting MELPA packages (and the source used by MELPA) to see how Makefile's aren't needed there either. > Therefore, I'd like to postpone the sync with savannah repo to a > future upload to avoid more immediate work for uploading if that's OK. That's OK with me! As noted previously, I'll support the decision you make in your choice of future upstream, but it needs to be a conscious and principled decision. If you don't want to decide at this time, please implement a method that will remind you (or a future maintainer) to investigate and fix this issue. Tldr, we don't want to switch back and forth between GNU source and fork source. At some point it might also be nice to see DEP12 implemented in this package: https://dep-team.pages.debian.net/deps/dep12/ > Meanwhile, when trying to figure out the emacs/elpa.git repo structure I > realized that this repo is actually synced package repo on GNU Elpa as > one of its branch, and the entry of muse in elpa-packages[2] says: > > , > | (muse :url "https://github.com/alexott/muse;) ;FIXME: > Not nearly in-sync > ` > > I guess the plot thickens, but I'll just let it be for now :P :) Fair, and yeah, the GNU monorepo is ugly... The new Debian maintainer of this package should contact GNU via email on publicly archived lists. If you don't want to do this at this time, that's ok, but please do something with the watch file that makes this issue more visible. If you don't want to contact upstream at this time, please file a bug against the muse-el package to track this long-term outstanding issue (future upstream source of the package). >>> [1
Bug#809931: org-mode: Correction to report
Hello Reuben, Reuben Thomas writes: > Package: org-mode > Version: 8.3.2-1 > Followup-For: Bug #809931 > > The correct value for org-odt-data-dir is actually > > /usr/share/emacs/site-lisp/org-mode/etc > > (not …/styles as I previously said). Wow, it seems no one saw this bug for quite some time... I recently did some Debian Emacsen Team uploads for org-mode, and I noticed that the following are not currently installed in the elpa-org package: etc/csl/locales-en-US.xml etc/styles/OrgOdtContentTemplate.xml etc/styles/OrgOdtStyles.xml however, emacs-common installs this: /usr/share/emacs/28.2/etc/org/OrgOdtStyles.xml Do you know if the copy bundled with Emacs is sufficient, or if we should be setting org-odt-data-dir to a value specific to elpa-org? Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, On Fri, 18 Aug 2023 02:07:46 +0300 Alexandru Mihail wrote: > >After that, let's talk about uploading. Think about whether you'd > >like > >to start gaining practice with dput (or dput-ng), or whether you'd > >like > >me to sponsor directly from git. > I'm pretty ambivalent to both..are you more comfortable with either one > ? I'd reckon practice with dput might help me in the case where I > become an uploading maintainer with full rights? They're about the same for me. Honestly I'd prefer to do a git upload at this time, and save the GPG key discussion for your next upload. We can use dput and mentors then, and I think we'll both agree that we've both worked hard enough for this first upload haha. > Cheers, we're getting close :D ! Indeed, I just merged, congratulations! At this point, please do a "dch -r" and ensure that the changelog entry is refinalised; this will update the date stamp. Hint: you may have to make do a noop edit like + to make this work properly. Commit the new changelog entry with a message like: Release 1.30-4 to unstable. And push that to the remote we're using for your MR. Then make an annotated and optionally GPG signed tag. I like to use "gbp tag" for this, but you can use whatever method you prefer. Please make sure the annotated tag is on the master branch and not a detached head. Let me know, and I'll review, and upload when everything looks good, as it no doubt will. Then I'll give you push permissions so you can push the release commit and tag to the actual project repository :) Cheers, Nicholas signature.asc Description: PGP signature
Bug#1016558: ITA: muse-el
Manphiz writes: > Nicholas D Steeves writes: >>> Nicholas D Steeves writes: >> > > Should have removed the redundant signatures and reuploaded to > https://keys.openpgp.org, though I don't think I had 5 signatures on the > same IDs? Anyway, PTAL. Web interface: keys.openpgp.org Error: No key found for email address manp...@gmail.com $ gpg --search-keys manp...@gmail.com gpg: data source: https://keys.openpgp.org:443 gpg: key "manp...@gmail.com" not found on keyserver gpg: keyserver search failed: Not found Strictly speaking, you don't need to worry about your key until you start wanting to make uploads (mentors, Debian Maintainer per-package upload privileges, Debian Developer uploading), so we can defer this. >> What is your intention here? Are you rebasing our package onto this >> fork, or are you using the fork as a code dump, or something else? >> > > Well to be honest I didn't realize the github one was a fork as the > d/watch file had been pointing there. "git blame debian/watch" to see who is to blame, and fix fdde4981, which introduced this problem. This is a blocker to uploading the package. > Also from your other mail: Thank you for merging these emails. >> I found that this UTF8 issue was already fixed upstream: >> >> @@ -412,11 +433,11 @@ >> >> https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?h=externals/muse=be347db7f1ad56f0384f76011bfd148ff3352610 >> >> and note that it's now an official GNU project (via copyright assignment) >> >> Copyright (C) 2004-2020 Free Software Foundation, Inc. > > So it should be clear that the Savannah one should be considered the > canonical upstream. I'll update my question on github to ask for > whether Alex want to forward the patches in his repo to Savannah as > well. Thanks. > Also as a result, I've marked the patch as "Forwarded: not-needed". Thank you. Alternatively you can either cherry pick the upstream commit (and export as quilt patch) and drop mine, or package a new upstream snapshot from the savannah source, since that's what we're tracking. >> Oh, there's one more thing that needs to be fixed before we upload: >> Bug #1048114 > > Attempted to fix it in [2] where I just regenerated the changing file in > sbuild. > > [1] https://github.com/alexott/muse/issues/16 > [2] > https://salsa.debian.org/emacsen-team/muse-el/-/commit/f5c217162d9c6f45c971cec2b8c70b2794bb77fe This doesn't look like the right approach to me, the changelog entries related to it are unclear/misleading, and a description is missing in the patch header. Have you checked Savannah for a fix? Rather than a Debian-specific approach, it's best to stay close to upstream source whenever possible. If the issue is truly Debian-specific, then why not use dh_auto_clean or dh_clean, or another cleaner method? Thank you for your attention to detail. We're just about done! Regards, Nicholas signature.asc Description: PGP signature
Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1
"Adam D. Barratt" writes: > On Thu, 2023-08-03 at 10:39 -0400, Nicholas D Steeves wrote: >> >> Thanks for the ACK, and for the reminder! I had forgotten to run dch >> with "--team", so I fixed that, and uploaded. >> > > I'm not sure what happened to the upload, but there appears to be no > sign of it in either the queued or dak logs. Oh my! Thank you for letting me know, I truly appreciate it. I checked my local build output and to-upload directory/queue and found that the package hadn't been signed, which means that my sign+upload command timed out requesting key signing password...which happened due to a horribly timed trustdb check (then I ran out of time). Gah. I've filed a debsign bug requesting feedback, since --no-auto-check-trustdb should probably be default for signing changes file. Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1050387: debsign: please run with --no-auto-check-trustdb (or allow it to be set)
Package: devscripts Version: 2.23.4 Severity: normal Earlier this month I attempted to upload a security-related stable-pu; however, "debsign foo.changes && dput foo.changes" never reached the dput stage, because GPG decided that it was a good time to update the trustdb. Updating the trustdb takes about five minutes on my system, and it runs this before running pinentry to actually make the signature. I ran out of free time while waiting. An up-to-date trustdb isn't needed to sign a changes file, so I think --no-auto-check-trustdb should be debsign's default. Alternatively, please allow it to be set as a config option. It looks like this would be a trivial patch, but I'd like to confirm with others that this would be a good idea, and that I'm not just biased! Thank you, Nicholas I consulted the changelog of 2.23.6 to confirm this bug is still outstanding. -- Package-specific info: --- /etc/devscripts.conf --- DEBCHANGE_MULTIMAINT_MERGE=yes DEBCHANGE_MAINTTRAILER=yes DEBSIGN_KEYID=E2A6261E3900AED7CDC667085A8830475F7D1061 DPKGSIG_KEYID=E2A6261E3900AED7CDC667085A8830475F7D1061 NMUDIFF_DELAY=7 USCAN_DESTDIR=/home/sten/devel/tarballs --- ~/.devscripts --- Empty. -- System Information: Debian Release: 12.1 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-11-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 devscripts depends on: ii dpkg-dev 1.21.22 ii fakeroot 1.31-1.2 ii file 1:5.44-3 ii gnupg 2.2.40-1.1 ii gnupg22.2.40-1.1 ii gpgv 2.2.40-1.1 ii libc6 2.36-9+deb12u1 ii libfile-dirlist-perl 0.05-3 ii libfile-homedir-perl 1.006-2 ii libfile-touch-perl0.12-2 ii libfile-which-perl1.27-2 ii libipc-run-perl 20220807.0-1 ii libmoo-perl 2.005005-1 ii libwww-perl 6.68-1 ii patchutils0.4.2-1 ii perl 5.36.0-7 ii python3 3.11.2-1+b1 ii sensible-utils0.0.17+nmu1 ii wdiff 1.2.2-5 Versions of packages devscripts recommends: ii apt 2.6.1 ii curl7.88.1-10+deb12u1 ii dctrl-tools 2.24-3+b1 ii debian-keyring 2022.12.24 ii dput1.1.3 ii equivs 2.3.1 ii libdistro-info-perl 1.5 ii libdpkg-perl1.21.22 ii libencode-locale-perl 1.05-3 ii libgit-wrapper-perl 0.048-2 ii libgitlab-api-v4-perl 0.26-3 ii liblist-compare-perl0.55-2 ii liblwp-protocol-https-perl 6.10-1 ii libsoap-lite-perl 1.27-3 ii libstring-shellquote-perl 1.04-3 ii libtry-tiny-perl0.31-2 ii liburi-perl 5.17-1 ii licensecheck3.3.5-1 ii lintian 2.116.3 ii man-db 2.11.2-2 ii patch 2.7.6-7 ii pristine-tar1.50 ii python3-apt 2.6.0 ii python3-debian 0.1.49 ii python3-magic 2:0.4.26-3 ii python3-requests2.28.1+dfsg-1 ii python3-unidiff 0.7.3-1 ii python3-xdg 0.28-2 ii strace 6.1-0.1 ii unzip 6.0-28 ii wget1.21.3-1+b2 ii xz-utils5.4.1-0.2 Versions of packages devscripts suggests: ii adequate 0.15.7 ii at 3.2.5-1+b1 ii autopkgtest 5.28 pn bls-standalone ii build-essential 12.9 pn check-all-the-things pn cvs-buildpackage ii debhelper13.11.4 ii diffoscope 240 pn disorderfs ii dose-extra 7.0.0-1+b2 pn duck ii elpa-devscripts 40.5 ii faketime 0.9.10-2.1 ii gnuplot 5.4.4+dfsg1-2 ii gnuplot-qt [gnuplot] 5.4.4+dfsg1-2+b2 ii how-can-i-help 17 ii libauthen-sasl-perl 2.1600-3 pn libdbd-pg-perl ii libfile-desktopentry-perl0.22-3 pn libterm-size-perl ii libtimedate-perl 2.3300-2 ii libyaml-syck-perl1.34-2+b1 ii mailutils [mailx]1:3.15-4 pn mmdebstrap pn mozilla-devscripts ii mutt 2.2.9-1+b1 ii openssh-client [ssh-client] 1:9.2p1-2 ii piuparts 1.1.7 pn postgresql-client pn pristine-lfs ii quilt
Bug#1040690: emacsen-common analysis for cruft files from elpa-foo packages during apt upgrade
Richard Lewis wrote:
> David Bremner wrote:
>
> > Richard Lewis writes:
> > > David Bremner wrote:
> > >
> >
> > As far as the actual bug with failing to clean up, I ran
> >
> > % systemd-nspawn --machine bullseye /usr/lib/dh-elpa/helper/remove emacs
> > dash 2.17.0
> >
> > and that cleans up the directory
> >
> > /usr/share/emacs/site-lisp/elpa/dash-2.17.0
> >
> > so the bug is at some other level of the stack. I guess I will have to
> > look at the log from the upgrade, but I haven't had a chance to do that
> > yet.
> >
>
> I was trying to understand when (and how ) your command above was intended
> to be run as part of the upgrade. I cna see that in bullseye
> /usr/lib/emacsen-common/packages/remove/elpa-dash would do it if called
> with 'emacs'. but this is never called:
>
> What happens in the 'apt upgrade' is:
>
> the old emacsen-common prerm is called (' upgrade
> '):
>
> /var/lib/dpkg/info/emacsen-common.prerm upgrade 3.0.5
>
> This calls:
> /usr/lib/emacsen-common/emacs-package-remove --prerm emacsen-common
>
> This calls:
> /usr/lib/emacsen-common/packages/remove/emacsen-common
>
> and at the end it _unlinks_:
> /var/lib/emacsen-common/state/package/installed/emacsen-common
@1
> Then, apt prepares to unpack elpa-dash:
>
> The elpa-dash prerm (from bullseye) is called as:
> /var/lib/dpkg/info/elpa-dash.prerm upgrade
> 2.19.1+git20220608.1.0ac1ecf+dfsg-1)
>
> but this starts with:
>
> if [ -e /var/lib/emacsen-common/state/package/installed/emacsen-common -a
> -x
> /usr/lib/emacsen-common/emacs-package-remove ] ; then
> /usr/lib/emacsen-common/emacs-package-remove --prerm elpa-dash
>
> fi
>
> ... and so does nothing,
> because /var/lib/emacsen-common/state/package/installed/emacsen-common is
> gone.
Oh! It's a state-related bug! I wonder if emacsen-common (old version)
has been deinstalled at @1 (see above), or if the state is
emacsen-common (new version) is unpacked, but unconfigured, and thus
missing /var/lib/emacsen-common/state/package/installed/emacsen-common,
which is presumably created as a last step during package configuration
post-unpack?
In other words, elpa-dash (and other...most?..all? dh-elpa-using
packages) upgrades depends on having emacsen-common fully installed and
configured at @1.
I wonder if this can be solved in emacsen-common, or if it needs to be
solved in dh-elpa and then all the dh-elpa-using packages rebuilt to
generate new prerm scripts? Which do you think would be the better
approach?
Cheers,
Nicholas
signature.asc
Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Thanks again for your work! I submitted a second (I think we're at the second one) gitlab review here: https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2/diffs Summary: 1. One minor nitpick for multi-maint changelog format 2. Two lines that I can't make sense of within the context of the changelog. If you haven't already, please follow-up with these two bugs you've noted on the BTS, and please CC any contributors to those bugs. After that, let's talk about uploading. Think about whether you'd like to start gaining practise with dput (or dput-ng), or whether you'd like me to sponsor directly from git. If there's anything you'd like to squash either squash it and force push, or let me what what you'd like help squashing. Cheers, Nicholas signature.asc Description: PGP signature
Bug#777578: initramfs-tools: update-initramfs fails with btrfs
Hi, jnqnfe writes: > On 11/02/2015 18:42, Ben Hutchings wrote: >> So the root (no pun intended) of the problem is that btrfs-tools was >> not installed. Ben. > > Ah ha, you're absolutely right, I assumed it was but it is indeed not > installed. Thanks for that. > > Yep, now it boots successfully :D Are you still able to reproduce the state where Debian is successfully installed to a btrfs rootfs, but where btrfs-progs is not installed? From what I can tell, that is the nature of this [by now most likely historical] bug. Regards, Nicholas signature.asc Description: PGP signature
Bug#757182: debian-installer: Please provide a warning about BTRFS
Dimitri John Ledkov writes: > On 6 August 2014 03:46, Russell Coker wrote: >> Package: debian-installer >> Severity: normal >> >> http://www.spinics.net/lists/linux-btrfs/msg36461.html >> >> BTRFS has some issues that can cause system lockups, filesystem deadlocks >> that >> prevent writing to disk, and other problems. After some discussion on the >> BTRFS mailing list (see the above URL for the archive) the consensus seems to >> be that we should have a warning. BTRFS isn't at the stage where someone >> with >> little knowledge of it can just use it. To have it work reliably the >> sysadmin >> needs to know more about it than for other filesystems. >> > > I disagree and the assessment here is unjust. By default we offer > ext4, [ with lvm2 [ with cryptsetup LUKS ] ]. mdadm raid needs > additional setup. > For none of the above, we show any warnings. > In the manual partitioning, again ext4 is the default. To get to > BTRFS, one needs to change from ext4 to it, which imho there is a > sufficient amount of hoops to jump through. > I wouldn't want to loose ability to install on to btrfs, since > developers have need to have working installers with btrfs. > From UX perspective, users don't read warnings =) > When people ask me if they should use btrfs, or if btrfs is ready my > reply is usually "if you have to ask, you shouldn't use it. Instead > study and benchmark it to know for sure what you are getting into with > your workload." > > ext4 is Debian's and Ubuntu's default filesystem for upcoming releases. Nine years since this bug was filed, and three years since Fedora has been using btrfs by default, I think this bug can be closed. Any objections? Nicholas signature.asc Description: PGP signature
Bug#757182: debian-installer: Please provide a warning about BTRFS
P.S. > Dimitri John Ledkov writes: > >> On 6 August 2014 03:46, Russell Coker wrote: snip >>> be that we should have a warning. BTRFS isn't at the stage where someone >>> with >>> little knowledge of it can just use it. To have it work reliably the >>> sysadmin >>> needs to know more about it than for other filesystems. >>> >> >> I disagree and the assessment here is unjust. I agree. That was supposed to be in the last email!
Bug#1016558: O: muse-el
Hello, Sorry for the delay, I hadn't realised that I had forgotten to actually send this draft: On Fri, 11 Aug 2023 at 22:09, Manphiz wrote: > Nicholas D Steeves writes: > Now also uploaded my PGP keys to https://keys.openpgp.org/. pgp.mit.edu > has been unstable for a while, so a good alternative is definitely a > plus :) For sure, and also, it's been the default keyserver in Debian since 2019 (gnupg 2.2.17-1) ;) Yeah, I've also noticed pgp.mit.edu has gotten slower and more unreliable than in the past. P.S. This might be a bit pedantic, but doesn't your key have five redundant signatures that could be deleted? > >> I: muse-el source: patch-not-forwarded-upstream > >> [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] > >> > >> I wonder whether you would also like to forward this patch upstream. > > > > If you really want to, go ahead, but I'm not interested in the FSF's > > identity verification for copyright assignment process, so this might > > end up as a futile effort. In light of this, a "hey, we have a UTF8 > > conversion patch...would you like to convert your copy to UTF8 either > > with or without our patch" might be smoother. If you happen to have > > have done FSF copyright assignment paperwork, please go ahead and > > claim ownership of that trivial patch. > > Forwarded upstream. As my pull request got merged fairly quickly I'm > slightly more optimistic here. Hmm, it appears that these patches were forwarded to a fork. The Source is set to git://repo.or.cz/muse-el.git (debian/and the Homepage is set to https://www.gnu.org/software/emacs-muse/index.html (debian/control). As the new maintainer it's your right to switch upstream sources, but I recommend you ask some team members and #debian-mentors on irc or the mailing list about what the downsides to this may be; the mailing list archives might have a record of someone else asking a question like this. I'll support your decision once you let me know you've investigated and considered. What is your intention here? Are you rebasing our package onto this fork, or are you using the fork as a code dump, or something else? > > I'm happy to sponsor from git when you finalise the changelog, but if > > ever you want to get some hands-on experience with dput (or dput-ng), > > then practise uploading to https://mentors.debian.net/. > > Uploaded using dput. Would be great to have you to take a look as > well. Thanks! The aspects relating to the upload look good to me. Oh, there's one more thing that needs to be fixed before we upload: Bug #1048114 Take care, Nicholas
Bug#1017762: incompatible after "btrfs subvolume set-default ..."
Hello, Osamu Aoki writes: > It is great to have btrfs support with @rootfs. Thanks. I wish if it > is a bit more verbose on what it does in installer dialogue. This is > more important if we want to use existing btrfs with something like > @home-uid1000 in it ;-) > You are welcome, and yes, I agree, the current state is definitely incomplete! By the way, it's cool to hear from someone who is using user $HOME subvolumes :) > Anyway, I experienced an unsuccessful install to the existing btrfs > partition. I had @rootfs-broken-backup in it and I set "btrfs subvolume > set-default ..." to it. Don't ask me why I did. But this caused d-i > to stop installation without much error report. > Agreed, silent failure is a major problem. > EXPECTED BEHAVIOR: > > 1. Clearly mention the use of subvolume @rootfs in d-i dialogue. > (This is for both fsck or fsck-less install cases.) > The entirety of my reply supposes that you intended 's/fsck/mkfs/'. Yes, I agree this should be more verbose. > 2. Check "btrfs subvolume get-default " to be "ID 5 > (FS_TREE)". If not, > * stop installation with clear message or (reasonable?) Yes, and this will not break other installed operating systems that use set-default (eg SUSE, last I checked). Have you investigated whether Snapper rollbacks necessarily use set-default as well? If so, we will need to coordinate with Hedeki Yamane. > * set-default to fix this. (better?) > (This is for fsck-less install) > As you know, I am categorically against this approach. Within a Debian context, it seems to me that the most typical use-cases for a shared volume are: 1. Boot environments (like system restore checkpoints). This is a project that I used to have a lot of energy for, and why I joined Debian, but I have suffered significant demotivation for a variety of reasons. 2. A rootfs subvolume for stable, and another rootfs subvolume for sid, or possibly some other Debian-derivative distribution. 3. Please share what you use them for :) Why not just: * Always mount a btrfs volume with subvolid=5 during the subvolume creation step of a Debian installation to btrfs. The debootstrap and bootloader steps occur after remounting subvol=@rootfs, so the bootloader subvol autodetection generates the correct config for the new installation. If os-prober fails to find other OS on other bootable subvolumes then that is a bug in os-prober. To put this option another way: If you want to hide something from debian-installer, use LUKS, not a default-subvolume...that said, I seem to remember that the use of default subvolumes, plus multiple installed OS plays havoc with GRUB. * To support this policy in an optimal way may also suggest the creation of a new subvolid=5 view in the default install. By this I mean the creation of something like /btrfs-admin, which is subvolid=5 of the device that contains @rootfs, by default, in all installations. > 3. Check existance of @rootfs. If exists, >* stop installation with clear message or (simple) I believe this is the current best option, and maybe go one step farther in an advanced installation and emit a message that advanced users will use to prepare the volume. (ie something like "The Debian Installer currently requires @rootfs; however, this subvolume already exists. Please switch to a console and move the existing @rootfs out of the way) >* make a backup snapshot of @rootfs to some other name and > remove @rootfs to have clean start. (better) >(This is for fsck-less install) > The Debian Installer cannot guess what the correct action is, and it is wrong to automatically make an existing working installation unbootable. Last I checked we didn't even do that to Windows. Regards, Nicholas
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: > Nicholas D Steeves writes: > > > Hi, > > > > Reply follows inline. Can we move this discussion to #1016558 to not > > bother Axel with our discussion? I guess that's a no? > > Manphiz writes: > >> Nicholas D Steeves writes: > >>>>> Nicholas D Steeves writes: > > > > Wonderful! I also see you have a GPG key now. Have you generated > > revocations certificates yet? > > > > > > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate > > Now I have one. Thanks for the tip! You're welcome :) > > Next, where can I find your key? > > I have previously uploaded my GPG key to pgp.mit.edu[1]. Ah, that's where it was. I thought everyone had switched to https://keys.openpgp.org/ these days (this is the default server on Debian) after the end of the SKS network. Thanks for the reminder to continue to check pgp.mit.edu as a fallback. > Please advise if https://keyserver.ubuntu.com is still recommended for > prospective DMs. This is the first I've heard of that recommendation. I wonder if people in #debian-mentors (OFTC) will also be surprised? I'd use keyserver.ubuntu.com if I had a Launchpad account and maintained a PPA, but honestly wouldn't bother. I started using keys.openpgp.org since that's where various people expected to find my key haha. > I have a few more commits[2] that should have fixed most of the lintian > warnings. LGTM > There is another INFO level warning: > > I: muse-el source: patch-not-forwarded-upstream > [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch] > > I wonder whether you would also like to forward this patch upstream. If you really want to, go ahead, but I'm not interested in the FSF's identity verification for copyright assignment process, so this might end up as a futile effort. In light of this, a "hey, we have a UTF8 conversion patch...would you like to convert your copy to UTF8 either with or without our patch" might be smoother. If you happen to have have done FSF copyright assignment paperwork, please go ahead and claim ownership of that trivial patch. I'm happy to sponsor from git when you finalise the changelog, but if ever you want to get some hands-on experience with dput (or dput-ng), then practise uploading to https://mentors.debian.net/. Best, Nicholas On Sun, 6 Aug 2023 at 04:37, Manphiz wrote: > > Nicholas D Steeves writes: > > > Hi, > > > > Reply follows inline. Can we move this discussion to #1016558 to not > > bother Axel with our discussion? > > > > Manphiz writes: > > > >> Nicholas D Steeves writes: > >>>>> Nicholas D Steeves writes: > >>>>> > >> Thanks! Though I'm not really a user of muse-el, I'd like to keep it in > >> a good shape as an exercise as an Emacs addon maintainer. It looks like > >> there is not too much work thanks to Elisp being a fairly stable > >> language :) > > > > That's fine, thank you once again for adopting it, and yes, generally > > everything is ok :) > > > >>>> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 > >>> > >> Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] > >> and agreed with Debian Janitor on the "no changes are needed" bit. And > >> to avoid having to wait for the bot to do the rebase I've manually > >> resolved the conflicts and rebased my MR on top of it as well. > >> > > > > You're welcome, and good call. > > > >>> Let me know when your done, and we can talk about the next steps. > >> > >> Now all MRs are merged. Please advise the next steps. Thanks! > >> > > > > Wonderful! I also see you have a GPG key now. Have you generated > > revocations certificates yet? > > > > > > https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate > > Now I have one. Thanks for the tip! > > > > > Next, where can I find your key? > > I have previously uploaded my GPG key to pgp.mit.edu[1]. > > > I'm assuming that you're committed to > > maintaining this identity for the foreseeable future, and that you'd > > like to build reputation for future involvement in Debian. It's not > > required at the stage you're at, but it's recommended. > > > > https://wiki.debian.org/Keysigning#Step_3:_Make_your_public_key_public > > Please advise if https://keyserver.ubuntu.com is still recommended for > prospective DMs. > > > > > The subkey that I was able to download didn't include any ident
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Alexandru Mihail writes: > I've redone some diffs, too. Also, my previous statement of 1.4.2 httpd > makes no sense, because, at a quick glance, I could observe the > introduction of virtual hosting in httpd 1.5*, which mini-httpd had > from the beginning. You're right to advise to look at 1.5* again. +1 and where can I see this new work? >>I started a review and noted what looks like one typo. > Where can I view the typo/review info ? I've looked in my original > merge details and I couldn't find it. Am I affected by temporary > blindness ? :) You should have received notifications for the review to the email address that you used to sign up for Salsa, and those emails included links to individual items. Alternatively, you can see the full review here: https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2/diffs If you strongly dislike using web interfaces and prefer patches via email, please let me know and we'll switch back to email. Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru,
Alexandru Mihail writes:
> MR filed:
> https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2
Thanks. We can rebase and squash at the end, but for now please don't
force push.
>>Oh man, yeah, hello early days of the internet! All you need now is
>>some MIDI files and GIFs.
> Haha, your paragraph makes me want to reinstall DOOM/Starcraft for the
> nth time now :)
:)
>>3. Please note which version of NCSA httpd matches mini-httpd.
> After much diff'ing and vim'ing and staring at #ifdefs and trying to
> separate Jef's unversioned changes to htpasswd.c from actual NCSA
> updates:
> It's 99.999% 1.4.2. I noted that in debian/copyright.
Remember my Wed, 21 Jun 2023 email (as well as the one with the
diagram)? 1.4.2 still has the "no commercial endeavour" clause.
Here is what I found with
https://github.com/TooDumbForAName/ncsa-httpd/
$ git checkout 1.5.1
$ git diff 1.4.2 -- support/htpasswd.c
diff --git a/support/htpasswd.c b/support/htpasswd.c
index a9263ec..fb3415a 100644
--- a/support/htpasswd.c
+++ b/support/htpasswd.c
@@ -4,12 +4,18 @@
* Rob McCool
*/
+#include "config.h"
+#include "portability.h"
+
#include
#include
#include
#include
#include
#include
+#ifdef NEED_CRYPT_H
+#include
+#endif /* NEED_CRYPT_H */
#define LF 10
#define CR 13
@@ -79,10 +85,13 @@ to64(s, v, n)
}
}
+#ifdef HEAD_CRYPT
char *crypt(char *pw, char *salt); /* why aren't these prototyped in include */
+#endif /* HEAD_CRYPT */
+
#ifdef HEAD_GETPASS
char *getpass(char *prompt);
-#endif
+#endif /* HEAD_GETPASS */
void add_password(char *user, FILE *f) {
char *pw, *cpw, salt[3];
=
I compared a couple of versions and found the same diff.
Hint: Read the commit message for 1.5.1. Having read that, what is your
explanation for this diff, and what is your explanation for the changes
between any version of httpd in this range and mini-httpd? There's
another hint in the tarball name that you're comparing with, but that
Jef Poskanzer may not have used.
> I hope everything is in order with my MR.
Yes, your MR looks good. I started a review and noted what looks like
one typo.
> Have a great day and may the Debian swirl girate eternally !
Haha, you too!
Nicholas
signature.asc
Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Hi, Reply follows inline. Can we move this discussion to #1016558 to not bother Axel with our discussion? Manphiz writes: > Nicholas D Steeves writes: >>>> Nicholas D Steeves writes: >>>> > Thanks! Though I'm not really a user of muse-el, I'd like to keep it in > a good shape as an exercise as an Emacs addon maintainer. It looks like > there is not too much work thanks to Elisp being a fairly stable > language :) That's fine, thank you once again for adopting it, and yes, generally everything is ok :) >>> [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 >> > Thanks for the tips! I checked the Debian Policy Upgrading Checklist[1] > and agreed with Debian Janitor on the "no changes are needed" bit. And > to avoid having to wait for the bot to do the rebase I've manually > resolved the conflicts and rebased my MR on top of it as well. > You're welcome, and good call. >> Let me know when your done, and we can talk about the next steps. > > Now all MRs are merged. Please advise the next steps. Thanks! > Wonderful! I also see you have a GPG key now. Have you generated revocations certificates yet? https://wiki.debian.org/Keysigning#Step_2:_Generate_a_revocation_certificate Next, where can I find your key? I'm assuming that you're committed to maintaining this identity for the foreseeable future, and that you'd like to build reputation for future involvement in Debian. It's not required at the stage you're at, but it's recommended. https://wiki.debian.org/Keysigning#Step_3:_Make_your_public_key_public The subkey that I was able to download didn't include any identities. Other than that, this package isn't quite ready to upload, because there are three unaddressed lintian warnings. https://wiki.debian.org/Lintian Best, Nicholas signature.asc Description: PGP signature
Bug#1016558: O: muse-el
Hi Xiyue Deng, I just realised that the package adoption conversation we're having didn't involve this bug. Just like converting a RFP bug to an ITP bug, you should convert this O to and ITA. To anyone else reading this, the sponsorship review is happening at the following bug: #1042911 Regards, Nicholas signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Hello, Manphiz writes: >> Nicholas D Steeves writes: >> > > Hi Nicholas, > > I have now prepared a merge request to migrate away from assoc.el[1] and > also forwarded the patch upstream. Also set the package as team > maintained and add myself as an upload. PTAL. Thanks! Wow, that was fast! LTGM, with one caveat: You are an Uploader for this package now, so please drop the "Team upload" line entirely. This makes you the human maintainer for the package, so I have sent you an invitation for salsa/gitlab maintainer permissions for muse-el. > [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/3 You will notice that there are two other MRs. Please double-check that the bot did its work correctly, and please manually go through the Debian Policy upgrade checklist, starting with the version muse-el uses, and each version up to and including the one the bot proposed. If you would like to take credit for this work, I recommend adding "and your name" to the changelog entries the bot proposes. [ The name of the bot and your name ] In other words, I would like to give you permission to write to this repo! Bots will often rebase their MRs to save you time, and I will leave the decision of what gets merged first, and what gets rebased up to you. Let me know when your done, and we can talk about the next steps. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1041612: Enhancing upstream version git awareness in Debian packages [was Re: Bug#1041612: RFS: dh-git/1.0 [ITP]]
Hi Aidan, Aidan writes: > OK, thank you for your quick feedback. > If the implementation is fundamentally flawed then I think I'll just leave > it. I liked the user-facing UI of your proposed solution, I agree that it can be hard to learn how to work with git in Debian packaging, and it can be hard to understand Debian upstream version numbers. https://wiki.debian.org/Packaging/SourcePackage https://www.debian.org/doc/debian-policy/ch-source.html Please note that many Debian packages are not child branches of upstream git history. Instead they import tarballs of git snapshots, but that's not to say that the metadata is lost! Might you be interested in writing a decoder of Debian upstream versions that already embed upstream git metadata? Some examples of existing versions are: 1.1+14.gb364e08 tagged_release + commits_since_that_release . letter_for_VCS_used hash 0.0~git20220110.1ce338b a_release_has_not_been_tagged ~ VCS_used date . hash 1.2.1+git20190611.dadb6258 tagged_release + VCS_used date . hash https://manpages.debian.org/bookworm/dpkg-dev/deb-version.7.en.html Between that, and the remote defined at debian/upstream/metadata:Repository for many packages, you can also write a simple program that searches upstream history for a confirmed match. https://wiki.debian.org/UpstreamMetadata Upstreams possess their git history, so they can just run the decoder on the Debian version. ie: $ git-upstream-decoder 1.1+14.gb364e08-2 b364e08009fe0062cf0927d8a0582fad5a12b8e7 The second third of this project could be the encoder, which 1. Generates a Debian Policy-compliant upstream version with embedded committish info (see the three examples included in this email). Some examples of how to do this can be found in dh-make-golang. 2. For workflows where upstream git history is merged, the encoder could also make it easier to tag an upstream committish for Debian use, which is just an extension of solution at #1. 3. Generates a watch file that uses mode=git, and that encodes the upstream committish into the Debian upstream version. If I remember correctly uscan already has built-in support for a format compatible with git-describe. The final third letting people know about your tool, encouraging upstreams to use it, etc. One problem I noticed with dh-git is that it would require upstreams to have access to a Debian system. Not all do, and not all want to. Please let me know if you're interested, please consider CCing your reply (in-line style, not top-posting) to debian-de...@debian.org, and please keep me in CC. Regards, Nicholas signature.asc Description: PGP signature
Bug#1042928: Please include example handler for mailto: URIs
David Bremner writes: > Nicholas D Steeves writes: > >> 1. Set Notmuch as the default application for email (or URI handler) >> 2. Navigate to the BTS in a web browser like Firefox >> 3. Find a bug, and click on one of the reply links >> 4. Emacs opens in message-mode rather than notmuch-message-mode > > OK, this seems like a completely different bug report :). :) Maybe! I also wonder if I simply assigned it to the wrong package. > Unfortunately also not really one I know much about, as I don't use > Gnome (I assume step 1 above means set default in gnome?). It's not GNOME specific (I use KDE), but given that a desktop file is used, I wonder if the nature of this bug is more of an XDG thing. For the purposes of this bug I'll attempt to reproduce using my laptop rather than desktop. > I guess my first question is if you can duplicate the problem from the > command line. I tried > > % notmuch-emacs-mua --hello mailto:brem...@debian.org > > It seems to do the right thing. Hmm, % xdg-open mailto:brem...@debian.org also seems to do the right thing. > Maybe your mailto URLs are more complicated? Anyway, if you can > duplicate the problem without requiring gnome or firefox, that would be > helpful. Good hypothesis! The following mailto link is copied from the BTS via eww-view-source, it points to your most recent email, which is the the one that this email--my reply--is replying to: xdg-open "mailto:1042...@bugs.debian.org?References=%3C169101992716.3310278.2992723615742697826.reportbug%40bras-base-mtrlpq0313w-grc-19-69-156-163-190.dsl.bell.ca%3E%0A%20%3C87fs517z32.fsf%40tethera.net%3E%20%3C87tttguclr.fsf%40digitalMercury.freeddns.org%3E%0A%20%3C87bkfo8mpa.fsf%40tethera.net%3Ebody=On%20Thu%2C%2003%20Aug%202023%2007%3A06%3A09%20-0300%20David%20Bremner%20%3Cdavid%40tethera.net%3E%20wrote%3A%0A%3E%20Nicholas%20D%20Steeves%20%3Csten%40debian.org%3E%20writes%3A%0A%3E%20%0A%3E%20%3E%201.%20Set%20Notmuch%20as%20the%20default%20application%20for%20email%20%28or%20URI%20handler%29%0A%3E%20%3E%202.%20Navigate%20to%20the%20BTS%20in%20a%20web%20browser%20like%20Firefox%0A%3E%20%3E%203.%20Find%20a%20bug%2C%20and%20click%20on%20one%20of%20the%20reply%20links%0A%3E%20%3E%204.%20Emacs%20opens%20in%20message-mode%20rather%20than%20notmuch-message-mode%0A%3E%20%0A%3E%20OK%2C%20this%20seems%20like%20a%20completely%20different%20bug%20report%20%3A%29.%0A%3E%20%0A%3E%20Unfortunately%20also%20not%20really%20one%20I%20know%20much%20about%2C%20as%20I%20don%27t%20use%0A%3E%20Gnome%20%28I%20assume%20step%201%20above%20means%20set%20default%20in%20gnome%3F%29.%0A%3E%20%0A%3E%20I%20guess%20my%20first%20question%20is%20if%20you%20can%20duplicate%20the%20problem%20from%20the%0A%3E%20command%20line.%20I%20tried%0A%3E%20%0A%3E%20%25%20notmuch-emacs-mua%20--hello%20mailto%3Abremner%40debian.org%0A%3E%20%0A%3E%20It%20seems%20to%20do%20the%20right%20thing.%20%0A%3E%20%0A%3E%20Maybe%20your%20mailto%20URLs%20are%20more%20complicated%3F%20Anyway%2C%20if%20you%20can%0A%3E%20duplicate%20the%20problem%20without%20requiring%20gnome%20or%20firefox%2C%20that%20would%20be%0A%3E%20helpful.%0A%3E%20%0A%3E%20%0A%3E%20d%0A%3E%20%0A%3E%20%0Asubject=Re%3A%20Bug%231042928%3A%20Please%20include%20example%20handler%20for%20mailto%3A%20URIsIn-Reply-To=%3C87bkfo8mpa.fsf%40tethera.net%3E; ...and that succeeds. Finally, it works properly in Firefox on my laptop...oh no, this is starting to look like a Heisenbug. I'm baffled why notmuch-message-mode opens correctly on my laptop, while my desktop opens message-mode. So what are the differences between the systems? My desktop had the dummy transitional package "notmuch-emacs" installed. Of course, that shouldn't make a difference one way or another, but I've removed it anyway. How can I trace Emacs, to see what data it receives as a startup argument, and to see what it does with it? I'd like to see if I can eliminate the "the desktop environment is sending a bad URI" hypothesis. Best, Nicholas signature.asc Description: PGP signature
Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.
Control: tag -1 + upstream wontfix Control: forwarded -1 https://list.orgmode.org/20160222085952.GA32746@garlic/ Hello Max, Max Nikulin writes: > On Sun, 21 Feb 2016 11:37:01 +0100 Sébastien Delafond wrote: >> >> thanks for your report. As this seems to be a pure upstream problem, >> could you please follow up on it using the org-mode mailing list[0] ? >> Once that's done, feel free to add a link to your post in the Debian >> BTS. > > I think, this issue can be closed as not a bug: > > Nicolas Goaziou to emacs-orgmode. Re: * [[shell:cat ~/tmp | grep "asdf > :: "]] does not work. Wed, 24 Feb 2016 18:38:09 +0100 > https://list.orgmode.org/878u2a57r2@nicolasgoaziou.fr/T/#u > >> This is not a bug. - :: *is* description list syntax, no matter how >> you look at it. You can easily work around this, e.g., by starting the >> link on the next line. I read the thread upstream, and see what you mean, and upstream's perspective makes sense. How do you feel about keeping this bug open, because this "gotcha" should be documented somewhere. I'm not sure if org-mode's documentation would be the best place, because it's non-free. For future readers of this bug, Brian G Powell wrote some nice style suggestions for avoiding this pitfall, so here is the link: https://list.orgmode.org/CAFm0skF=3JNXQQPFYutEvM8y+FRZJziE+QngVX=gocx3rkq...@mail.gmail.com/#t > And a related issue: try to export text where /italics breaks the link > [[https://lists.debian.org/msgid-search/?m=zitsdg4dp0wxd...@powdarrmonkey.net][Bits > > from the Release Team: a trixie customer]] due to adjacent slash and > question mark./ Thank you for documenting this one too. > It is a price for lightweight markup and it is how org-element parser works. Indeed! Please go ahead and give this bug a more useful title. Regards, Nicholas signature.asc Description: PGP signature
Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1
Jonathan Wiltshire writes: > Control: tag -1 confirmed > > On Mon, Jun 12, 2023 at 07:44:52PM -0400, Nicholas D Steeves wrote: >> Updated debdiff attached. > > Please go ahead (you should probably add a non-maintainer upload line, or > add yourself to uploaders, as well). Thanks for the ACK, and for the reminder! I had forgotten to run dch with "--team", so I fixed that, and uploaded. Kind regards, Nicholas
Bug#1042928: Please include example handler for mailto: URIs
Hi David, David Bremner writes: > Control: severity -1 wishlist Spoiler, it looks like this may need to be increased. > Nicholas D Steeves writes: > >> It would be wonderful if elpa-notmuch provided an example handler for >> mailto: URIs. Somewhere along the line I seem to have added a custom >> one; however, for some reason it opens message-mode rather than >> notmuch-message-mode. Consequently, messages are not correctly Fcced, >> and are lost rather than inserted into the correct folder. Needless >> to say, they're not indexed either. >> >> I'm not sure if I made a dumb mistake, or if this is nontrivial. >> >> I think the dh-examples mechanism should be used, because the user may >> be using emacsclient, or may be using Gnus or some other alternative >> to Message Mode. > > I'm not sure exactly what you want, but it doesn't sound debian > specific. I'd imagine that your desired example could be included in the > upstream info / html docs. I agree that this shouldn't be Debian-specific. Meanwhile, it seems like this wasn't a dumb mistake of mine. $ apt-file search notmuch | grep desktop notmuch: /usr/share/applications/notmuch-emacs-mua.desktop Given my bug report (the URI with the email body isn't opened in notmuch-message-mode), I'm not sure if the bug is in bin:notmuch, bin:elpa-notmuch, or Emacs. Steps to reproduce: 1. Set Notmuch as the default application for email (or URI handler) 2. Navigate to the BTS in a web browser like Firefox 3. Find a bug, and click on one of the reply links 4. Emacs opens in message-mode rather than notmuch-message-mode Cheers, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Alexandru, Thank you for this latest update. Notes follow inline. Please count the TODO items, resolve 4/4, and file an MR. Alexandru Mihail writes: > Hello again, Nicholas ! > > --- > debian/copyright: > > Files: htpasswd.c htpasswd.1 > Copyright: 1993-1994 Rob McCool > Copyright: 1997 Jef Poskanzer > License: BSD-2-clause > Comment: htpasswd* are mostly NCSA licensed. > RobMcCool's copyright was established by examining original NCSA httpd 1. Please indent everything in the Comment: field by a single white space at the beginning of the line. > source code mirrored here: > https://github.com/TooDumbForAName/ncsa-httpd/ > This git repository is a convenient copy of the NCSA HTTPd 1.5.2 source > code which was verified to be accurate and complete by comparing with a > WaybackMachine capture of the original NCSA ftp archive found here: > https://web.archive.org/web/20130120184619/http://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z Does that link really work? Are you sure it's not this one? https://web.archive.org/web/20160619204223/ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z I'm surprised the WayBack Machine dates that file June 19, 2016--very curious. > Portions of htpasswd* were edited by Jef Poskanzer, thus these files > remain under BSD-2-clause. The copyright info you've written in this version is immensely improved :) 2. Beyond this, you'll need to add a on every blank line that . so that the paragraphs in the "Comment" field of the "Files: htpasswd.c htpasswd.1" aren't split by an empty newline; they need to remain part of the same field. Nagivate to /usr/share/doc/*/copyright for many examples. > NCSA License: > This code is in the public domain. Specifically, we give to the public > domain all rights for future licensing of the source code, all resale > rights, and all publishing rights. . > We ask, but do not require, that the following message be included in > all derived works: . > Portions developed at the National Center for Supercomputing > Applications at the University of Illinois at Urbana-Champaign. . > THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED, > FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT > LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A > PARTICULAR PURPOSE. /\ It will look something like that (note the new indented periods) > debian-legal thread: > https://lists.debian.org/debian-legal/2023/07/msg1.html > > --- > Nicholas, I've finally found an "original" copy > of the httpd 1.5.2 src !! (Mentioned in the text above, it's the very > long WaybackMachine link). You have exceptional research skills. > After diff'ing the github copy and the > original .tar.Z (also, haven't seen that format in years), they seem to > match! Thus, I can confirm the github copy is accurate (previously, we > had no authoritative way to trust the github repo). Oh man, yeah, hello early days of the internet! All you need now is some MIDI files and GIFs. 3. Please note which version of NCSA httpd matches mini-httpd. >>I'm still not certain that this wiki contributor's position is >>legally >>sound everywhere in the world. For a counter example see: >> > https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe > > I've read the link and I share your concerns. I'm a bit lost > here..maybe another question to legal is the right choice ? While I'm not a lawyer, I believe that the approach we're going with is more legally defensible around the world than the aspirational public domain one. BSD-2-clause is also better understood than NCSA as far as I know. I'm relieved that work this didn't end up being a pulp novel situation where someone stumbles onto a dirty rotten secret at the heart of the origins of the internet while untangling the roots of a project like this one. As an aside, the last release that Robert McCool worked on was v1.3, and then he left in 1994 [1]. > Thanks for your time and may you have a great day, You're welcome, you too! Send me that merge request when you have time. Cheers, Nicholas [1] https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html signature.asc Description: PGP signature
Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager
Hi Paul, Paul Tagliamonte writes: > I /am/ one of the package maintainers :) > It's great to hear from you :) As one of the maintainers, will you have time and energy to review and merge Mateusz's work in the near future? Alternatively, would you be willing to add Mateusz as an Uploader and to let a mentor review and sponsor the proposed changes? I'm happy that you wrote back, because the best solution is collaboration! Mateusz, I'm supposing that you would be ok with this, because you've made a number of changes to fluxbox that are not appropriate for an NMU and that are the domain of a package's maintainers. Consequently, it makes it look like you'd like to help with the periodic maintenance of this package. Please let us know if this isn't what you want. Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1042928: Please include example handler for mailto: URIs
Package: elpa-notmuch Version: 0.37-1 Severity: normal It would be wonderful if elpa-notmuch provided an example handler for mailto: URIs. Somewhere along the line I seem to have added a custom one; however, for some reason it opens message-mode rather than notmuch-message-mode. Consequently, messages are not correctly Fcced, and are lost rather than inserted into the correct folder. Needless to say, they're not indexed either. I'm not sure if I made a dumb mistake, or if this is nontrivial. I think the dh-examples mechanism should be used, because the user may be using emacsclient, or may be using Gnus or some other alternative to Message Mode. If this sounds uninteresting, please ping me in a few weeks, and then periodically, because this a papercut that I'm motivated to look into when I have time. Thanks again for making high volume email tolerable! Nicholas
Bug#999962: silversearcher-ag: depends on obsolete pcre3 library
Dear Hajime Mizuno, or whoever might be thinking about salvaging this package, The best solution appears to be encouraging and supporting this friendly fork: https://github.com/ggreer/the_silver_searcher/issues/1515 The next best solution appears to be switching to a fork that fixed this pcre3 issue (and added the new PCRE2 support); however, it's also currently unmaintained. Please see the above link for what I believe is the locus of future community support for The Silver Searcher. Sincerely, Nicholas https://wiki.debian.org/PackageSalvaging signature.asc Description: PGP signature
Bug#1042671:
lu...@mailbox.org writes: > Hi Nicholas, > > thanks for your quick response and your proposal. I will give it a try in the > next days and report back as soon as possible. You're welcome. P.S. Slight correction in the last email: I meant to write that "Borg 1.2.4" was uploaded during the hard freeze, and not "Vorta 1.2.4". 'hope that was obvious! signature.asc Description: PGP signature
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Hello, Would you like to fix this RC bug and adopt the package? https://bugs.debian.org/1042911 and the orphan bug is here: #1016558 Best, Nicholas signature.asc Description: PGP signature
Bug#1042450: elpa-org: #+LANGUAGE: de-de is not working in LaTeX export
Control: tag -1 moreinfo Hello, H.-Dirk Schmitt writes: > Package: elpa-org > Version: 9.6.7+dfsg-1-c42-bpo-1 > Severity: normal > X-Debbugs-Cc: none, H.-Dirk Schmitt > > I use a backport from sid/trixie below bookworm. > In difference to the 9.5 version the setting `#+LANGUAGE: de-de` is not > working any more. > The option of the babel LaTeX package is in this case now empty. > > An easy mitigation is to use instead `de-de` the `de` language code. Have you eliminated issues pertaining to the new org-latex-language-alist? https://orgmode.org/Changes.html https://orgmode.org/manual/LaTeX-specific-export-settings.html https://orgmode.org/worg/org-irc.html > May somebody please check if this is a backport problem or reproducible in a > „clean“ trixie setup. $ rmadison elpa-org elpa-org | 9.1.14+dfsg-3 | oldoldstable | all elpa-org | 9.4.0+dfsg-1 | oldstable| all elpa-org | 9.5.2+dfsh-5 | stable | all elpa-org | 9.6.7+dfsg-1 | testing | all elpa-org | 9.6.7+dfsg-1 | unstable | all There are no other supported elpa-org versions in Debian. Please provide steps to reproduce (and/or an example file). Regards, Nicholas signature.asc Description: PGP signature
Bug#1042671: vorta: diff feature broken
Control: retitle -1 vorta: diff feature broken Control: tag -1 upstream fixed-upstream Control: fixed -1 vorta/0.8.12-1 Thanks for the bug report, and I agree this is an important (and expected) feature. This happened because Vorta 1.2.4 was uploaded during Bookworm's (Debian 12's) hard freeze, and I trust that the release team will accommodate the targeted fix you've proposed. You can find the package I intend to upload here: https://drive.google.com/drive/folders/1xKyYKhVEByeo0-Jdp8Fvbheh28xSYNUk?usp=sharing It's just a trivial cherry pick of the relevant commit, but metadata (documenting metadata takes much longer). Would you please confirm if this is enough to resolve the bug? Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, For brevity I've omitted the parts that look good. Alexandru Mihail writes: > RobMcCool's copyright was traced from a git repository which > imported NCSA httpd (which was verified to be precise). > Multiple commits by RobMcCool on HEAD > show his contributions on the files specified here. Thank you you have the right idea about writing how you established copyright. That said, what you've written is impossible, because Rob McCool's work was 1993-1994, but git's first release was in 2005 ;) Also, please revise the text to explain what "verified to be precise" means. Grammatically, it sounds like you verified that the tags in the repository match the WayBack Machine's copies of release tarballs. Did you verify that Jef Poskanzer didn't make edits? If Jef Poskanzer made edits, they would most likely be under the mini-httpd project license, thus the effective license would be BSD-2-clause. A simple solution would be claim these files are BSD-2-clause, but to note that htpasswd* contain (or are mostly) NCSA licensed, and then shift the NCSA licence text into the Comment section of Files: htpasswd.* If you run lintian without shifting the license text you'll learn why I recommend it. \cut this/ > The files are under the NCSA license which qualifies as DFSG > compatible after inquiry (specifically, from the license text: > > "This code is in the public domain. Specifically, we give to the > public > domain all rights for future licensing of the source code, all resale > rights, and all publishing rights" > > From DSFGLicenses's Q on DebianWiki: > > "Software placed in the public domain has all the freedoms > required by the DFSG, and is free software." /cut this\ I'm still not certain that this wiki contributor's position is legally sound everywhere in the world. For a counter example see: https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe > git repository: https://github.com/TooDumbForAName/ncsa-httpd/ Note: If you provide a link that isn't on Debian infrastructure then you'll also need to summarise what it contains (for various reasons that I can explain if you're interested). It may be worth noting that someone else can use this to verify if the htpasswd.* copy in mini-httpd corresponds to the NCSA copy. > debian-legal thread: > https://lists.debian.org/debian-legal/2023/07/msg1.html > DFSGLicenses: https://wiki.debian.org/DFSGLicenses / \ Nice, but cut the last line of /this\ Thanks again for reading this page, as well as for sharing the story of how it inspired you to contribute to Debian! :) > Is my TLDR still a bit TL ? I was trying not to leave out anything > related to discussion on debian-legal or how we traced everything back > to RobMcCool. Thank you for your attention to detail, and yes, still too long. There has been far more discussion at this bug than at debian-legal... > Did i get the right field ? > > "6.6. Comment > > Formatted text, no synopsis: this field can provide additional > information. For example, it might quote an e-mail from upstream > justifying why the license is acceptable to the main archive, or an > explanation of how this version of the package has been forked from a > version known to be DFSG-free, even though the current upstream version > is not. " > > Sounded like a good fit. You're right, yes, that's the one :) > Replying to previous untackled mail: >>Wow, that's wonderful (and unexpected) news! I hope negotiations go > well. > > Thanks, me too :) I'll have to complete the new maintainer process here > (and actually have an upload by my mentor (you!) before I can discuss > matters more firmly with higher-ups. There's no rush; your patience and > attention to detail are very appreciated btw :) Thanks :) >>My key is on both the Debian keyring and public servers >> >> https://wiki.debian.org/DebianKeyring >> https://keys.openpgp.org/ >> and maybe also here >> http://pgp.mit.edu/ > > OK, thanks, I'll have to find a good place for my key too, then. I confirmed your signature on this email. Here are some key-related resources: https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning/Coordination Best, Nicholas P.S. Please consider trimming the irrelevant quotation from correspondences on the BTS. It's a top-posting convention that takes up a lot of space and waste time (since we're an in-line posting community) https://bugs.debian.org/1036751 signature.asc Description: PGP signature
Bug#1041824: src:volume-el: disable d/watch and sync to latest head version
Manphiz writes: >>> I have been trying to fix uscan error of Emacs addon packages. When >>> working on volume-el, I found that the repo on salsa didn't accept merge >>> requests while most other packages did. If it can open up merge request >>> access it would be great and I have some pending d/watch fixes. Thanks >>> in advance! >> >> This may indicate that the Uploader wants patches rather than MRs, and >> at the very least may indicate the Uploader doesn't want to monitor >> Salsa for MRs. >> > > Thanks for the explanation, Nicolas! Totally make sense. You're welcome! > Done. A little bit of explanation for the changes: > > * Upstream never had any tags, so uscan will always fail, so disable > d/watch for now. This will result in an empty uscan results. Why is breaking notification of any future upstream tags better than using uscan's git mode? Uscan's git mode will notify when upstream pushes any commit, with or without a tag. Help is available in #debian-mentors if writing an output format line that is suitable for volume-el's existing version scheme is too challenging. Regards, Nicholas
Bug#1041824: src:volume-el: Enable merge request on salsa
Xiyue Deng writes: > Source: volume-el > Severity: wishlist > X-Debbugs-Cc: none, Xiyue Deng > > Dear maintainers, > > I have been trying to fix uscan error of Emacs addon packages. When > working on volume-el, I found that the repo on salsa didn't accept merge > requests while most other packages did. If it can open up merge request > access it would be great and I have some pending d/watch fixes. Thanks > in advance! This may indicate that the Uploader wants patches rather than MRs, and at the very least may indicate the Uploader doesn't want to monitor Salsa for MRs. You can use git-format-patch to prepare a patch series from your git history, and can attach those to a bug report here. To retitle this bug, but this as the first line in your reply (won't work with HTML email, of course): Control: retitle -1 src:volume-el: Useful subject of choice Control: tag -1 patch If you attach a patch, I recommend updating the metadata with that second line. Cheers, Nicholas signature.asc Description: PGP signature
