Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
Hello Go and Rust packagers, On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote: > With the increasing amount of programs in Debian that Build-Depend and > statically link with Golang and Rust libraries, it's important that > the Debian Policy clearly sets out the requirements for declaring > these statically-linked libraries. I think Maytham is right that updating Policy for this is a priority. It has been bothering me that misunderstandings of Built-Using have been proliferating somewhat among newer contributors. See also #999785. Could you take a look at his proposed changes to Policy in #1069256, please, and confirm they successfully reconcile Debian Policy with your team policies? I think that we should also include an explanation of why we have chosen to do this using a new field in d/control like Static-Built-Using. Policy is meant to be a record of our lessons learned in building a distribution, and the lessons learned in trying to handle these new hyper-statically linked language ecosystems seem important. My immediate question is why the Haskell and OCaml team's approaches, were not copied. They seem to work well and don't require a new field. That seems worth writing down. Thank you Maytham for your work so far. -- Sean Whitton signature.asc Description: PGP signature
Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs
Hello, On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote: > Sean Whitton writes: > >> control: tag -1 + moreinfo >> >> Hello Xiyue, >> >> Please explain the autopkgtest_keep change. Remember that autopkgtests >> are to test the installed package. If you need to keep the .el files, >> it must be for some reason other than because the test suite actually >> just tests those. >> > > I think this is another example of buttercup tests that requires source > .el files to run. I'll probably open a bug on buttercup to see whether > this is required for buttercup. Meanwhile I think it'd probably be > better to just disable autopkgtest as the tests are already run as part > of the build process. I agree. It is important not to use autopkgtest_keep without being sure it's the right answer. >> You've removed the Built-Using with the justification that it's an >> arch:all package, but that doesn't make sense; Built-Using is for >> licensing reasons, and may well be applicable to an arch:all package (I >> think this came up before with one of your uploads?). > > Ah I was following the suggestions of Lintian which said it cannot be > used by arch:all packages which is probably wrong. See #999785. > On the other hand, on a closer look at the policy regarding > Built-Using on section 7.8[1], it has the following passage: > > , > | This field should be used only when there are license or DFSG > | requirements to retain the referenced source packages. It should not be > | added solely as a way to locate packages that need to be rebuilt against > | newer versions of their build dependencies. > ` > > I checked that lua-mode is of GPL-2+[2], and of all its dependencies > lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL > 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using > requirement. The change was introduced in [3] but it was part of the > modernization effort so there is no direct justification of adding the > field. May be I'm missing something here? It sounds like it shouldn't have been introduced. So you can remove it based on your reading of Policy, and briefly note your reasoning in d/changelog. -- Sean Whitton signature.asc Description: PGP signature
Bug#1069078: Acknowledgement (RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs)
control: tag -1 + moreinfo Hello Xiyue, Please explain the autopkgtest_keep change. Remember that autopkgtests are to test the installed package. If you need to keep the .el files, it must be for some reason other than because the test suite actually just tests those. You've removed the Built-Using with the justification that it's an arch:all package, but that doesn't make sense; Built-Using is for licensing reasons, and may well be applicable to an arch:all package (I think this came up before with one of your uploads?). -- Sean Whitton signature.asc Description: PGP signature
Bug#1069001: dgit: tag2upload: [dgit ...] should include source= and version= fields
Source: dgit Version: 11.8 Severity: important Dear maintainer, As discussed elsewhere, we want source= and version= tags in the tag2upload metadata to prevent the possibility of a certain form of attack by someone who is able to replace git objects on salsa. -- Sean Whitton signature.asc Description: PGP signature
Bug#877337: single-page html of debian-policy to be revived?
Hello, On Sun 14 Apr 2024 at 01:57pm +02, Holger Wansing wrote: > 1. > Currently, the package does not ship this version. So this would have to > be re-added there. The changelog for 4.2.0.0 says * Stop installing policy-1.html because Sphinx's singlehtml output is too buggy at present (Closes: #873456, #876075, #879048). See also #877367. Thanks to Paul Wise for switching the web mirrors away from policy-1.html. I had forgotten about this. It seems that the first thing to do would be to determine if the issues discussed in those bugs still exist. > 2. > There are pro's and con's for both the single-page and multi-page variants. > Thus the only possible way IMO is to ship both via www.d.o. > The developers-refererence also ships both already, so it would be consistent > there. ... but if dev-ref is already shipping both, maybe singlepage is indeed usable these days ... > Could the Policy Editors team check, if everything is fine now, and if > this should be published again? > At least there is still an issue with the footnotes, there are 16 occurrences > of #id1 for example... (search for "[1]" in policy-1.html). Hrm. That seems like a pretty serious problem :\ Holger L., did you know about this issue? Did you decide it was worth publishing anyway? -- Sean Whitton signature.asc Description: PGP signature
Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors
Hello, On Thu 11 Apr 2024 at 08:32am GMT, Holger Levsen wrote: > On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote: >> A single page html may be an additional option but there's already the >> single page txt version and the PDF. That's sufficient and I see no >> need in providing more formats of this manual. >> >> Therefore we can close this and I will close 877337. > > fwiw, I disagree with this conclusion. single page txt and pdf versions > are no replacements for single page html. I agree, and still think we should be publishing the single page version. -- Sean Whitton signature.asc Description: PGP signature
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Ping again. Thanks. On Thu 28 Mar 2024 at 01:33pm +08, Sean Whitton wrote: > Hello, > > On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote: > >> The vote has concluded. The result is that the Technical Committee >> recommends that Craig Small be appointed by the Debian Project >> Leader to the Technical Committee. >> >> Jonathan, over to you. > > Quick ping about this. The appointment holds up some administrative > stuff for us. Thanks. -- Sean Whitton
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
Hello, On Fri 12 Apr 2024 at 12:44pm +01, Jeremy Sowden wrote: > On 2024-04-12, at 17:53:15 +0800, Sean Whitton wrote: >> Do you have your 1.34 upload of buttercup in git, please? > > Yup, it's all on Salsa. Er. I got confused, then, didn't I? Should this RFS be closed? -- Sean Whitton signature.asc Description: PGP signature
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
Hello Jeremy, Do you have your 1.34 upload of buttercup in git, please? Xiyue, you need to merge in the 1.34 upload, either something from Jeremy, or we can fall back to merging from dgit/sid. This has happened a few times now -- please check whether you're missing uploads before starting to work on top of the branch on salsa :) -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Mon 08 Apr 2024 at 07:15pm +02, Salvatore Bonaccorso wrote: > Hi Sebastian, > > On Mon, Apr 08, 2024 at 06:43:01PM +0200, Sebastian Andrzej Siewior wrote: >> control: tags -1 patch >> control: reassign -1 yapet 2.6-1 >> >> On 2024-04-08 08:32:58 [+0200], Kurt Roeckx wrote: >> > There might be a related change that doesn't allow restarting the >> > operation with the same context without setting things up again. >> >> Yapet is broken and the openssl update revealed the problem. I >> reassigned it to yapet 2.6 but probably affects earlier versions. >> But then the 1.1.1 series is no longer maintained so… >> >> Patches attached and they hold the details of why and such. >> >> This needs to be applied to unstable and Bookworm. >> The testsuite passes and I can open Sean's test file. >> Further testing is welcome by actual users ;) > > Thanks for the investigation and bringing the fixes to upstream > already: https://github.com/RafaelOstertag/yapet/pull/29 >> >> I can NMU if needed just yell. > > No need for that, will take it with my maintainers hat on from here. Many thanks both. -- Sean Whitton
Bug#963524: fixed in debian-policy 4.7.0.0
Hello, On Sun 07 Apr 2024 at 08:44am +02, Petter Reinholdtsen wrote: > For the record, and as stated in https://bugs.debian.org/999598 >, > I would rather have the description lines back in the changes file to > provide the information in the emails presenting uploads, instead of > dropping them. I guess this bug report will be closed unsolved instead. In this case we weren't really making a decision on the Policy side, but just updating documentation. So it can be changed back if the decision is reversed. -- Sean Whitton
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Hello, On Sun 07 Apr 2024 at 08:54am +02, Paul Gevers wrote: > Hi, > > On Sat, 09 Sep 2023 18:51:52 -0700 Russ Allbery wrote: > > """ > +``systemd`` uses dependency and ordering information contained within the > ++enabled unit files to decide which services to run and in which order. > """ > ^ is that "+" before "enabled" really intended? It looks weird to me. Fixed in git, thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 06 Apr 2024 at 03:24pm +02, Salvatore Bonaccorso wrote: > As it is a regression caused by libssl3 3.0.11 based to 3.0.13, why is > it reassigned to yapet? (the regression is as well present in > unstable). I was just thinking that it may be a flaw in how YAPET calls into openssl, and we don't have evidence either way atm. > That said: You are right, opening 1.0 format databases should still > work that said, but is regressing with the openssl update. And as per > manpage: YAPET 2.0 will read and write pre YAPET 2.0 files. Pre YAPET > 2.0 files are converted to YAPET 2.0 files when changing the master > password. Once converted, the files can no longer be read by pre YAPET > 2.0 versions. > > I can ask upstream, but currently yapet will FTBFS with problems in > the testsuite anyway, and the problems are related. > > And yapet FTBFS with the new openssl in bookworm-pu in same way as in > unstable (but not with the old version). > > Thus I believe #1068045 and #1064724 are actually related. Thanks for the info. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 06 Apr 2024 at 09:30pm +02, Sebastian Andrzej Siewior wrote: > On 2024-04-06 17:17:45 [+0800], Sean Whitton wrote: >> Hello, > Hi, > >> It looks like the problem is opening YAPET1.0-format databases, which >> the manpage explicitly says is meant to work. >> >> I've made a sample YAPET1.0 database using a stretch VM. Using the >> attached: >> >> - On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it. >> - On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't. > > Thank you for the testcase. It asks for a password, what is it? Sorry! It's 'asdf'. -- Sean Whitton
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote: > On 30 March 2024 13:14:37 CET, Sean Whitton wrote: > >>I downgraded, changed the password for my database to 'asdf', >>changed it back to the password it had before, upgraded libssl3, >>and the bug did not appear. >> >>I reverted to my original db, downgraded again, deleted an entry without >>changing the password, upgraded, and the bug appeared. >> >>I can't really say more without compromising my opsec. But does the >>above give any clues / further debugging ideas? > > I would look at the function yapet is using from openssl and compare the > results. > Could create a database from scratch an use similar patterns in terms number > of entries and password (length, special characters) until you have something > that you can share with me. I don't mind if throw it in my inbox without Cc: > the bug. It looks like the problem is opening YAPET1.0-format databases, which the manpage explicitly says is meant to work. I've made a sample YAPET1.0 database using a stretch VM. Using the attached: - On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it. - On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't. Thanks again. -- Sean Whitton yapet1.0.pet Description: Binary data signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
control: reassign -1 libssl3,yapet control: found -1 libssl3/3.1.5-1 control: found -1 yapet/2.6-1 control: retitle -1 libssl3,yapet: YAPET cannot decrypt YAPET1.0-format DB Hello, On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote: >> >>> Also, yapet is unchanged in unstable. Is the problem there, too? >> I have now confirmed that the problem is in unstable too. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
control: tag -1 + pending Hello, On Sat 06 Apr 2024 at 01:23am -04, Daniel Kahn Gillmor wrote: > On Sat 2024-04-06 11:40:14 +0800, Sean Whitton wrote: >> On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote: >> >>> On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote: >>>> Thanks, but can you sign this off? Ty! >>> >>> Sure, attached. Let me know if you need anything different. >> >> Thanks. Unfortunately, it doesn't seem to fix the FTBFS, on sid. > > Here is a replacement patch, tested now against mypy 1.9.0-4. It also > updates the typechecking for imap-dl for the same version of mypy. Thanks! Just to note that I also had to add python3-gssapi as a b-d. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Hello, On Sat 06 Apr 2024 at 12:15pm +08, Sean Whitton wrote: > Hi Russ, > > We have two seconded solutions, so you and I should perhaps break the > tie. I prefer the Bill's 'Autobuild: no' solution as the more > conservative change: we only have data about packages that are currently > autobuilt, not those that aren't, so we might be making those buggy if > we just ban network access for all non-free packages. How about you? (It's not actually a tie in terms of number of seconds, but we don't do this quantatively.) -- Sean Whitton signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Hi Russ, We have two seconded solutions, so you and I should perhaps break the tie. I prefer the Bill's 'Autobuild: no' solution as the more conservative change: we only have data about packages that are currently autobuilt, not those that aren't, so we might be making those buggy if we just ban network access for all non-free packages. How about you? -- Sean Whitton signature.asc Description: PGP signature
Bug#1068022: Document the Testsuite-Triggers field
Hello, On Fri 05 Apr 2024 at 11:30am +02, Christian Kastner wrote: > Hi again, > > On 2024-03-29 20:30, Christian Kastner wrote: >> Policy 5.6.30 lists the Testsuite field, but it doesn't list the >> Testsuite-Triggers field that seems to be part of Sources files and is >> generated by dpkg-source >= 1.18.8. >> >> This field is quite useful, as given my package src:foo, I can find out >> which packages have autopkgtests that depend on it, and are thus in the >> set of reverse dependencies that I could check for breakage. > > I've read up on the change process [1], and I guess my proposal to > submit a patch was too far into the process. > > Thus, I take a step back, and seek discussion first. > > In addition to what I've said above, I think documenting this field > would not only enhance discoverability, but give more weight to it for > tooling that makes use of these fields. > > For discussion context, I'd like to quote dsc(5) on this field: >> Testsuite-Triggers: package-list >> >> This field declares the comma-separated union of all test dependencies >> (Depends fields in debian/tests/control file), with all restrictions >> removed, and OR dependencies flattened (that is, converted to separate AND >> relationships), except for binaries generated by this source package and its >> meta-dependency equivalent @. >> >> Rationale: this field is needed because otherwise to be able to get the test >> dependencies, each source package would need to be unpacked. Sounds good to me. If you'd like to propose wording, there's some more guidance in our README.md. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#1064593: issue with Debian-style html theme for sphinx-based documents
Hello, On Fri 05 Apr 2024 at 02:07pm +02, Holger Wansing wrote: > Hi, > > Holger Wansing wrote (Tue, 2 Apr 2024 14:47:12 +0200): >> We need a separate copy of 3 packages in our www build tree on >> wolkenstein and all www static mirrors (simply let DSA install those >> packages on the machines will not work). >> And every sphinx-based manual needs relative symlinks in its tree, pointing >> to the above packages' content. >> The 1ftpfiles and 7doc scripts, which need to be adapted for that, and >> also the situation on the www mirrors is getting more complex, so I'm unsure >> if we want this. >> See my patch. >> >> On the other side, I don't see any other solution apart from developing >> a new theme. > > Since there were no objections, I pushed that yesterday (+ one additional > change was needed), and that works now. Thank you very much again. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
Hello, On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote: > On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote: >> Thanks, but can you sign this off? Ty! > > Sure, attached. Let me know if you need anything different. Thanks. Unfortunately, it doesn't seem to fix the FTBFS, on sid. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
Thanks, but can you sign this off? Ty! -- Sean Whitton
Bug#1064593: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello, On Mon 01 Apr 2024 at 02:50pm +02, Holger Wansing wrote: > I now tend to switch to another approach (also proposed similarly by Adam): > > instead of relying on the rtd-theme package in the default install path of the > package installed by DSA, I will use the infrastructure in 1ftpfiles and > 7doc of webmaster's cron repo, to (always) fetch the latest version of that > package (and two more packages, which the former depends on: > fonts-font-awesome > and fonts-lato, to get the needed fonts) and unpack+copy them into > a dedicated path inside the www build tree. > > That path will be synced to the static www mirrors, and we can symlink > to it from the manuals. > (And the content of that path will automatically be kept up-to-date on > the unstable version of packages, so we don't get outdated/orphaned > copies of that packages in the isolated path.) > I want the unstable version of that packages here, since they need to > incorporate with the unstable version of the different manuals (like > debian-policy), and those packages are built by buildd, so unstable. > > How does that sound in the light of Debian guidelines and best practice? > > Is it ok, to have such "isolated copies" of packages as described above? > > I have not much experience in similar things, so I would like to get > some comments here, please. I mean, it seems okay to me, but it's up to the web team really. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hello, On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > Package: debian-policy > Version: 4.6.2.1 > Severity: normal > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org > Control: affects -1 buildd.debian.org > > Hi, > > The debian policy, section 4.9, forbids network access for packages in > the main archive, which implicitly means they are authorized for > packages in contrib and non-free (and non-free-firmware once #1029211 is > fixed). > > This gives constraints on the build daemons infrastructure and also > brings some security concerns. Would it be possible to extend this > restriction to all archives? We need to know if this is going to break existing packages and allow some input from their maintainers. Are you able to prepare a list of the affected packages? -- Sean Whitton
Bug#1068094: RFH: sbcl -- Common Lisp compiler and development system
Package: wnpp Severity: normal X-Debbugs-Cc: s...@packages.debian.org, debian-de...@lists.debian.org, debian-emac...@lists.debian.org Control: affects -1 + src:sbcl I request assistance with maintaining SBCL in Debian. It is the most popular Free Software compiler for Common Lisp. So, most anyone who is interested in both Debian and Common Lisp is likely interested in SBCL, too. The upstream project is stable but seems relatively often to introduce changes that break our packaging scripts. Possibly there should be an attempt made to simplify how we do things. This would be good for a new contributor to Debian who is otherwise experienced with bootstrapping compilers / development environments. You definitely don't need to be a Debian Developer to help. The package description is: SBCL is a development environment for the ANSI Common Lisp language. It provides a native-code compiler and an integrated debugger, as well as all the features in the ANSI specification. . SBCL also contains other extensions to the ANSI specification, including a foreign-function interface, a pseudo-server API, user-extensible stream functionality, a Meta-Object Protocol, and an ability to run external processes. . To browse SBCL source definitions with development environments, install the sbcl-source package. For documentation on SBCL's usage and internals, the package sbcl-doc is provided. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 30 Mar 2024 at 09:29am +01, Sebastian Andrzej Siewior wrote: > On 2024-03-30 09:25:27 [+0800], Sean Whitton wrote: >> Package: libssl3 >> Version: 3.0.13-1~deb12u1 >> Severity: grave >> Justification: renders package unusable >> X-Debbugs-Cc: t...@security.debian.org >> Control: affects -1 + yapet >> >> Dear maintainer, >> >> This version of libssl3 from bookworm-proposed-updates breaks YAPET. >> When I try to open my passwords database, it claims the master password I >> type >> is incorrect. But downgrading libssl3 fixes the problem. > > Can you give me more to go on? I installed yapet created a database, > updated and it remains to work. > Maybe supply a test database which works with the old but not with the > new library. I downgraded, changed the password for my database to 'asdf', changed it back to the password it had before, upgraded libssl3, and the bug did not appear. I reverted to my original db, downgraded again, deleted an entry without changing the password, upgraded, and the bug appeared. I can't really say more without compromising my opsec. But does the above give any clues / further debugging ideas? > Also, yapet is unchanged in unstable. Is the problem there, too? Unfortunately I do not have an unstable machine to hand right now, and until we know more about the xz-utils situation I would want to set up something air-gapped before copying my password db in there -- but can do that if we can't otherwise make progress. Thanks for looking! -- Sean Whitton signature.asc Description: PGP signature
Bug#1068022: Document the Testsuite-Triggers field
Hello, On Fri 29 Mar 2024 at 08:30pm +01, Christian Kastner wrote: > Package: debian-policy > Version: 4.6.2.0 > Severity: wishlist > > Policy 5.6.30 lists the Testsuite field, but it doesn't list the > Testsuite-Triggers field that seems to be part of Sources files and is > generated by dpkg-source >= 1.18.8. > > This field is quite useful, as given my package src:foo, I can find out > which packages have autopkgtests that depend on it, and are thus in the > set of reverse dependencies that I could check for breakage. > > I'd provide a patch based on the documentation in dsc(5), but I don't > know what the current process is. Does anyone have a link to a doc on > how to submit a change? There is a chapter of Policy regarding the Policy Changes Process. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: libssl3: breaks YAPET
Package: libssl3 Version: 3.0.13-1~deb12u1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: t...@security.debian.org Control: affects -1 + yapet Dear maintainer, This version of libssl3 from bookworm-proposed-updates breaks YAPET. When I try to open my passwords database, it claims the master password I type is incorrect. But downgrading libssl3 fixes the problem. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libssl3 depends on: ii libc6 2.36-9+deb12u5 libssl3 recommends no packages. libssl3 suggests no packages. -- no debconf information -- Sean Whitton signature.asc Description: PGP signature
Bug#1067895: RFS: emacs-format-all-the-code/0.6.0-1 [Team] -- Auto-format C, C++, JS, Python, Ruby and 50 other languages
control: tag -1 + moreinfo Looks like the Source: in d/copyright is bogus? -- Sean Whitton
Bug#1067924: dgit: can't clone/fetch dockerfile-mode past few days
Package: dgit Version: 11.6 Severity: important spwhitton@chiark:~/tmp>dgit clone dockerfile-mode canonical suite name for unstable is sid fetching existing git history fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. dgit: failed command: git ls-remote -q --refs https://git.dgit.debian.org/dockerfile-mode 'refs/tags/archive/debian/*' 'refs/tags/debian/*' refs/dgit/sid refs/dgit-rewrite/map dgit: error: subprocess failed with error exit status 128 255 spwhitton@chiark:~/tmp> I was able to successfully dgit push the package, after doing an import-dsc for the purposes I wanted to fetch. -- Sean Whitton
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Hello, On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote: > Sean Whitton writes: > >> Hello, >> >> Rob, can you review the implementation in d/rules for Xiyue's patch to >> this bug, please? I'm not sure it's the straightforward way to do it. >> >> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), >> for the relationships. > > Ah indeed, I should update the versions after the Emacs 29.3 upload, > though I think you meant "1:29.3+1-2". Also, as we are just moving > files from emacs-common to emacs-pgtk, breaks/replaces is only needed > from emacs-pgtk to emacs-common but no the other way around, so I > dropped the breaks on emacs-pgtk from emacs-common. > > I have updated the patch accordingly and attached here. PTAL. Thanks. > (BTW, I'm always curious about the "+1" part of the version number. I > would expect something like "+dfsg" or "+ds" as we are dropping some > of the non-DFSG conformant files, but why "+1"? :) It's just in case the DFSG split is done incorrectly and another attempt is required -- given how complex it is. -- Sean Whitton
Bug#1067581: RFS: package-lint-el/0.22-1 [Team] -- package-lint Flymake backend
control: tag -1 + moreinfo Hello, Looks like you didn't push to master :) -- Sean Whitton signature.asc Description: PGP signature
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Hello, On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote: > The vote has concluded. The result is that the Technical Committee > recommends that Craig Small be appointed by the Debian Project > Leader to the Technical Committee. > > Jonathan, over to you. Quick ping about this. The appointment holds up some administrative stuff for us. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Hello, Rob, can you review the implementation in d/rules for Xiyue's patch to this bug, please? I'm not sure it's the straightforward way to do it. Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), for the relationships. Thanks both. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
types in assignment > (expression has type "Message | str | list[Message | str] | Any", variable > has type "list[Message] | str | bytes | None") [assignment] > email-print-mime-structure:109: error: Incompatible types in assignment > (expression has type "Message | bytes | Any", variable has type > "list[Message] | str | bytes | None") [assignment] > email-print-mime-structure:121: error: Incompatible types in assignment > (expression has type "Message | bytes | Any", variable has type > "list[Message] | str | bytes | None") [assignment] > email-print-mime-structure:181: error: Incompatible types in assignment > (expression has type "Message | str | list[Message | str] | Any", variable > has type "list[Message] | str | bytes | None") [assignment] > Found 6 errors in 1 file (checked 1 source file) > make[1]: *** [Makefile:15: check] Error 1 > make[1]: Leaving directory '/<>' > dh_auto_test: error: make -j2 check returned exit code 2 > make: *** [debian/rules:4: build] Error 25 > dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 > > > The above is just how the build ends and not necessarily the most relevant > part. > If required, the full build log is available here: > > https://people.debian.org/~sanvila/build-logs/202403/ > > About the archive rebuild: The build was made on virtual machines > of type m6a.large from AWS, using sbuild and a reduced chroot > with only build-essential packages. > > If you could not reproduce the bug please contact me privately, as I > am willing to provide ssh access to a virtual machine where the bug is > fully reproducible. > > If this is really a bug in one of the build-depends, please use > reassign and affects, so that this is still visible in the BTS web > page for this package. > > Thanks. > -- Sean Whitton
Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files
Hello, On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote: > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index 4307e89..2fb05cd 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -685,7 +685,7 @@ variables are also available. > > The ``debian/substvars`` file is usually generated and modified > dynamically by ``debian/rules`` targets, in which case it must be > -removed by the ``clean`` target. > +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``). > > See :manpage:`deb-substvars(5)` for full details about source variable > substitutions, including the format of ``debian/substvars``. > @@ -725,8 +725,9 @@ building packages to record which files are being > generated. > > It should not exist in a shipped source package, and so it (and any > backup files or temporary files such as ``files.new``) [#]_ should be > -removed by the ``clean`` target. It may also be wise to ensure a fresh > -start by emptying or removing it at the start of the ``binary`` target. > +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``). > +It may also be wise to ensure a fresh start by emptying or removing it at the > +start of the ``binary`` target. > > When ``dpkg-gencontrol`` is run for a binary package, it adds an entry > to ``debian/files`` for the ``.deb`` file that will be created when Instead of "It may also be wise ..." can you use one of the sets of magic words from Policy 1.1, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello,
On Fri 22 Mar 2024 at 06:46pm +03, Dmitry Shachnev wrote:
> Actually, I would move ${sphinxdoc:Depends} from Recommends to
> Depends, because the documentation is mostly unusable without the
> static files.
I think it's in Recommends because we ship other formats that don't need
it, and to ensure installability on stable, or something similar.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello, On Sat 23 Mar 2024 at 05:08pm +01, Holger Wansing wrote: > While working on adapting the parts/7doc script (from Debian Webmaster > Team's 'cron' repo), I realized that this is not going to work out of the > box: while the concept of the symlinks mentioned above is working fine, > when the debian-policy document is installed on a machine as usual > (means it recides in the same path as in the binary deb package, aka > /usr/share/doc/debian-policy/policy.html), we have the docs for the website > on the debian.org website machine in another path. That is in > /srv/www.debian.org/www/doc/debian-policy/. > > That means the (relative) symlinks will not resolve! > Therefore I think the best solution here is, to change the relative > symlinks into absolute ones, on the debian.org website machine. > > I have worked out the needed changes for cron/parts/7doc to deal with all > this (it works fine here locally). The debian-policy package could stay > unchanged. > I attach the patch here just for reference; will apply it, as soon as > sphinx-rtd-theme-common gets installed on wolkenstein > (working on a bugreport to DSA to get this done). > > Closing #1066967 against sphinx-common/dh_sphinxdoc now. > Thanks python people for your help! Many thanks all for working on this, especially you Holger for this scripting work. So, we're waiting in DSA and then on your script changes, and it'll work again. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Hello, On Tue 26 Mar 2024 at 10:11am -06, Sam Hartman wrote: >>>>>> "Josh" == Josh Triplett writes: > > > > I tend to agree with Sean that your rationale is not convincing. > It sounds like you want to use policy as a stick to hit people > over the head and say "policy is not a stick." This was basically my concern. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067630: fixed in emacs 1:29.3+1-1
Hello, On Mon 25 Mar 2024 at 04:58pm +07, Max Nikulin wrote: > On 25/03/2024 15:47, Sean Whitton wrote: >> On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote: >> >>> On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote: >>>> Source: emacs >>>> Source-Version: 1:29.3+1-1 >>>> Done: Rob Browning >>> >>> Should this issue be reopened or be cloned to backport fixes to Emacs-28 in >>> Debian stable? >> Neither are necessary. > > Do you mean that somebody is working on backporting changes to 28.2 in > bookworm already? This bug is closed. Have I missed other ones for elpa-org in > unstable and for emacs in stable? No, I just mean that the bug metadata is correct. Closed does not mean resolved in all suites. -- Sean Whitton
Bug#1067630: fixed in emacs 1:29.3+1-1
Hello, On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote: > On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote: >> Source: emacs >> Source-Version: 1:29.3+1-1 >> Done: Rob Browning > > Should this issue be reopened or be cloned to backport fixes to Emacs-28 in > Debian stable? Neither are necessary. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067155: debian-policy: prerm scripts cannot actually rely on dependencies
Hello, On Tue 19 Mar 2024 at 01:02pm +01, Julian Andres Klode wrote: > Package: debian-policy > Severity: wishlist > X-Debbugs-Cc: de...@lists.debian.org, debian-d...@lists.debian.org > > APT's installation planner does not consider dependencies of packages > being scheduled for removal, so a prerm must fail equally gracefully > as a postrm does in absence of its dependencies. > > This does break dpkg's assumptions which it happily tells you about, > but this is the reality we live in. > > So e.g. one thing you see is that apt removes libapt-pkg6.0, then > unpacks libapt-pkg6.0t64, then removes libapt-pkg6.0 reverse > dependencies. > > Clearly APT should be considering dependencies when removing packages > but even in that case, removals may sometimes need to be forced in the > wrong order because any order leads to broken dependencies, so still, > prerms should not rely on dependencies, but only on essential packages. I'm not sure that Policy is the place to discuss a change proposal like this, and we can't render a swathe of packages RC buggy by making such a change here. The archive would need to change first. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Hello, On Mon 18 Mar 2024 at 04:06am -07, Josh Triplett wrote: > On Mon, Mar 18, 2024 at 05:38:15PM +0800, Sean Whitton wrote: >> Was there some recent packaging situation that prompted you to think >> about this? I'm cautious about adding it in the absence of that. > > Mostly, recent discussions in various places regarding whether packages > are required to use *cron* to run periodic jobs. Policy says what > packages must do if they install a cronjob, but that itself does not > mandate the use of cron specifically. It seemed worth explicitly stating > the understood-but-unwritten interpretation that having Policy about XYZ > does not mandate that packages use XYZ. > > I've also seen a few arguments over the decades that amount to "Policy > talks about A, and doesn't talk about B" being used as some amount of > weight towards A or against B. > > And finally, I have occasionally seen someone try to build a Debian > package by sitting down with the Policy manual, and start down the route > of trying to supply everything Policy talks about that seems like it > makes sense for the package. The mention of "Policy talking about where > to install info documentation, but that doesn't mean you have to have > info documentation" was not a hypothetical; I've seen that and similar > reasoning a non-zero number of times. > > I figured that something like this text would help address all of those. Thanks. For the time being, I myself am not convinced. Policy is not a stick to beat maintainers with, as we say, but I'm not sure that idea is one that ought to be in Policy itself. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067420: RM: emacsql-sqlite3 -- ROM; obsolete
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: emacsql-sqli...@packages.debian.org Control: affects -1 + src:emacsql-sqlite3 Quoting Aymeric Agon-Rambosson <https://bugs.debian.org/1052967#15>: > [...] I think we should not be packaging emacsql-sqlite3 anymore, and we > should use the occasion to remove it. > > The upstream maintainers themselves contend that package developers should not > use it, and rely on emacsql instead : > https://github.com/cireu/emacsql-sqlite3#important-note. > > It has no reverse dependencies [...] > > The next release of emacsql will not support it, and will make it obsolete, > a point of view the upstream maintainers of emacsql-sqlite3 themselves seem > to accept : https://github.com/cireu/emacsql-sqlite3/issues/38. > > It was removed from MELPA last April for this reason. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
Hello, On Wed 22 Feb 2023 at 05:21pm -07, Sean Whitton wrote: > > Right, but the pile of Emacs addons I maintain using dgit-maint-merge(7) > will never hit any of those behaviours. So it's a high cost to impose > on someone in a position such as mine. > I still regret that this change went into bookworm, and would like to simplify things again. I still think that this is a case where the cost of correctness-in-all-cases is too high. I think we can revert the behavioural change and come up with an appropriate warning in the workflow manpage. It might be relevant to recommend users consider using source format 1.0, even. -- Sean Whitton signature.asc Description: PGP signature
Bug#1050713: mixed team workflows incl. --overwrite, split brain
Hello, On Wed 20 Mar 2024 at 06:12pm GMT, Ian Jackson wrote: > Control: severity -1 important > > Having thought about it, I propose the following changes to try to > help with this: > > 1. Provide an alias for --overwrite (without version) called >something like --trust-changelog, and make that be the primary name. >That's really what --overwrite (without version) does. Nice. > 2. Provide a new option --collab-sceptics [1] which implies >--split-view=always --trust-changelog. > > [1] I'm very unusre of the right name. This option should be used in > two situations: > > (a) The package is team maintained, and you are doing a team upload; > your teammates don't use dgit (and object to the .dsc import > commits that can happen in the dgit history (so the maintainer > history doesn't have the .dsc imports). So you must hide the > .dsc imports (which are in the dgit view) and trust the > changelog. > > (b) You are doing an NMU, and you're doing it from maintainer git, > but the maintainer doesn't use dgit. Nevertheless the maintainer > wants your git commits. So you want to provide a git branch that > doesn't have the .dsc import commits (and you must truxt the > changelog). How about --with-non-dgit ? -- Sean Whitton signature.asc Description: PGP signature
Bug#1050713: mixed team workflows incl. --overwrite, split brain
Hello, On Thu 21 Mar 2024 at 10:16am +08, Sean Whitton wrote: > > How about --with-non-dgit ? Or, combining suggestions, --collab-non-dgit . -- Sean Whitton signature.asc Description: PGP signature
Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest
control: tag -1 + pending control: close 1067133 Hello, On Wed 20 Mar 2024 at 12:06am -07, Xiyue Deng wrote: > Found the upstream fix for the test failures[1]. I have backported the > patch in [2] In the future, especially with dgit-maint-merge(7), it's a good idea to use 'git cherry-pick -x' to backport upstream patches like this, so that it's easily traceable by others. In lieu of this, I've added a note of the upstream commit in d/changelog. > Meanwhile, it looks like I was jumping to conclusion a little too > soon. TL;DR it will still get stuck without running in the source > directory. So IMHO disabling autopkgtest would be a sensible choice, > which I did in [3]. > > Also built and uploaded the latest version to mentors[4]. PTAL. TIA! > > Longer analysis of tests getting stuck: > > Comparing working and not working settings using strace, I noticed that > during buttercup tests it would get stuck closing > test/clojure-mode-refactor-rename-ns-alias-test.el, which I still didn't > know why unfortunately. If I disabled/renamed this file, buttercup > would finish running, and would fail due to unable to load clojure-mode > in the source tree. And yes, specifically the file in the source tree > as in the following error message: > > , > | Cannot open load file: No such file or directory, > | /home/manphiz/Projects/debian-packaging/clojure-mode/clojure-mode > ` > > I even tried directly using `--eval "(load-library \"clojure-mode\")"` > which actually succeeded, but it still failed with the same error. > Given this I would have to assume that buttercup requires running in the > source tree. It's likely possible to patch the tests; I doubt it's fundamental to Buttercup. Thanks for adopting the package. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest
Hello, On Tue 19 Mar 2024 at 04:04pm -07, Xiyue Deng wrote: > Sean Whitton writes: > >> Hello, >> >> On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote: >> >>> Control: tags -1 pending >>> >>> I have prepared a fixed version and uploaded to mentors[1] with RFS[2]. >> >> Thanks for looking at this, but I'm not sure the fix is valid. >> >> The idea behind autopkgtest_keep is to ensure we test the installed >> package, not the files in the source tree. But if you just include them >> all, don't the files in the source tree get tested? > > After some testing this turns out to be an issue with buttercup: if the > required module is not immediately in the current loading path it will > get stuck. I've tested with `-L` and directly `--eval "(load-library > 'clojure-mode)"` and while the load-library succeeded it will still get > stuck. > > Meanwhile I have tested locally that with a newer buttercup version 1.34 > this won't be an issue anymore. However it fails some other tests which > we'll have to deal with later. > > So this is a workaround of the buttercup issue in 1.31. An alternative > is to disable autopkgtest as it's doing basically the same thing as the > test during building. > > Wdyt? Looks like buttercup 1.34 is now in unstable, so perhaps worth making an attempt at fixing those failing tests, before considering disabling? -- Sean Whitton signature.asc Description: PGP signature
Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest
Hello, On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote: > Control: tags -1 pending > > I have prepared a fixed version and uploaded to mentors[1] with RFS[2]. Also, you need to remove me from Uploaders in order to close the ITA :) -- Sean Whitton signature.asc Description: PGP signature
Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest
Hello, On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote: > Control: tags -1 pending > > I have prepared a fixed version and uploaded to mentors[1] with RFS[2]. Thanks for looking at this, but I'm not sure the fix is valid. The idea behind autopkgtest_keep is to ensure we test the installed package, not the files in the source tree. But if you just include them all, don't the files in the source tree get tested? -- Sean Whitton signature.asc Description: PGP signature
Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Hello Josh, Was there some recent packaging situation that prompted you to think about this? I'm cautious about adding it in the absence of that. -- Sean Whitton
Bug#904233: Adoption of persp-projectile
Hello, On Tue 12 Mar 2024 at 08:47pm -07, Xiyue Deng wrote: > Sean Whitton writes: > >> Hello Xiyue, >> >> Do you still intend to adopt persp-projectile? >> >> Thanks. > > Yes. And it seems I forgot to close this ITA bug in the Changelog. Can > we close this directly instead? We could, but I don't think you actually adopted it :) -- Sean Whitton
Bug#904233: Adoption of persp-projectile
Hello Xiyue, Do you still intend to adopt persp-projectile? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
On Sun, Mar 10, 2024 at 10:06:42AM +0800, Sean Whitton wrote: > Package: tech-ctte > X-debbugs-cc: csm...@debian.org, lea...@debian.org > > I call for votes on the following ballot to fill a vacant seat on the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt. > > ===BEGIN > The Technical Committee recommends that Craig Small be > appointed by the Debian Project Leader to the Technical Committee. > > C: Recommend to Appoint Craig Small > F: Further Discussion > ===END I vote C > F -- Sean Whitton signature.asc Description: PGP signature
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Package: tech-ctte X-debbugs-cc: csm...@debian.org, lea...@debian.org I call for votes on the following ballot to fill a vacant seat on the Debian Technical Committee. The voting period starts immediately and lasts for up to one week, or until the outcome is no longer in doubt. ===BEGIN The Technical Committee recommends that Craig Small be appointed by the Debian Project Leader to the Technical Committee. C: Recommend to Appoint Craig Small F: Further Discussion ===END -- Sean Whitton signature.asc Description: PGP signature
Bug#1065148: vokoscreen-ng: asks to install package with wrong name
Package: vokoscreen-ng Version: 3.5.0-1 Severity: minor Dear maintainer, On bookworm, when you start vokoscreen-ng under Sway, there is a popup asking you to install "gstreamer-plugins-pipewire". But the package one should install on Debian is gstreamer1.0-pipewire. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vokoscreen-ng depends on: ii gstreamer1.0-plugins-good 1.22.0-5+deb12u1 ii libc6 2.36-9+deb12u4 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2 ii libgstreamer1.0-0 1.22.0-2 ii libpulse0 16.1+dfsg1-2+b1 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus55.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5multimedia5 5.15.8-2 ii libqt5network5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5x11extras5 5.15.8-2 ii libstdc++6 12.2.0-14 ii libwayland-client0 1.21.0-1 ii libx11-6 2:1.8.4-2+deb12u2 Versions of packages vokoscreen-ng recommends: ii gstreamer1.0-libav 1.22.0-2 ii gstreamer1.0-pulseaudio1.22.0-5+deb12u1 ii libqt5multimedia5-plugins 5.15.8-2 ii pulseaudio 16.1+dfsg1-2+b1 Versions of packages vokoscreen-ng suggests: ii gstreamer1.0-plugins-bad 1.22.0-4+deb12u5 ii gstreamer1.0-plugins-ugly 1.22.0-2+deb12u1 pn gstreamer1.0-vaapi ii intel-media-va-driver 23.1.1+dfsg1-1 -- no debconf information -- Sean Whitton signature.asc Description: PGP signature
Bug#973393: truncate less of the backtrace during failing ert tests
control: tag -1 + pending Applied, thanks. -- Sean Whitton
Bug#973393: truncate less of the backtrace during failing ert tests
Hello, On Mon 26 Feb 2024 at 06:16pm -08, Xiyue Deng wrote: > Recently when debugging an ERT failure I found that enabling larger > backtrace margin by default would be very help. Hmm, interesting. Can you show an example where it helps, so I can get an idea of what you have in mind? > I have tested [1] in my fork to be working. As dh-elpa doesn't enable > merge requests, I'd like to gather some reviews/comments here before > merging. TIA! I'd be grateful if you'd attach patches to BTS mail in the future, for inline review. Thanks for looking into this. -- Sean Whitton signature.asc Description: PGP signature
Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs
control: tag -1 - moreinfo + pending Hello, On Tue 27 Feb 2024 at 09:17am +08, Sean Whitton wrote: > Hmm, I added Breaks/Replaces, and piuparts is happy. Requesting manual > review. Thank you. Ah, my relations were missing the 1: epoch. Uploading shortly. -- Sean Whitton signature.asc Description: PGP signature
Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs
control: tag -1 + moreinfo Hello, On Mon 26 Feb 2024 at 06:26pm +01, Helmut Grohne wrote: > 4 packages from emacs have an undeclared file conflict. This may result > in an unpack error from dpkg. > > The file /usr/bin/emacsclient.emacs is contained in the packages > * emacs-bin-common >* 1:27.1+1-3.1+deb11u1 as present in bullseye >* 1:27.1+1-3.1+deb11u2 as present in bullseye-security >* 1:28.2+1-15 as present in bookworm >* 1:29.1+1-5 as present in trixie >* 1:29.1+1-5~bpo12+1 as present in bookworm-backports > * emacs-gtk/1:29.2+1-1 as present in unstable > * emacs-lucid/1:29.2+1-1 as present in unstable > * emacs-nox/1:29.2+1-1 as present in unstable > * emacs-pgtk/1:29.2+1-1 as present in unstable > > These packages can be unpacked concurrently, because there is no > relevant Replaces or Conflicts relation. Attempting to unpack these > packages concurrently results in an unpack error from dpkg, because none > of the packages installs a diversion for the affected file. Hmm, I added Breaks/Replaces, and piuparts is happy. Requesting manual review. Thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1064593: debian-policy: missing static resources for www.debian.org policy page
Hello, On Sun 25 Feb 2024 at 02:24pm +01, Holger Wansing wrote: > Seems there is more than only one issue: > > 1. > In the binary package (debian-policy latest version) the above files and > directories are existing, but the files are all empty (0 B size). > However, in the previous version (4.6.2.0) the javascript .js files > are also empty (0 B), so that's most probably not the issue. > I remember we don't have full javascript functionality in our sphinx-based > manuals on debian.org for a longer time, search is not working for example. > That's #1026446, #872944, #987943. > > In a local build here, they are all fine, and the document is displayed > correctly. But that's build on bookworm, so sphinx version 5.3.0. > The binary packages built by buildd will get build on sphinx 7.2.x > I think, so maybe there is the difference? > Maybe we need some adaption for latest sphinx version? > > > 2. > The first file from above list _static/css/theme.css is likely to be > the point, since the html layout is completely broken. > That file is also empty in latest debian-policy binary package. > Since it is fine in local build here, also an issue with latest sphinx > version maybe ??? > Or do we no longer need _static/css/theme.css, as we now have > _static/debian.css ? > > > 3. > Despite the fact, that the files from above are empty, there seems to be > another issue with debian.org website: > the subdirectories under _static are not existing on debian.org, as well as > the files within of course (like _static/css/theme.css). > Apparently there is some more magic needed in webmaster-team's cron > https://salsa.debian.org/webmaster-team/cron/-/blob/master/parts/7doc?ref_type=heads#L319 > to get such files copied over to debian.org during website build. > > But first, we need to have a working version in the binary package, > since that's the basis for website build. I guess I should have done a debdiff huh? :) Thank you for the analysis. Osamu, Stéphane, could you take a look? Thank you. -- Sean Whitton
Bug#1064593: debian-policy: missing static resources for www.debian.org policy page
Hello, On Sun 25 Feb 2024 at 08:44am +01, Holger Wansing wrote: > Hi, > > Am 24. Februar 2024 20:15:41 MEZ schrieb James Addison : >> >>(this may relate closely to #915583) >> >>Some of the web resources referenced by the online[1] copy of the Debian >>policy >>manual seem to return HTTP 404 responses at the moment, meaning that the >>intended Sphinx CSS theming fails to apply. >> >>[1] - https://www.debian.org/doc/debian-policy/ > > Hmm, locally built it's fine here ... > > @Stéphane: could you take a look? The new debian.css is there. So, which file is it that's missing? -- Sean Whitton
Bug#915583: about html_static_path
control: tag -1 + pending Hello, On Sat 24 Feb 2024 at 08:52am +01, Holger Wansing wrote: > Hi Sean, > > Sean Whitton wrote (Sat, 24 Feb 2024 11:58:59 > +0800): >> Attached is the patch I prepared, which I couldn't get to work. Maybe >> you can see what is wrong. Thanks! > > As I know it, the debian.css file has to reside in policy/_static. > And activate (un-comment) the path declaration for that in line 105 of > conf.py.in. > > Additionally, as I already wrote somewhere, for navigating it would be good > to have the Next/Previous buttons at the top of the page as well, not only > at the bottom. > > And: do we want to have the > "Built with Sphinx using a theme provided by Read the Docs." > in the footer? If not, that could be suppressed by > html_show_sphinx = False > in conf.py.in. > > > My diff for conf.py.in would be like this (with above suggestions): Thank you very much, both -- now merged for the next upload. -- Sean Whitton signature.asc Description: PGP signature
Bug#915583: about html_static_path
Hello,
On Thu 15 Feb 2024 at 11:44pm +01, Holger Wansing wrote:
> Sean Whitton wrote:
>> On Fri 29 Dec 2023 at 07:08am +01, Stéphane Blondon wrote:
>>
>> > Yes, html_static_path must be set but it's already the case in conf.py.in:
>> > https://sources.debian.org/src/debian-policy/4.6.2.0/policy/conf.py.in/#L105
>> >
>> > I guess conf.py is generated from conf.py.in so we only need to keep
>> > the current setup.
>>
>> That line is commented out, though. Are you saying it takes on its
>> default value in that case?
>
> I think it would be good to un-comment such lines which are needed, so it's
> clear without doubt, what is used and active.
> Works fine here BTW.
Attached is the patch I prepared, which I couldn't get to work. Maybe
you can see what is wrong. Thanks!
-- >8 --
From: =?UTF-8?q?St=C3=A9phane=20Blondon?=
Date: Mon, 27 Nov 2023 23:36:06 +0100
Subject: [PATCH] New Debian-specific Sphinx style
---
debian/changelog | 3 ++
debian/control| 1 +
policy/conf.py.in | 5 ++-
policy/debian.css | 103 ++
4 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 policy/debian.css
diff --git a/debian/changelog b/debian/changelog
index ffa0f8b..6d04491 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,9 @@ debian-policy (4.6.2.1) UNRELEASED; urgency=medium
package metadata.
* Update Installed-Size algorithm used by dpkg (Closes: #793499).
+ [ Stéphane Blondon ]
+ * New Debian-specific Sphinx style (Closes: #915583).
+
-- Russ Allbery Sat, 09 Sep 2023 15:27:27 -0700
debian-policy (4.6.2.0) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index a98b425..ebb3c3f 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Build-Depends:
libxml2-utils,
links | elinks,
python3-sphinx,
+ python3-sphinx-rtd-theme,
sphinx-common (>= 1.6.5),
sphinx-intl,
texinfo,
diff --git a/policy/conf.py.in b/policy/conf.py.in
index d516d7b..86bc1ac 100755
--- a/policy/conf.py.in
+++ b/policy/conf.py.in
@@ -84,7 +84,7 @@ todo_include_todos = False
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
-html_theme = 'nature'
+html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
@@ -92,6 +92,9 @@ html_theme = 'nature'
#
# html_theme_options = {}
+# Overwrite theme to fit Debian colors
+html_css_files = ['debian.css']
+
# Override the title to remove the unnecessary "documentation" suffix.
html_title = "Debian Policy Manual v@VERSION@"
diff --git a/policy/debian.css b/policy/debian.css
new file mode 100644
index 000..7f0981b
--- /dev/null
+++ b/policy/debian.css
@@ -0,0 +1,103 @@
+/* Debian Cascading stylesheet for Sphinx */
+
+div.related {
+background-color: #C70036;
+}
+
+.rst-content h1, .rst-content h2, .rst-content h3, .rst-content h4,
.rst-content h5, .rst-content h6 {
+color: #C70036;
+}
+
+.wy-nav-top {
+background-color: #C70036;
+}
+
+.wy-side-nav-search {
+background-color: #C70036;
+}
+
+.rst-content a:link {
+color: #0035C7;
+text-decoration: none;
+}
+.rst-content a:visited {
+color: #00207A;
+text-decoration: none;
+}
+.rst-content a:link:hover {
+color: #00207A;
+text-decoration: underline;
+}
+
+
+/* Table in content */
+
+.wy-table-responsive table td, .wy-table-responsive table th {
+white-space: normal;
+}
+
+.rst-content table.docutils, .wy-table-bordered-all {
+width: 100%;
+}
+
+.wy-table-responsive table.docutils thead tr {
+background-color: #C70036;
+border: 1px solid black;
+color: black;
+}
+
+.wy-table-responsive table.docutils thead tr:hover {
+color: #fcfcfc;
+}
+
+.wy-table-responsive table.docutils tbody tr:hover {
+background-color:#66;
+color: #FF;
+}
+
+.rst-content table.docutils:not(.field-list) tbody tr:hover:nth-child(2n-1),
.wy-table-backed, .wy-table-odd td, .wy-table-striped tr:nth-child(2n-1) td {
+background-color:#66;
+}
+
+/* Previous and next buttons */
+
+.rst-footer-buttons .btn:hover {
+text-decoration: none !important;
+}
+
+/* Version release more readable */
+
+.wy-side-nav-search > div.version {
+color: #FCFCFC;
+}
+
+/* Infos blocks */
+
+div.warning {
+border: 1px dashed #EFF500;
+background-color: #eff50030;
+}
+
+div.note {
+border: 1px dashed blue;
+background-color: #ff30;
+
+}
+
+.warning, .note {
+margin-left: 1em;
+margin-right: 1em;
+}
+
+@media (max-width: 5in), (max-device-width: 5in){
+.warning, .note {
+margin-left: 0.5em;
+margin-right: 0.5em;
+}
+}
+
+/* Notes */
+
+html.writer-html5 .rst-content aside.citation, html.writer-html5 .rst-content
aside.footn
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
ll also want to minimise how much it gets in the way of people who have no interest in that sort of feature -- most of our classic Debian desktop power users, I suspect (which includes most DDs). Russ, I think there are some changes to your most recent wording you intended to make after feedback from Simon, but I don't think you've posted an updated patch yet? If you could, I can review and second. I think what you write in your patch is fair to proponents of alternative init systems, though it would be good to have explicit approval from one of them if someone has time. We could post your updated patch to one of their lists? Thank you for your efforts on this. -- Sean Whitton signature.asc Description: PGP signature
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
Using`` > @@ -666,21 +710,6 @@ requirements to retain the referenced source packages. > It should not > be added solely as a way to locate packages that need to be rebuilt > against newer versions of their build dependencies. > > -.. [#] > - While ``Build-Depends``, ``Build-Depends-Indep`` and > - ``Build-Depends-Arch`` permit the use of alternative dependencies, > - those are only used for the backports suite on the Debian autobuilders. > - On the other suites, after reducing any architecture-specific restrictions > - for the build architecture in question, all but the first alternative are > - discarded except if the alternative is the same package name as the first. > - The latter exception is useful to specify version ranges like > - ``foo (rel x) | foo (rel y)``. This is to reduce the risk of > inconsistencies > - between repeated rebuilds. While this may limit the usefulness of > - alternatives in a single release, they can still be used to provide > - flexibility in building the same package across multiple > - distributions or releases, where a particular dependency is met by > - differently named packages. > - > .. [#] > The relations ``<`` and ``>`` were previously allowed, but they were > confusingly defined to mean earlier/later or equal rather than -- Sean Whitton
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
Hello, On Mon 11 Sep 2023 at 01:04pm +02, Santiago Vila wrote: > I wrote: >> I believe that by choosing the wording appropriately, we can still keep this >> desired property of Policy while still not mandating any given >> implementation. > > Sorry, that was terribly worded. I meant that we can avoid the hassle of > documenting everything dh_installsystemd does and at the same time not > *formally* mandating the use of dh_installsystemd. In general, I agree with Santiago. I find Policy's current scope and working process effective, and not especially ambiguous. I think everyone should read it during the NM process, if not sooner. Russ has concretely considered these issues much more than me, and Niels has worked extensively on an implementation, and I have not. These things count, so my sense that things are broadly okay as they are only goes so far. I do think we should put weight on our actual experiences as Debian contributors, and what's useful, and, as elsewhere in software, focus on incremental improvements over rewrites. For example, I think that the knowledge of good documentation practices that's already implicit in how we all actually write Policy text counts for more than abstract discussions of best practice. -- Sean Whitton signature.asc Description: PGP signature
Bug#915583: about html_static_path
Hello, On Fri 29 Dec 2023 at 07:08am +01, Stéphane Blondon wrote: > Yes, html_static_path must be set but it's already the case in conf.py.in: > https://sources.debian.org/src/debian-policy/4.6.2.0/policy/conf.py.in/#L105 > > I guess conf.py is generated from conf.py.in so we only need to keep > the current setup. That line is commented out, though. Are you saying it takes on its default value in that case? -- Sean Whitton signature.asc Description: PGP signature
Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST
Hello, On Sat 30 Dec 2023 at 11:11pm +01, Holger Wansing wrote: > Source: debian-policy > Tags: patch > > Debian Policy has been migrated to restructedText / Sphinx. > However, the current html theme is not conform with the look of the Debian > website. > > Bug #1053549 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053549) > requests to create a new theme for Sphinx-based documents "to match our docs > appearance with the Debian website colours etc." > > I have worked on this and a patch is attached, to fulfill this goal. > > An preview how the Debian Policy would look like with this theme can be found > at > https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/debian-policy-manual/ > > Please consider to apply this proposal. We're actually in the middle of applying someone else's proposal, here: #915583. Possibly some of your changes could be applied on top of that? -- Sean Whitton signature.asc Description: PGP signature
Bug#1057238: debian-policy: Take dpkg-build-api into account for Rules-Requires-Root
Hello, On Sat 02 Dec 2023 at 01:22am +01, Guillem Jover wrote: > Starting with dpkg 1.22.0, it implements a dpkg-build-api mechanism > similar in concept to the debhelper-compat levels. > > You can check its documentation in the dpkg-build-api(7) and > dpkg-buildapi(1) manual pages. > > I think at least the part that involves the Rules-Requires-Root field > which in level 1 defaults to value «no» instead of «binary-targets» > should be documented in the Debian policy. Agreed. Thanks for the report. > I'm ambivalent on whether documenting the general mechanism in Debian > policy makes sense though. When many/most Debian package maintainers need to know about this, as they do debhelper compat, then we should add it, but until then, perhaps not. -- Sean Whitton signature.asc Description: PGP signature
Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks
Hello, On Fri 01 Dec 2023 at 02:11pm +01, Helmut Grohne wrote: > §7.4 currently starts with: > > When one binary package declares a conflict with another using a > Conflicts field, dpkg will refuse to allow them to be unpacked on > the system at the same time. > > I believe this is technically wrong. There are situations where dpkg > will allow such unpacks to temporarily co-exist. §6.6 goes into further > detail and is accurate. Thank you for the detailed report. Do the dpkg and apt people think that the bug here is just in Policy, or are there any code changes under consideration in response to this work? -- Sean Whitton signature.asc Description: PGP signature
Bug#915583: patch for debian style
Hello, On Mon 27 Nov 2023 at 11:36pm +01, Stéphane Blondon wrote: > Hello, > > the attached file (debian.css) sets up the custom style. > > In order to work: > - add the 'python3-sphinx-rtd-theme' package to the dependencies > - in `conf.py.in`, replace: >html_theme = 'nature' >by >html_theme = 'sphinx_rtd_theme' > > The generated conf.py file must contain: > # Overwrite theme to fit Debian colors > html_css_files = ['debian.css'] > > > Please tell me if it does not work because I made several workarounds > in order to get it work without everything properly > installed/configured. This doesn't seem to be enough to ensure that debian.css gets installed to the .deb. I think we might also need to set html_static_path ? -- Sean Whitton signature.asc Description: PGP signature
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Hello,
On Sun 10 Dec 2023 at 09:09pm -08, Xiyue Deng wrote:
> So a little further reading from the policy[1] and the lintian bug[2]
> helped me understand the usage of "Built-Using" a bit better: it's used
> to include other source package required for building without having to
> depend on them. So technically it's not mutually exclusive with
> arch:all as stated in the bug. However, in the case of
> persp-perspective, I tried with or without it and it doesn't make any
> difference. What's important is that ${elpa:Depends} correctly added
> elpa-perspective and elpa-projectile to the dependency list of the
> binary package. So I think in the end dropping it should be OK.
>
> Still, it makes sense to clarify the actual reason to drop it, so I've
> updated the changelog entry to reflect this fact[3]. PTAL, TIA!
Well, it's more about ensuring that those source package versions aren't
dropped from the archive by dak, rendering us license-incompliant.
Thanks for looking into it further. I've made a further change to your
changelog message. Please take a look.
I've also noticed that there has been an upload to the archive,
1:0.2.0-4, which is not accounted for in our history. Please merge it
in. 'gbp import-dsc apt:persp-projectile/sid', and then a manual merge,
is probably what you want, because of how the patches are unapplied.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Hello, On Fri 03 Nov 2023 at 05:01pm -07, Xiyue Deng wrote: > I thought mentioning dropping Built-Using from arch:all package could be > an acceptable reason, which in turn also follows Lintian's suggestion :) > But do let me know if I should further clarify. But why couldn't an arch:all package have Built-Using? Built-Using, per Policy, is for license issues. arch:any vs. arch:all isn't determinative. -- Sean Whitton signature.asc Description: PGP signature
Bug#1055379: RFS: clojure-mode/5.18.0-1 [RC] [Team] -- extra font-locking for clojure-mode
Hello, On Sat 09 Dec 2023 at 04:08pm -08, Xiyue Deng wrote: > Looks like the deleted changes are the patches that dropped the > package.el based installation instructions from README.md and an extra > loading path of Eldev based directory. I don't think they'll matter > much to be honest (especially the latter doesn't cause any issue for the > tests), so please feel free to leave them as is. Cool, thanks for reviewing. -- Sean Whitton signature.asc Description: PGP signature
Bug#1055379: RFS: clojure-mode/5.18.0-1 [RC] [Team] -- extra font-locking for clojure-mode
Hello, On Sat 09 Dec 2023 at 04:23pm GMT, Sean Whitton wrote: > Hello Xiyue, > > I made some commits before uploading. Please review. > > For the dgit-maint-merge(7) workflow, there is no need to manually > refresh patches. dgit will do it for us whenever necessary. See the > automatic commit now on the branch. Hmm. Looks like I might have deleted some changes. Could you take a look? Thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1056595: dgit: must not override dpkg include lists
control: tag -1 + wontfix control: close -1 Hello, As has been explained, this bug is invalid, at least as currently titled -- it's fundamental to the design of dgit that it behaves in this way. If the discussion yields some ways in which dgit can become friendlier to users and non-users, then it might be better to file new bugs with those concrete change proposals. Julien, given that you have decided not to use dgit in the near future, it would have been more helpful to frame this bug explicitly in terms of helping people like you, who have decided that. As it stands, your submission rather like a complaint, and that is not fair or kind to those of us who work on dgit. We don't want you to feel frustrated! -- Sean Whitton signature.asc Description: PGP signature
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
control: tag -1 + moreinfo control: owner -1 ! Hello Xiyue, Thank you for working on this. A review of 2ea5e050fe78c7a382a613bc60ce5f14da4f130a: I'm wondering why you've updated git watch to check for the git HEAD, since upstream seems to now be tagging releases? The changelog should mention the switch d/compat -> debhelper-compat. The typo fix in d/control should be mentioned in d/changelog. You should say that it's --parallel that you dropped from d/rules. Your justification for dropping the Built-Using should not be that Lintian suggested dropping it. Please determine the real reason :) -- Sean Whitton signature.asc Description: PGP signature
Bug#915583: debian sphinx styling: second attempt
Hello Stéphane, Thank you for working on this. A couple of things I have written in my notes, from years ago, on this topic: - it would be good for footnote references to stand out more than they do at present. I think your theme achieves this. - it would be good to do some accessibility testing of some kind, at least with screenreaders. But maybe the fact that you've based your theme on an existing, popular Sphinx theme means this is covered? Thanks again. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053993: RFP: emacs-eask -- CLI for building, running, testing, and managing your Emacs Lisp dependencies
Hello, On Mon 16 Oct 2023 at 07:46pm +02, Martin wrote: > Quoting Sean Whitton : >> Typically we try to patch out the need for build-deps like this. Have >> you tried to do that? > > Thanks for the suggestion, I'll do that! > > I did that for the current version of the package (which uses cask, not > eask). And I can probably keep it that way. I wonder, if that is the > right direction for the future, in case more and more packages use such > build tools? But maybe this bug is not the right place to discuss it. Typically these things come in and out of fashion quite fast. If you find a package where it looks like stripping it out will be a lot of labour, let's discuss. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053993: RFP: emacs-eask -- CLI for building, running, testing, and managing your Emacs Lisp dependencies
control: tag -1 + moreinfo Hello Martin, On Sun 15 Oct 2023 at 01:32pm GMT, Martin wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: debian-emac...@lists.debian.org > > * Package name: emacs-eask > Version : 0.8.3 > Upstream Author : Jen-Chieh Shen > * URL or Web page : https://github.com/emacs-eask/cli > * License : GPL-3 > Description : CLI for building, running, testing, and managing your > Emacs Lisp dependencies > > Eask was built to use as a package development tool in your Elisp > packages. But now, Eask supports various types of Emacs Lisp tasks. > > Eask is a new build dependency for emacs-dashboard. Typically we try to patch out the need for build-deps like this. Have you tried to do that? -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Mon 16 Oct 2023 at 03:51am -07, Xiyue Deng wrote: > Looks like I got confused about what you suggested as there was a "0.3" > tag that was from the upstream repo which I assume "git deborig" can use > so I thought an "upstream" may help more. > > I've now also pushed an "upstream/0.3" tag at the commit that matches > the "0.3" tag, but not sure whether this is what you were referring to. > If this works better I can remove the upstream branch to avoid further > complications. Please advice. Thanks! What I meant was simply pushing the 0.3 tag to salsa. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Sun 15 Oct 2023 at 10:45pm -07, Xiyue Deng wrote: > Ah I see. So for d/copyright we need to stick to the source > information. Dropped Wilfred from the list of copyright holders for > now. Also opened a PR upstream for tracking[1]. Cool. Just to note, in your commit message you wrote that he's not a copyright holder yet, but we can't assert that -- in fact, he probably is a copyright holder. You could have written that he's not /documented/ as a copyright holder. > As this is the first time I attempt of ITP/RFS, I'd like to go over the > steps for packaging as much as possible if OK. But AIUI this package > will need to go through the NEW queue, so I guess if you sponsor my > upload to mentors.d.n it may require some extra steps, then I'm OK if > what you propose can save some trouble. Okay, go ahead and let me know when you've done 'dch -r'. I will still work out of git, so please don't push a signed tag there. See dgit-sponsorship(7) for more. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Sun 15 Oct 2023 at 10:46pm -07, Xiyue Deng wrote: > Sean Whitton writes: > >> Hello, >> >> On Sun 15 Oct 2023 at 03:10pm +01, Sean Whitton wrote: >> >>> Hello, >>> >>> On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: >>> >>>> Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have >>>> also filed an RFS bug#1053987. >>> >>> Alright, pushed that to a team repo, let's work from there. >> >> It would be a good idea to push upstream's git tags to the repo, so that >> I can just type 'git deborig'. > > Done. The `upstream' branch should be available now. I did mean the tags -- I myself prefer not to push an upstream branch. The idea is that from our point of view the upstream source is immutable, like tags, and unlike branches. But of course it's fine to have one. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Sun 15 Oct 2023 at 03:10pm +01, Sean Whitton wrote: > Hello, > > On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: > >> Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have >> also filed an RFS bug#1053987. > > Alright, pushed that to a team repo, let's work from there. It would be a good idea to push upstream's git tags to the repo, so that I can just type 'git deborig'. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: > Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have > also filed an RFS bug#1053987. Alright, pushed that to a team repo, let's work from there. Review of 8123e6e09fa1591dc2182682661421d9be80c328: - d/copyright is required to say where upstream sources were obtained -- see Debian Policy - It looks like you made up the copyright statement for Wilfred Hughes, right? While he may indeed hold copyright, what the GPL requires is just that we reproduce the copyright notices we actually find in the source. So it's probably best to drop it for now, and consider offering a pull request upstream. - I'd like to suggest dropping the .gitignore, because it interferes with me uploading using dgit. Can explain more if you want. - description "electric support" is ambiguous. Support for doing what? - in general, do you mind if when I upload I commit the 'dch -r' change for you? I.e. the upload is signed off by me, but there'd be [ Xiyue Deng ] in the changelog. This avoids an e-mail roundtrip. Totally up to you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello Xiyue, On Sun 15 Oct 2023 at 04:32am -07, Xiyue Deng wrote: > Package: sponsorship-requests > Severity: wishlist > X-Debbugs-Cc: Xiyue Deng , debian-emac...@lists.debian.org > > Dear mentors, > > I am looking for a sponsor for my package "bison-mode": > > * Package name : bison-mode >Version : 0.3-1 >Upstream contact : [fill in name and email of upstream] > * URL : https://github.com/Wilfred/bison-mode > * License : GPL-2+ > * Vcs : https://salsa.debian.org/emacsen-team/bison-mode Can you give me a git repo to clone, please? I'll create and push it to that team repo, then review and sponsor. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium
Hello, On Fri 13 Oct 2023 at 09:59pm +01, Sean Whitton wrote: > === BEGIN > > OPTION A: > > The Technical Committee formally repeals its moratorium recommending > that maintainers of individual packages should not proactively move > files from the root filesystem to corresponding locations under /usr in > the data.tar.* of packages (see #1035831). > > Under Constitution 6.1.5, the Technical Committee now recommends that > maintainers consult with those driving the merged-/usr transition before > moving files from the root filesystem to corresponding locations under > /usr in the data.tar.* of packages. > > The transition driver, which at the time of writing is Helmut Grohne, is > using a phased approach, in which the moratorium is rolled back for only > certain classes of packages, and changes, at a time. In addition, > restructuring uploads should be targeted at experimental, and left for > three days. This is in order that automated testing by dumat can occur. > > We recommend following <https://wiki.debian.org/UsrMerge>, as edited by > the transition driver(s). If there is any doubt as to whether a change > you wish to make is appropriate, please seek explicit approval from the > transition driver(s). > > OPTION N: > > None of the above. > > === END I vote A > N -- Sean Whitton signature.asc Description: PGP signature
Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium
Package: tech-ctte I call for votes on the following resolution. Voting lasts for one week or until the outcome is no longer in doubt. === BEGIN OPTION A: The Technical Committee formally repeals its moratorium recommending that maintainers of individual packages should not proactively move files from the root filesystem to corresponding locations under /usr in the data.tar.* of packages (see #1035831). Under Constitution 6.1.5, the Technical Committee now recommends that maintainers consult with those driving the merged-/usr transition before moving files from the root filesystem to corresponding locations under /usr in the data.tar.* of packages. The transition driver, which at the time of writing is Helmut Grohne, is using a phased approach, in which the moratorium is rolled back for only certain classes of packages, and changes, at a time. In addition, restructuring uploads should be targeted at experimental, and left for three days. This is in order that automated testing by dumat can occur. We recommend following <https://wiki.debian.org/UsrMerge>, as edited by the transition driver(s). If there is any doubt as to whether a change you wish to make is appropriate, please seek explicit approval from the transition driver(s). OPTION N: None of the above. === END -- Sean Whitton signature.asc Description: PGP signature
Bug#1052967: emacsql-sqlite3: FTBFS: make: *** [debian/rules:4: build] Error 25
Hello, On Mon 09 Oct 2023 at 08:18pm +02, Aymeric Agon-Rambosson wrote: > No. In fact, I think we should not be packaging emacsql-sqlite3 anymore, and > we should use the occasion to remove it. > > The upstream maintainers themselves contend that package developers should not > use it, and rely on emacsql instead : > https://github.com/cireu/emacsql-sqlite3#important-note. > > It has no reverse dependencies, and I fail to see how it could be useful to > anyone if not as a dependency for another package. > > The next release of emacsql will not support it, and will make it obsolete, a > point of view the upstream maintainers of emacsql-sqlite3 themselves seem to > accept : https://github.com/cireu/emacsql-sqlite3/issues/38. > > It was removed from MELPA last April for this reason. Cool, would you like to file the RM bug? -- Sean Whitton signature.asc Description: PGP signature
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Hello Russ, Thank you for working on this. On Sat 09 Sep 2023 at 08:35pm -07, Russ Allbery wrote: > In order to structure the discussion and prod people into thinking about > the implications, I will make the following straw man proposal. This is > what I would do if the decision was entirely up to me: > > Licenses will be included in common-licenses if they meet all of the > following criteria: > > * The license is DFSG-free. > * Exactly the same license wording is used by all works covered by it. > * The license applies to at least 100 source packages in Debian. > * The license text is longer than 25 lines. Something that hasn't been brought up yet is the effects on NEW review. I would like to expand the idea of the same license wording being used by all works, to include the additional requirement that there aren't any very similar licenses that are easily confused with the license. For, if it's a license with small variations of any kind, including variations that are not project-specific things like the names of copyright holders, then NEW review is much easier if all the text is right there in d/copyright. I would be in favour of the 25 lines criterion. The main problem with manipulating d/copyright is only the really long licenses, IME. -- Sean Whitton signature.asc Description: PGP signature
Bug#1052967: emacsql-sqlite3: FTBFS: make: *** [debian/rules:4: build] Error 25
Hello Aymeric, On Tue 26 Sep 2023 at 03:44pm +02, Lucas Nussbaum wrote: > Source: emacsql-sqlite3 > Version: 1.0.2+git20220304.1.2113618-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230925 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Given that you maintain emacsql, would you be interested in taking over emacsql-sqlite3 as well? -- Sean Whitton signature.asc Description: PGP signature
Bug#1053298: emacs: Buggy handling of transparency changes / blur/unblur
Hello Tollef, Please M-x report-emacs-bug to send this upstream. -- Sean Whitton signature.asc Description: PGP signature
Bug#1024367: In 4.9.1, the example uses not recommended install -s
Hello, On Sat 09 Sep 2023 at 03:16pm -07, Russ Allbery wrote: > I looked at this snippet and I think it has worse problems than the use of > install -s. For example, it predates the existence of dpkg-buildflags, > which would also handle noopt. I'm also dubious that it serves any useful > purpose given that nearly every package should just use debhelper. The > typical current Debian packager seems more likely to be confused by this > fragment than aided by it. > > I'm therefore going to propose fixing this bug with the following patch, > which is more aggressive than you propose. > > I think this is informative rather than normative and therefore > technically doesn't require seconds, but I'll give this some time for > other people to take a look and talk me out of deleting this section if > they wish. > > -- > Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> > >>From 409bbd815a946a7bb7b1eea8cab8198c494dd7d4 Mon Sep 17 00:00:00 2001 > From: Russ Allbery > Date: Sat, 9 Sep 2023 15:10:21 -0700 > Subject: [PATCH] Remove old Makefile DEB_BUILD_OPTIONS example > > The correct way to implement most DEB_BUILD_OPTIONS these days is > to just use debhelper. The detailed Makefile fragment was probably > more confusing than helpful, given that it predates dpkg-buildflags, > uses install -s (which Policy elsewhere recommends against), and > manually does other work debhelper would automate. Replace it with > a note that packaging helper frameworks do much of this work. > --- > policy/ch-source.rst | 35 +++---- > 1 file changed, 3 insertions(+), 32 deletions(-) LGTM. -- Sean Whitton signature.asc Description: PGP signature
Bug#1050709: tar-ignore debian/source/options
Hello Niels, On Mon 28 Aug 2023 at 06:56pm +02, Niels Thykier wrote: > So this is a common pattern in my packages although it sometimes appears in > d/s/local-options rather than d/s/options. > > Basically, the issue is when you have something you want to have locally, not > in git and also not in the archive. In one my other packages, I have a > "local" directory filled with local work items (including a full copy of the > sudo deb package for testing purposes). Here the "local" directory is listed > both in .gitignore and in "tar-ignore", because I do not want it in git nor in > the archive when I do an upload. > > To solve this, I add `tar-ignore=...` (for native packages) to > debian/source/(local-)options. However, if you add that option, you end up > with the entire *.git* directory in the tarball. To avoid that, I add the > `tar-ignore` on its own to get the sane defaults back. > > This then breaks dgit leading to this bug, which is kind of a catch-22 if you > want local specific things (IDE files or local prototype stuff) that you > guarantee is excluded from git and dpkg-source automatically and also support > dgit at the same time. dgit will never let you accidentally perform an upload containing something that's in the tree but not in git, and you can use .git/info/exclude as a local way to ensure it's never in git. So a simple policy of always doing uploads with dgit might achieve what you want, without introducing all these deltas between source packages, git, local trees etc.? -- Sean Whitton signature.asc Description: PGP signature
Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?
Hello, On Tue 12 Sep 2023 at 10:14am +02, Jörg-Volker Peetz wrote: > Right you are... It doesn't happen with 'emacs -q'. > And putting just these lines: > > ;;; Set eln-cache dir > (when (boundp 'native-comp-eln-load-path) > (setcar native-comp-eln-load-path > (expand-file-name "~/.cache/emacs-eln-cache/" > user-emacs-directory))) > > into init.el and starting 'emacs' makes the flaw happen. And how about if you put them into early-init.el? -- Sean Whitton signature.asc Description: PGP signature
Bug#1051677: emacs: Provides backport of 29.1
Hello, On Tue 12 Sep 2023 at 01:31am -07, Manphiz wrote: > I'll try :P No, not now, it's already in backports-NEW. -- Sean Whitton signature.asc Description: PGP signature
Bug#1051677: emacs: Provides backport of 29.1
Hello, On Mon 11 Sep 2023 at 12:02pm -07, Manphiz wrote: > Ah noted. I guess they'll redirect me to the actual team/person > handling the requested packages. In this case you could have been that person! -- Sean Whitton signature.asc Description: PGP signature
