[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Accepted debputy 0.1.65~bpo12+1 (source) into stable-backports



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 10 Mar 2025 22:25:00 +0000
Source: debputy
Architecture: source
Version: 0.1.65~bpo12+1
Distribution: bookworm-backports
Urgency: medium
Maintainer: Debputy Maintainers <debputy@packages.debian.org>
Changed-By: Niels Thykier <niels@thykier.net>
Closes: 1099543
Changes:
 debputy (0.1.65~bpo12+1) bookworm-backports; urgency=medium
 .
   * Rebuild for bookworm-backports.
   * Remaining delta compared to testing:
     - Remove two optional build-dependencies. They are present
       in -backports now but the CI is using stable and
       therefore fails. The relevant dependencies are currently
       1:1 with testing and the CI has working tests for them
       in sid/testing.
 .
 debputy (0.1.65) unstable; urgency=medium
 .
   * LSP/Lint:
     - Skip hover/completion inside Deb822 comments. Generally.
       it ended up triggering for the next content line instead.
     - Improve hover docs for packages when viewed in some editors
       (concretely `kate`). The previous docs worked
       specifically with how `emacs` rendered its Markdown docs.
       However, `emacs`'s method does not reformat text blocks,
       so it does not seem like it was the best editor to test with.
     - Tweak Inlay hint for inherited Deb822 values to make it
       prettier in `kate` and other editors. The previous rendering
       relied on editors to "gracefully" cope with newlines in the
       Inlay Hint label. The specs says nothing about the editor
       should react to those, so it was safer to avoid them.
     - When emitting a code action to the editor, do not provide
       `TextEdit`s in the "old" and the "new" format. Some editors
       (Concretely, `kate`) apply both with exciting but unhelpful
       results. The spec seems implies that the server is at fault
       if this happens, so the bug was probably `debputy`'s to
       begin with.
     - Track diagnostics with full metadata internally in `debputy`.
       This enables quickfixes in editors that either do not inform
       `debputy` of related diagnostics when requesting code actions
       (`kate`) or when the editor does not support the `data`
       attribute in the diagnostic (which the spec allows the editor
       to "not do"). Either way, more editors should now see
       quickfixes with `debputy`'s diagnostics.
     - Fix incorrect duplication warning for `foo` vs. `foo:native`
       when validating package relationships. Thanks to
       Otto Kekäläinen <otto@debian.org> for reporting this problem
       with the new check introduced in 0.1.64.
 .
 debputy (0.1.64) unstable; urgency=medium
 .
   * LSP/Lint:
     - Detect simple cases of duplicate relatations.
       Thanks to Matthias Geiger <werdahias@debian.org>
       (Closes: debputy#134)
 .
   [ Vincent Blut ]
   * debputy: Fix command example to show editor snippets
   * debputy.pod: Fix typo in man page
   * deputy lsp editor-config: Fix missing '}' in filetype mapping
     instructions for neovim
 .
   [ Niels Thykier ]
   * Add an rtupdate script to ensure byte-compilation happens on
     python interpreter update.
     Thanks to Stefano Rivera <stefanor@debian.org> (Closes: #1099543)
   * debputy lint: Print the related context when provided
   * Fix type error/crash with certain diagnostics
Checksums-Sha1:
 14e4540e0a5d2acfcfab09ba091955ffce542394 2037 debputy_0.1.65~bpo12+1.dsc
 f2158c19326fb5efdbf971bd045fc34d429a9d92 675360 debputy_0.1.65~bpo12+1.tar.xz
Checksums-Sha256:
 9fb1269bbd058852025e87e99f2cd58e576388976262f626140ec6ae3d9c3f21 2037 debputy_0.1.65~bpo12+1.dsc
 d424d1724a4938470443aa0f950894d450dfda84b5004086ccb2c38000322297 675360 debputy_0.1.65~bpo12+1.tar.xz
Files:
 32622ffd840a05c4e2611b050646edc3 2037 devel optional debputy_0.1.65~bpo12+1.dsc
 d275157d05579c173bbc296aa1e1a61c 675360 devel optional debputy_0.1.65~bpo12+1.tar.xz

-----BEGIN PGP SIGNATURE-----

iQFGBAEBCgAwFiEE9ecZmu9eXGflVYc/dA1oiINl0okFAmfPZ0ISHG5pZWxzQHRo
eWtpZXIubmV0AAoJEHQNaIiDZdKJ1ykH/R3Ir6b/gObzHWd9VCxlgs9eVcB4kKhB
17EHeCDF8bWfJPK/dghNnUHbYr9xUPNEiVhicP0V9xyb3niyVJ0Fd9GSK4vh9M1c
krBcNQhtjD5ZzaU7tnxHc36AiqDxAHZZLOAbNTsbn72SrvzQmIekkapJZvImDZwZ
+gmDs3Bh0Kzx9pvk6TodW21mBfelfYWFBx1oSGE9drTb5TyUxJbyznTehVqg1H2a
02n1NBRNNxwT+RxmGarxWHRj913jLWnweUejKTbU82AM7Vx9s3ZTBYoiTIx3ndVb
dkcuqgrNCoMo4BUy9hafWL9pbFTOy5H8EB8Xqy+EU/FsGoZqGhX825M=
=xPmM
-----END PGP SIGNATURE-----

Attachment: pgp00uOysdGI8.pgp
Description: PGP signature


Reply to: