Re: proposal: Hybrid network stack for Trixie
Quoting Sirius (2024-09-22 17:22:21) > On fre, 2024/09/20 at 13:12:36 +0200, Lukas Märdian wrote: > [snip] > > # Proposal > > My proposal is to enable a hybrid network stack, using systemd-networkd (on > > server/cloud/container/embedded systems) and NetworkManager (on > > desktop/laptop > > systems) unified through a common layer of Netplan configuration on top, to > > avoid fragmentation. This utilizes 3 tools that are under active upstream > > development and are already used as defaults in certain variants of Debian > > today. Furthermore, it allows people to control this stack on the native > > systemd-networkd/NetworkManager layer directly, while at the same time > > providing a way to describe network configuration that is common across > > Debian. > > > > I've repeated the reasons why I think a hybrid stack using Netplan is a > > feasible solution many times in previous threads, therefore I'd like to > > refer > > to a list of frequently asked questions, instead of spreading more reasons > > across more replies: https://wiki.debian.org/Netplan/FAQ > > If at all possible, permit it to also run without systemd and/or > Network-Manager in the mix, for use-cases where all the bells and whistles > (and complications, and deep integration into things it does not need to > integrate into, nor necessarily should integrate into, like SSH server) > is not required. > > To have Netplan as an option (which should be the case for systemd and > Network-Manager as well, options) seems very sensible IMHO. Netplan seems like *different* bells and whistles, rather than none. If you want no belss or whistles, then install neither of ifupdown, network-manager nor systemd-networkd, and operate your network using ip and (unless you also consider that a too large bell) iwd. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1081784: ITP: rust-human-panic -- panic messages for humans
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-human-panic Version : 2.0.1 Upstream Contact: Yoshua Wuyts * URL : https://github.com/rust-cli/human-panic * License : Apache-2.0 or Expat Programming Lang: Rust Description : panic messages for humans human-panic provides panic messages for humans. It handles panics by calling std::panic::set_hook to make errors nice for humans. This package is needed for sdml (bug#1064145). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-human-panic>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbl1IsMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEh3ZEP/0rH8DTzCr2nrg/Zcr46Z5CV5XXq24X9bygqPcFh yBazr3DNtxX9AoiE2GjDVWSVJ2MRyZ12UXKUuUqDijsI+9Mz4ZsC/qjPz9NznADJ caYEIw4tpDcm97S9BIZslrUN/kIOIZUtVV5n5oUow+oahKt3wyXcYxpd+MrSoxaR OvbI0Q/TT+EF9Z3H5pmBDPKQB+4DNg/MzQLX90l6Us7blAEa1qerdM6AkCJQ4SLr GDA+sFDBQ838kCwi+PHUj+0UwsyC6saanWNT+2scTfSs2y3dAiNWr6JX/DQm6t7n 3eJn1hMYyrJ3TUQuI1GRJ6/u1eAsuwcYB7RUztq6a/ELDmxwtLKekeNBmnIvQQgE CGDkIgHPmMbsLq6t7bCzsGO6OLVUUAnGbVRZ8qA/ncLRKkMxPNMTYL0W1CAqpFLG QKHlGcjsh/IsVGHwvV6eod0uC0tNllXLxmotL0Prh6bmjSr5izj6qkkjtAINJIHI /Lj1EoTVChRZbL5xO16XnKS5y6RV8oUOm4pGaa/kppPVOXOh5ppX6WirxuSQ4rcs bX9ugsNG1tOztoYNZynbYk3c7H6+c59tBftNMtO8qc7QUqj/Rlm+OYFQkwSQfh0o BIpNXpZgC8FvVt+8/xEaqOCalKwzaIqRJij0yWf7Qu75B1kDdwxqUj1waxX+NOrB ZSJV =vmrm -END PGP SIGNATURE-
Bug#1081778: ITP: rust-search-path -- very simple search path file finder
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-search-path Version : 0.1.4 Upstream Contact: Simon Johnston * URL : https://github.com/johnstonskj/rust-search_path * License : Expat Programming Lang: Rust Description : very simple search path file finder The SearchPath type allows for the finding of files using a series of search directories. This is akin to the mechanism a shell uses to find executables using the PATH environment variable. It can be constructed with a search path from an environment variable, from a string, or from a list of either string or Path/PathBuf values. Typically the find methods return the first matching file or directory, but the find_all method specifically collects and returns a list of all matching paths. This package is needed for sdml (bug#1064145). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-search-path>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmblz/QMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhpN8P/Ru/THrY44pLbeM1rPOPKe+jzK7Sq1HLgK/VHPM8 dTKRjEDob8u1iTyNM7RoMR3ugS/BIrOfs41ZUlhSadNypMklXStOXQnZAjlVSLQ0 5NypokqncF4Aqk/C/d+UCR6vN0TZ1Th89jzLtG4tBpZ5a/zdXMBpH1Ffi+HbzCfx wkKyBherm/kz+P4K56NYg22f+cYZex+JcnoaOa4Nsq94ehOkB50tZ+WYndNVyuU4 +RnzYlaV9NOOvJXfXIwClQn3ZDmjpYQnh6u2Ov3yE+umyfSIZqRPDmGQKixNcBHT cic8SMAjpUPg0VSKorj10D10M7KY8ne7sN+wSsfBlmLUGgtrQA4/d5hne927wzzQ 0+maosbG4I+L+n/+skE8n2j0DCZop1FdD+HEloR+R6fY6RcY98Z2099+ELcsC7W9 eukQJYwhahdmbbmwHDW0th5J0PZaRm3bMQmJU+H5dSB/8rnvpCxu9fQ9fH74EPFp ckcRDt8NAwf6Q2QEMO8ABLooTkW4UilYDaZ7SD6OAsBnIQPWj40VFjD0lNWFMnPL HD0lovFwHE4P2Bmfqs5WzlJ2LlwDUnSBS8iygAstVi2b7EBGwXy/jVqWYp8CsczB D1iRuWEVjVKAPd4Bjj0O7cz3l/+hXiIp6KPqUNEMb9arBPTzkrbyLBg4kb0YASs0 c0yb =XgXO -END PGP SIGNATURE-
Bug#1081775: ITP: rust-text-trees -- simple textual output for tree-like structures
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-text-trees Version : 0.1.2 Upstream Contact: Simon Johnston * URL : https://github.com/johnstonskj/rust-text_trees * License : Expat Programming Lang: Rust Description : simple textual output for tree-like structures text-trees will output a tree structure in text. Similar to the ascii_tree crate, however it is more flexible in its formatting options. This package is needed for sdml (bug#1064145). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-text-trees>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbly/IMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhRiUQAKAWIsg113ukHTH4q7HaxjsO0UthslF7EF3Dgkqw OZFNjvnGRVDF3THORALuAoXkEezXY8DlnUHjbJwVP7p+hiJXqh8tRT70g35+JEHD CeG0XmMjIYm/Dpne7wCloBtKo25kuUeQ2QG6+YMhQdaWJ2paMQgPJGWnbpzFmBgW 5kX2fYZheAw8CmUhIcDE0IWvSblXS2zvkuWzX3ZmRL0uIuYXd2dWP3CUkRzcnjiT TbRZlwv563zaESLUwJjbZZicoI9MXhkLOgTfBwXjC/pPkyeeNQJTZvDD/sZ9+Vrw fmW9sApXkIjHjLnaK2z0DBJLPdGHsWitUr5LGqEtqddwKnzfValTfeNXpfE3cFyB MMtODozHivOB0WiCLz6rZhY2nF5u6MjCUoGQ1RNhpZk1kYQ1C2jKS8LiYLiX82NQ vGyLtB7fdFUmqEW+Rm5TLnAlnlYm8IX63474j6Sq57TEJ1px06HDwMuksqzBMntt vHEzTUQv/CjO03e2x8J6QcynnHH0gY/2rT6T5rpLQ3ZC9zCMGE6gQMadT3bF19tQ eRTZKPQSdV6w59Gjm7QjP7FqK9039AuQV3ve7pORxMIcEC29tvyKjSjEie8bqmV4 /JfMaYV2gl0mHx1NnXqmudvT32jsIfLLszDGbhU0GlLFWzlBL8IkIYHgSrJkVHUD 99w/ =gBvl -END PGP SIGNATURE-
Bug#1081755: ITP: rust-serde-qs -- querystrings for Serde
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-serde-qs Version : 0.13.0 Upstream Contact: Sam Scott * URL : https://github.com/samscott89/serde_qs * License : Apache-2.0 or Expat Programming Lang: Rust Description : querystrings for Serde serde_qs is is a Rust library for serialising to and deserialising from querystrings. It is designed to extend serde_urlencoded when using nested parameters, similar to those used by qs for Node, and commonly used by Ruby on Rails via Rack. This package is needed for rust-indieweb (bug#1081745). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-serde-qs>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmblny0MHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhpoEP/i8wMr6UrBbTglrr8DAaC40+qYf6rWVeGYopVCVw fBCLxm1F8SpXY+heZlfKD2gyRxMo+gUNjLWWaQ9+mKanoGRtl56MXZlgcOJHcn8E XQYG8nAO/nCPNZmIG4NV9qX3r8OClLc4Hk/dI81+ZYkxV/Ep5sfQ1fqjOTk0fEJp QOC5/y/CiAiGmLhAZ3ISgyIf3xxENsCom+uF5jajOShiigFeXCWtc1d4Xk9oKqUS tKsJddmT0l+waSyCoGhc//dI4dpB713vfq+5+KAcAKfPKfciOlLRy0POb/zTwy+T tYxG/1pIztCZ1Dg9EMefypsXw7B7ZH2vxy4fhzUCwje0BSMSH6lfsufq3CKKJpC6 mBN7R7dxYGlqsUhrnjHtmEOiGUyzQIwKVSBQSuNrv4zRvyeeE1/L1pQyPcv8g0al aDt+P0MDQgHnprc7PbGPYGslxcKpspUA0mmOrIJIozk7Ohpx8JuyuB+hBgYFLBgO Loa0aY1ZgaFg9c7XXQrVxy4spB4wRMKvGZb6B0CcEB6c1HUrN4jOOL1+bKYn44L0 pMFOlrI2LEOgZ2cyJlKlaOBkjOJxbNGp6pKZDMxT+Pgu0HVb73cE0aSozDm/LBQZ 56yWRVXLd/iADtXSNllzvkLJtxhuUpfNOWnGey7MnGMHIoxtCV/tufyjfnklWlVR ja4P =RTI0 -END PGP SIGNATURE-
Bug#1081745: ITP: rust-indieweb -- utilities for working with the IndieWeb
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-indieweb Version : 0.4.5 Upstream Contact: Jacky Alciné * URL : https://indieweb.org/Rust#Library * License : AGPL-3 Programming Lang: Rust Description : utilities for working with the IndieWeb The indieweb library provides a collection of tools to work with the IndieWeb in your Rust applications: * IndieAuth supporting <https://indieauth.spec.indieweb.org/20201126/> * Webmention support <https://www.w3.org/TR/webmention/> This package will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-indieweb>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmblgeoMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhx2UP/1MkhAZari/PzpaOoVteDfr/1/Cwub2sD1+jTOmI nkHFaXoA4c/+hqaWGjYhuffCCkmAtsnhY3p/1O2efmi4J2wda9gaDLaRh8C9zIFH JmQL3Ey0IRk4odOAOKTUhWcXcBqVsKc9g0KSFbZ1Cl5VFtL41ZiVaO20LZa3nhtM owtP8aN6ARx/Yd9PiiWDTsMYxpzTAsgS/0UmpJnoPFq4AWCmy5VvQbX5rJjjVRMS 5ztx5IhkPtaS34m50+9zFOdvDG7WwEsn/PUNMbxwv4aHH/quknfhun3MAF26CGeL 8fLITlseiuD77XK5K6B9TlHO5KveDAt82Pfp0UzlbHem5fKaO+5NH9vYWMzBxsoi 56la2XR7sES3AMF598jWPzfK+KOyrgkcBASNhbKNz9qibcgx9Uj8r+Yy9Y1iJGx4 Y3PRL0dO0vZMCyLi7t27A3RNz9vD0BOKrwe8VsBrRiWJsRKkENUfA620pMIdQZwm bJFFraJtbbrg0IUDDc6hXCF7nbp6N75BE26U7vZCHvmbnmTzwF1imyEplL2NMbVI YBAh6a19eMgKMXQGiYzgYeanDXfECf5vKAP8/nJBCzFvQ1kyWgDFrM9Bps0JtM4X SXcDCCl6C1Tf5NsRj/24XohqI8ejtp+4vwS3Q91Su9GExbH5POkThjzDTrSVb+Qm TN2V =hu5f -END PGP SIGNATURE-
Bug#1081511: ITP: rust-yamux -- multiplexer over reliable, ordered connections
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-yamux Version : 0.13.3 Upstream Contact: Parity Technologies * URL : https://github.com/paritytech/yamux * License : Apache-2.0 or Expat Programming Lang: Rust Description : multiplexer over reliable, ordered connections Yamux is a stream multiplexer over reliable, ordered connections such as TCP/IP. This package is needed for rust-libp2p (bug#1059908). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-yamux>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbisKoMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhKXIP/3Qql3BvS7iBaTIMOUqiv0yxBFOQH2eyl6+Guxus gjCLF0fcST7g6Is2XsWsiuFAwKrICx0zTQA4KbJTyXzxN8MZdoOC8pvzlHlLcrBu oJvtSF6jN0BA23XVoG9wFdbapIpBtnBZcE7BvXzlQTPkkE2qxor7LVvgde2YS9pZ NHle5guPu1nhKf7jtSeqP0jg+wk19JqQlJExrDyM3P+0/BFDQlNMP6kbH5iWMgPG MDVRrdxq4b8HqV5mZBgOoA4qlp1Fr/0lQoZX+v8NsAgtlnQRWduMScMM6TWMZjOZ 53avF1apsdGzCPXv5+/6Kdv0MRdPMJ2Lk97RKftaBn3CJTceppl8wQoca+NZwJAH GAfoJDAMNmWbwszF2YMnUpjcrq6deO1jj3Wc0o/YIpMU2Qv/PBVZ0s2vqn6p/409 mSqTmsjft9IHMBKqf+tGmOX3dkkBU8gtUVSHLqWNfyjLNb/t2/5bK7tU6mnw0sB1 AMotGlI0quweLvyZWZMmDeTeFyB4wZQ3+/HgmlJnqHIOvGmur5uQaX45LIG7NkpI 9n2k2889sHdUGQAs0BdTfd3Pc48BglNrIgbYHE5ERkMJhvLwPorWbqajaQVhZXaM rVLsRTFhKpkexoFuDaOosiWrP8QCza3qHIYBx3X+GNFmPKicd5pac/Al8XxQrASH M76w =Yris -END PGP SIGNATURE-
Bug#1081472: ITP: rust-clio -- library for parsing CLI file names
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-clio Version : 0.3.5 Upstream Contact: AJ Bagwell * URL : https://github.com/aj-bagwell/clio * License : Expat Programming Lang: Rust Description : library for parsing CLI file names clio is a rust library for parsing CLI file names. . It implements the standard unix conventions of when the file name is "-" then sending the data to stdin/stdout as appropriate. With the "clap-parse" feature it also adds a bunch of useful filters to validate paths from command line parameters, e.g. it exists or is/isn't a directory. This package is needed by sdml (bug#1064145). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-clio>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbiAZwMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhtM8P/iHUhDOJ5fgJxLLQ6pBATcgubpkTedpgywbNXwqV tbfTzXEK8jBFAFBQKeMy8WgRJYKhr1r1DixeSWNxfy8YZ/u3JOrzUVxKtsOnQQlu PYtf4/1Y6SLA898XFEhHbW0DmCgvszOrCfgzVdDcNQD/552F37hf+64/e6VEa3Ac 3aI+QXxUz+4EdNiSZ5CwwLdqmh6/YLpivgqKp6wYgHrWdjMCz+CRpZPzZVxI0/0v nO2osVuy/hPjqZrM5McdtZYiBVeUvOQ0i+NuzYNlG01o1pfVsxXu/8qerO4JW3md 2qgXRJZ2QVk6e9b+/lceTkz88XNNLr0i0wGBmLvjAEeTKXBzJ1nMJMt+bYi112rO qXVpIO96AmLQ3Eao36yhJymgOtI0T+lGjsmw7a6wTWtXehC0rC6iNehQ2Yu7/CKy 6IYKaugYoK8uyEJlKt5ull8ssTTtlATTkMDP1JQptjK33fXV13bPM5EslLqABR+8 ZG/xlxlIWJC8TaJihIQjJ2Sd0+o5cFrWL0exPfaarYsV/n4mt9GAc9vBTVFKbdEY M73/s9UAr8aKAQC7J4qr2osN827VLZAlQyaVMtRQgfZOB5yr2l88i8UwWYZOZEpr mQSUlcShnoO+KXRqsGsjhIWaHYRse8+ATs4C69MfULBOeqpdv/UfMWFbBEIRoLew eAak =r8eG -END PGP SIGNATURE-
Bug#1081349: ITP: rust-mail-send -- e-mail delivery library
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-mail-send Version : 0.4.9 Upstream Contact: Stalwart Labs Ltd. * URL : https://github.com/stalwartlabs/mail-send * License : Apache-2.0 or Expat Programming Lang: Rust Description : e-mail delivery library mail-send is a Rust library to build, sign and send e-mail messages via SMTP. This package is needed for himalaya (bug#1000161). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-mail-send>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgtNMMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEh4IwP/Ra29TvIcBndhtkT9YabxhpRhJz9HB3Lr/4CaxTZ lgjG1eYBYGP1Ps7hz0QO+S56pwGFv4plOWni3VmoxIVKXBh4vwqEqXoLCswR3HfF iKayHbB/My3Lw/60PlrMR9MZYJG5AVihOKkqR14FMQDMFiTGhUgQqonGChgNbf4x gmehB0orckyXD5LyaO3tYqZ65PTKN7XUmQToprFbI7WJZ6tNDwv2HaQXQnr5LdaB v5zXxwpOw92Br1cNfck0rMsu6Hw+crUUw6IWul4SRILti8fpIsU8VIPyzXV2Yhsy i91XXojRNy5jfcEMk7trA785Ev568IPzA7p89qKyZoBHTjscvjfeMCoaXVz2uAv7 Zp2RwlVb3pyxibNO9NpHQaPF/XCs5U1KWOOwYeu1iAZGohYHUDuUSCyUr9slgRgb QeXyraQv2IcyqQ9ubJKatXlmqUXS4psxeWAMeUfWpZC3oBzBZUyd/Raim2DyJN5E gz0FpNP0/8MR88ngvJBUPYy3J6t6usInnuAAprGaXSPXu8IxbJMegntZfwIvnia4 pEAsJrqs7iPeIhSU3uqmbULRwipfx6uB1os4YHBrOJ4HrVBoSZW2dvrNKmJIrjTA G2bZEt41f6BPN+c5jsATDF3WE7Os2nbyJ3ac/4YCbm4eeWCEQ0T+UETHo1AZddrg AmI2 =6La7 -END PGP SIGNATURE-
Bug#1081344: ITP: rust-imap-client -- library to manage IMAP clients
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-imap-client Version : 0.1.4 Upstream Contact: soywod * URL : https://github.com/soywod/imap-client * License : Expat Programming Lang: Rust Description : library to manage IMAP clients imap-client is a Rust library to manage IMAP clients. This package is needed for himalaya (bug#1000161). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-imap-client>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgr34MHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEh1ucP/i9U9n0g1eLJknOxAJzVTXc/65WKrjwOUhsTSDZa mvprAvquvHfVNUVLqnIVpNPKdqXxACHwQ23fIcDLXhVX+x8cxBn1c9uid4AExCfd WzEgDOpHgl4I/6o1diNmBRe9OxuGlOl7hUFPq3Lb/vE8jTa1yxNejP1fIeTIGfC6 f8QhF1ozSNPj185DGZaY7LpJK2inCEtNWtJFJMZs1FTdU/yj2D56ZsFsDSkcXFMN o6/+Y2mxJ6HM7YymPho0jb2hKaG95huVgtD/nf5RySReGl969Tpg4r3CGk1GXS66 K3IMa4xXj4QQSHoshPj2QFkblvrflLIm4mspB0HuP85/fN5qKBxDFEa6IzHme8Vg FYUDOHwA8zmu0eot1PbVrTHHiocxxYiZ3+DjXWwE3n7N2jRLeof49hZ42JMUTc7B ayUZ6pFjyDqS3dgX0SBLTUnwVIG2WMXMGb0kPREBcEXUMcqKwSeZyEPSRX6SPWoQ bERa9t0OKhRuUjjtFbIYvHGgUgCmDP13FJ+5H706bLpfQ1CtYPhpXCfkQU/Jm2UM sWD6mrwsMIGCg1Lb/nxh5OW0af+8Dtz/rYcE1K2TamP5Yj9IAjtNorSRMz6BBKV4 SdEj3D6AYWebTg0UEtyN8OqmKxm2hKgk+mX4Ybul11/ulIu3sS2fACF3FjNOkKxU 7DRw =jvXa -END PGP SIGNATURE-
Bug#1081335: ITP: rust-imap-next -- thin abstraction over IMAP protocol flows
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-imap-next Version : 0.2.0 Upstream Contact: Damian Poddebniak * URL : https://github.com/duesee/imap-next * License : Apache-2.0 or Expat Programming Lang: Rust Description : thin abstraction over IMAP protocol flows imap-next is a thin sans I/O abstraction over IMAP's distinct protocol flows. These are literal handling, AUTHENTICATE, and IDLE. This package is needed for himalaya (bug#1000161). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-imap-next>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgn2AMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEh+OUP/2d0y1dphsLoq/rZB1hnPS4u7ZWk0bPhznP2ENXd PLm5w06FGytbXJL/TElHo8lkAosKLPOF0EbRxV+Z6jFbFmyJz+f/JRKbYDNEZSeB eCo27f09wiYmfutjJKhtP3Bm27s/pzN5z9V0eKkft1nAwptQgef2ENJDG/B4y+Vd TJMe+XhQYnBbYbBpnNthiywUGQ0/zKR2rKArKtjYctk2ZX2t6pA8tm6a5gmiwzGh nLWU2TOQarwAVXsaiHn/gP5KupZ6mFazYpjYjHs7pIVWIFkj5/n/6uOZukHTD08k r9U3PPuHvHYTi4u+PeoPco5gSeRzC3MrikiP6rrWVHzYeqwsj3Wpo84ico5wqtXY Z1sX/ofe6tatHd8+cWaDVUIjKH1hLpx9uIWaO8RyKZU5XFXrHghlx4kGDbYqE2No fDxc62CEz7M9og34HyUtlYgu3jQn0dVPtXgurCQxX1ea0tPT/TCUCbGFdvtzvoOP lmTQ3MuCGN1Lwv1unyj1a5xloZjIOOIeGmw2yZb+3WpJ72l1q4UZBR+h+dtZrg1/ ijWX2Witn/ADWnoVw/J+SPbOK8cQNlbkt4azHDykKNI+bsz+ciERkAtXlOYAy3/V 8io6VCBKyyOVnTC/zha9FHr5qB4Uc1j7PvfaVAVGYcPvJgtWvZ0rR6vFEDc/oTHi gCNw =0Rkq -END PGP SIGNATURE-
Bug#1081332: ITP: rust-smtp-proto -- SMTP protocol parser
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-smtp-proto Version : 0.1.5 Upstream Contact: Stalwart Labs * URL : https://github.com/stalwartlabs/smtp-proto * License : Apache-2.0 or Expat Programming Lang: Rust Description : SMTP protocol parser smtp-proto is a fast SMTP/LMTP parser for Rust that supports all registered SMTP service extensions. This package is needed for himalaya (bug#1000161). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-smtp-proto>- -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgm8kMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEh3QgP/1AMFQGoc+1uuIE6VNGST5yo3YLpKhRKDzHoV78L MNBhxvG1MVYQLWiEFZFTPUHt6qpdGVUa1SdiZIEsiU7542RnyMvO9zdpvGiBHR3R BOTupvsbeiytzekRHA/oUsdKwwklErzXf9MeaNGVgMuYD6QE9ihM73/+663JQTF7 R5w+vQ1ZLpmeZyuY6I21Sn2A0kdad0AQgwMStzq/WajY+n4kaxQOzdHmKRQq9Ni0 d0QJa38UAh3at7/pIHRbdvjGjzK2yzUlYwVTcnXXupRZ76FJTCtE8eAmenaSTbsZ xMiGrGqCg1f1/Bi9fYvn/Pbx7vlOhKh60ZQUazbt9Rc4cjarXs3+efltNhKE3VJH dynAyT7wT+NJUEnIwZx+zdpi9jHtHVfKYKyE+aHWzD4V9hGsWDtyEDCWl/xdvCPg YcuoT/346tgC6DFrs+5nVg6ydJeIqQZFpEEhFFK0nalZKo6EiCKi5dbaWSZSU6D1 YVEmwJ4YCNQKSCv5iiAWkr4UcjB7h14JJlB7CfWuD6S8DJKNtw0sVZTH7zjv0467 THEjdyz5HfJZAaPwgFDBYOtcdwsqwxyEqofURIWEoCMob/QTR+YOnFjzYTW064p1 HU1Y8jUyKtfs8qic05bEX2P0Nmg0onm70hfgu6Kuw23721gR2K6a2Gwne7zQ6uiR Lg2O =JlwT -END PGP SIGNATURE-
Bug#1081318: ITP: turtlefmt -- auto formatter for RDF Turtle
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: turtlefmt Version : 0.1.1 Upstream Contact: 2022 Helsing GmbH * URL : https://github.com/helsing-ai/turtlefmt * License : Apache-2.0 Programming Lang: Rust Description : auto formatter for RDF Turtle turtlefmt is an auto formatter for RDF Turtle. . For now, it... * validates that the file is valid * maintains consistent indentation and line jumps * normalises string and IRI escapes to reduce their number as much as possible * enforces the use of `"` instead of `'` in literals * uses literals short notation for booleans, integers, decimals and doubles when it keeps the lexical representation unchanged * uses `a` for `rdf:type` where possible . Resource Description Framework (RDF) is a standard model for data interchange on the Web. This package with be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/turtlefmt>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbgiY0MHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhYR4P/3KcRjPWSrCAozUkq96UOSxStreL2NB1rEOum0gD vpakDnelSPSnS85S4CevgozmzpcxSK6gcuauJof1WkBSeepBZA0Vf1xcqHQeZaa+ 5+YbN2KxfY3CcdOuXlh2+Ry8SpCpO5yiuyprsF0rzq4zgOjrJyABGXRW2Wl/CJAC qa7L0poB85aLOSwD31owyPkDmXkJXDZYvQR5KZXFBCmfyii/lScxOozH7+JDK9Sr Li84eok7T4rlKS1qGODcY+K5XxmUPUrULMi8AAbGdHfI9ZjIdzfBBcDaVU5BdslH oNpp0tyHrtMawgoLqvKXhz3fezHDrSBwihUgmgKUvWlBto2b9R+ETYYN4zKqIb20 2nt+RgT1xkpaqpBCuxJmyzrqZdJC9XwRdPAtP0zvle5I/UUpLMlb7oFNQeHaTysZ UbwfK24h9nEtoOaCfC9qQ7SShsUkX9HGVF7qs8I4am4qPZg6dpJT6z//qN5m4xP7 Ie1zZT3jf6smGBrLqDKSe4VoQHiaZ5ZvaJgs21upBv60pYl2n1AYm+yO3Ya2X0t6 pgrjoNsJgAaBvfxydCN34xHWHoDvTCE3dSlyQn0SjKhr5TuBPCZbsf51HrDymhU2 3t2WhlVLM/ZL9GH/vrh8ekuzhaHmoMVCY/f3kxKcvJ3i59y6fN9RjO4+0r4EToWu E2SG =8aZ/ -END PGP SIGNATURE-
Re: DEP5 and spdx shortname of license
Quoting Fabio Fantoni (2024-09-08 19:29:18) > licensecheck even if with "--shortname-scheme spdx,debian" seems show > some debian name where can show spdx instead, with only spdx is probably > good but i haven't tested it enough Interesting. Please file bugreports, one issue in detail in each bugreport (summarizing multiple ideas/issues is difficult to handle). Similar for the issues you've discovered with other tools. Thanks, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: DEP5 and spdx shortname of license
[CC'ing Fabio as they seemingly missed my earlier list-only reply] Quoting Fabio Fantoni (2024-09-07 23:57:35) > Il 07/09/2024 22:56, Aurélien COUDERC ha scritto: > > Le samedi 7 septembre 2024, 21:43:35 CEST Fabio Fantoni a écrit : > >> So I wonder, is it possible to put in d/copyright DEP5 the short license > >> names using the spdx ones? > > we’ve been doing that for KDE packages since upstream started tagging all > > source files with SPDX-License / SPDX-Copyright headers and so using SPDX > > license identifiers some years ago. See [1] for example. > > > > While not strictly adhering to DEP-5 I consider it useful to have a > > machine-readable-with-SPDX-identifiers and I’m not sure how useful it is to > > try and translate upstream-provided SPDX identifiers into something else. > > > > Our spec [2] already defines an equivalence rule between License-X and > > License-X.0 declarations for SPDX compatibility. > > For what I’ve seen on the quite vast and diverse KDE source corpus we’d > > only need 2 additional equivalence rules to be added to matches what that > > upstream ships : > > - equivalence between the + and -or-later suffixes (GPL-2+ / > > GPL-2.0-or-later) > > - equivalence between MIT and Expat. > > > > > > [1] > > https://salsa.debian.org/qt-kde-team/kde/plasma-workspace/-/blob/debian/experimental/debian/copyright > > [2] > > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name > > Thanks for the information, about tools that help to create and check > d/copyright are you experiencing problems? You might already be aware, but (also for others following along) an overview of tools is maintained here: https://wiki.debian.org/CopyrightReviewTools > I use a lot decopyand I found that there is this MR of 1 year ago not > merged: https://salsa.debian.org/debian/decopy/-/merge_requests/4 > > it would be useful even if it didn't have spdx generation by default but > at least as an option, I was wondering if there was something preventing > the use of the spdx name but from the current responses it does not appear. Licensecheck can use strictly SPDX shortnames like this: licensecheck --shortname-scheme spdx --check '.*' --recursive --deb-machine --lines 0 -- * ...or more relaxed use fallbacks for patterns without SPDX shortname: licensecheck --shortname-scheme spdx,debian,internal --check '.*' --recursive --deb-machine --lines 0 -- * If you want another output than the DEP5 file format implied by the option --deb-machine (e.g. one that includes hashes for each file, never shortening file lists with wildcards) then please file a bugreport against licensecheck and let's discuss that in detail there: https://www.debian.org/Bugs/Reporting > one more question, is there any tool/script to convert current > d/copyright to spdx names? See to tools at https://wiki.debian.org/CopyrightReviewTools and please update that list if you find additional tools helpful. Thanks for interest in copyright and licensing tracking, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: DEP5 and spdx shortname of license
Quoting Fabio Fantoni (2024-09-07 21:43:35) > Hi, spdx has an ever-increasing usage. Today trying reuse tool I tried > to convert DEP5 d/copyright to REUSE.toml thinking a possible help to > some project upstream, when license and copyright "management" is not > good, converting from d/copyright (DEP5) which is better, for example > with additional parts resulting from research done on files that were > taken from other projects but did not contain headers with license and > copyright. > > I noticed that even though reuse supports DEP5 the short license names > used by Debian (and partly by spdx but deprecated) were not supported. > > So I wonder, is it possible to put in d/copyright DEP5 the short license > names using the spdx ones? > > I supposeeven using them by default in the future could help the > contributors (especially the new ones)who already know and use spdx and > maybe it could help them to reduce the time of creation and management > of d/copyright files (unfortunately often long even using very useful > tools like decopy, licensecheck and lrc). What do you think? DEP5 already encourages (but does not require) use of SPDX shortnames, except where Debian and SPDX disagree on sensible naming. See https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#spdx and the historical notes at https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_and_SPDX Do you have ideas on how to address the documented differences in naming choices? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1081043: ITP: rust-notify-rust -- show desktop notifications
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-notify-rust Version : 4.11.1 Upstream Contact: Hendrik Sollich * URL : https://github.com/hoodie/notify-rust * License : Apache-2.0 or Expat Programming Lang: Rust Description : show desktop notifications notify-rust is a library for displaying desktop notifications. This package is needed for himalaya (bug#1000161), iamb (bug#1061425) and meli (bug#1001084). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-notify-rust>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbcYKQMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhrF8P/2mbk14tvxFhLiKYQgVL0apXxJvM3q9i7vCKNP2E UmIHGpqxAM5j8r+icXfNnIGucd6WazCKj/LTqDmg+LsTmtbH+BeapSJ+elgzW5zE IH0xMfXDm/YX7CZ11T/9FNWksXuwGoT1iqHDrablHN4XLVyOZNtK4LvT1b5hi4eu /cRE5DoF7mu+w6v3n4GhU8Ezum7eT1K5Kvd6QQf4E09PPP0lp/y1Pbco0Rxq4goE MbemdxHvZ1gZiLzo9LRqn4Z8S89TvlLZNWkymiaaWscYRmSX7KcHnK7e34eQC/PN sHU0LqKeGbugGlB5PHcPgW5hFWP4e9erOccMVmyWvNBzrt0vdMAv1sxoftlxpoxo ZXYUr51Hn/7zul37hfZ6rOMaWl7u8KW34/tbkm1Slng6jZs6LtypzpQsdZat7CyV n/v/qSW0SNgRWjM3Vu6+IeVa75zZfurtYmdIetvdISGr9KaI14ZsSnohFP6Zy16L 9G500fE92o4dnvGEID/vpuGJD/p5FPB0M8VJyWBA2qjysIQs4TXbGbYtSFmdIb7f WOtksjYSJoMJ9qrqsn3L6Ewxn8r9szZrJRvCJ0S/ZcD5zouWOECtyYmFjIrAIWkH ivsuaF7WiohxS65TsJGCgpZIR+FygBBlrLvvZi/gqOd2TAEupwICNR0AhjZbATUe YWeU =6E2/ -END PGP SIGNATURE-
Bug#1081036: ITP: rust-inquiry -- interactive prompts on terminals
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-inquiry Version : 0.6.2 Upstream Contact: Mikael Mello * URL : https://github.com/mikaelmello/inquire * License : Expat Programming Lang: Rust Description : interactive prompts on terminals inquire is a library for building interactive prompts on terminals. . It provides several different prompts in order to interactively ask the user for information via the CLI. With inquire, you can use: * Text to get text input from the user, with _built-in autocompletion support * Editor to get longer text inputs by opening a text editor for the user * DateSelect to get a date input from the user, selected via an _interactive calendar * Select to ask the user to select one option from a given list * MultiSelect to ask the user to select an arbitrary number of options from a given list * Confirm for simple yes/no confirmation prompts * CustomType for text prompts that you would like to parse to a custom type, such as numbers or UUIDs * Password for secretive text prompts This package is needed for himalaya (bug#1000161) and radicle (bug#1073266). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-inquire>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbcMOwMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEh7q8QAKmijrIoSe6K8hTDEJLzSef/oj+Bq5EglMPMr77N VCk/zlillfoX3h2AM2TwIzl0xrKzoD4jg2r6BOiv+/B9gLGaistA9eTNoA8z0pEt RD6pmKSVrJVIV/PB3tyLkA37me3JMXc5QiCR8KEO0MT9WxrrUoxV8e4TUwIOSy5N /1lcGXmT/FzJAFmA9JC3LXJdBXxBAhGb1TMoQ3zY7JjcxFfCjs3jDiSBAPjkHHX1 80SCottet6eSVB22YzdU9DuDAIbBT0BIVQUVeQ0FndbbJwwd2Icq9duoP7EwMNH6 np91e4uM8hiA2ENyR1tN/tTvsaUDKDHRbv2kw25BCoRnIv6mF4n2waMVUSqR0/E1 DBknGijTZxHSC7pQBnlvnZuK7dXQKag08I9TykimX/3EeRNBeWDnd4tB/perztQA bf8vL1Y6z/GYcuxiBvC49cElDgf++AVDfZI4l1QeWmgnTW72zttDX9WTY9gCKQLm ICGPbqtFoR9iguKqTVGIBenOZVe6Xj2kt2GIHQTb80Eo8oWVeEnVHIsw3PMl2i5X BHcbvmbPgqfhwFE4Qqtl2LpoQua9af+w+YZS5R4Q48G+ODJNUDPozX8l0jPJAs2C dGPfDkqoonQEeckK+Ttrk9hv3rfw9IstD03K3wwhTLLAwW5kqi+DjVY0J5/ktxYF IcYI =A3t+ -END PGP SIGNATURE-
Re: Why does Salsa use reCAPTCHA?
Hi Branden, and other fellow Debianites, Quoting G. Branden Robinson (2024-09-07 05:47:17) > On a less sarcastic note, I am taken aback by the fact that this > project can have a ~100 message thread proposing a DEP > > "Enable true open collaboration on all Debian packages" > > without either the proponents or the detractors finding the blatant > thumb on the scale in the proposal's very _title_ a cause for > embarrassment. Thank you for rehashing(!) this point, in your famously sharp tongue. In case you really didn't notice the previous objections to the title, and to others that might have missed it, here are some quotes: Quoting Jonas Smedegaard (2024-07-28 01:48:10) > Sorry, but I disagree that the only true collaboration is Salsa-rich > collaboration. Quoting Shengjing Zhu (2024-08-03 08:43:14) > I also feel uncomfortable with this proposal that pushes the use of > Gitlab in the name of true collaboration. Quoting Simon Richter (@sjr) (2024-08-04 07:14:07) > Simon Richter started a new discussion on web/deps/dep18.mdwn: > https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_512536 [...] > "true open source" is marketing drivel (as is most of this document). > > Please educate yourself on the political aspects of the free software > movement, and why the term "open source" has a negative connotation > for many. You might also understand why building on top of an overly > complex framework that requires non-transferable knowledge to operate > is not seen as desirable for many. Quoting Louis-Philippe Véronneau (@pollo) (2024-08-11 15:15:45) > Louis-Philippe Véronneau commented on a discussion on > web/deps/dep18.mdwn: > https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_514421 [...] > I'd propose to remove `which severely stifles the true open source > process from progressing` from that sentence. IMO it doesn't make the > point clearer and brings in additional controversy to this DEP. Quoting Simon Richter (@sjr) (2024-08-08 05:05:56) > Simon Richter commented on a discussion on web/deps/dep18.mdwn: > https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_513638 [...] > The argument against this DEP is that it doesn't take a step closer to > collaboration, it just claims that what we had before was not > collaboration. Which is frankly offensive to people collaborating long > before git was introduced. Quoting Jonas Smedegaard (2024-08-28 12:43:08) > Quoting Guido Günther (@agx) (2024-08-28 11:51:44) > > Guido Günther commented on a discussion on web/deps/dep18.mdwn: > https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_520426 [...] > > Or maybe put on the tin what's inside: > > > > "Encourage Continuous Integration and Merge Request based > > Collaboration for Debian packages" > > I like this suggestion a lot: I find it quite distracting that the > title implies other workflows to be "untrue", and this avoids such > distraction. Yeah, the second half of the above quotes are arguably not from *this* thread, as they appeared in the tightly related discussion spawned on Salsa. I I included them here out of respect for those considering the Salsa tooling more "true" than other collaboration, including this dusty old email conversation (who uses email nowadays anyway, right? Please stop using email: It is a dinosaur tool doscouraging new developers, so is slowly killing Debian!). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1081004: ITP: rust-async-fn-stream -- lightweight implementation of async-stream without macros
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-async-fn-stream Version : 0.2.2 Upstream Contact: Dmitrii Kalianov * URL : https://github.com/dmitryvk/async-fn-stream * License : Expat Programming Lang: Rust Description : lightweight implementation of async-stream without macros async-fn-stream is a version of async-stream without macros. This crate provides generic implementations of Stream trait. Stream is an asynchronous version of std::iter::Iterator. This package is needed for meli (bug#1001084). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-async-fn-stream>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbbMAgMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhDCUQAJKw/A5QwqLt1CAGizAXxhLpfFkMnCupsaljLYJt ZolaJiamKTtf6xVclpSVWP/hcG5e4PJrx//r//ORHURv10Gftm1RHyxTD7r4dy8D Oj3E4oE03HUtF/buWlHQfgc0nJvWpQG4ToWsaI8K2bCFnSO0zE/68UIhIvQPt5bz Fdg0Wk210WdhZ7/UzOIriSPtHGF796tWhCqClMY23lkNGiXHOmIfURIZChmI6qKP w4y+lgSDbCPm6nA/bQ6w2cyvoPQWg7gZKuatwCtyoZLb0s3SwMRUqxNoqNaADVDe p4869b8tZNUXTFussm2LWCrGHcQGWDF0Zg4/6qVFEVv0v9hq26vVjxxzcqwieWap vV8IE1OrorOj5gatE3Nck6B9qEwk6Z/jScyO8rqMseo1yeSdDSZ7n5L5oXRGGls4 CdPZ4FcIliQVHDBTp3jmH9ZVkOk845MpELzoSRGswaMM1OleS0xlXDMhalBXodUq MEQqVQ2xcfS5eH6ZsmHHw4Tly0MmRifdQGKu+qWOcjcXBDbrk21/WzaaMiEe5l7I XfSbZfXACC4uOXjskNaMQPxAC0c6oiICWm4JA/8nf9FxXfJ0cpKrvfQF5rhx9WlZ xGVsb30cFdsJz8zQ9ymoLJJIn8tI0KG/DlwqmWeh3Sk7gyhgvxfG3Pkmf6FX86tU 1nL3 =uOOZ -END PGP SIGNATURE-
Re: Community survey on network stack for Trixie
Quoting Marc Haber (2024-09-04 15:43:15) > On Wed, 4 Sep 2024 13:28:30 +0200, Daniel Baumann > wrote: > >On 9/3/24 18:24, Lukas Märdian wrote: > >> The nice thing about Netplan is that it [...] functions as a > >> layer on top. > > > >I don't understand what actual problem netplan is trying to solve. > > I am also missing that piece of information. At the moment, I see > netplan as an implementation of RFC 1925 Clause 6a, with a very > friendly and motivated upstream. When I feel evil, I'd say it's just > another Ubuntuism. > > That's not enough for me to consider Netplan. So I'm going to stay > with network manager on my mobile boxes that need Wi-Fi, and > systemd-networkd on everything else. For those using network manager only for wifi, there is also the option of iwd (+ iwgtk if you dislike the functionally fine but non-graphic builtin command-line tool iwctl) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi Blair, Quoting Blair Noctis (2024-09-04 04:33:10) > On 02/09/2024 06:38, Richard Lewis wrote: > > PICCA Frederic-Emmanuel > > writes: > > > >> What about dog fooding ? > >> > >> for now we can setup a schroot and sbuild very easily and start to build a > >> local repository in minutes. > >> > >> But when it comes to install gitlab and the CI system it is another story. > >> So we rely on the central salsa instance. > > > > fwiw, i dont think that a properly scoped DEP would change any of > > that. eg, it could be written to be only about what goes into the > > archive and not say anything about using schroot locally, or whether > > salsa is gitlab or something else. but maybe i misunderstand > > >> I do not know if I am clear but I have the fear that this > >> centralisation will make us forget that de-centralisation is sort of > >> "central" to the Debian way. > > > > I suspect that if the DEP was clearer in scope and aims, these concerns > > would not actually arise > > Debian infrastructure is "centralized" in many ways. The power to decide which > packages go in the archive and which do not is "centralized" in the FTP team, > and you must upload to a "centralized" machine for them to review. buildds > build > the public facing packages, debci runs migration reference tests, they are all > "centralized" on a few hosts and in a few people. Packages are distributed > from > a single source (mirrors don't have the say of the content). Even the very > list > you are posting to is hosted on a centralized machine. How would storing > packaging sources on a centralized code hosting instance be different than > package distribution? How would a centralized CI be different than buildds and > debci? > > The more important decentralization is in the decision process. Not everything > is fit for decentralization; don't push it only for the sake of it. > > GitLab isn't perfect, sure, but it's an implementation detail of having a > centralized code hosting and CI. I'd personally expect the CI to be basically > the same as debci (maybe even merge the two or make salsa delegate CI to > debci), > but that's another topic. Yes, some parts of Debian are centralized, but it seems you turn those into reasons for giving up on the flexibility of others which are not. I have worked in areas with weak internet connection (near the Amazonas jungle in Peru, and at the country side of Sweden) where I could have a full mirror of Debian and an archive of email conversations, and from that not only release package updates but also work on developing Debian Pure Blends (i.e. "forks" of Debian containing purely Debian parts), with only occational need to syncronize my data with Debian. I don't say that Debian must work for jungle developers, nor that we must all use email and not different forms of collaboration requiring better connectivity. My point is that Debian *allows* collaboration also without heavy realtime connectivity that most of us take for granted in our working environments, and I fail to see why the few points that are centralized is a reason for giving up on all the others as well. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing
Quoting Jonathan Kamens (2024-09-02 17:52:42) > On 9/2/24 11:47 AM, Colin Watson wrote: > > On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote: > >> I was suggesting that perhaps the root cause of /why/ the .deb files are > >> not > >> identical is because if there's no timestamp in the trailer line of the top > >> changelog entry, that impacts the contents of the .deb. > > IMO your debian/changelog should be syntactically well-formed (per > > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog) > > even when you haven't finalized it. The exact value of the timestamp > > isn't very important (you can let "dch" pick something when you first > > add something to the unreleased changelog, and "dch -r" will update it > > when you're ready to make an upload), but it should be present. Leaving > > it empty isn't the usual practice among other developers as far as I've > > seen, and it's just making trouble for yourself. > > I leave it empty exactly because the build scripts complain when I do > that, so that I'll remember to finalize it with the correct date before > I put out a release. The common thing to do to hint that a package is not yet ready for release is to set the distribution to UNRELEASED - which dch handles nicely. (this post is for those reading along that are interested in common practices of Debian developers - if you just wanna do as you've always done then simply ignore this post as it was not written for you). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1080003: ITP: tree-sitter-sdml -- sdml grammar for the tree-sitter parser
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: tree-sitter-sdml Version : 0.3.2 Upstream Contact: Simon Johnston * URL : https://github.com/sdm-lang/tree-sitter-sdml * License : Apache-2.0 Programming Lang: Rust, C, Python, JavaScript, Golang, Swift Description : sdml grammar for the tree-sitter parser tree-sitter-sdml is a tree-sitter grammar for SDML. . Tree-sitter is a parser generator and incremental parsing library. . The Simple Domain Modeling Language (SDML) is a small data-oriented language for constructing, documenting, and reasoning about a conceptual domain model. This package is required for sdml (bug#1064145). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/tree-sitter-sdml>. -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbQWZgMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhgsYP/0Kk20g1ouRzrgeO1dW8oWYfgql1AfuNk8mTr7pm mFXAkz2RmABJJYgcg38AFxZtGNw527KjkkUlqbV8YGmAoPb+MnAFMFBbBG26m7BK IfEqkYX/dAsxh1QlbZ8aXypRhhyzg+9di2+buhCuuoQNvW0B7QJXSBv890czngto wY2JesygZPnLusDq0SmB7Lyuk7A1qpExaiO9hJLhBkrWX0FiExgMZUjSdFNiCeL3 v7RJN95xk07hXoMURwmCeGxObb79XQw3IXOyutFCclemOWxbqD7onYUDLALwjhnK AHTw8uOrQAs6v6bdL7swz8l8Wne35EA+6q82ejiG4ctRxLdP/D8omtri/sKwvGd4 cCTYB/0qhSfCtUEY6FsOmVp+wGBG8J1P6zMyIZxik56WnHSXCJA7tYy4KmLFHzAB 7pgS8JF3ENeieY8AUu7YEEkefg8wBP4DqKOQj2KD0o3CFweW+fiP2GOjoUTjEpO9 iIVwnNFjvjaBzin6K8UOHmJNYMmKUx7r/98V/JrG/h8Co08gB0xhPcjFOn5tuHFb EGwgt+eR92XoPFPr1YijPbBkR3LQ4OClfA2rprskqA0b0PklQj8C2crnNmyvDxi7 P21zq2pmNldy3Bdsr/MrGoL2OpS17JQnvE9+shuPGhWOt2aYjRBlFagB+391Sdzs bg/H =RVKb -END PGP SIGNATURE-
Bug#1079754: ITP: scaphandre -- electric power/energy consumption monitoring agent
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: scaphandre Version : 1.0.0 Upstream Contact: Benoit Petit * URL : https://github.com/hubblo-org/scaphandre * License : Apache-2.0 Programming Lang: Rust Description : electric power/energy consumption monitoring agent Scaphandre is a metrology agent dedicated to electric power and energy consumption metrics. The goal of the project is to permit to any company or individual to measure the power consumption of its tech services and get this data in a convenient form, sending it through any monitoring or data analysis toolchain. This package will be maintained in the collaborative Debian section of Salsa, at https://salsa.debian.org/debian/scaphandre -BEGIN PGP SIGNATURE- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmbNfU8MHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhEF8P/3jp6H08YoVinTpSJHnvZlbY63kInz03pnfnJxFY ItPvop1G8GPBrA7TwLl0hhfid1Xa3+A25lYAAnbFYuqXNkG2MKn9aRyDK1nfUiUa iWhZ/JDFO4Oazuayt6H5tL2f/Foiol5qV7ia1fp4scrYIkAMNYjjhprlN4hUJfMw m2xUh7KmUKDVjThuk1Lzc870sL4z9u/PU7a9lfbzu4SSBaVxkzcmwRUmsrhOXpfl gDO8oWmeT8RX+88iIUFpIsAqD5AaYZ48RcxFRQEuXTwG5DWACHm+UdXqP7HT/pRD oqfdA9qdAJ8pht94YVi5Z07ucaHrbd1fLEiiBU2VaS5fK29GnUHSxnI4ngLM5I/M cuKhOftl06tXH2spgh1rZFlC9oFsnUZU9j7FvA3XlWPcc8W6atZPddRJ9wYI337T gMkiRu67KxM7gY+J8sXX05aXhJMWjJLJHW6RBPLfW/3wVTdBBKsnYZEu5XlWes4U EvnrZL5gp1Zzm4wmHRqsV7v0E8Sjlg9gGYVpLyFISWRL9AkXsBwOmYDj6vC/x6cv FLESUq9Psk/Msj45IGx27Gwv/jZrnF2SkZLJCY+qWIxcfs90+JRCV/soDTqKT2EH dRPHrUYAXHc+KDCOIrxZeDkaOyQmOw6D+D7PXNAULW8Ssoh7JMOqB/GMt5cBE6wi nQcz =X8ld -END PGP SIGNATURE-
Re: Re: Accepting DEP14?
Quoting Chris Hofstaedtler (2024-08-17 22:45:59) > > > Additionally, in my opinion debian/latest is a mistake we should > > > not recommend. > > > > Please elaborate why you consider it a mistake. That's not obvious > > to me. > > "latest" is illnamed. Thanks for that (small) elaboration. > What do you expect to find in a branch thats called debian/latest? > > Packaging for unstable? For experimental? What if both evolve in > parallel? Yes, some packages do that. I expect that the latest *long-term* changes to reside in debian/latest, whereas debian/unstable and debian/experimental I expect to contain short-lived deviations. Just as is described in DEP-14. I find that sensible: Sometimes I temporarily push my long-term work to experimental, and keep the git branch name. Except then maybe, while that long-term work is still settling (maybe testsuite fails, or maybe it is waiting for NEW queue approval) a need arise for a quick fix targeted unstable, in which case I branch off as debian/unstable temporararily. Other times I make an experiment, i.e. something that I don't expect will last, in which case I right away branch off as debian/experimental. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Accepting DEP14?
Quoting Fabio Fantoni (2024-08-17 11:20:01) > Il 17/08/2024 10:47, Jonas Smedegaard ha scritto: > > Hi Chris, > > > > Quoting Chris Hofstaedtler (2024-08-17 10:17:19) > >> On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: > >>> IMO, and from discussions in the Debian Perl Group, the blocker is > >>> the conversion of existing repos, both on salsa (which should be > >>> doable via the API as suggested in the sketches mentioned above) and > >>> also locally for hundreds of developer machines [git fails horribly > >>> on the upstream/ → upstream/latest change]. > >> I want to echo this pain. When changing the layout it seems almost > >> better to start from scratch. > > I have in the past found it confusing how to handle it, but now I find > > it tolerable (and don't recognize the "better to start from scratch" > > judgement), after I figured out (as also hinted at in one of the links > > by gregor) that you need to do the following, in that order: > > > > 1. unlock branch "upstream" on salsa > > 2. rename branch "upstream" → "upstream/latest" on salsa (or delete it) > > rename branch in salsa would be very handy, i searched for it when i > converted some repositories but i didn't find it, can you tell me how to > do it please? I cannot (I sloppily drop the branch and the republish a moment later), but please see the links mentioned by Gregor. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Accepting DEP14?
Hi Chris, Quoting Chris Hofstaedtler (2024-08-17 10:17:19) > On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: > > IMO, and from discussions in the Debian Perl Group, the blocker is > > the conversion of existing repos, both on salsa (which should be > > doable via the API as suggested in the sketches mentioned above) and > > also locally for hundreds of developer machines [git fails horribly > > on the upstream/ → upstream/latest change]. > > I want to echo this pain. When changing the layout it seems almost > better to start from scratch. I have in the past found it confusing how to handle it, but now I find it tolerable (and don't recognize the "better to start from scratch" judgement), after I figured out (as also hinted at in one of the links by gregor) that you need to do the following, in that order: 1. unlock branch "upstream" on salsa 2. rename branch "upstream" → "upstream/latest" on salsa (or delete it) 3. rename branch "upstream" → "upstream/latest" locally 4. push local changes to salsa (strictly speaking you can do step 3 before 1-2) > Additionally, in my opinion debian/latest is a mistake we should not > recommend. Please elaborate why you consider it a mistake. That's not obvious to me. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Accepting DEP14?
Hi Andrej, Quoting Andrej Shadura (2024-08-17 10:19:57) > A couple of years ago I was thinking about implementing DEP-14 support > in gbp, [...] Please note that you are posting to the d-devel thread about DEP-14 in general, not the debbugs issue about DEP-14 support in git-buildpackage. I suggest that you repost the above to 829...@bugs.debian.org, so that those particularly interested in that issue (now and in the future) can easier locate your fine contribution to solving it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Accepting DEP14?
Please stop cross-posting to both bugtracker and d-devel. Quoting Andreas Tille (2024-08-15 11:15:33) > considering that it makes sense to settle with DEP14[1] first before we > can decide about DEP18 I wonder what is finally needed to accept DEP14. > I think its cruxial to make git-buildpackage supporting DEP14 per > default[3] but I'm somehow sensing some hen-egg problem here what to do > first. If DEP14 might be accepted the motivation to fix bug #829444 > would be probably way higher. I fail to see this as a chicken-egg problem: DEP14 do not depend on git-buildpackage supporting DEP14 with zero configuration. Quoting Andreas Tille (2024-08-16 11:44:38) > I prefer having no debian/gbp.conf at all in case the repository > layout would fit team policy. I understand that it would be lovely if git-buildpackage supported DEP14 without you needing to touch a thousand packages. But do you really put on your DPL hat and raise that wishlist bug to a matter for d-devel to debate and try solve? Please do consider the simpler approach here: Step one: Discuss on d-devel if DEP14 can be accepted as-is. Step two: Discuss in bugreports how various tools might be improved for as exciting a user experience with DEP14 as sensible for each tool. Personally, I think DEP14 is usable as is, and look forward to have it formally be declared done. I do not, however, understand the details of the DEP procedures well, however, so look forward to feedback from others beter understanding those details. ...but not details on git-buildpackage: Details on the formal DEP procedures - unless those really are super intertwined. Until someone knowledgable on DEP procedures explains how that necessitates solving specific tooling issues as well, please pretty please discuss tooling details, like git-buildpackage migration handling and/or default settings, at the appropriate bugreports *without* cross-posting to d-devel. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Fabio Fantoni (2024-08-03 16:45:24) > Il 03/08/2024 15:59, Jonas Smedegaard ha scritto: > > Quoting Fabio Fantoni (2024-08-03 15:39:00) > >> Il 03/08/2024 14:40, Kentaro Hayashi ha scritto: > >>> Hi, > >>> > >>> Even though +1 for DEP-18 basically, I think that it might be better > >>> to add an option > >>> to formalize package owner's (single person maintainer) collaboration > >>> policy > >>> especially about non-team maintained packages under > >>> https://salsa.debian.org/debian/. > >>> > >>> If such a package repository enables merge request feature, then I > >>> will send merge request and > >>> send E-mail to bugs.d.o about url of the MR to notify it. > >>> But it is not true that such MR is merged in timely manner. > >>> (Surely collaboration takes longer time, I know.) > >>> > >>> If the package owner expresses a collaboration policy in advance, it > >>> can improve such a situation > >>> in a particular case and we can respect it. > >>> > >>> NOTE: The following idea might be out-of-scope in DEP-18, but specific > >>> use-case to improve > >>> collaboration in Debian, IMHO. > >>> > >>> Here is just an idea: put collaboration policy metadata in debian/control. > >>> (The following idea assumes that non-maintainer DD tend to hesitate to > >>> commit/merge it) > >>> > >>> * Collaboration-Policy: debian/CONTRIBUTION.md > >>> Yes, we have README.source already, but it might be better to note > >>> in a separate file about collaboration. > >>> * Collaboration-Policy-Commit: yes > >>> It declares that the package owner encourages non-maintainer DD to > >>> commit directly without merge request. > >>> * Collaboration-Policy-Merge: yes > >>> It declares that the package owner encourages non-maintainer DD to > >>> allow merge requests. > >>> (DD has maintainer right in salsa.d.o by default as you know, but > >>> you can merge without worry if there is it.) > >>> * Collaboration-Policy-LowThresholdNmu: yes > >>> It declares that LowThresholdNmu rule [1] is applied. > >>> * Collabollation-Policy-NMU-Delay: 15 > >>> It declares that NMU delay the package owner wants. > >>> > >>> [1] https://wiki.debian.org/LowThresholdNmu > >>> > >>> Pros: > >>> * DD/DM and contributors can respect the package owner's intent about > >>> the package collaboration. > >>> * Reduce a chance to cause inconsistency between the content of each > >>> package repository on salsa.d.o and NMU'ed package source. > >>> * Because other DD (non package owner) can commit/merge, then ship > >>> NMU package. > >>> Cons: > >>> * Maintainers will be bothered to add that new field to every package > >>> (If there is no Collaboration-Policy, it is safe that sending merge > >>> request and let it the package manager, thus nothing changed) > >>> * No mechanism to enforce Collaboration-Policy-Commit: no or > >>> Collaboration-Policy-Merge: no policy > >>> because DD has maintainer rights on salsa.d.o and can commit/merge > >>> it in reality. > >>> > >>> It might worry too much, but it might be able to block an unfortunate > >>> accident, a so-called package hijack > >>> with incomplete communication in some cases. > >> Hi, this I think is can be useful (beyond the example use of > >> salsa/debian packages which is not necessary as replied by Tobias > >> Frost), I think will be better with only one additional (and optional) > >> field in d/control, like Collaboration-Policy that point a file or url, > >> this I think that can decrease the possible annoyance and in the case of > >> teams or even single maintainers having a single policy file to point to > >> and update in a simpler and faster way (especially if there were the > >> same policies for dozens of packages or more, there could be also > >> hundreds or thousands) > > What annoyance are you referring to? > annoyance maintainers for update it on many package, with a url that > point to an external file can be update once for even on tens, hundreds > or more packages it could be set on > > > > Are some new contributors annoyed by the lack of formalized rul
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Fabio Fantoni (2024-08-03 15:39:00) > Il 03/08/2024 14:40, Kentaro Hayashi ha scritto: > > Hi, > > > > Even though +1 for DEP-18 basically, I think that it might be better > > to add an option > > to formalize package owner's (single person maintainer) collaboration policy > > especially about non-team maintained packages under > > https://salsa.debian.org/debian/. > > > > If such a package repository enables merge request feature, then I > > will send merge request and > > send E-mail to bugs.d.o about url of the MR to notify it. > > But it is not true that such MR is merged in timely manner. > > (Surely collaboration takes longer time, I know.) > > > > If the package owner expresses a collaboration policy in advance, it > > can improve such a situation > > in a particular case and we can respect it. > > > > NOTE: The following idea might be out-of-scope in DEP-18, but specific > > use-case to improve > > collaboration in Debian, IMHO. > > > > Here is just an idea: put collaboration policy metadata in debian/control. > > (The following idea assumes that non-maintainer DD tend to hesitate to > > commit/merge it) > > > > * Collaboration-Policy: debian/CONTRIBUTION.md > >Yes, we have README.source already, but it might be better to note > > in a separate file about collaboration. > > * Collaboration-Policy-Commit: yes > >It declares that the package owner encourages non-maintainer DD to > > commit directly without merge request. > > * Collaboration-Policy-Merge: yes > >It declares that the package owner encourages non-maintainer DD to > > allow merge requests. > >(DD has maintainer right in salsa.d.o by default as you know, but > > you can merge without worry if there is it.) > > * Collaboration-Policy-LowThresholdNmu: yes > >It declares that LowThresholdNmu rule [1] is applied. > > * Collabollation-Policy-NMU-Delay: 15 > >It declares that NMU delay the package owner wants. > > > > [1] https://wiki.debian.org/LowThresholdNmu > > > > Pros: > > * DD/DM and contributors can respect the package owner's intent about > > the package collaboration. > > * Reduce a chance to cause inconsistency between the content of each > > package repository on salsa.d.o and NMU'ed package source. > >* Because other DD (non package owner) can commit/merge, then ship > > NMU package. > > Cons: > > * Maintainers will be bothered to add that new field to every package > >(If there is no Collaboration-Policy, it is safe that sending merge > > request and let it the package manager, thus nothing changed) > > * No mechanism to enforce Collaboration-Policy-Commit: no or > > Collaboration-Policy-Merge: no policy > >because DD has maintainer rights on salsa.d.o and can commit/merge > > it in reality. > > > > It might worry too much, but it might be able to block an unfortunate > > accident, a so-called package hijack > > with incomplete communication in some cases. > > Hi, this I think is can be useful (beyond the example use of > salsa/debian packages which is not necessary as replied by Tobias > Frost), I think will be better with only one additional (and optional) > field in d/control, like Collaboration-Policy that point a file or url, > this I think that can decrease the possible annoyance and in the case of > teams or even single maintainers having a single policy file to point to > and update in a simpler and faster way (especially if there were the > same policies for dozens of packages or more, there could be also > hundreds or thousands) What annoyance are you referring to? Are some new contributors annoyed by the lack of formalized rules for collaboration? Are some maintainers annoyed by how some new contributors initiate collaborative contributions? As a maintainer, I can imagine getting annoyed by *non-collaborative* contributions done in ways that I feel leaves an extra burden on me. One description for that is "drive-by contributions", meaning that someone contributes without having the time to *collaborate* on it, to align the contribution with how the package is maintained. But since this whole thread is about "true open collaboration", I assume that you are talking about *collaborative* work, and then I cannot recognize what is the kind of annoyance you are referring to. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Kentaro Hayashi (2024-08-03 14:40:51) > Hi, > > Even though +1 for DEP-18 basically, I think that it might be better > to add an option > to formalize package owner's (single person maintainer) collaboration policy > especially about non-team maintained packages under > https://salsa.debian.org/debian/. > > If such a package repository enables merge request feature, then I > will send merge request and > send E-mail to bugs.d.o about url of the MR to notify it. > But it is not true that such MR is merged in timely manner. > (Surely collaboration takes longer time, I know.) > > If the package owner expresses a collaboration policy in advance, it > can improve such a situation > in a particular case and we can respect it. > > NOTE: The following idea might be out-of-scope in DEP-18, but specific > use-case to improve > collaboration in Debian, IMHO. > > Here is just an idea: put collaboration policy metadata in debian/control. > (The following idea assumes that non-maintainer DD tend to hesitate to > commit/merge it) > > * Collaboration-Policy: debian/CONTRIBUTION.md > Yes, we have README.source already, but it might be better to note > in a separate file about collaboration. > * Collaboration-Policy-Commit: yes > It declares that the package owner encourages non-maintainer DD to > commit directly without merge request. > * Collaboration-Policy-Merge: yes > It declares that the package owner encourages non-maintainer DD to > allow merge requests. > (DD has maintainer right in salsa.d.o by default as you know, but > you can merge without worry if there is it.) > * Collaboration-Policy-LowThresholdNmu: yes > It declares that LowThresholdNmu rule [1] is applied. > * Collabollation-Policy-NMU-Delay: 15 > It declares that NMU delay the package owner wants. > > [1] https://wiki.debian.org/LowThresholdNmu > > Pros: > * DD/DM and contributors can respect the package owner's intent about > the package collaboration. > * Reduce a chance to cause inconsistency between the content of each > package repository on salsa.d.o and NMU'ed package source. > * Because other DD (non package owner) can commit/merge, then ship > NMU package. > Cons: > * Maintainers will be bothered to add that new field to every package > (If there is no Collaboration-Policy, it is safe that sending merge > request and let it the package manager, thus nothing changed) > * No mechanism to enforce Collaboration-Policy-Commit: no or > Collaboration-Policy-Merge: no policy > because DD has maintainer rights on salsa.d.o and can commit/merge > it in reality. > > It might worry too much, but it might be able to block an unfortunate > accident, a so-called package hijack > with incomplete communication in some cases. What is the core purpose of adding these suggested new metadata fields? An NMU is non-collaborative - it is a non-maintainer that not only offers a contribution but bypasses maintainers and issues a release with the contribution integrated. It makes sense for me that we have ways for maintainers to communicate ahead of time, how NMUs are acceptable, because NMUs lack collaboration. I was under the impression that collaboration was, well, collaborative. That it was about collaboration between contributors and maintainers. Am I mistaken, and it is instead about collaboration between contributors and non-maintainer mentors, which potentially ends in an NMU? If not - if it is collaboration with maintainers - then I don't understand the need for signalling ahead of time how maintainers prefer to work, as contributors can simply ask the maintainer. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Otto Kekäläinen (2024-08-03 06:38:38) > > I am not suggesting salsa use because I think it's the best thing since the > > invention of sliced bread. But personally, I rather use something > > suboptimal if > > it means that we can more or less agree on a "default" and I think that the > > current situation (submission of patches by mail and the debian archive is > > the > > bts) is deterring to newcomers. I know that most people probably have faster > > machines than I. As it was pointed out elsewhere in this thread, Debian > > work > > already implies a lot more waiting than "a few seconds" for salsa to finish > > loading a page or finish yet another animation, so meh. With the glab tool I > > think I can be happy enough. > > This I think summarizes well the opinion of most people I have spoken > with. GitLab is not perfect, but it was chosen and we have been using > it for 5+ years mostly successfully. Most packages are there and we > should state that it is the recommended option. Currently the second > most popular option is to use GitHub, or not use any vcs at all. > > A lot of this thread has gone into people expressing their dislike for > Salsa. Most people still use Salsa - I guess the silent mass isn't > chiming in in this thread that much now. Some people probably have > very optimized email workflows, and nobody can argue against the > statement that a pure email workflow for sure is simple, and has its > elegance. But it also has shortcomings such as no lack of > metadata/status, no built-in way to run CI and share the code+logs+CI > results etc. > > Following the principles 1 (use git) and 2 (use Salsa) allows for the > next principles 3, 4 and 5 to take place. I would be curious to hear > more views about them. > > DEP-18 summary (https://salsa.debian.org/dep-team/deps/-/merge_requests/8): > 1. Have package source code in version control, using git > 2. Host package source on Debian's code forge Salsa > 3. Run Salsa CI at least once before every upload to ensure minimal > level of quality > 4. Allow Merge Requests to be submitted > 5. Allow changes to be reviewed before uploads to Debian > > My plan is to summarize the discussion and update the proposal in the > coming days, incorporating as many views as possible. I will also in > the next update include additional relevant context info such as > tag2upload, glab and examples of how to easily work with both Debian > bug tracker and MRs in parallel. > > Please share your views, and also +1 or -1 the proposal on Salsa so we > can incorporate that too in measuring the support of this. > > Remember that DEPs are soft rules - unlike General Resolutions (GRs) - > and maintainers who have specific reasons to not want to use git or > Salsa will not be forced to do so. My problem with DEP-18 is that people who have zero problem with using git and are also not fundamentally against using salsa, but have reservations surrounding *which parts* of salsa to use and the consequences for related already used tooling. I am also not against being welcoming to newcomers, but I am concerned if the focus on tose unreasonably reshapes the tooling for all of us. Essentially, my concern is that DEP-18 reduces a spectrum of options to "either you are for or against true collaboration". Leaning more on Gitlab is not the "true" choice, but the pragmatic one, because yes, we have invested in it, and some parts of it might be made to better use for use. I imagine that some in the silent crowd hesitate to chime in due to that lumping together the use of git and the use of Gitlab into an all-or-nothing choice. I think you intended that reduction, for the purpose of simplifying the conversation. I don't think that simplification is helpfull, however. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Fabio Fantoni (2024-08-02 23:51:26) > Il 02/08/2024 15:49, Jonas Smedegaard ha scritto: > >> I think that both email and systems like salsa/github/gitlab etc. are > >> useful, both with pros and cons. Forcing people to use only one or the > >> other could be counterproductive at the moment. One thing that I think > >> would be useful is to have certain, fast and simple information for each > >> package about which actual collaboration methods it uses and prefers. > >> > >> For example seeing a package it would be very useful to know immediately > >> if it wants a collaboration only through bugtracker and patch, only > >> through vcs or both are accepted. If managed in a team point more easily > >> to information about the team and any pages with details (for example on > >> wiki). > > I guess that you mean something like this: > > ```patch > > --- a/debian/control > > +++ b/debian/control > > @@ -60,6 +60,7 @@ Standards-Version: 4.7.0 > > Homepage: https://github.com/oxigraph/oxigraph > > Vcs-Git: https://salsa.debian.org/debian/oxigraph.git > > Vcs-Browser: https://salsa.debian.org/debian/oxigraph > > +Contact: https://bugs.debian.org/oxigraph > > Rules-Requires-Root: no > > > > Package: oxigraph > > ``` > > > > In principle I find that an interesting suggestion, as I can imagine > > such information being helpful in understanding if debbugs is used only > > by "dinosaurs". > > > > I see two problems, however: > > > > a) Maintainers will be bothered to add that new field to every package > > (or at least a substantial subset) for it to be of practical use. > > > > b) Which other answers exist for that field? I mean, is it ok in Debian > > for a maintainer to not use Debbugs? Is it ok in Debian for a > > maintainer to also use another issue tracker and not replicate whatever > > is collected elsewhere in Debbugs? > > > > Or perhaps I am missing the point of your suggestion, and you do not > > mean where *bug* chatter goes, but instead where *non-bug* conversations > > go. If that is the case, then I believe we have a field already for > > that, called "Maintainer:". If you mean neither issue tracking nor the > > main contact information for a package, then please elaborate what you > > had in mind, because that's pretty essential to get clarified before > > discussing any further... > > > contact field don't exist now right? even if the contact field maybe > doesn't give you an idea, maybe something like "contributing" that links > to the bugtracker, to the repository MR/PR or a wiki page or site with > any details (especially in case of a group) Yes, the contact field exists: https://www.debian.org/doc/debian-policy/ch-controlfields.html#maintainer > maybe I'm not good at explaining myself, I think the problem is that if > a contributor, maybe even new or who wants to make even occasional > contributions on specific packages is not able to find in a simple and > fast way about the package on which he wants to contribute as he should > (or is better to do), in some cases you can understand in short time by > looking a bit at the bugtracker and the vcs while, looking for any wiki > pages if he is part of a team but in many cases it is not simple/fast to > understand how he should contribute for that package in order to get the > best result. using patches on bugtracker or vcs (like salsa) is just one > part, then there could be more > > you could say to force everyone to use the same system, in theory it > would solve the problem, but in practice I find it difficult and perhaps > more harmful. I try to summarize: the contributors are people and not > machines, moreover many do it as a passion in a little free time and not > as if it were a job. We all do it as a passion in little free time and not if it were a job. Also Maintainers. What is the point of introducing additional ways to interact with maintainers than the ones that already exist and (as I understand it) is mandatory: A general contact *email* address, and tied to that a connection to the *Debbugs* issue tracker. If a new contributor is unable to contact a package maintainer through that main contact address, then I am concerned about their ability to help out. Don't get me wrong, I do understand how some people can be excellent coders or testers or translators without ever using email, but how can those who are fluent in Gitlab but unable to send and receive emails avoid being a burden in their offers for help to a software distribution which at its very core is email-bas
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi Fabio, Quoting Fabio Fantoni (2024-08-02 14:31:04) > One particular thing noticed in some cases (and I hope they are not > many) is the lack of use or especially updates of the Vcs-* fields in > d/control. I think is important point to packaging repository from the > tracker if present and to update it if moved, this can help > collaboration and reduce possible waste of time doing things that are > perhaps already done by others (or WIP) but which have not yet been > uploaded. That's tracked as OLD key at https://qa.debian.org/cgi-bin/vcswatch - also included in the Maintainer Dashboard for each package at https://udd.debian.org/dmd.cgi Whenever you stumble upon a package misaligned with its declared Vcs metadata, please file a bugreport, and while doing so consider encouraging the maintainer to use the Maintainer Dashboard. > I think that both email and systems like salsa/github/gitlab etc. are > useful, both with pros and cons. Forcing people to use only one or the > other could be counterproductive at the moment. One thing that I think > would be useful is to have certain, fast and simple information for each > package about which actual collaboration methods it uses and prefers. > > For example seeing a package it would be very useful to know immediately > if it wants a collaboration only through bugtracker and patch, only > through vcs or both are accepted. If managed in a team point more easily > to information about the team and any pages with details (for example on > wiki). I guess that you mean something like this: ```patch --- a/debian/control +++ b/debian/control @@ -60,6 +60,7 @@ Standards-Version: 4.7.0 Homepage: https://github.com/oxigraph/oxigraph Vcs-Git: https://salsa.debian.org/debian/oxigraph.git Vcs-Browser: https://salsa.debian.org/debian/oxigraph +Contact: https://bugs.debian.org/oxigraph Rules-Requires-Root: no Package: oxigraph ``` In principle I find that an interesting suggestion, as I can imagine such information being helpful in understanding if debbugs is used only by "dinosaurs". I see two problems, however: a) Maintainers will be bothered to add that new field to every package (or at least a substantial subset) for it to be of practical use. b) Which other answers exist for that field? I mean, is it ok in Debian for a maintainer to not use Debbugs? Is it ok in Debian for a maintainer to also use another issue tracker and not replicate whatever is collected elsewhere in Debbugs? Or perhaps I am missing the point of your suggestion, and you do not mean where *bug* chatter goes, but instead where *non-bug* conversations go. If that is the case, then I believe we have a field already for that, called "Maintainer:". If you mean neither issue tracking nor the main contact information for a package, then please elaborate what you had in mind, because that's pretty essential to get clarified before discussing any further... > Another thing that seems underestimated and I think it is good to > emphasize is the excessive slowness of the wiki.debian.org, it seems > much worse than salsa to me, and I think it's important to solve. I don't think that the speed of wiki affects the use of Salsa. Please stick to the topic - i.e. if you want to shift to another topic then do so explicitly by changing the Subject: line in your email post. > If someone thinks that these speed/reachabilityare not important because > they are used to even longer times for many operations, for example > regarding the bugtracker, tracker, upload etc., unfortunately we live in > an increasingly frenetic and continuously worsening world (this world > causes more and more stress and less and less time available). If you mean psychological stress, then I find your reasoning flawed, as that is about a *perceived* lack of time (or other pressure), not necessarily actual lack of it. Possibly but not necessarily. If you mean stress on the Earth, then I find it highly unlikely that we can solve that crisis by speeding things up. Instead we need to find ways to *reduce* the *amount* of computing we do, and find ways to time that computing in ways that fit more optimally with the availability of needed resources (e.g. consume less electricity when there is less wind and sunny, to reduce stress on green parts of related electricity grid). Please elaborate what kind of stress you are really talking about, and again please consider the topic of the conversation (see above about changing Subject: line). Thanks for your inspiring input, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Salvo Tomaselli (2024-08-02 00:38:15) > > saying out loud phrases such as "The only right way to > > collaborate is reading and writing emails is in my terminal" > > Please. This feels like trolling. > > You're literally making up a quote and then you reply to it. > > Nobody said that. This is not useful. > > Also, there's IRC/matrix for more real time communication, but I challenge > you > to follow those long threads on d-devel on something like teams or slack. Please, let's focus on the topic of this conversation: Are conversations like this (modulo insults¹) not considered a part of "true open collaboration", or are they reasonably and sensibly possible to conduct through Gitlab notification/issue/code comment/MR comment channels, instead of this "dinosaur¹ channel" /whatever - i.e. the communication channels part of the "true open collaboration" on topic here, instead of the "dinosaur open collaboration" practiced through this very mailinglist. - Jonas ¹ If I understand you correctly, Luca, you do not consider the term "dinosaur" an insult. I do find it insulting, but perhaps I simply misunderstand and I should not translate it to "obsolete", but I don't have the energy to even have a conversation about that so just dump my refelctions in this footnote less inviting for further conversation. In retrospect, I realize that my use of the term "old farts" might be seen as an insult as well: I found it funny to use that because it chimed with my references to "smelly" usage patterns, and I thought it safe to use because I was myself included in the subset of Debian members that I was referring to - if anyone found it insulting then I am interested in (not debating, but) understanding that better: Please then consider sharing why you found it insulting, perhaps through an intermediary if (like me, se abov) you don't have (or want to waste) the energy in facing me for providing me the criticism. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Debian works fine with each of us using whatever UI we prefer, but moving to a web-centric UI we need to agree on a universal UI. Essentially I don't like the Gitlab UI. Maybe the majority of Debian are ok with the UI of Gitlab, but if it is sane for UI choice to be decided democratically, then why not have a vote on editor choice as well? and while at it, let's vote on KDE vs. GNOME (and not even waste time on snowflakes like Sway or Xfce). That would be a different community than the Debian I like to collaborate within. ...and I *do* mean "collaborate", not "cooperate". I do want collaboration, even if my too many packages can be seen as a "smell" that personally I have failed at collaborating. Yes, collaboration is likely ensured with a platform like Gitlab, but no, mono-cultural collaboration is not the only form of collaboration, and I find it a problematic one. > Also, I can see that you are already following principles 1 and 2 of > the proposal by having almost all of your packages in git and on > salsa.debian.org. As the DEP-18 draft text says, strict enforcement is > not a wise tactic in the context of fostering collaboration, and I > would not expect you to move away from what you are doing now, as it > works for you and benefits Debian with 650+ packages. In your case > following the principles 3, 4 and 5 would probably not be appropriate > in cost vs benefit. For example running Salsa CI or asking for code > reviews prior to upload would probably just slow things down too much > without the gain in your case. If you mean to say that my current contributions to Debian comply with DEP-18, then I am surprised, and I think the text need a heavy rewrite. In its current form, I would expect the next revision of codesmells to have me smelling badly of non-collaborative. You may find my ways of contributing to Debian perfectly fine, but I have a hard time not seeing this draft formalisation of what constitutes good collaborative manners in Debian as a strong tool for pressuring those collaborating differently into "getting in line" - conforming. Conforming on choice of editor is, I think, a repulsive thought to most if not all of us in Debian, but e.g. from a sustainability PoV I find it quite harmless compared to conforming on collaboration as web-based, as opposed to decentral and offline-first. > However, I would still argue that DEP-18 would be useful as a general > guideline in Debian and in particular for team maintained packages and > important packages (as discussed in the "end single maintainership > thread"). Having such principles published would help maintainers (at > least new maintainers) to align on a set of basic principles that help > drive more collaborative development. I agree that DEP-18 represent "principles that help drive more collaborative development", but I disagree that they are "basic", since 3 of 5 principles are strongly tied to a specific UI. Yes, that UI allows multiple workflows, and DEP-18 sensibly steers clear of promoting a specific workflow. But implicitly the text discrouages e.g. decentral and offline-first workflows that I find important. Thanks a lot for all the time you put into this. Despite my strong opinion, I do see the value of pushing this agenda, and of exploring the boundaries of the forge we have currently invested in using. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Jonas Smedegaard (2024-07-28 01:48:10) > Hi Otto, > > Quoting Otto Kekäläinen (2024-07-28 00:38:40) > > Hi all, > > > > I have drafted a new DEP at > > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > > Enable true open collaboration on all Debian packages". > > > > Direct link to raw text: > > https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn > > > > This would have been a great topic to discuss in person at DebConf, but > > unfortunately I can't attend this year, so I'll just kick this off on the > > mailing list. I think it is great that you started a conversation here on our d-devel mailinglist: Not all of Debian is at Debconf. Also great if those at Debconf discuss this topic there - and then share valuable points at those conversations here at the larger forum of Debian as a whole. Speaking of multiple conversation platforms: I received a followup to my previou post here on this mailinglist, posted through one of those multiple Salsa conversation spots. I received that followup post by email, but when I replied, my reply was rejected for being from a wrong email address. @Otto: You should have received a copy of my reply. Please consider reposting that forked conversation here on the mailinglist, to help keep the conversation going - not splintering it by shifting platform mid-way through the conversation. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi Otto, Quoting Otto Kekäläinen (2024-07-28 00:38:40) > Hi all, > > I have drafted a new DEP at > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > Enable true open collaboration on all Debian packages". > > Direct link to raw text: > https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn > > This would have been a great topic to discuss in person at DebConf, but > unfortunately I can't attend this year, so I'll just kick this off on the > mailing list. > > This is continuation to the 'single maintainership' discussions earlier > this year. I also think that more unified and open collaboration processes > could help decrease maintainer burnout, lower barrier for existing and new > maintainers to help with multiple packages, and overall perhaps also > improve quality of uploads by having more attention on the source code > prior to upload. > > If you think this proposal makes sense, please press the thumbs up button. > > If you have comments, please share them here or on the draft itself. I like how Debian discussions are email-based. It means less work depends on being online. I can read conversations without worrying about tolls on network activities, and can search my private archive of historical conversations however I want to set that up (e.g. using notmuch). DEP-18 mandates (or more accurately it "should-ifies") web-based conversations. Not for bugs, specifically, but for other conversations where I consider Debbugs and mailinglists as reasonable alternatives. (yes, I understand that some disagree with me, and find email clumsy and Salsa web interfaces far better). In section 4, we "should" enable discussion and review of merge requests as web-based Salsa conversations, which means those conversations will not happen on mailinglists or in Debbugs. That section also says that there is no pressure on the maintainer to engage in those conversations, it is all about letting others contribute, but it is in the best case confusing for contributors if their contributions are ignored, and more likely that is perceived as quite rude behaviour of the maintainer. To not accidentally come across as rude, I have consistently enabled only the ability to *fork* but disabled all other more "chatty" features because while I *do* want "true collaboration", I dislike the web-based conversation platform offered as part of Salsa, and unfortunately Salsa cannot be told to redirect to anywhere else, so the best I can do to signal "I am not hanging out here, please look for me elsewhere" is to turn those features off. Sorry, but I disagree that the only true collaboration is Salsa-rich collaboration. Where are my options to mirror the data at Salsa, as I can do with mailinglists and Debbugs, to work with it also offline? Regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code
Hi Sylvestre, Quoting Sylvestre Ledru (2024-07-12 11:13:23) > Le 12/07/2024 à 10:35, Jonas Smedegaard a écrit : >> Quoting Birger Schacht (2024-07-12 08:17:12) >>> On 7/11/24 9:55 PM, Jonas Smedegaard wrote: >>>> Quoting Philipp Kern (2024-07-11 21:13:42) >>>>> I'd - at the very least - would like to see a statement why a fork >>>>> is necessary. Innovation can happen in forks. But they don't >>>>> necessarily need to be in the archive to make a point. >>>> dh-cargo is designed to repackage prepackaged code projects already >>>> distributed through crates.io. If you do an NMU where you include >>>> the preferred form for distribution, you are kindly asked to stop >>>> doing NMUs because that messes with how the Rust team deliberately >>>> avoids tracking the actual source for the code projects >>>> distributed. >>>> >>>> I listed in the ITP a list of features lacking in dh-cargo, which I >>>> need for packaging Rust-based code projects in Debian from >>>> preferred form for distribution source. I do not need all of the >>>> features for all of them, but some of them sometimes. >>> This still does not answer the question why a fork is the better >>> option instead of working with the people behind dh-cargo to >>> integrate those features into the codebase? >> I have tried but failed to work closely with the Rust team. It was a >> painful experience, and I would prefer not to elaborate in public. >> >> I nowadays work only loosely with the Rust team: To the extend that >> they use the Debian bugtracker, we coordinate our packaging efforts >> there, and my patches for their tooling have been publicly available >> for the past two years, where I have maintained it structured so as >> to be easy for them to cherry-pick back into dh-cargo/cargo as much >> as they might find relevant, at the cost of my use of it being >> cumbersome, and the code not really inviting for more innovative >> changes. >I didn't know that you were making patches easy to be cherry-picked. >I would have tried otherwise >> The Rust team has chosen to not cherry-pick any of my patches into >> their tooling. I have not strongly pushed for that, and expect >> strong pushback if I tried: > > I would be happy to take all your patches that makes sense. Sounds promising. A starting point is the last paragraph of this email (which was directly targeted your email address, btw): lists.debian.org/171260770946.146326.6707604887885287...@auryn.jones.dk - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code
Hi Birger, Quoting Birger Schacht (2024-07-12 08:17:12) > On 7/11/24 9:55 PM, Jonas Smedegaard wrote: > > Quoting Philipp Kern (2024-07-11 21:13:42) > > >> I'd - at the very least - would like to see a statement why a fork is > >> necessary. Innovation can happen in forks. But they don't necessarily > >> need to be in the archive to make a point. > > > > dh-cargo is designed to repackage prepackaged code projects already > > distributed through crates.io. If you do an NMU where you include the > > preferred form for distribution, you are kindly asked to stop doing > > NMUs because that messes with how the Rust team deliberately avoids > > tracking the actual source for the code projects distributed. > > > > I listed in the ITP a list of features lacking in dh-cargo, which I need > > for packaging Rust-based code projects in Debian from preferred form for > > distribution source. I do not need all of the features for all of them, > > but some of them sometimes. > > This still does not answer the question why a fork is the better option > instead of working with the people behind dh-cargo to integrate those > features into the codebase? I have tried but failed to work closely with the Rust team. It was a painful experience, and I would prefer not to elaborate in public. I nowadays work only loosely with the Rust team: To the extend that they use the Debian bugtracker, we coordinate our packaging efforts there, and my patches for their tooling have been publicly available for the past two years, where I have maintained it structured so as to be easy for them to cherry-pick back into dh-cargo/cargo as much as they might find relevant, at the cost of my use of it being cumbersome, and the code not really inviting for more innovative changes. The Rust team has chosen to not cherry-pick any of my patches into their tooling. I have not strongly pushed for that, and expect strong pushback if I tried: The added functionality relates to ideologically conflicting views on what is the source of a Rust project and what is really the purpose of Debian. As an example, Rust team tooling includes debian/patches in the binary package as part of a design principle to mimick crates.io code distribution as closely as possible. Another example is that Rust team tooling can only treat a single crate located in the root as source, not a crate in a subdirectory or multiple crates in what is called a "workspace" in Cargo lingo, again because crates.io always redistributes code as single crates, regardless of how the code was developed, i.e. the preferred form for upstream development. After two years of not trying to convince the Rust team that their ideology is flawed, but practicing another approach to Rust packaging, depmonstrating that e.g. multi-crate workspaces are possible to treat as Debian source for multiple Debian binary packages, and offering publicly my patches easily adoptable if they wanted to, I have shifted to make my patches into a proper fork of their tooling, making it much easier for the little team now working on it to maintain and develop further, including tracking bugs in it which was close to impossible for the past two years of it being copied into each and every Debian package needing it. The cost of this shift is that the codebase is no longer as easy to merge back into the Rust team tooling - not because we want to steal from them or punish them, but just as a side-effect of this shift. Hope that clarifies. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code
Quoting Philipp Kern (2024-07-11 21:13:42)
> On 11.07.24 18:06, Jonas Smedegaard wrote:
> > * Package name: dh-rust
> >Version : 0.0.1
> >Upstream Contact: build-common team
> >
> > * URL : https://salsa.debian.org/build-common-team/dh-rust
>
> This ("build-common") reminded me of cdbs. Can we not have another
> schism and actually work together?
Sorry, what?
How is "build-common" or CDBS incompatible with "work together"?
Licensecheck use build-common for upstream development, does that make
licensecheck incompatible with "work together" as well, or where is that
fine line that I seemingly have crossed by my choice of contact address?
> cdbs also got orphaned but its legacy not cleaned up. I still count
> 1.6k reverse build-depends in unstable.
Yes, CDBS introduced the idea of common packaging "sequences", but the
idea was implemented inelegantly using purely the same language as
debian/rules (yes, make is a programming language). Then debhelper
(which at the time was a collection of independent helper tools) adopted
the idea and expanded to include the dh sequencer, implemented elegantly
in another language. Elegantly not so much because of the choice of
language, but more because the user interface did not require messing
with the language at all, and for a community where lots of developers
care more about other languages than make and perl (despite having to
touch both of them occationally), there was much rejoice, and history
was rewritten to CDBS being incompatible with "work together" even
though it really was the inspiration for the marvellous dh sequencer.
As for the 1.6k package still using CDBS, I believe I am to blame for
only a dozen of those. For most of them please go yell at the Haskell
team rather than me.
> I'd - at the very least - would like to see a statement why a fork is
> necessary. Innovation can happen in forks. But they don't necessarily
> need to be in the archive to make a point.
dh-cargo is designed to repackage prepackaged code projects already
distributed through crates.io. If you do an NMU where you include the
preferred form for distribution, you are kindly asked to stop doing
NMUs because that messes with how the Rust team deliberately avoids
tracking the actual source for the code projects distributed.
I listed in the ITP a list of features lacking in dh-cargo, which I need
for packaging Rust-based code projects in Debian from preferred form for
distribution source. I do not need all of the features for all of them,
but some of them sometimes.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code
Hi Nilesh, Quoting Nilesh Patra (2024-07-11 19:57:56) > On Thu, Jul 11, 2024 at 06:06:21PM +0200, Jonas Smedegaard wrote: > > * Package name: dh-rust > > I would be happy if this makes it to the archive, though. Would be > easier to have a dh for rust which would be specifically useful to > build packages that are not just crates, but instead use multiple > language including but not limited to rust. Indeed. We are not familiar with many non-cargo-centric Rust projects, but know that they exist. Personally I am aware of only Mozilla projects and one project using Cargo-in-meson. Please (when/if accepted into Debian) file wishlist bugreports this package for concrete examples of interesting Rust projects that might benefit from non-cargo-centric packaging debhelper tooling, then we can discuss if reasonable to extend this package to cover them. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org, build-common team -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: dh-rust Version : 0.0.1 Upstream Contact: build-common team * URL : https://salsa.debian.org/build-common-team/dh-rust * License : GPL-3+ Programming Lang: Perl Description : debhelper buildsystem for Rust code dh-rust provides a debhelper buildsystem to build Rust code. . This builds and tests binaries and libraries from rust crates, the latter installed as source code below /usr/share/cargo/registry. . Feature highlights, compared to dh-cargo: * supports workspace (i.e. multi-crate project) * allows overriding CARGO_HOME * installs crate contents using "cargo package" * can use debian/Cargo.lock or Cargo.lock during build * uses crates below debian/vendorlibs when available * builds in make target dh_auto_build (not dh_auto_test) -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaQAvoACgkQLHwxRsGg ASEvTQ//W+YQjP71QIGyP3bgs2Sow8pSRga9BkbY7vjGNGGih9FPGFxDmG18dSV0 JcLHuksh+kjHxoDoFpufOLcNTBPf3AQG6O6VuySxt7cG9L27w1a7jxKBXvKtDAtW 7ZBEi/fySLj5PyHYyZWY2fLmhEzBMmuNcY/l1wBklktF5Jkc7mwYSaqI/3mMxeeE pa6btQuW3Mdf3SyZEc05eriNIi9A6wBTy0Yc+m7oU2QGo+2ckXy3hOcN2SjQR5OM /h3NydY+bXP8V9Sz/wJ0qhep89Mh/CvEcKeNyw1BbKCHr1e+4UQ8WzEsWSq9c1+c f8woy3KNbtt1JXpCaJcM2I+PBOIaZ0HupV4IzQYevbpSawgnLY5AsGruJgAHiERj GVdBrykEj2YHfhw6clqJVTxx2sVYifLgOu5RiM4dGsBwMf0DpuqWXh3HeXnS6Z81 2xj0PTA5t38bQsqLW0JU1IOvzR4m/40SDMpTWo3FjWpc263QmjFMRXSVaUha8qQs fV9WhL0jTjvNbrUxRM7jKaPyioGXk+RjXQtCJwAG5moJxDVVQD65oQy6Z0q+yZqF xq9HLaqrC6At2rTyUxCVK5IDavMYXAL+IB7rkJ6ahG7ThDh8cPuSC5+0Ss2f65tB QtAqmxKPvjr0uLUeMQAvMLWagKKVP39gmtLL7o5LH8OFhZ2DDIM= =oOzs -END PGP SIGNATURE-
Re: WolfSSL and Netatalk
Quoting Daniel Markstedt (2024-07-01 12:04:03) > On the licensing situation, so my understanding now is that *some* > permissive licenses can coexist with GPLv2 licensed code, such as > BSD-*, MIT, LGPL* etc. > However, SSLeay explicitly forbids redistribution under GPL, while GPL > explicitly says the entire software package has be distributed under > the GPL. > Does this sound about right? Almost: It is GPL that forbids anti-freedoms in the SSLeay license. Free software licensing is all about freeing software from the slavery the monopoly-minded laws called "copyright". GPL contains wording to ensure that its promised freedoms are not hampered e.g. by additional licensing terms introducing through linked code: GPL will terminate, if combined with lesser free terms. Some perceive GPL as being a "viral" license due to this mechanism: GPL cannot be "watered down"; The combinatorial result of mixing licensing terms must be at least as free as GPL. Confusingly, OpenSSL v3 do not use the OpenSSL license, so reusing SSLeay-licensed code is legally different from linking with OpenSSL: https://www.gnu.org/licenses/license-list.en.html#OpenSSL > FWIW, I naively thought it was sufficient to retain the original licensing > blurb for each source file, and independently adhere to the licensing terms > for each. > But I see now how one license can impose its terms on other source files in > the same distribution... > > Anyhow, let's work towards a broader solution in the upstream issue ticket > that you raised. Yes, let's discuss those details upstream :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: WolfSSL and Netatalk
Quoting Daniel Markstedt (2024-06-23 07:58:54) > On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz > wrote: > > > A few days ago, we released Netatalk 3.2.0 which comes bundled > > > with a customized subset of WolfSSL as SSL provider. > > > However, when I spoke to a Debian developer last year about this > > > very topic, they told me that using WolfSSL for packaged software > > > in Debian required some kind of special exemption and approval. [...] > > (I didn't check for licence compabilites and such things, guess > > you've done that already). > > > > All of the original WolfSSL codebase is GPLv2 licensed, which is the > same license that Netatalk uses. > However, a handful of source files (five of them to exact) are > licensed under the traditional SSLeay license. > They constitute key parts of the OpenSSL compatibility layer... Problem *is* licensing, not of WolfSSL but of the "handful of source files" recently added to Netatalk: I looked at one of those files you recently introduced, include/atalk/cast.h, and it contains the following note just below (or arguably part of) the SSLeay license text: > The licence and distribution terms for any publically available > version or derivative of this code cannot be changed. i.e. this code > cannot simply be copied and put under another distribution licence > [including the GNU Public Licence.] Since Netatalk is licensed under GPL-2+, it is perfectly legal¹ for the Netatalk project to include the above file as part of its source, and for the Debian project to provide prebuilt shared libraries involving such source files as input as long as it does not link with code licensed under GPL licenses, but anyone (other than the Netatalk project itself, who is not bound by its own license²) violates the GPL-2+ licensing terms if linking with that file, so effectively your project is not Free software when making use of those files, and Debian cannot distribute (in main) a build of Netatalk making use of that code. I have reported this upstream to the Netatalk project as well: https://github.com/Netatalk/netatalk/issues/1185 - Jonas ¹ I am not a lawyer. Take my words here only as inspiration. ² But beware: It is everyone holding copyright in the Netatalk project that needs to agree on distributing binaries under different terms, not only its current developers. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1073786: ITP: rdfsx -- CLI tool to process RDF with ShEx, SHACL or DCTAP
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rdfsx Version : 0.0.12 Upstream Contact: Jose Emilio Labra Gayo * URL : https://www.weso.es/shapes-rs/ * License : Apache-2,0 or Expat Programming Lang: Rust Description : CLI tool to process RDF with ShEx, SHACL or DCTAP rdfsx is a command-line tool to inspect and validate RDF data using ShEx, SHACL or DCTAP. . Resource Description Framework (RDF) is a standard model for data interchange on the Web. . Shape Expressions (ShEx) is a data modelling language for defining schemas for RDF graphs. . Shapes Constraint Language (SHACL) is a data modelling language for describing constraints for RDF graphs. SHACL is a W3C standard. . Dublin Core Tabular Application Profiles (DCTAP) is a simple model for defining an application profile - i.e. metadata usage for a specific application. This package will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rdfsx>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZxYn4ACgkQLHwxRsGg ASH7Bw/7BsNSIMe6UnlhdHd0eFUZp32Zkw1RpKY0LD2HPEUDnMGHoq+kZyNbLAwL /QnY3rXhVHhfmiZw6xSB7sPbMr52nwNLn8oonfGonyeRoBU88/x75juob7fjh40Z 00bVoFy3G3GGqCV7TVHxxSCkpjs6D8onilNU3ICRHeCx0jkbzUCNtssC0zc58h75 WFtFP9Wa4IAyMDUcBm1ey07YInA9J94PjmhVscWhQ8fCLxtfiRZZU1Bkf9OZhZsT d9DRYSQSZQVnW/2J8vOh4iBDrQxdkZAqpDsLTg1wyHxyuAswfRk/tChoPp1R1swv a8xF3NGx+YzOAyBTvpHg0j17syiw4E1B0Yjj3m/HaEfMJW9jEVY+mDyzN14UWv3f nWT/XYUPXLcIkwe4aHyRt5t3Zuv2AJ/u5QyiPG8oleY0LC8b3Y5SrEgd12epjw9/ nLVKeNwQDguYUsogCqx70B/ew/arYsvhuZY1Jg6t2BWj49mqTxLz7fuPKyShkrvi mI9oHvaLyPGRrJCt8PwKaRzNtNhaOXzyWYd8OBCUqJcKP0tR5OdCJUPz6KAGa1ap tOrmV8Vbd6OMSkopMAjG0651XTSXQl9iyZb08nBxno7U4Fv3LPlMGIinge9gp/ed HvNfdLVpp8fl3G0XQ0KbdHYSyP/sjatdTUhythSA1Tax39iPpWY= =xwcY -END PGP SIGNATURE-
Bug#1073266: ITP: radicle -- P2P code platform Radicle
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: radicle Version : 1.0.0-rc.10 Upstream Contact: The Radicle Foundation * URL : https://radicle.xyz/ * License : Apache-2.0 or Expat Programming Lang: Rust Description : P2P code platform Radicle Radicle is a peer-to-peer code collaboration stack built on Git. Unlike centralized code hosting platforms, there is no single entity controlling the network. Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow. This package will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/radicle>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZtlEAACgkQLHwxRsGg ASE6EA/+LIeTy4mWdvagmxCF5wRe4D6ST5ZGM3Ukt2lkUMQqVc4au6ZmwZ+SLeCs gbLi9PhAVtm71uOuwwEIFXJhFQuBY5V8Gh8Y8Zciw/b8WIpK5MbH3dzorStP257u w4XUT9D+R2Cz9Vyg5491SpcAZBopFG0j6tnmuLk3yJjyzT0LHkGqUj2wKcwck1TE QTeiCnBvyd04YWQivnRmeAnus9bHYD0jaHk/TuUyleVFnSv2YzDjNckkQIH0seLc K5lyGQgdwfTcKGJ5cgNl/mvsXBWk0s4Ki03ZtyWyrZ8vKE8rHIo5yjd4jWS4f0KE jsQtzZIsPpvglx8ITvrIMt/qp1fUmbnwfmX/hGyN+Zp7O2Wj+pw0UGKfLveeP2gi HztWF70qizYEGaJMlOZRS5zfcIo32BEkNdb/hB5IS8PAgbYaqi7KtR41l78sexD7 LY7vGlL1BImSmbvmPqdzefUmh5QQ/sHMtEYsndEDHEf0q7ALBcKR4DcqQcTJg3L1 wJZif8DqWHdZcrzyOvOYQG4qWbAUNHI6RdNncHen4xYCB9euomsbooZ5xt4C4tap +Uabza6p0ju+lwmz6W+rGvkW8yAdg8YQXn23zpYtbNtY8tyecgiYGPYKJofoFmcH roqG4cd8sLZ2n9Fjt56MvKJZRRPpfAqUmC0VdLHNpPU5WlnCUwg= =saAk -END PGP SIGNATURE-
Bug#1073123: ITP: nanopub -- CLI tool to sign nanopublications
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: nanopub Version : 0.1.4 Upstream Contact: Vincent Emonet * URL : https://vemonet.github.io/nanopub-rs * License : Expat Programming Lang: Rust Description : CLI tool to sign nanopublications Nanopub is a command-line tool to check, sign, and publish nanopublications. . A nanopublication is a small knowledge graph snippet with metadata that is treated as an independent (scientific) publication. This package will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/nanopub>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZqh3IACgkQLHwxRsGg ASGjNg/9HA6SEj2WTanU6QLCaIma0dgzqpzxpRgLhgfXT7KodGo50itDrR7BWl96 SpKcsX56W2f1/Wp+tQKpKRjK7TTpzflPuQm8rnl0z3Y7PcPsKXbARhXXLXv+XXAZ ZAq86T966y1RFGykNJdCs6/iKXGO1qlYhfdst+S/vptxg7EpBWV1wtccaRJ4KoPr V1yG7o1PNmhYCaJyNkWoBTOh+UqWn+ys1VLgRX9LiGN8vUVpuLXYmTRSTUPSe/IE WanQva6YK07KmIZZG67Vu6eTmWfhhY/LczIINkR+tDK4pR/qGlKfJoZWwM1bPYl8 mGEm+Rwpte7T18wu6qk/YT3umRQQQR025vKnNiVZZXp8YwgBC0Slz+YfSnSHBqHN YkMBOQnGkwoUBHW/9gzaY+iGdWpGzS8COavhA4dbAAphqV323RdxPDLj3PKsH9ly 4t1n/7kkpZPurWgbwRM7WuHqufs0KmMWl+0ClG6w6TJHF2iOHsh7T0Q5Q++ZOwUE J52mGgQy2UawTntRKJ6RrNoUIgZari7IX9Nz5T1KJdfIjCPRsvj2iK0L2KsybI7R 2mFyQjKGnMEfMxQVsVslCe9Ih+GFttQFpkwaaAsT/o551mAwlAcHjoj/sZCCac5d WGQt4hWkVAl8EXSz6LWuriTxU7a/RaSeOUenTSTybLif3Rumrlg= =9WsE -END PGP SIGNATURE-
Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED
Quoting Shengjing Zhu (2024-05-16 12:14:57)
> On Thu, May 16, 2024 at 4:35 PM Jonas Smedegaard wrote:
> >
> > Hi FTP-masters (cc d-devel list),
> >
> > A package, that I had initially introduced to Debian some months ago and
> > had been pending in NEW queue since, was rejected few days ago, like
> > this:
> >
> > Quoting Debian FTP Masters (2024-05-14 12:00:12)
> > >
> > > An exception was raised while processing the package:
> > > Traceback (most recent call last):
> > > File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 121,
> > > in wrapper
> > > function(upload, srcqueue, comments, transaction)
> > > File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 248,
> > > in comment_accept
> > > transaction.copy_binary(
> > > File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 390, in
> > > copy_binary
> > > self._ensure_extra_source_exists(filename, db_source, archive,
> > > extra_archives=extra_archives)
> > > File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 214, in
> > > _ensure_extra_source_exists
> > > raise ArchiveException('{0}: Built-Using refers to package {1} (=
> > > {2}) not in target archive {3}.'.format(filename, source.source,
> > > source.version, archive.archive_name))
> > > daklib.archive.ArchiveException:
> > > p/pandoc-filter-diagram/pandoc-filter-diagram_0.2.1-1_amd64.deb:
> > > Built-Using refers to package rust-ahash (= 0.8.9-2) not in target
> > > archive ftp-master.
> >
> > I it correct to derive from the above, that packages in NEW queue must
> > be freshly built, and that I (and we, generally) therefore should
> > routinely rebuild packages pending in NEW queue to ensure that they are
> > acceptably?
>
> Not a ftp-master, but if you see such a message, it means that your
> package has already been accepted, and you can continue uploading
> without going through the NEW queue again.
Thanks, Shengjing Zhu - you are right, althought the concrete *release*
of the package was rejected, the package was nonetheless approved.
Confusing. I learned something new that day.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#1071475: ITP: rdf2rml -- visual graph modelling using RDF semantic graph notation
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rdf2rml Version : 0~20240410 Upstream Contact: Vladimir Alexiev (valexiev) * URL : https://github.com/VladimirAlexiev/rdf2rml * License : GPL-1+ or Artistic Programming Lang: Perl Description : visual graph modelling using RDF semantic graph notation The rdf2rml provides two command-line tools: . * rdf2rml - convert RDF example to R2RML script * rdfpuml - convert RDF to PlantUML diagram . rdfpuml makes true diagrams directly from Turtle examples using PlantUML and GraphViz. . rdf2rml generates R2RML transformations from examples, which saves about 15x in complexity and ensures compliance of the actual conversion to the model. Typically the example is an rdfpuml model. . Diagram readability is of prime concern. . Resource Description Framework (RDF) is a standard model for data interchange on the Web. This package will be maintained in the collaborative Debian section of salsa, at <https://salsa.debian.org/debian/rdf2rml/>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZKdg4ACgkQLHwxRsGg ASGRoxAAkM4Be1fiF/YTCdkF9EomWdprqRPFp17neSS2We/QNZNtXn8SHJfqCP0D CHe63ZJo0dQPpVxOmsklLM02qffC5hwKTZaBj7HpBk0rW2aylb+a1ragJV6/dkkS T4oJRKpbokEH9+toXaSbl1ghi1GRmMfcFG1IpKyZzf36V3qUS/1lMddQ1r/ZEbJm vMgAyNVkq/pYsew/IvkAYDSiIzBAPqhAO9/ZbNZbHsWErKMtrym4QulnZwmZTdex b09B3JbuxCJoa/sk9AM99evS+2jrwRMOpe54pAOXQtMqLIhmgfxk8UmOiLtMI6vO W2gtHKo1lZn8Ogsms6d4xKNMfIHz3ZfBf1gOhbt/Ayn6dXH00SphztdhQQnKncKq AcD4GQm4CMU5vb9VKdAKRXwPj2tCVrCqjaJJOEbANBqDOp9g6x9vJ1mxvTnIFx0V XAChweqiaB1xTMk+lSFamcZDtVpeaJAImWy17ikDZtBvrrRCl0FVRn/2TqSFYHYz 6EWvMxfph9As2Jzr4XR4lXOi0DH67ToktexQrDsbopVPppqgkxcJ+FHvBskOMQXp PMc5Yo3gDMFxupDwXULaaF4XO0wq2sLZp8xzY8cgK6H+yTuwIlyXD+DBsvz2AAHF RxrI8035RdVfi9puCXHVuy1+9vEvSHeoLTTW/Cb2+FcRW+O1Yl4= =pXRE -END PGP SIGNATURE-
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Otto Kekäläinen (2024-05-19 21:32:36) > > > My concern about Gitlab is not its *additions* to existing services, but > > > its *duplications* of core services already in Debian. > > > > I agree, that's the key problem. > > I agree that duplication is bad - but I disagree that use of version > control duplicates the use of the Debian archive for source code > storage, or that use of GitLab for code reviews would duplicate > Debbugs. > > > > ...instead of lumping all those discussions into a discussion of ease of > > > user interface for a single catch-all code forge that maybe make all those > > > other complications go away by affecting all those questions and that way > > > implicitly provides *some* answer to them all. > > > > Also, there is a difference between ease of use and intuitivity. GitLab > > does not provide any tools that really make packaging easier. It is > > initially more accessible to non-maintainers, because of familiarity, > > but actual work happens outside of it. > > Would you be kind and try to understand the opposing viewpoint by > trying it for one day? > > You could go to > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and > conduct a code review? > > You might discover that GitLab is useful and is not duplicating > Debbugs or anything else in Debian - it is currently the only platform > to conduct code reviews on in a way that has automatic testing and > comment-response-resolved -tracking. Doing code reviews patches > attached in email does not have that. > > If you try it out, and still think Salsa is bad for Debian, then I am > more willing to accept your stanze. But it *is* duplicating Debbugs: None of your valuable contributions posted as part of your code review appears on Debbugs. The developers of FreedomBox (which is a Debian Pure Blend, i.e. a project fully within Debian) has embraced Salsa, and when I asked about an issue with network instability for certain hardware, I was told that it was in the issue tracker - which meant it was missing from Debbugs while actively discussed in Salsa. Salsa is *great* if you fully embrace it. Salsa is not good if you want single features without fully embracing it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Mathias Behrle (2024-05-19 11:08:58) > * Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re: > finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 > +0200): > > > > i.e. you are being > > asocial if you don't, and can expect your behavior being discussed as a > > public-wide issue for the project). > > I very much agree with all what you say, however could we rather say instead > > -> i.e. you are not being collaborator friendly, and can expect your behavior > be > frowned upon... > > I am not a native english speaker, I think we can avoid to trap in a can of > worms with problematic terms like 'asocial, unsocial, anti-social...' which > could have quite special meanings in different cultures. Thanks for raising awareness to this. I was unaware that "asocial" was disruptive to the conversation, but indeed danish dictionaries (I am no native english speaker either) flag that word as condescending. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Paul Gevers (2024-05-19 10:05:38) > In this discussion about mandating things, I've been wondering > > On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote: > > * mandate VCS-tracking > > * Yes > > * mandate the use of one specific VCS > > * Yes: git > > What do people think this should mean, a *should* or *must* in policy? > That the package has a RC bug if the packaging isn't tracked in git? And > if the packaging is in git but I forgot to push my latest changes to the > documented git server (this happens regularly to me as I do most uploads > with dgit)? RC? In all suites where the packaging version isn't pushed > for? And how about NMU's? (I just checked a random package without git: > aspell-am, last non-NMU upload was in 2013)? > > If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the > person that did the changes, (and has nice local commits) somehow isn't > available, will the package (if not key) be auto-removed? Or can > everybody fix the repo? What if you don't have write access to the > existing repo? And then what if the uploader comes back and tries to > push the real history? What if my harddisk with local changes crashes > before I push (again, I forget that sometimes, but for me luckily dgit > will mostly have the commits). > > Or is this "just a bug", maybe even at level important, but no other > consequences. Than I think this discussion is going to be moot. I don't > think there's much forcing possible and I think most already agree that > stuff *should* be in VCS, so this isn't going to change for those in > favor. And does it really add enough value if those that are forced are > just going to do "gbp import-dsc" for each upload to the archive on a > ./debian only repository? Because that (or better) we could already > automate (see also my PS). With "mandate" I do not mean kick out if non-compliant. Same as we (as far as I am aware) mandate declaring Poilcy version followed by a package, but don't kick out packages having mismatching declaration or not following latest policy. I think there is a big difference between saying that Salsa (or git, og Debbugs, or public-wide WNPP work tracking) is an optional addon to Debian, to saying that it is expected of everyone (i.e. you are being asocial if you don't, and can expect your behavior being discussed as a public-wide issue for the project). So I disagree that tool-use severity of "important" makes progress moot. I have met developers who have the view that we are already at the point of non-use of Salsa being asocial behavior, and had at least one very interested (and calm) exchange of such differing views at Debconf in Kosovo. Deciding project-wide where we are on that scale do help, I think. > PS: I've always wondered if the dgit server shouldn't track history, > even if uploads don't happen via it. A dgit clone could (should?) > already provide available history, even if no upload happened via it yet. All the points that I listed are all about optional/expected/required *contributor* streamlining. If I understand your comment above about dgit correctly, it is about automation of history tracking, which is (mostly) orthogonal to *contributor* streamlining. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
ally, my current opinion on each of the above is this: * mandate VCS-tracking * Yes * mandate the use of one specific VCS * Yes: git * mandate one specific VCS workflow * Not yet, but require unusual workflow flagged and documented * mandate collaborative packaging * Not yet, but * mandate project-wide issue tracking * Yes: personal/team issues like WNPP work are project issues * mandate a single project-wide issue-tracker * Yes: Debbugs (for now: open to switch but not to duplicate) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED
Quoting Paul Gevers (2024-05-16 11:37:54) > On 16-05-2024 10:35 a.m., Jonas Smedegaard wrote: > > Just to clarify, the package in question does not directly depend on > > rust-ahash 0.8.9-2, that Built-Using information is (as is the general > > purpose of that field, I believe) transitive. > > Built-Using is used for license compliance so we HAVE TO have the exact > version in the archive. If the version mentioned in the Built-Using > field is no longer in the archive, the package can't be accepted. Makes great sense. Thanks, Paul. I will try in future to pay attention specifically to Built-Using for long-pending NEW packages. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED
Hi FTP-masters (cc d-devel list),
A package, that I had initially introduced to Debian some months ago and
had been pending in NEW queue since, was rejected few days ago, like
this:
Quoting Debian FTP Masters (2024-05-14 12:00:12)
>
> An exception was raised while processing the package:
> Traceback (most recent call last):
> File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 121, in
> wrapper
> function(upload, srcqueue, comments, transaction)
> File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 248, in
> comment_accept
> transaction.copy_binary(
> File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 390, in
> copy_binary
> self._ensure_extra_source_exists(filename, db_source, archive,
> extra_archives=extra_archives)
> File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 214, in
> _ensure_extra_source_exists
> raise ArchiveException('{0}: Built-Using refers to package {1} (= {2})
> not in target archive {3}.'.format(filename, source.source, source.version,
> archive.archive_name))
> daklib.archive.ArchiveException:
> p/pandoc-filter-diagram/pandoc-filter-diagram_0.2.1-1_amd64.deb: Built-Using
> refers to package rust-ahash (= 0.8.9-2) not in target archive ftp-master.
I it correct to derive from the above, that packages in NEW queue must
be freshly built, and that I (and we, generally) therefore should
routinely rebuild packages pending in NEW queue to ensure that they are
acceptably?
Just to clarify, the package in question does not directly depend on
rust-ahash 0.8.9-2, that Built-Using information is (as is the general
purpose of that field, I believe) transitive.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: gnulib
Quoting Simon Josefsson (2024-04-18 09:34:26) > Jonas Smedegaard writes: > > > That said, you are welcome to try nudge me if some concrete task > > emerges where you image I might be of help. > > Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to > allow others to help and to allow you from not having to feel a need to > reply at all :) Thanks for releaving me. ...but then you bring up licensing, which has my special interest :-D > One of the things that bothered me with the gnulib Debian package that > I've been too afraid to touch is the debian/copyright file. It triggers > a lot of lintian errors: > > https://udd.debian.org/lintian/?packages=gnulib > > For reference here is current debian/copyright: > > https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright > > I've seen debian/clscan/ and ran the tools there, but I don't yet feel > comfortable patching things, and it didn't produce clean results even > for the last version in testing before I started to work on this > package, so I'm not convinced this toolchain is the best approach going > forward. When I took over maintenance my first thought was also to get rid of the clscan script, but then I realized how enormous a work it would be to approach it differently and wrapped my head around the script and adjusted it. Does it sound like you are in a similar situation now as I was, or is there something in particular that makes you consider abandoning clscan? If you are simply not fluent in perl, then perhaps reach out to the Debian perl team for help? Or perhaps look in the git history the tweaks that I made - perhaps those are of inspiration to whatever issue you are running into now? > One problem is that lintian doesn't like [REF01] in lines like this: > > License: FSFAP [REF01] I agree with lintian about the above (but we disagree on other things - see bug#786450). I am confident that the above syntax is incorrect: copyright format 1.0 requires a single-word shortname. > Is the reason why this is done that you want to record a full copy of > the actual text from the particular file AND some more information? > Sometimes there is a file X with the FSFAP license and some additional > text not part of the core FSFAP license, and another file Y that also > uses FSFAP but has some OTHER additional text that you want to record? I guess so. While I maintained the package I did some cleanup of the copyright file, but did not get around to tightening the [REFnn] syntax, and I have not been in touch with the previous maintainer who introduced it, Ian Beckwith, which is why I am only guessing here. > In some other packages, I've used the Comment: field like this for > situations like that. Maybe it is applicable here? > > Files: * > Copyright: 2016 Google LLC. All Rights Reserved. >2022 Trillian Authors. All Rights Reserved. >2016 The Kubernetes Authors. >2017 Google LLC. All Rights Reserved. > License: Apache-2.0 > Comment: Quoting AUTHORS: > # This is the official list of benchmark authors for copyright purposes. > Antonio Marcedone > Google LLC > Internet Security Research Group > Vishal Kuo > > The idea is that from a legal perspective, the copyright notices and > keywords 'FSFAP' and 'Apache-2.0' with full text copy of the license is > sufficient documentation. However, for reasons like proper attribution > and having more background information, it is useful to say something > more than what's legally required, including properly quoting the > relevant files. I think the Comment: section makes for a better place > than License: fields for this. I generally agree with your approach above. Specifically for your concrete example above, I find the Comment superfluous. Also, one detail: I would avoid content in first line of the Comment field - i.e. I would move the text "Quoting AUTORS:" down on a separate line, indented same as the following lines. Arguably the syntax used above is technically permitted, but I have not seen it used. Details on that is here: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#formatted-text - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Silent hijacking and stripping records from changelog
Quoting Jonathan Dowland (2024-04-18 09:35:41) > On Wed Apr 17, 2024 at 7:26 PM BST, Jonas Smedegaard wrote: > > To be fair, I _was_ upset (not with Jonathan, but) earlier in this > > thread, which makes it harder to err on the side of a mistake when I > > write something that can be read as being sarcastic. > > I would be upset too if my packages were repeatedly hijacked. > > > Sorry, Jonathan, for being difficult to read here. > > No problem: Sorry for lapsing in assuming good faith on my part. > > WRT Haskell and the monorepo, I've just done a bit of digging to try and > remind myself why it was necessary, and I've not found a satisfactory > answer. Perhaps there isn't one! [1] says it's "easier to update them > in bulk" which, in isolation, I personally don't think is sufficient for > the trade-off. I agree with your view. The need for efficiency is the reason that I mentined in my rant previously that the Perl team has made use of myrepos to kinda get a bit of both: Track each package in independent VCS, while easing sweeping operations across a pile of similarly structured packages. > I've just noticed that you upload Pandoc, and it (thankfully) is in an > individual repo. You don't build a library package, perhaps that's > relevant. I haven't traced the history that results in there being a > separate haskell-pandoc source package yet. > > [1] https://lists.debian.org/debian-haskell/2024/02/msg1.html > [2] https://tracker.debian.org/pkg/haskell-hakyll Until recently, Debian source package src:pandoc provided binary packages pandoc (containing an executable binary) and ghc-pandoc-dev (containing a Haskell library). I never liked the Haskell team giant-git-repo thingy, and that source package has been mainained in an independent git repo, with collaboration and coordination with the Haskell team on doing that. The reason for the split was changes to upstream tooling (instead of building lib and binary in concert, they were split into separate git repos and building binary would need library already built), combined with infexible tooling in Debian (Haskell libraries still rely on CDBS which in itself can handle chainloaded builds but it is tricky to do right and even more tricky to do so with the Haskell-specific CDBS addons). I tried but gave up, and handed over maintenance of the Pandoc library part to the Haskell team. I also maintain a few other Haskell libraries and binaries, also outside of the Haskell team giant-git-repo thingy. The Haskell team tolerate that. I am unaware if I am alone in maintaining Haskell packages outside of the team giant-git-repo thingy. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Silent hijacking and stripping records from changelog
Quoting Russ Allbery (2024-04-17 19:53:06) > Jonas Smedegaard writes: > > Quoting Jonathan Dowland (2024-04-17 17:29:11) > >> On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote: > > >>> Interesting: Can you elaborate on those examplary contributions of > >>> yours which highlighted a need for maintaining all Haskell packages in > >>> same git repo? > > >> My Haskell contributions (which I did not enumerate) are tangential to > >> the use of a monorepo. But it strikes me as an odd choice for you to > >> describe them as examplary. Paired with you seeming to file me on "the > >> opposing side", your mail reads to me as unnecessarily snarky. Please > >> do not CC me for listmail. > > > I can see why it might come across as snarky. It was not intended that > > way. > > > I just meant to write describe your contributions as examples, but I > > realize now that with your emphasizing it that I wrongly described them > > as extraordinary examples. > > I suspect (based on Jonas's domain) this is one of those subtle problems > when English isn't your first language. The English language is full of > weird connotation traps. > > For anyone else who may not be aware of this subtle shade of meaning, an > English dictionary will partly lie to you about the common meaning of > "exemplary" (which I assume is what Jonas meant by "examplary"). Yes, it > means "serving as an example," but it specifically means serving as an > *ideal* example: something that should be held up as being particularly > excellent or worthy of imitation. > > If you ask someone "could you elaborate on your exemplary contributions," > a native English speaker is going to assume you're being sarcastic about > 90% of the time. In common usage, that phrase usually carries a tone > closer to "please do enlighten us about your amazing contributions" than > what Jonas actually intended. > > I keep having to remind myself of this in Debian since many Debian > contributors have *excellent* written English skills (certainly massively > bettern than my language skills in any language other than English), so > it's easy to fall into the trap of assuming that they're completely > fluent, but English is full of problems like this that will trip up even > highly advanced non-native speakers. Thanks for elaboring, Russ. To be fair, I _was_ upset (not with Jonathan, but) earlier in this thread, which makes it harder to err on the side of a mistake when I write something that can be read as being sarcastic. Sorry, Jonathan, for being difficult to read here. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Silent hijacking and stripping records from changelog
[replying list-only - unable to identify who is subscribed] Quoting Jonathan Dowland (2024-04-17 17:29:11) > On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote: > > (or did I misunderstand your point?) > > You misunderstood my point: I was actually supporting your position. Oh! > You've read it entirely backwards. > > > Interesting: Can you elaborate on those examplary contributions of yours > > which highlighted a need for maintaining all Haskell packages in same > > git repo? > > My Haskell contributions (which I did not enumerate) are tangential to > the use of a monorepo. But it strikes me as an odd choice for you to > describe them as examplary. Paired with you seeming to file me on "the > opposing side", your mail reads to me as unnecessarily snarky. > Please do not CC me for listmail. I can see why it might come across as snarky. It was not intended that way. I just meant to write describe your contributions as examples, but I realize now that with your emphasizing it that I wrongly described them as extraordinary examples. I am still curious what you meant - regardless if pro or con Haskell team packaging style. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Silent hijacking and stripping records from changelog
Quoting Jonathan Dowland (2024-04-17 11:14:20) > On Mon Apr 8, 2024 at 9:21 PM BST, Jonas Smedegaard wrote: > > What I am not open to is abandon the one-git-repo-per-source-package > > packaging style that is commonly practiced in Debian. As I understand > > it, only Haskell and Rust teams use giant-git-for-all-team-packages > > style > > I've never interacted with any Rust packaging. > > For Haskell, I believe there are sound technical reasons for the > monorepo. I have found that trying to contribute fixes to Haskell > packages is difficult because it is so different from Debian convention. > I think that's important, so a decision to use a monorepo should not > be taken lightly. Interesting: Can you elaborate on those examplary contributions of yours which highlighted a need for maintaining all Haskell packages in same git repo? (or did I misunderstand your point?) Also, for the record (as the above could be misread as such): I do not take such decision lightly. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1069129: ITP: rust-hypothesis -- wrapper and CLI for the Hypothesis API
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-hypothesis Version : 0.11.1 Upstream Contact: OutOfCheeseError * URL : https://github.com/out-of-cheese-error/rust-hypothesis * License : BSD-2-clause Programming Lang: Rust Description : wrapper and CLI for the Hypothesis API The hypothesis crate provides a lightweight wrapper and CLI for the Hypothesis Web API v1.0.0. It includes all APIKey authorized endpoints related to... * annotations (create / update / delete / search / fetch / flag) * groups (create / update / list / fetch / leave / members) * profile (user information / groups) . This package contains the source for the Rust hypothesis crate, for use with cargo and dh-cargo. This package is needed for gooseberry (bug#106). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-hypothesis>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYe1scACgkQLHwxRsGg ASHzMg//TaU1z7OY+DS0MtsAiXpTO9yHdw6DJMogbDtuFS764y6fPK/A5JNC0NUw ZJoY8ycArhOCzWYDbSFGxYz0llwJwO6VuaPtKa3EUy+www8WjxCkQMzmXiqlSbhl 2qnh3Aj03XyUhmFl4hqiCyVeV0RH7B3Ylj4JGEEgOZhvYZL99OdMixwgHtTZDg6y 2yOxUyhU7ULiuGa5JZaOSSnHqpPdygimny0GDdj5FM5KJ4h32v9u7q9QLoyYADQQ eNVa1zT9hukTee9AlpD7uFtxhXF3IReArakTAjmxoEqAssc+DAZBp4DBHVquai/p Mw6AQY2kX8QOTzaGlNVZ3cVmAGXUxjAhUJfxpJswRmou9mtuI+E1L8N0znfmqQJ4 QfUEq2ZCVvaAis6QysBSZ/AvRfzjX4mIrpeChifk1jxsa8CkIjRdwKEUpiqlpaDf bIIr/K/PpTR2duo/b9U+Y62WyZo/7XTjQTe4pqxcR3E6JmuHSB+K7z8IVxDJzOIA gHzllETerCbMoi+fM1qOKZlCzb5SBIRKyERnFUF1grMsQJr/73jFkS2Bxq+B5sSm dfZsf7D4TeXcdIy6kBcAeZwQsNnINZT0xvHjvJ14oekqm3ayg80okAK8lL505aTE VvkgO632KoD4AVG7GJemSmaKO0nF4djhtK1l9lHe6R0QhAs2uZc= =PeP/ -END PGP SIGNATURE-
Bug#1068927: ITP: rust-event-listener-strategy -- block or poll on event_listener easily
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-event-listener-strategy Version : 0.5.1 Upstream Contact: John Nunley * URL : https://github.com/smol-rs/event-listener-strategy * License : Apache-2.0 or Expat Programming Lang: Rust Description : block or poll on event_listener easily event-listener-strategy provides a strategy for using the event-listener crate in both blocking and non-blocking contexts. . One of the stand-out features of the event-listener crate is the ability to use it in both asynchronous and synchronous contexts. However, sometimes using it like this causes a lot of boilerplate to be duplicated. This crate aims to reduce that boilerplate by providing an EventListenerFuture trait that implements both blocking and non-blocking functionality. This package is needed for newer releases of src:rust-async-lock and src:rust-async-channel. It will be maintained in the collaborative Debian section of Salsa, at https://salsa.debian.org/debian/rust-event-listener-strategy -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYaklcACgkQLHwxRsGg ASHWLhAAoN2U3vUvMe6vng6U0BCHoImeJor7wGb0RsR8SagWtONeDyubBoK/kNgx lWhvgwcLcgc4bTKPdqqfH44svsQ9qMAQFdYp9QZZXXuUJCKwPjlbrgwcEpUu0gy1 H3mVsZOzwWH2ldnlE6F71L+uQSJriaCyN5HbFXfkXIo25WELcE0trGJletqHuiVM cONmMXGSFNjPc6DFNOfIAUrfyIt9qp1urCu4nzLWsvxBV3CgrUyPBZLlcezOa9wd NfVv2A2FVwxDYqst5hwckmemgjr/82Y5jn8Wd644vhlxIHN7cNFq8awQ1wY3Bz8/ C9VuVyz7P0NCotqM0oWosYk+hZyDEGkiapFiGPQlQSbPTSbBdPRLoMd25W6ABSxk wnW9mBPRhebNl30ZODCePM1PRlM8DhVygeIFkXs3kBScLSRjAMtHh3c4EWw3pcls 7e819qb/mHce4xcrHxeybCl5DB3k6pDpn6+0gHYemrbpAsCcr9aWLoRxTMbh9Uin 5vYugGlaROdD13Ojkinbm+HXmwEEWqTXu/y2M+dzNJNIRS45XsOSAq6nHZKot3jg /LlwCresEdWv7UY8PO4Z21EoXUSrStA8pIqqJyzKx+hXvf/l1vIvV8iYLWDgGGmU ht7rS5GLaoXx2HI0o1hFDeMFU51F0D5Vy6unvbKulJNzv7fLVyA= =Cau5 -END PGP SIGNATURE-
Re: Silent hijacking and stripping records from changelog
Quoting James McCoy (2024-04-09 03:25:16) > On Mon, Apr 08, 2024 at 10:21:49PM +0200, Jonas Smedegaard wrote: > > ...and about moving on: Can you please also clarify if you understand > > "moving on" as reverting to me maintaining the package that you > > accidentally hijacked, or if you instead understand it as you (on bhalf > > of the Rust team) now having taken over maintainership of that package? > > I've already filed an RM request for src:rust-lazy-regex-proc-macros, so > your package will prevail. Ah, good to know. Thanks! > > > Den mån 8 apr. 2024 kl 12:41 skrev James McCoy : > > > > Now, that happens because our tooling is based around a 1:1 > > > > relationship of crate to source package where as you've been > > > > packaging an entire workspace as a source package. We need to adapt > > > > our tooling to better detect this so we get accurate information > > > > presented to us and avoid stepping on your work. > > > > Yes, please improve your tooling to better align with Debian packaging > > rules, not assume your team rules apply also outside of your team. > > Having policy for a language ecosystem is pretty common, since that > makes it easier to interoperate. Yes, team-specific policies exist, to ease work within those teams. Team-defined policies do not, however, hold any special powers outside of said team, so it is sensible for them to not conflict with general Debian packaging policies or assume that all packages *outside* of the team are aligned by those team-specific policies - e.g. that a binary package containing cargo crate source files must¹ be built from a source package with same name as that cargo crate. ¹ "Package naming" in https://wiki.debian.org/Teams/RustPackaging/Policy > > > > I'd still prefer if we could consolidate our efforts into the rust > > > > team (and re-integrate your forks of our package helpers), rather > > > > than have two divergent sources of rust packaging. > > > > I would also prefer if we could consolidate our efforts, and am open to > > joining the Rust team and collaborate there, as also stated previously. > > > > What I am not open to is abandon the one-git-repo-per-source-package > > packaging style that is commonly practiced in Debian. As I understand > > it, only Haskell and Rust teams use giant-git-for-all-team-packages > > style, and only the Rust team strictly enforce that style (Perl team > > uses myrepos to work across many packages which I recommend you to > > consider). > > When I first started looking into Rust packaging it was initially going > to be for a workspace of crates. I didn't receive any pushback when I > asked about taking over the one crate that had already been packaged and > handling it from a single source package for that workspace. In the end > I changed my mind and continued using the monorepo for the rest of the > crates. > > It makes certain things easier, while using a repo based on upstream git > makes other things easier. Which method is used is up to the maintainer. > Not using the monorepo just requires better coordination. Well, I received strong pushback by Ximin (on irc - I can share chat log discretely if interested) when I joined the team and published a single-package-repo rust library (possibly the first librust-* in Debian), and the pushback and insisting on strong rules imposed for team members lead me to drop that package and leave the team. I have since, every time I have been approached by Rust team members and suggested to join the team, shared my concern about the Rust team policy, and asked if those policies might have changed, or if those approaching me might see a benefit of working towards changing team policy. I am not quite sure what you are really saying above. Squinting my eyes it kinda sounds like you might be open to relaxing team policy. If that's the case then that's great news. I look forward to that. If you are interested in better understanding my notivation for the crisicism I raise towards the Rust team policy, then feel free to reach out - I am happy to elaborate. > > More important, however, and despite what I can or cannot agree with: > > For as long as the Rust team chooses to deviate from general Debian > > practices, it *must* constrain those deviated rules to team work, and > > *not* make the flawed assumption that all Rust crates in Debian are > > aligned with Rust team packaging rules. At any time any Debian developer > > may upload a rust-* package - that namespace does not belong to the Rust > > team, regardless if/when I join the team. > > As far as I know, no one has claimed that we have s
Re: Silent hijacking and stripping records from changelog
Hi Alexander and James, Quoting Alexander Kjäll (2024-04-08 16:42:22) > I'll second what James wrote, this was done by mistake by me as our > tooling didn't discover your package and I'm sorry for the extra work > it caused. Thanks for clarifying that it was an accident. Accidents happen. Let's move on. ...and about moving on: Can you please also clarify if you understand "moving on" as reverting to me maintaining the package that you accidentally hijacked, or if you instead understand it as you (on bhalf of the Rust team) now having taken over maintainership of that package? The reason I ask about that so meticulously is that in the recent past, I assumed the former but Sylvestre evidently meant the latter (judging from his later response and his inaction regarding related bugreport). > Den mån 8 apr. 2024 kl 12:41 skrev James McCoy : > > On Sun, Apr 07, 2024 at 09:58:10PM +0200, Jonas Smedegaard wrote: > > > And when you do hijack packages²³, then please be respectful and > > > give credit, by preserving/reviving past contributions in the > > > changelog file. > > > > As the person who uploaded rust-lazy-regex-proc-macros, I wasn't > > aware the crate already existed in Debian and wasn't intending to > > upload a hijack of your package. The Rust team _does_ have a lot of > > automated tooling and when I prepared the upload to NEW, it agreed > > the package was new. Thanks for the clarification. As said above: Understood, accidents happen. > > Now, that happens because our tooling is based around a 1:1 > > relationship of crate to source package where as you've been > > packaging an entire workspace as a source package. We need to adapt > > our tooling to better detect this so we get accurate information > > presented to us and avoid stepping on your work. Yes, please improve your tooling to better align with Debian packaging rules, not assume your team rules apply also outside of your team. > > I'd still prefer if we could consolidate our efforts into the rust > > team (and re-integrate your forks of our package helpers), rather > > than have two divergent sources of rust packaging. I would also prefer if we could consolidate our efforts, and am open to joining the Rust team and collaborate there, as also stated previously. What I am not open to is abandon the one-git-repo-per-source-package packaging style that is commonly practiced in Debian. As I understand it, only Haskell and Rust teams use giant-git-for-all-team-packages style, and only the Rust team strictly enforce that style (Perl team uses myrepos to work across many packages which I recommend you to consider). I am also not open to abandon packaging as Debian source the upstream code files in the preferred form for editing. Rust team instead distributes upstream preferred form for prepackaged distribution, as also practiced elsewhere included in the Perl team, but as far as I am aware is only strictly required in the Rust team. The one-crate-per-Debian-source-package packaging style enforced within the Rust team is a consequence of above preference of tracking upstream not-preferred-form-for-editing-source-but-crates.io-distribution. I find that problematic and as long as you insist on that you will need to be cautious to not wrongly asume the same for the rest of Debian. More important, however, and despite what I can or cannot agree with: For as long as the Rust team chooses to deviate from general Debian practices, it *must* constrain those deviated rules to team work, and *not* make the flawed assumption that all Rust crates in Debian are aligned with Rust team packaging rules. At any time any Debian developer may upload a rust-* package - that namespace does not belong to the Rust team, regardless if/when I join the team. I am happy that you bring up my forks of cargo-related package helpers. I'd be delighted if they were to be adopted in dh-cargo, as that would simplify my packaging. Only reason I haven't filed bugreports was that my past interaction with Wimin and Josh regarding the core packaging choices of those helper script of yours left me with a very clear understanding that the Rust team had made those choices deliberately and was not about to negotiate changes to them. As I've mentioned before, if I am mistaken and Rust team *is* interested in adopting my changes (not only single persons like yourself, and others from the Rust team that have discretely reach out to me in recent years) then great: Please do tell me if you need help adopting them or perhaps understanding them - beyond what I have already attempted to clarify in commit messages here: https://salsa.debian.org/build-common-team/dh-cargo-fork/-/commits/wip/opinionated/ Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Silent hijacking and stripping records from changelog
Hi Sylvestre and Alexander (cc Rust team and debian-devel), Please do not silently hijack packages. If you would like to take over maintenance for some package, then please ask. Then I won't bite¹. And when you do hijack packages²³, then please be respectful and give credit, by preserving/reviving past contributions in the changelog file. Kind regards, - Jonas ¹ Just like I didn't bite at the accidental hijack in February: Quoting Jonas Smedegaard (2024-02-17 02:20:03) > Hi Sylvestre, > > Quoting Sylvestre Ledru (2024-02-16 19:24:00) > > I am really sorry but it seems that I made a mistake with rust > > palette: > > > > https://tracker.debian.org/pkg/rust-palette > > > > I didn't realize that it was already uploaded (probably because I > > uploaded https://tracker.debian.org/pkg/rust-palette-derive ) > > > > Please let me know how to fix this issue :( > > > > I needed it for the new version of eza! > > Ok, I will try fix that. I recognize how that confusion could arise (as > in: I could've easily made the same mistake - and possible did). > > Please take a look at related bug#1063779. And just as I didn't bite when, after ignoring the above mentioned bug and after my work cleaning up after the February accident, that same package *again* was hijacked: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-April/040451.html Only when you shrugged when my pointing out that second hijack did I arguably bite: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-April/040452.html ² This changelog: https://tracker.debian.org/media/packages/r/rust-palette/changelog-0.7.5-1 is missing these entries: https://salsa.debian.org/debian/rust-palette/-/blob/debian/0.7.4.0+dfsg-3/debian/changelog ³ This changelog: https://tracker.debian.org/media/packages/r/rust-lazy-regex-proc-macros/changelog-3.1.0-1 is missing these entries: https://tracker.debian.org/media/packages/r/rust-lazy-regex/changelog-3.1.0-1 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Is it allowed to remove attribution in public domain "licensed" source code? (and pondering about ftp-level reviews)
Quoting Otto Kekäläinen (2024-03-30 22:09:46) > Is it so that the debian/copyright file is reviewed by ftp-masters > only for packages in NEW queue, and there is probably no automation in > place to flag subsequent copyright changes for re-review? It is my understanding that it is, and always has been, the responsibility of the _uploader_ and not ftp-masters to ensure that debian/copyright data is accurate. True, ftp-masters review, but we should not rely on that. Which means the flagging you ask about is something each package maintainer should (either themselves or through their choice of tooling) put in place. What I do is recheck for changes to copyright and licensing changes each time a package is changed to use a new upstream release. I am greatly helped (but do not fully trust - I also manually look at source files) by an automated licensecheck scan, where I keep a dump of that in the source package, and compare to a rescan after importing the upstream code but before releasing it: https://wiki.debian.org/CopyrightReviewTools#licensecheck - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1067574: ITP: rust-leptess -- rust-leptess
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-leptess Version : 0.14.0 Upstream Contact: QP Hou * URL : https://github.com/houqp/leptess * License : Expat Programming Lang: Rust Description : productive Rust binding for Tesseract and Leptonica Leptess provides productive and safe Rust bindings/wrappers for Leptonica and Tesseract. . This package contains the source for the Rust leptess crate, for use with cargo and dh-cargo. This package is needed for subtile-ocr (bug#1014093). It will be maintained in the collaborative Debian section of salsa, at <https://salsa.debian.org/debian/rust-leptess>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmX/T4AACgkQLHwxRsGg ASGBUA/+NOIWlXT6DSTueqHMsnrAHe82jM3solSp2amVBhLt9GYdz/sjZtzW+R2s tRx3Fjh/aPPecE57lOtphLmBe7MxN1I+ulsCSfExCga33LJuHd0Cm2LGdM7tnaTK DIa7R4JwQapregebbcvTZOrzSBp1i9iugU7+OOdR1Yiluu5BW5+aaN8bNrjI MWuTcPwQ7YO8gIejQBH5Gh1pZ1KvgZrbeeea41gNksFnMwh2JGfsuTaNvHVUztcL oovJg05sRjblpvbTEVEEg/Ad2cmrw3OUmx2qSCcHbzu5yJtgRTPmXBAwoNjSf+2b ZhTMHtP3WeQkMqWKybj7LPlqD7hlj7VsfdQ7P/GjDpSMx9MAMeTxsZ8wQCc1nMUI 8M1N3i3ArT2VNBYx3t5YcsZxyRo4MLtoPnbUnh5dZdS6YyI65miR5wxbKO4UUSQG koa8u6F3CEQ61dBS6SAzTuz/8CdYhgHTT8ytdQL51z+Tmdt7bG/ecXclsev3ZWEm DTSb5rn2K03pKsBDsAKIbwJNgd/VS18vquAibgQooqgcRigONKR5U/ahYo30sIlJ EWMHhNfRpissfOF1csS0uCV14m2Hwffo3dMreBh0Q3llzPTziykFjwSHonKzsq5x kf3pD3cD4U5lNWY6XwjIXCHAx3vu6MV71Ev6dRARaQogaK/NQV4= =96nN -END PGP SIGNATURE-
Re: Policy: should libraries depend on services (daemons) that they can speak to?
Quoting Vincent Lefevre (2024-03-06 12:17:55) > On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote: > > Quoting Arnaud Rebillout (2024-03-06 02:26:00) > > > However it's true that some packages are installed before that, at the > > > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"? > > > > Correct. This is tracked as bug#742977 > > Bug#742977 is about whether to mark installed packages as > auto-installed or not. It is not about Recommends. Sorry. You are right, of course. It is another related issue. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Policy: should libraries depend on services (daemons) that they can speak to?
Quoting Arnaud Rebillout (2024-03-06 02:26:00) > On 05/03/2024 9:22 pm, Vincent Lefevre wrote: > > On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote: > >> For example, when I implemented libuuid, if you want to create a huge > >> number of UUID's very quickly, because you're a large enterprise > >> resource planning application, the the uuidd daemon will allow > >> multiple processes to request "chunks" of UUID space, and create > >> unique UUID's without having to having to go through some kind of > >> locking protocol using a single shared state file. > >> > >> So libuuid works just fine without uuidd, but if you are populating a > >> large ERP system, then you very much will want uuidd to be installed. > >> So in that case, you can make the dependency relationship be either > >> suggests or recommends, instead of a hard dependency. > > Except that in Debian, this is a "Recommends:", and "Recommends:" > > are normally installed by default... except by the Debian installer! > > This is inconsistent. > > This is not correct. The majority of the packages installed by the > installer are in fact installed via tasksel, and it does install > "Recommends:". The command is there: > https://salsa.debian.org/installer-team/tasksel/-/blob/546b5b99e81bfb69b88de105b6fc78fceacb5ee1/tasksel.pl#L930. > > However it's true that some packages are installed before that, at the > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"? Correct. This is tracked as bug#742977 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1064483: ITP: rust-self-encryption -- self-encrypting files
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-self-encryption Version : 0.29.1 Upstream Contact: MaidSafe.net limited * URL : https://github.com/maidsafe/self_encryption * License : GPL-3 Programming Lang: Rust Description : self-encrypting files self_encryption implements a version of convergent encryption with an additional obfuscation step. This pattern allows secured data that can also be de-duplicated. . Convergent encryption, also known as content hash keying, is a cryptosystem that produces identical ciphertext from identical plaintext files. This package is needed by safenet (bug#1008016). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-self-encryption>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXX2mIACgkQLHwxRsGg ASGebBAAlpdeliOH5hFVNQGgEFWTK93RaB+FmdJlp6y8ug8jEZncuxzYZfb7Nf7L K/tccUfifB9lqz6tGQBhqKFRJ8iOtYk0IqxIdhZqjAagmQMSZYS0+lTw/NY4WCrl M3hGcrpu4+dibj59FNxj3uoMBBfe7wLMn5pHzzcBL3BBUl9VLAGH82YcLTAeh0jW heBjdy4Ro3IQ8Y1ZcnXgr7QINlRrm57JtG0LxzSnrIKeISLsDO/YqIaM6e7gUcSd 4giz/2Urv9N3fysMR+JXyxq651z4LICh+jnUmVWB2O+Fbh1v5X4JqwxOAnr0BZQF W667aj1MzOpC8A7wqxDGz24zKcgE0fHAVKoVSP45AG/lkVSWD+ppIiyZXXrX6fwE lWXwwXnN7SaFNXxZzM4/w+GREnvqa7loNZ+AKFSh+qBQVjvd1/1Q4Dkn5jezNbjz ZK6hcL7YmR8eMKOo08OpWBk9e1JRU4TGsLIKFR6PepvZCES71X4Vm8mPshSDSeQ3 Uadv1gQtTW5akLDz8s+SDwZ5V82GYM4H4JDHonaSCyDNR85oxeNASUz9VMCBv3BW uJXMXa7xzDk/T5y7lMIA7D/ioKwEsHL/prYB3Tdfv+RLi0C4Z9VA5I+ftA9adzo5 G0dfPHNkzdLSMBfV7s4GT6Z6dbmsim6Qm7s3VHhqZ5zPAsLb5nA= =mQH1 -END PGP SIGNATURE-
Bug#1064474: ITP: rust-rustls-pki-types -- shared types for the rustls PKI ecosystem
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-rustls-pki-types Version : 1.3.0 Upstream Contact: Dirkjan Ochtman * URL : https://github.com/rustls/pki-types * License : Apache-2.0 or Expat Programming Lang: Rust Description : shared types for the rustls PKI ecosystem This crate provides types for representing X.509 certificates, keys and other types as commonly used in the rustls ecosystem. It is intended to be used by crates that need to work with such X.509 types, such as rustls, rustls-webpki, rustls-pemfile, and others. This package is needed by recent releases of rust-rustls and others. It will be maintained in the collaborative Debian section of salsa, at <https://salsa.debian.org/debian/rust-rustls-pki-types>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXXsb4ACgkQLHwxRsGg ASHhSw/+JRLgav5wk3niZQvqMtyKmXTb3DfZlx5DK+GMJL2qFtf3TG3hbrWURe2X iX/OZqGSk5/IFJamgKbEFQI6JBtXjzCti6oXaPfVRIHBCF6ZPyISNdStKA2KAf5K q/mh4NpbsSxDhJ00y5dkHSdg5d2p8DFAH+2ZvoW+TdS8eQHORYJ7Tty4G8N60CY7 YnlqefMIFa9i9AU57PlM1sUhTY71jrnwuCeR1dGL1VavBpeQrQihN+j0UdzDaTO7 jjvpmesrdfRMv9wUgvGaZ9GQLeox/rCFp7m5Cktdp5M4pX0itGhIljUd3iFcnvAq hZoJTGvehWdia8GIJHtGk/Ivf9pajTIb4XFT6VWKeoM74H0zpjQSO4AA+WP/TzBk vliuf5moOXVjV3UnvIKdPeLlsr1PtZm7dAzHryoxuru8rI4Sfz3zAU1uFbGrJ2jR DkMSV9ozwPuOXliCaIdQdKzgITz3UN6lcqC9OqNhxJMpI1MOzx1wgNYYcVGOYGMz FaI1yYakhjfJ4W/Jl+PE2sqjuY5dp/kEa8rL7Dq2346rGFOjzSOVIW6gX98QfiMr eug0EBwYDO3QjEfQ/ziLmrt3ClPlSWw5hEAiISJjEEQaMQM2+4ABfndtP8cHWq77 9inuoMQmFyZuvB0CquuyO1Lx3BsBCe8uSjIAINo2JtMnk98pLLw= =oPvz -END PGP SIGNATURE-
Re: Another take on package relationship substvars
Quoting Boyuan Yang (2024-02-22 20:25:32)
> 在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
> > I think our package helper tooling should just automatically aggregate
> > all provided substvars of the format ${*:Depends} and append it the
> > Depends field. Rinse and repeat for other relationship fields.
> >
> > The list of fields where this is applied would be curated, so it only
> > applies to known relationship fields where we feel it makes sense. My
> > starting list would be:
> >
> > * Any dependency field, that is: Pre-Depends, Depends, Recommends, and
> > Suggests
> >
> > * The Provides field.
> >
> > I am omitting Breaks, Conflicts, and Replaces because I am not aware of
> > any users of these at the moment. I am open to adding them, if there is
> > a strong use-case.
>
> Can we also consider ${*:Built-Using} as typically seen in
> ${sphinxdoc:Built-Using}?
> This is another field that people keep forget adding. While missing
> this field is not severely harmful, having it automatically handled
> would be beneficial.
...and related to that, also ${*:Static-Built-Using} which is generated
by Rust (and, I seem to recall having read somewhere, Go) tooling.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON
Quoting Facundo Gaich (2024-02-22 17:12:22) > I can work on packaging this if you're still interested, I'd need a sponsor. > > I've already done some preliminary work on this, in particular I renamed > the bin to "rust-toml2json" but maybe you've got a better idea? If the command-line tool does somewhat the same as the existing one, I suggest to rename it with the deviating part as the end instead, so that users TAB-completing would easier notice the alternative: toml2json-rust. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1064163: ITP: rust-futures-rustls -- asynchronous TLS/SSL streams for futures using Rustls
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-futures-rustls Version : 0.24.0 Upstream Contact: quininer kel * URL : https://github.com/quininer/futures-rustls * License : Apache-2.0 or Expat Programming Lang: Rust Description : asynchronous TLS/SSL streams for futures using Rustls futures-rustls provides asynchronous TLS/SSL streams for futures using Rustls. . Rustls is a modern TLS library written in Rust. It uses ring for cryptography and webpki for certificate verification. . Ring is a Rust library implementing safe, fast, small crypto using Rust with BoringSSL's cryptography primitives. . Webpki is a Rust library to validate Web PKI (TLS/SSL) certificates. . This package contains the source for the Rust futures-rustls crate, for use with cargo and dh-cargo. This package is needed by rust-libp2p (bug#1059908). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-futures-rustls>. -BEGIN PGP SIGNATURE- iQIyBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXRK7AACgkQLHwxRsGg ASEUtw/3eYe0loixgZd/xPwqYxUIYoDd/upVNDRNSuXk7mjx4trW+btOrABxhn7P /7odiwyI6ZC8/aLjvDa+YotECCl0E6/ZAEDF72Pz4ZzMQCousCdZTsNSB5l/1P/F 16G54lVRwU2IjPYEPhDXsTAT/8LFSPV2oY/0fRJiWSESNQLDstrJ3DENmFJvmjWZ 0MOUkFWCZouGjXwzqxso0Na8sK97wsjM6aMS7QZzEsUtuqplw0nkvFMnI5ZJm4VG 8EU1zz/JpwgxFyDI8Zw0EbVhjpzRWD0wb13VEzaROyWvysFAjjH6jNxJZfifYNlh 0Lb2f7Yay7h2IA8M+e3Xh3s+/FXiJLv/X9irqWclU3cSDc2knLQjekdYAQ8yEOWA EJYYdQyVWczwk1+BtaH7KDyWB573XgyhJrq5AjVt1zfFNglVCPbh9eOCyBtE/jvM dbhf9xjqN9Pp2P62xv+qKmGRVeHGpSERniIZFgpaLhNsrgng8dEbY9mAcG/k2r6B Tt5HOfRHUIzEzqq9MfJO8AGwZNrp+cryqTYReOocjb3jMQGg1DcgcBZaZYp28uQr OhM/BDLCpA4BJXdCByg2uTaKIXeevioDb82QxImFHTEyLbqf4P3SOdWKFyF/15Wo ytcmwUVaFIlchmqRhJGRSMVqXs15F6KSNfCsjzmcpao7QO0zGw== =6bYc -END PGP SIGNATURE-
Bug#1064155: ITP: rust-soketto -- websocket protocol implementation
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-soketto Version : 0.7.1 Upstream Contact: Jason Ozias * URL : https://github.com/paritytech/soketto * License : Apache-2,0 or Expat Programming Lang: Rust Description : websocket protocol implementation Soketto is an implementation of the RFC 6455 websocket protocol. . This package contains the source for the Rust soketto crate, for use with cargo and dh-cargo. This package is needed by rust-libp2p (bug#1059908). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/soketto>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXRDocACgkQLHwxRsGg ASGObg//UTYrtTt+t5iXeZWM6rXbZYpGhYPO5BYg0sGdykRwGWDq5RM0bC8s0acT oTKm7HqkZLa+uiDVEH4Kl6RPKQ/zglScu+rsZPtx/KiRVjI3pNJuh699uZgIEBUn /14lAMHStMEbiobb5q6REeAQIp0sL+Gi/hoU6+qg3+SvntkC4Asu2XzkHIiaMh37 CKye9bxmGJ/XFTgjxub91AAxCQJaxHyCHyF5wXfGZSpYVuzLKb17vqIuHmHCoyEv UqMfT/HITZph/nKiDMAMx8Zvogf7vCb2plyEiezmeZ79e3SfinCNacUoxr8dNRyV l7sGoKhfd633Q3PesO1Ux2i3Tb7b/ulI8AThzJh9Vs7JKHGrrbeIy+CRvKdhhWhJ GLanrJdSUbqAPey6VxEzu56rW1QcGTpVayd+QOTlGy7c4vRqQHP3kIpOeUPML7hY wyYnA9EVkEDhkIdI4pEMFvF05slBZXF5Ae9zQWdtvod7JwIqsDh0Strw3W0Q4VSh npZY9JD5qjujd2jwpuBjyFezlBOsuOm7zujSA6Urt5rnX0WVJLFcAmW5TFATRJyl Sr9pOssqcQBKtMUMyLBlH9oeS552mX7rOpqhdQRUixKDGauad9xt97UCL5hCg1v7 qv84WHefm94nUt+aRNOE105dfpO+qOvljmFdvfO2DFHS9mTsMHw= =RzfY -END PGP SIGNATURE-
Bug#1064145: ITP: sdml -- CLI tool for Simple Domain Modeling Language
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: sdml Version : 0.2.7 Upstream Contact: Simon Johnston * URL : https://github.com/sdm-lang/rust-sdml * License : Apache-2.0 Programming Lang: Rust Description : CLI tool for Simple Domain Modeling Language sdml is a command-line tool that provides functionality to process SDML files. The Simple Domain Modeling Language (SDML) is a small data-oriented language for constructing, documenting, and reasoning about a conceptual domain model. The SDML language comprises: * a semantic model whose structure and semantics are described in RDF by an OWL ontology * a surface syntax for editing and sharing model artifacts * a constraint language to capture model invariants not covered by the data descriptions in the surface syntax . Resource Description Framework (RDF) is a standard model for data interchange on the Web. . The Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies. This package will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/sdml>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXQ99cACgkQLHwxRsGg ASHdZw/+J+Ku4OKwRJ30CuDKM6wQc5mgoTSGa0tJWZtFkvlKMv8ncblEAcjHVclT 4q7V3+u3umCrO6DErJxgvB5vU2tZvNifoqABtLjluwyTTiKMR2ZxZBc0W/EomdiO O5pL6X5558HCC6mNRxrWhgRA3EqG97UIP156JSo7TCqEfH9sUklVuqF1+HmJjlEM okotoqkL+jNnjBnvajTBdNV2zebqlTrqUo56UBOqQHQzD25otMxNUWkRGTHpven0 fjIhV9UCTVbENH2lNWoat5E/UghsOAeobkCQm6/wWhlxP5vsItp7elzZ3dK7FaA3 s81f7Bue7PVfnAv0NXVK/0pcJTilLSWR3UO2uYWlB/EgRSWIf4cBSpv5H8OycifU /diOy2OA+qu6vPE44a3wnkU6qp3tMIdQc6xdigdsQdvyy6rKAV9gbp8aJqK53NzF ElYdQ+kaISZ6Idx/ha17oBuDghsEv1UGNcf6SS1Hk8Q0T+TAZdGoCDRS6qXOTNYE 251bdusyeJc8CPe5wMHvrisQ/nh5acOdYV49ZLpqGtFYnqQSmdPgok8p2La3qreT ihPHlK1/32C9Q/BfRn2suG09jXRSQ0pkPG7NVwYVx9jeZZxMb+MA/cbhssmE4msF Y743G/zSWLtuTCZxsalDEog1AcMUI6DD+/w5Ucd9XM4vJ+Wq3hc= =Zvbp -END PGP SIGNATURE-
Bug#1062222: ITP: gooseberry -- CLI tool to generate a wiki from Hypothesis annotations
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: gooseberry Version : 0.9.3 Upstream Contact: https://github.com/out-of-cheese-error/gooseberry/issues * URL : https://github.com/out-of-cheese-error/gooseberry * License : Apache-2.0 or Expat Programming Lang: Rust Description : CLI tool to generate a wiki from Hypothesis annotations Gooseberry provides a command-line interface for Hypothesis and lets you generate a knowledge-base wiki, without you having to actually type your knowledge out. . Hypothesis is a tool to annotate the web. This package will be group-maintained at the Debian section og salsa, at <https://salsa.debian.org/debian/gooseberry>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmW6ou0ACgkQLHwxRsGg ASEmWA/+Lxiy5QS2wqjMyyWUVUSgiI8WVzxJLVgXBKI6XgZ+fKQgLP07LFiqtbLm 97xsA6apVPXJWY5ifngGNfvlka6voUwHa8KQ7M/J8H7QXOYahzY4hro06iwddlWg JlkFGtiWJ5Ad7jvnIL7mzKGOi+K0rC8VGV8zpqdbzpd5C9iIokBueMn4jwbZVvCj Zjty/nQz18TW8ZYBSFb5zbs9PntEOVNXhg4rIrjkftFK3is7AGm4/4bQzTm4BWVQ 89S38U14h1Ox1Ev28do04j/kL5LF7/iSz7VFTlfCXyjqROESDBXsSn/FxnyInciN aq4PrUjVtxUuHC9Jg6pHY5OJi6mi4CRU397VzdK1p4RXd+62XRE9ti0MlDUYlgg+ n0TGMAcTsLxXScYMMH253wNTXb4iQT8eYlaX6xVez78IS1LgmReQUmhDlcvYVWyk dJAd/LPqLkm10kvZKgHlro9BaqULpwUS9hxx2JAOh5qbAYDrblHuIc8vuqJIGXwU P3UNg54OVWfE7G7FSp1X6fHJRuvFRAwN+/BrDo/JLoJmHX7xN8LAiPt0G+Ie2+KW ArlIAr/5qzaVIdWscMLS6PkJ6KdIvRt6JyC8xCwv6SLjLSLBilMVU7lgtn/03rqP rWruNgXRjWFs7uVDDLKuLrumcRa2PGx9hlYyPFgadpW0KPuWKdM= =DwAH -END PGP SIGNATURE-
Re: Proper handling of Lintian warnings due to other packages
Quoting Scott Talbert (2024-01-31 16:49:59) > On Wed, 31 Jan 2024, Jonas Smedegaard wrote: > > > Unfortunately it is not likely that the package will be catch up soon, > > because the Haskell team upgrade most Haskell libraries only as a whole. > > > > That issue is not tracked in debbugs, because those vocal in the Haskell > > team actively discourages the use of debbugs: > > https://lists.debian.org/debian-haskell/2024/01/msg00012.html > > Note: I don't discourage usage of debbugs. It's just that I'm unlikely to > notice bugs immediately due to the way debbugs notifications work. The net effect of a) silence in response to filing bugreports, b) responses when reporting issues to Haskell mailinglist, and even c) you [dissing] my explicit attempts at steering conversation to the bugtracker is discouragement of using the bugtracker. - Jonas [dissing]: Sorry, I cannot find any other way to describe what you did when you replied to the list when I posted https://lists.debian.org/debian-haskell/2024/01/msg3.html and wrote "Meh" when I posted https://lists.debian.org/debian-haskell/2024/01/msg00010.html -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Proper handling of Lintian warnings due to other packages
Quoting G. Branden Robinson (2024-01-31 05:49:00) > At 2024-01-30T19:55:07-0800, Loren M. Lang wrote: > > While building a package preparing for a possible upload, I am getting > > a large number of warnings from groff-message due to invalid fonts for > > C and CB in the manpages that are generated from Markdown with pandoc. > > From what I understand, this is a known issue with how pandoc > > generates nroff man pages and more recent versions of groff have > > started complaining about the issue. Here is an example warning I am > > getting: > > > > groff-message troff::89: warning: cannot select font 'C' > > > > And it seems to match the issue documented here: > > > > https://github.com/jgm/pandoc/issues/9020 > > Yes. I work on groff upstream (and at rare intervals make minor > contributions to the Debian package), and you've accurately summarized > the situation. > > > My question is how to handle this. Should I just ignore it for now and > > upload anyways since it's only a warning or should I add an override > > to suppress it as it doesn't seem to be causing any breaking issues at > > the moment? Have other developers dealt with this warning before? > > Well, the version of pandoc that resolved the issue was 3.1.7, released > in August 2023.[1] But the version in Debian unstable is still 3.1.3, > and the package is team-maintained.[2] This particular bug is tracked in Debian as well: https://bugs.debian.org/1053777 > Unless it's release-critical to have these Lintian warnings, I would > disregard them in hope that the pandoc package in unstable will catch > up at some point soon. Unfortunately it is not likely that the package will be catch up soon, because the Haskell team upgrade most Haskell libraries only as a whole. That issue is not tracked in debbugs, because those vocal in the Haskell team actively discourages the use of debbugs: https://lists.debian.org/debian-haskell/2024/01/msg00012.html - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: icc-profiles_2.2_source.changes REJECTED
Quoting Jeremy Bícha (2024-01-25 22:05:27) > On Wed, Jan 24, 2024 at 9:48 PM Jonas Smedegaard wrote: > > For the record I have not heard from ftpmasters on this issues, and I > > know only what is in this public mailinglist thread. > > > > Obviously I would be happy to be able to maintain the package that I am > > listed as maintainer of. And if that for some reason is unreasonable of > > me to expect then I would appreciate an explanation why. > > I found https://bugs.debian.org/1021999 which suggests that DSA is > responsible for maintaining the version of lintian used for the upload > queue. Do you want to contact them about our request for an upgrade? I would prefer not to do it. Please go ahead if you are up for it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: icc-profiles_2.2_source.changes REJECTED
Quoting Jeremy Bícha (2024-01-25 02:50:07) > On Fri, Mar 3, 2023 at 5:58 PM Bastien Roucariès wrote: > > Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit : > > > Quoting Bastien Roucariès (2023-03-03 22:21:49) > > > > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit : > > > > Hi jonas, > > > > > > > > I have just checked the source code of lintian. Could you double check > > > > your package and create a simple test case ? > > > > > > > > According to: > > > > https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91 > > > > The test should not raise > > > > > > Sorry, I don't understand what you ask me to do. > > > > > > In case it was unclear from my previous posts: The rejection messages I > > > shared was not from a lintian check done locally by me, but a rejection > > > message I received from ftpmaster. > > > > > > Locally I did not experience the same messages. Are you asking me to > > > test again that I (again) do not experience the kind of messages that > > > ftpmasters for some reason unknown to me trigger? > > > > Yes could you double check ? > > > > If you do not experience the kind of messages with locally installed > > lintian, it means that lintian need to be backported and that ftpmaster > > should install a backport version. > > I am still getting the LIntian autoreject for thawab for > license-problem-md5sum-non-free. It is especially annoying that > current Lintian does not emit this error or even a warning because it > knows that thawab is in non-free. > > This is blocking me from being able to fix a RC bug in thawab unless I > repack the tarball which seems like a lot of work for a package that > is in non-free and a version that is **already in the archives**. > > I originally tried to fix this RC bug a year ago but my upload > was auto-rejected then and I forgot to mark this issue for followup. > It was an early enough upload that thawab could have landed in Debian > 12. > > https://alioth-lists.debian.net/pipermail/debian-islamic-maintainers/2023-January/004920.html For the record I have not heard from ftpmasters on this issues, and I know only what is in this public mailinglist thread. Obviously I would be happy to be able to maintain the package that I am listed as maintainer of. And if that for some reason is unreasonable of me to expect then I would appreciate an explanation why. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1061425: ITP: iamb -- Matrix chat client that uses Vim keybindings
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: iamb Version : 0.0.8 Upstream Contact: Ulyssa * URL : https://iamb.chat/ * License : Apache-2.0 Programming Lang: Rust Description : Matrix chat client that uses Vim keybindings iamb is a terminal-based client for Matrix for the Vim addict. You can edit messages, navigate windows and manage tabs in the same ways that your fingers are used to from your favorite text editor. This package will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/iamb>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWw7iUACgkQLHwxRsGg ASH50g/+NS9ZivOH2LjhBqR9wJYSBplB4WkacHYIiy6qNxz6mMD8exfAWtDSZP5V 96ABfcGuS2PIP6mTcfnA61DMep0mlbAQecZ3l2SxBEbqtpXcn8nsqRpKgg1vVWRd 3uIcd7PAnJB7+AdssOL664MoZMRAH+NchzeoGku/jOgjCI8gnaMNiR0BHA0k8McF NN437JVBTx/cJOtlkMgbJtRr8D36J9fzJIfiJo3pjU9IRlSE13/pwa7HZTpnQ+DE ckxU+Fi9xrnHFW0mc76n7nD8Wf5k4VGe/bzN6M1uodZpk0UFdCDR+F93AJTLz5y0 0VU7bkJX4cyGybOuMK6pP2x0p/05ErwtMxRcY7wYm+tqCL9T/SLuSZ3xnprwteTL kWwQrpuoD/8PXbdtte2aC7g9brK8lXeo2FUOcQ+76xvRlM0j4hq2bHMnlnI1rN1l u9fPI6HbOZ1UBmcM2BcBldOGOmzUJhjqAtCWY2Rdn2LAdcO7Ji+N7p13XKgwG6b3 cOpug96wPTUgXTFDLFn2ULrdL7sPJLcwzz0YA7BG3hubbMJv4KIuv0soC0Ih6iJ9 F5zg9OdsWkZFGYzYCXp7bEpQdRUZxj5MF69OmU7OgkU1a3KWcVQcNgBB8sgK8C77 P0RUoV3RaZaOk0thM8G3F0pi5JMwGzVV02oBRAuBfr8jUPiyq3A= =2DPA -END PGP SIGNATURE-
Re: Policy: versioning between releases
Quoting Matthias Urlichs (2024-01-21 13:35:05) > question: policy 3.5 states, rather unequivocally, > > Every package must specify the dependency information about other > packages that are required for the first to work correctly. > > Now … does that apply to crossing release boundaries? Specifically, if > foo/testing requires bar >=1.1 to work but just states "Depends: bar > >=1", and bar/stable is 1.0.42 … is that a bug? If so which severity? > > If not, shouldn't that be mentioned somewhere in Policy? Offhand I > didn't find anything that even mentions Debian suites / releases, but > admittedly I only skimmed the table of content and didn't re-read the > whole thing. It is not a bug to fail at predicting *future* breakage, which - if I understand you correctly - is what you are describing above. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Maintainers needed for debtags.debian.org
Hi Enrico (cc d-devel list), Quoting Enrico Zini (2022-10-19 15:20:43) > I would like to let go of the responsibility of maintaining > debtags.debian.org. > > Over the years I did my best to simplify the whole system, so picking up > maintenance shouldn't be too hard, if there is interest. > > I'm going to keep the service in life support until bookworm releases, > and if no other DD has picked up its maintenance by then, I'm going to > announce a plan for taking it offline. > > debtags.debian.org is a Django site. Its code is at > https://salsa.debian.org/debtags-team/debtagsd I can offer to maintain hosting and packaging of debtags code projects. Would that be helpful, or are/were you looking for new code maintainer? Sorry for not chiming in way way earlier. When you posted the above, I silently assumed that you were in need of a code maintainer, for which I consider myself a lousy fit. Only recently in another thread here on d-devel, Paul Wise made me realize that you might have interest in skills that I do feel confident in offering. I have also reached out to others who might potentially have interest and skills needed - again inspired by input from Paul Wise. If this action is too late and/or too little, then I understand, and apologize. Thanks for all your work on debtags over the years! Btw, is another communication channel perhaps more suitable than this? https://wiki.debian.org/Teams/DebTags lists a mailinglist, but that one doesn't exist, and indeed seems discontinued according to https://wiki.debian.org/Debtags Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor
Quoting Paul Wise (2024-01-21 06:51:08) > On Sat, 2024-01-20 at 09:40 +0100, Jonas Smedegaard wrote: > > > I am (very) willing to act as service maintainer. > > Please get in touch with the debtags team about this. > > https://wiki.debian.org/Teams/DebTags > https://salsa.debian.org/groups/debtags-team/-/group_members > > > I have interest myself in continued use of debtags, but don't have C++ > > coding skills needed to work intimately on the programming parts of the > > project. > > It does not seem to use C++, just Python/Shell/HTML/CSS/JavaScript: > > https://salsa.debian.org/debtags-team/debtagsd/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-vocabulary/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-tagdb/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-tools/-/graphs/master/charts Thanks - I am not comfortable with Python either, but that's certainly less scary to me. > You may be thinking of libept, which got adopted by the apt team. It was a mixture of thinking of goplay (see bug#930676) and reducing "languages I am not fluent in" to "C++". > In case you want collaborators, 5 people forked debtags git repos: > > https://salsa.debian.org/search?search=debtag > > Additionally apt-xapian-index needs a maintainer and the debtags > package needs to be updated from the debtags-tools git repository. > > Some of the debtags related wiki pages may need to be updated: > > https://wiki.debian.org/?action=fullsearch&context=180&value=debtag&titlesearch=Titles Thanks a lot! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor
Quoting Paul Wise (2024-01-20 07:32:14) > On Fri, 2024-01-19 at 18:24 +0100, André Maroneze wrote: > > > I want to use debtags metadata for a research project > > The debtags service is planned to be shutdown and the data no longer > published, as there is no-one in Debian who wants to maintain it. > > https://lists.debian.org/msgid-search/20231126160111.7nr56b7oje6uw...@enricozini.org > > > I started contributing, by adding and removing some tags using the > > online tag editor, but the "Checks and hints" part seems wrong to me > > in several cases. > > Sounds like there may be bugs that need fixing, but first there would > need to be a new maintainer who could take over the project. If you > were willing to be the primary code maintainer, perhaps you could find > some Debian member willing to be the service maintainers and review and > deploy all of the changes you could make, at least until you become a > Debian member on the basis of your debtags and other contributions. I am (very) willing to act as service maintainer. I have interest myself in continued use of debtags, but don't have C++ coding skills needed to work intimately on the programming parts of the project. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Policy: should libraries depend on services (daemons) that they can speak to?
Quoting Ansgar (2024-01-07 20:39:57) > I therefore think that libraries (be it classic C shared object > libraries or Python modules or others) should in general *not* have > Depends: or Recommends: relations on services (DBus services, DBus > itself, daemons, ...). I thought this was already in policy. If not then yes, certainly makes sense to add that! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1059914: ITP: rust-pandoc-ast -- markdown ast (de)serializer for writing Pandoc filters
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-pandoc-ast Version : 0.8.6 Upstream Contact: Oliver Scherer * URL : https://github.com/oli-obk/pandoc-ast * License : Expat Programming Lang: Rust Description : markdown ast (de)serializer for writing Pandoc filters pandoc-ast allows you to implement filters for pandoc. The easiest way is to them in conjunction with the `pandoc` crate. You can also create a binary that reads from stdin and writes to stdout, and pass that to a normal pandoc call using the --filter option. This package will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-pandoc-ast>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWVZOkACgkQLHwxRsGg ASGrgg//Z/fjvXI78q6FYNLegruIWm5WBz4GDyEP8itiYnbK/R3bYRhT6Gp/oUQj AF2B34pEEq2PyA63w4rHLIIAfm4kWO0dJaOaiBZUTKgF8oZ9dt7RlNhM9+YjcFn2 w0TyG2zBuc0zuq1rra6zWdQcylXzarb+M2sbRuBDKVyoMzxBv7Ru1oUQ0ZKZ/Ax8 jIV/haLwzq4R44UEtTYLN/NikhMruaQjYsR/bPpNxeTUag8F6RSEYO+AAhh3eDx7 eUbRTJn8qBcjxRm4SaZxZIUlnLQcRo2pEvf8gr+J7iUnRqj4TQ47yJ7/dEmK0CZG 4iZdSKp2pDWBIOugM7ZjshEX/Irzd/alcqIFrdGoPm9ye2C/sIWoreWcsfSecwWS gLykQ8cAsbwjUSsgJekPij9ASpFHm+wGvuve98XNCZaxJ1CpsrqKym+oBKRe8Z5o CKCHQaq5Zm/n9Ceh6AY9go1dVVxQB54DXO+nFadtAHGcwtW5cEbnLE8yAv51OIAI 61H3Z0Mi7lTxePhHv6OylNbgoiEJBWKxm+E5RsEumMvm3yPk/99sK48VU4zGaq5Q i4IkXR+eLc4PYxSwktrq6BKPORtp0M8WQxyBBCuS9mUJLbh5bYrOfljjkqEZ+4dN qVixaQP79hnvRX17jyJZolI6N30/Tf5PoCBw4ww26qRnUQm8iOA= =fH2I -END PGP SIGNATURE-
Bug#1059908: ITP: rust-libp2p -- peer-to-peer networking library
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-libp2p Version : 0.53.2 Upstream Contact: Parity Technologies (UK) Ltd * URL : https://libp2p.io/ * License : Rust Programming Lang: Expat Description : peer-to-peer networking library libp2p is a modular system of protocols, specifications and libraries that enable the development of peer-to-peer network applications. There are many distributed peer-to-peer network models with different challenges and tradeoffs that try to improve on the way we network. Libp2p aims to be a modular, general-purpose toolkit for any peer-to-peer application. This package is needed transitively for safe-network (bug#1008016). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-libp2p>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWVVl4ACgkQLHwxRsGg ASEI+Q//YULyfKdG7bRZG3PyVtnkJJ/LoqyJ7QacY302qjosjjEzYh3U0RfGhfOw PY3lU6q9/nlP3tPeILNXDTWriNGu7/cCo7Hbp7sWUF0XIh4cWQU7xXWDTYMVflhy hNMxj4xzwe+Rd+7FRPSbk2tS9R184jgeGpUSpRScWqSeMXGHEntZ6tdmwsO48Mvy f7HZ6t6Eilbh3oAT9jvzisxXMn/lQyq3TdX5EU61Kh0MmrGUJuCmnHZtB6JDkiO7 LvlgNYI6VxHJ/8oUCDGtvD/+NT7zrudRVwVNYUPwFc5U4obJ9EjuerLQQaK+UfnF TBSQLQTeVT4rWjnRnrN+JCa5+nowftMJsY7/uxldcu9sReZF2pI3AfyXCWCFqi0I XafWEzTs82WTUbCcuomnFgLJvBSg57c8qEvIMaS+uJ77eKTskJwvs81WSR24SHMw zy2E0X8TGafnFNCobc1NQn9yYvoCMX+DeOk0RYlRNg1kh1Odgqwz3qVe5kXj9UD2 ifTI7BZTFmOkeSXNdNlKAPtMZDbxkXVvI5SXwpFK9GrVSyGVocr7h5ka8v+tCnv+ M6Xd+VAeC0kzhuJLh+GGafhUebMuvzIFFrILKs/bhXOGKSSrOA4uCfTTjEp+DwsA O7PboXoaXR2OeiJXN5ZsZcoBR4ndvEBihcipguSKRo2MnIkRtYc= =m/WI -END PGP SIGNATURE-
Bug#1059905: ITP: rust-if-watch -- asynchronous network watcher
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-if-watch Version : 3.2.0 Upstream Contact: David Craven * URL : https://github.com/mxinden/if-watch * License : Apache-2.0 or Expat Programming Lang: Rust Description : asynchronous network watcher if-watch is a cross platform asynchronous network watcher. This package is needed transitively for safe-network (bug#1008016). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-if-watch>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWVTMEACgkQLHwxRsGg ASHVZQ/+JzD0/SNMjSCkJ17DRxk4ZS9XTKZGKDEdtyq/u0MTqZBlsIcQP7XGH1ZV 3u3ErK4jYkuR6pybNnjlE0ycaaBAMuQquHMz2vYS1a9SU4p1xv5XPEWCgi0OsbZD AtPcKTdsVJa5zMYcYiR3wNM9qpWmAQSDnCdnonltqXJA16v0C+uP2+WzSTGtNPs3 EjepX8mTcvNj2iPMbkG8hu3CQP1bZuAZctZWaWLsprM/gvjzlzp9r5RzHkXw1hBy Fov8Cnxdcc5AgUhL8Br7p60xwMoF4gPfQzU/Nj1iRtmyenza20pdKL6AgT1dIlc6 okIffnJZJSMnnRPIVMP+F8WBpnKpl9K5DlpzFBExJMdsWPWDCi1NoNz2WoJOpv1N NZv4yfUj74weFbiUkHNq9ntHp9Ye5hf5+A4yoZ2qTk0+1qx6nbbQf9qSv2eZnjMM 8tfyPQjmOVcQIVEHV29+kDb/AkGGAuRk/h293XYpHQrUpZnfOXnGg+RSbGTwjZAZ UpScLJvOs2aY4wx9pZcEp9QzdYqbMSqNEhmTzA6Q7HyTr5blGka3oOVgGLrNuQP3 Ow/FMjHLQJR4jNtY88Z6mnT2IDrBAl6CbMhc49ACGUCMlYL1Hj2CjxibGvi792XM 42wgR718z+YtnepArVODb9XgntOvJzTkn1WvU/g0l4yeoDtNem0= =x07f -END PGP SIGNATURE-
Bug#1059665: ITP: pandoc-filter-diagram -- Pandoc filter to render diagrams in Markdown code sections as SVG
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pandoc-filter-diagram Version : 0.2.1 Upstream Contact: Lars Wirzenius, Daniel Silverstone, pep.foundation * URL : https://gitlab.com/larswirzenius/pandoc-filter-diagram/ * License : MIT-0 Programming Lang: Rust Description : Pandoc filter to render diagrams in Markdown code sections as SVG pandoc-filter-diagram is a Pandoc filter to render as SVG diagrams in various markup languages, embedded in Markdown as fenced code blocks that are marked with the appropriate class. . Diagram languages supported: * pikchr * Graphviz dot * PlantUML * roadmap * raw SVG This package will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/pandoc-filter-diagram -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWPNysACgkQLHwxRsGg ASEXsA//dXE3GTmjI6IfOEJWjGp9NvyGGCHLZdr4mXQW4TW+C+bB8tOcTmVmYd92 7CH31/TpYQY7PIFW4J90kTt+qpKLthkbU5BIB07ZkKYHcLYrrxvIbDEPXT3P/Qib 5WILCOtliDPFEJCoJbHK2etdKHyEUQu3hJ15AU3JrU07qCgZsuCZ5xNEuQdehzbi HKa96JWkKxKmxor1oBrZoci4Lc9RAqOSAZANkmJEZLUiUKtc+aDBRCANkrgDiSqL RFz9ORIBFGU/kLDDA28LUxcOpndkse+8+ts9bSRfkkQdBN/UlcXSfPstQiUyRFZs ZDCuUveqaMVg1WwfA5K0d1gq3yxrRFLg40n4dnEsWUgBu4NEXXy0+8QpL9BizeNh 6oXLl5qudV8O0krWGOnncscm4Lx3i2irMAoB0Dsbz5O8OqHLIX51LjhuankG2kEH /Rbk2l3nxBC480dUF3MM/hducbXfVJghIydRJRk7r+di4nO1P8Xo6icfgMGmS6B7 /s3H5w+JKkDFvaYNs1Kb5NbzltjI2YuqlAkAdBiz0h+YUTJbo4lb8Oy8UX81Q7mh /8U3JJWMtS6fJznd69iyJRnEYeI9L6IGcauGGmlKA7Z5Tlaz7ppoHPk0eKhONaGN FZGYJCmCNl+m9KtM8J4RpUYWrEhV8q6mt9FTz601hpsnT3Qi8Cc= =mwVh -END PGP SIGNATURE-
Bug#1059655: ITP: rust-roadmap -- model a project roadmap as a directed acyclic graph
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-roadmap Version : 0.5.0 Upstream Contact: Lars Wirzenius * URL : https://gitlab.com/larswirzenius/roadmap * License : MIT-0 Programming Lang: Rust Description : graph-based project roadmap modeling project generates directed acyclic graph representations of a project roadmap. The idea is to show the steps needed to reach a goal, and the order they need to be taken, but ignore due dates and other irrelevant details. This package will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/rust-project -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWPLrAACgkQLHwxRsGg ASGKfg/+Jtgx6/Vl1kBctGxoeCa4b3wbX7JslUp30ADFAsv+dEyJsV3fsLZsebvW U8+IPxxKzOFr501D65JyF8o3CqeNA3H3MeEBc/ObfgYGgFBZLPOTtCT7lGrjMVwC d3g/bBH9eFO6++LMIekackImFeVnHM9xlbpWu3zxugQHUwEfg7u8r56qOXppjR// 7WrnC7W3Lsh+4sDthCQEuciY6T/yczPdIeDnwwLvNqajT4GhPRgEZ2wHGhopSwU3 9/2+jvKgDnPVeEgAw1fiTOQw33UyQToBU9KnsbR5m/H46pJ4FAafTdAotenrOjNN 3P5NiYssPMkqpDkr6ztPSJCwf6nTc1bSvSp3PaxPKYT/BwL4d96G0G2zS5EoNV51 87vrU2ob9ajaikqjtoMkJzhEnY0q0g8BacTf3UnLT10AwGBqYViGLBEBvlOrvQvF vOas/CL8zaf8G5Ud3YZZ0DO0H8kQZpC8+2MmTeZBsPFDqEmaCdZccQ0ll4iyv4Vx wTwu9n0PgWo6WUwm9GEcp9HRHV8yRRyyE2kJeuORbuspW5mt5KB2gJVkZT9NsmKC QHIwWEsbdHeOGeY4k99WcoEszkRTXtIsOqVT/arRuM6qp/NLvDNa/wGlMdDBzgL0 44xXzfvKQIljYEHutDidyUykafUTNVJS16T6d5T7Cgd6K9boTGY= =PpF5 -END PGP SIGNATURE-
Bug#1059521: ITP: rust-pikchr -- PIC-like diagramming language to SVG converter
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-pikchr Version : 0.1.3 Upstream Contact: Daniel Silverstone * URL : https://github.com/kinnison/pikchr * License : Apache-2.0 or Expat Programming Lang: Rust and C Description : PIC-like diagramming language to SVG converter Pikchr (pronounced "picture") is a PIC-like markup language for diagrams in technical documentation. Pikchr is designed to be embedded in fenced code blocks of Markdown or similar mechanisms of other documentation markup languages. This package will be maintained in the collaborative debian section of Salsa, at https://salsa.debian.org/debian/rust-pikchr -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWMK6cACgkQLHwxRsGg ASFeBA//bcFWS7kwUJXjVM6FgPmF6PCAFwFp+S03F2zH/b/GuynbvG1hyptVsV1e DokQYTG9jMPTrEy0UVw2popVegodkVHzPAXQZdy1TRR3r3wvpO0ezhikcTwbobpX lXMN0tAbfOTFdTQYi3aqYsmJA+9yCX6KmM2RSLdeR89javonW05T9SfzQSEUtKeX vDLtBA9JyICe/ox8Ymq/S7Zj6m8hoEK81ZsrBu2+x7O7lnI3g9X7/le7JxN2SyAr njunNioSq8bEHmGD8pMNbGadei+N2Eq8AyxinsZTbGF3Goc6eaz1ePfiNHeBST4v /hDfgc5n+xXegZfxfuR/q8e2jHd52RyVC0bsEOZ13W8eSMhCCyhF3AuTBI/3YUWW yoXyrBez3d+Wf/G3FU5kXCfPTF5pmoCKVq7dr90nWsyFp4zH5HlFHyOVAw31oef1 oxZu+81AS9ch6NtKJycxyQE3+ZiFiJ8dcALcZWAM1noMV5pYEeN1ciJFnAmMlCeB UfcFhdJYJI+/82+fWkBQMwPYkSPn1bhNX7aAabGs++CJkBcU9AeNQ/nv7AJ4xrCE nWiC1tWAmOmzTmEC5CJZzrkm3u5+4Syjp4Q5FwivEzRq6X9DpuXs4xOgCizfYz1o Zuy/0pKdDR5p4MhHFVtm3ahIIwQmdmhxXEFesMJUZQse+S3MjaM= =9MTY -END PGP SIGNATURE-
Bug#1057068: ITP: rust-bounded-static -- ToBoundedStatic and IntoBoundedStatic traits
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-bounded-static Version : 0.7.0 Upstream Contact: FujiApple * URL : https://github.com/fujiapple852/bounded-static * License : Apache-2.0 Programming Lang: Rust Description : ToBoundedStatic and IntoBoundedStatic traits The bounded-static crate defines the ToBoundedStatic and IntoBoundedStatic traits, the ToStatic macro and provides implementations for common types. This crate has zero-dependencies, is no_std friendly and forbids unsafe code. This package is needed for rust-imap-codec (bug#1057065). It will be maintained in the collaborative section of salsa, at https://salsa.debian.org/debian/rust-bounded-static -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVmu5MACgkQLHwxRsGg ASEa7g//SbnWe8bEjVMRt4b8IKNiU6bcgTrUVd9zeXajrOON3b5JKlZm1VOFfZXO TiNFFsMI/zxWxGE4dIkKf+96XqLlwOGaLtNWd0Z6CpQpJq0PSzGnOHrHFus9tE/A 52KxS7SU+0n7ZXACM/zp+dpjRC+ajxhvZwWNHb+IDlW4XXBHf/gsDVm7MZkxdulW GcRB7rqKntoS/Bbn3YY8VCsUjzpJXc95sq4au0xLy+tYHMaZqQfHPbP984kYdLZD iQ2OOmQ2FyQu/OOFobN3j6f2h3V8d2LYN9ncbr7eKTOD7T0MwOqHHEffEeXWC22A 8AnQRPJidS8x0qMnkkxQI6zA3yPWWFAimSWPuZzzveWrgWxZYVU4bfGni5mr1Jnm 7FQbjA1RWW9xR7xeZoG1tOUVdYi94HSyvpgGw7x+TOsVEwZdK3lEaa0jizf0LvXe qmeX2hLqXqo8EmAygqeMRJWd1XnkpgkKPNsNIrEjzKU4XzzbW899F1RbSqJiNT5y UCY3qTezs+9dOhia3Q1vxgNuKPsDJZJyLoWhNa2Mw/KpXy59n1cR2CYFcI3as102 TtDB0C7acYpbMIm2fjzrMk1KFHvSspD3mC6UGel7O9AK62nxuSN6hEpcwWJdn3d/ 4WjBpJlruTHRZkb13sni7HXWMfpmMOwj9OX9k9VfpCQ605Gv56k= =viSa -END PGP SIGNATURE-
Bug#1057066: ITP: rust-abnf-core -- nom-based parser for ABNF core rules
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-abnf-core Version : 0.6.0 Upstream Contact: Damian Poddebniak * URL : https://github.com/duesee/imap-codec * License : Apache-2.0 or Expat Programming Lang: Rust Description : nom-based parser for ABNF core rules The abnf-core crate is a parser for ABNF core rules based on nom 7. It is primarily a building block for the ABNF parsing crate, but should also be useful in itself. This package is needed for rust-imap-codec (bug#1057065). It will be maintained in the collaborative section of salsa, at https://salsa.debian.org/debian/rust-abnf-core -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVmtVwACgkQLHwxRsGg ASGS1A/8DG0E01SiEQDr74R2CR34gcFbMqZKoFdui76YC5XkfgF7/MtcLNbP8XqD AbOgtb+eOW1Uqgj12qzmmdadiU+bTYsp7+bm3jcNLOt2ziDf4J30iew5kaNhU+WM 23HAkpulF9RKyeVb42sdkyjkcdGKbMKax61sIOrQUK+C1fBb6dkPHyGYJx4UlQb5 d7Po+iS1875vwR5iuXaCwUG515KT1VigFrzk70TYD1Xz4jE0QX6J//F7Q7YqqoeM Q3fPKJ3vsmLqOy0aXqcqz/V3FSIyOxj6sUzSo8qMlMlBWBbU8InXy/gMKm9+FFMj rWSC3iwRfwuNyxQOFQLgwoDxE9TAgfZbFq37Xq7mGMt3evdvDBm+S0JJ+E7KOgik natMzCH2jpjkSVnx+lLNeOJVFbOYbSwg7Vy9en4lYu+bMYLNL0/0NpYSZc9SJBOy hxfRpYxRLbfWZ72Ua47Ilqf3XSypWaADTpZ03cm6GDX2Fn89UKeZaB4FdRS+IXtV yxxaOoage51dLQXT66tUrOszD0SH2mFDiq7naSiG+9XIkhLBmMiXDeGBe352MhIh pPGxdeMjfvCEcNqo/W7ovuR4WVuLTBTJQw8gZUUQAHbB21u9l2ytPhz+S1VWEarU VrhV7BOez2cN0+VweNUeFyoEFZzqlRKiWudUaaqLORmmg8NKJZg= =bBMd -END PGP SIGNATURE-
Bug#1057065: ITP: rust-imap-types -- misuse-resistant data structures for IMAP
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-imap-types Version : 1.0.0 Upstream Contact: Damian Poddebniak * URL : https://github.com/duesee/imap-codec * License : Apache-2.0 or Expat Programming Lang: Rust Description : misuse-resistant data structures for IMAP The imap-types crate provides a complete set of well-designed, misuse-resistant types for the IMAP4rev1 protocol and various extensions. Notably, it does *not* provide parsers, nor serializers, but tries to become the "standard library" for IMAP in Rust that is useful for a broad range of crates. This package is needed for meli (bug#1001084). It will be maintained in the collaborative Debian section of salsa, at https://salsa.debian.org/debian/rust-imap-codec -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVmr6IACgkQLHwxRsGg ASF97A//RItyoOZSJWXdVCjyzvEfyEzueEh3WhvwtOuT0D95h5ffKbl3apSJf1nx G3uKqiebn0k8cxkUeQQ33t1aTSGGr6jC7p3uXbpDHbUsN/sVzoEk5i6N2O0lv3dg 1TG5jUpW6DTudGKbrE0/UHkIkM9Zf9G70ge6a3Ov4i4Dch2lvitnpJ4Nz7wd3M9T df2ixE+RreMzJPBMYJKSHDkzl9GDaPcTor5RTHbPnU3WesUyZw/sscGoA2iVQpsI jCYuYJDXF8rDSoYYjjDn0nJBT+poq6Jw6wSiOjcbyTPqCNo+S4miHIazJzMzBiZ2 PpbzPyIZN2mMJOMXhgSCcyjoyrQZFWgDg2e9ag8kKOU5Y9I4OBj7gsakx/bzxeSw UeD1wnj6yI/9kzmBkc8opXrwLtYOGyntXW3En8UwQUiMPWIPfuSAQpZL+Y60AmTu h5TYh91ZMIDcRtmjqzwaigl6kyDZNL9J+5+lw4ZnEySUJvwPYoc6YsYole7Lexto zCWvBbXbKdqbtAyKVFsvj3d+hBU967EwYC0xAhmqyNpxNHVvn8gb/ffuFe9qwrWk hX7iAs8sU7YeLEQkP5lrQY55tNj3U/7yMJDd9ce/keueoR5kW/e30zPi9EhUWXHb 2e/1/NREk8wXejGsb7O3gS1H10gi5jAAGvjkpF6fLehAd2GS5f4= =a5C7 -END PGP SIGNATURE-
Bug#1057063: ITP: rust-strfmt -- rust library for formatting dynamic strings
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-strfmt Version : 0.2.4 Upstream Contact: Garrett Berg * URL : https://github.com/vitiral/strfmt * License : Expat Programming Lang: Rust Description : rust library for formatting dynamic strings strfmt is a rust library for formatting dynamic strings. It is a library is for rust developers who want to bring rust-like formatting to non-static strings. This package is needed for recent releases for btm. It will be maintained in the Debian section of salsa, at https://salsa.debian.org/debian/rust-strfmt -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVmnuQACgkQLHwxRsGg ASHvbw//cezjOWl7N/r18kJSC+zX+BwhpOOQZQFj6cUWDF12nbTK2trTlkgmnlRv tvdDO6yH0v+CQOIBsrqvIvM9oifYTl8eFHsuAC7KEIWHJ4ri+H5pduCosclIHO+4 m53/6QS40TLemWB3rissmL4QO2Bv5U5BzgcULk0TJ6CnMy50YaP5WOfhaL5/oPcC vLWHA9vfvgydQkTcXsUuqRXEzbLcowvLA6T+wg6knpudPn/D5In9xuvNmK1UCUN6 okpc5npyCbv89qpQywZQRNandB7U3+6ZJbHQH4bEEpAq8FD6QzUNK1vOun/jioqU 1zM/clDR6wbq2ikGkkRrRwxHjmzhAEviCWaOhnValta2f1IUh0zDNhtEUbDFd6B3 fNQAutAwMt24xSU8o/z9Nch3Yopp2skeq1JPhTFav1/ERZjdZavBRq7fXiHkrfDQ ECRdTVv4QGXmN5byyxUvuANdkc1RrOKU7GMFpyjWdwObkb5t6Ny0Pi+VVgFeMYRb C2fg9lf5xwuDWCwu3AYesb1bPBnIXlodWKRJrADSifVnNLoZh3fyDie1D4gbhmOD U/hGuSkx6dqh2gp2wWfm5IP/fVC9KoGLCVFY8NZ+iuAq+mZA2IFc/aN0DPRwgEjJ I2RzvE7yxwp5FKzPcCUUMIr92wcpeqBjllZ7GWfPw+HBqNIX6jY= =wN7u -END PGP SIGNATURE-
