Re: finally end single-person maintainership
On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote: > - I love git. > - I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. > - I like salsa. (though I think for many new contributors this is rather > a barrier "why not use github" directly. Also salsa is Debian only, > which also is a barrier for some.) > - I love autopkgtests. > - I hardly every look at the autopkgs logs on salsaci, cause I find > them incomprehensible and the javascript "UX" makes me wanna chop wood. > - I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. I agree with everything you say here! Wrt git-buildpackage, I'd like to add that personally, I respect the gbp authors and maintainers and it's a very useful tool to bring together some complex workflows and in particular successfully move a lot of people over from svn-buildpackage. I do however agree that there's too much magic. Some of that is inherited from the Debian-specific tooling it sits on top of: I also think there's too much magic and/or complexity in debuild and dpkg-buildpackage. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: finally end single-person maintainership
Hi all, hi Holger, On Di 09 Apr 2024 18:37:23 UTC, Holger Levsen wrote: hi, just adding some random data points to this thread: - I love git. - I very much dislike git-buildpackage, too much magic. I try to avoid it where I can. - I like salsa. (though I think for many new contributors this is rather a barrier "why not use github" directly. Also salsa is Debian only, which also is a barrier for some.) - I love autopkgtests. - I hardly every look at the autopkgs logs on salsaci, cause I find them incomprehensible and the javascript "UX" makes me wanna chop wood. - I also think disallowing single-person maintainership would be very unwise, though I agree team maintenance in general is probably better than single-person maintainership. Still disallowing single-person maintainership doesnt make a team and motivation lost is often motivation lost forever. Very well summarized, fully agreeing with the above, esp. the part about single-person maintainership (let's simply keep it and, at the same time, encourage people to work in teams). Also regarding gbp, my packaging workflow does not require it (debian/-folder-only in Git). Being enforced to use some other pkg'ing style would reduce my fun and end up with less productivity, I fear. The gbp workflow has its pros, but for me it is a too complex overhead without much gain to the end result (the uploaded package). Debian is about freedom, so let's apply that to free choice of the tooling to be usable. light+love, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
Re: finally end single-person maintainership
On Fri, Apr 12, 2024 at 09:53:29AM +0100, Jonathan Dowland wrote: > On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote: [...] > I agree with everything you say here! :) > Wrt git-buildpackage, I'd like to add that personally, I respect the gbp > authors and maintainers and it's a very useful tool to bring together > some complex workflows and in particular successfully move a lot of > people over from svn-buildpackage. absolutly. > I do however agree that there's too much magic. Some of that is > inherited from the Debian-specific tooling it sits on top of: I also > think there's too much magic and/or complexity in debuild and > dpkg-buildpackage. absolutly. Thanks for these additions! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “I'll tell you what freedom is to me No fear.” (Nina Simone) signature.asc Description: PGP signature
Bug#1068861: ITP: rlottie-qml -- rLottie QML module
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rlottie-qml Version : 0.1~git Upstream Contact: Michele (@mymike00) * URL : https://gitlab.com/mymike00/rlottie-qml * License : GPL-3 Programming Lang: C++ / QML Description : rLottie QML module rLottie is a platform independent standalone C++ library for rendering vector based animations and art in realtime. . This package provides a QML module binding for rLottie.
Bug#1068862: ITP: node-microsoft-fast -- FAST monorepo, containing web component packages, tools, examples, and documentation
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-microsoft-fast Version : 0~20240320-1 Upstream Contact: https://github.com/Microsoft/fast/issues * URL : https://github.com/Microsoft/fast * License : Expat Programming Lang: JavaScript Description : FAST monorepo, containing web component packages, tools, examples, and documentation FAST is a collection of technologies built on Web Components and modern Web Standards, designed to help you efficiently tackle some of the most common challenges in website and application design and development. * Create reusable UI components with `@microsoft/fast-element`, all based on W3C Web Component standards. * Use `@microsoft/fast-foundation` library to rapidly build W3C OpenUI-based (https://open-ui.org/) design systems without re-implementing component logic. * Leverage modern, W3C standards-based SSR for Web Components by plugging in `@microsoft/fast-ssr`. * Bring all the pieces together to build SPAs and rich experiences with our Web Components router by installing `@microsoft/fast-router`. * React users can drop in `@microsoft/fast-react-wrapper` to turn any Web Component into a native React component. * Integrate FAST Web Components with any library, framework, or build system. This monorepositopry will provide the following packages: * node-microsoft-fast-colors * node-microsoft-fast-element * node-microsoft-fast-foundation * node-microsoft-fast-react-wrapper * node-microsoft-fast-router * node-microsoft-fast-ssr * node-microsoft-fast-web-utilities This is required to update node-jupyterlab.
Re: finally end single-person maintainership
On Tue, 9 Apr 2024 18:37:23 +, Holger Levsen wrote: >- I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Agreed. > Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. Agreed. It is too easy for three singel maintainers to form a pro forma team where everyone works on their packages and not on the others'. You cannot enforce team work. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: finally end single-person maintainership
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel wrote: >Also regarding gbp, my packaging workflow does not require it >(debian/-folder-only in Git). Being enforced to use some other pkg'ing >style would reduce my fun and end up with less productivity, I fear. >The gbp workflow has its pros, but for me it is a too complex overhead >without much gain to the end result (the uploaded package). The debian/-only layout was quite common in the svn days and back then we had adequate tooling to support that but those tools have rotted away, it feels unnatural to me, and, frankly, exim's debian/-only layout (that I introduced myself fifteen^wtwenty years ago) is the main reason why I am a mostly inactive member on the exim team since I still don't know any more how to properly build the package. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Bug#1068863: ITP: python3-atcom -- A tool which makes AT communication easier.
Package: wnpp Severity: wishlist Owner: Cody Scott X-Debbugs-Cc: debian-devel@lists.debian.org, cody.sc...@giatec.ca * Package name: python3-atcom Version : 0.4.3 Upstream Contact: Sixfab * URL : https://pypi.org/project/atcom/ * License : Apache Version 2.0 Programming Lang: Python Description : A tool which makes AT communication easier. This is a Python package that provides utilities to use cellular modems. I am using it in a travelling device. There appears to be an alternative that I haven't used. https://pypi.org/project/atcom/ I plan to maintain it.
Re: finally end single-person maintainership
On Tue, 9 Apr 2024 20:51:45 +0200, Gioele Barabucci wrote: >Asking maintainers "to use git" means: please push your changes, even >those unreleased to a public git repository (salsa, github, codeberg, >your own domain...), so other people can contribute 1) knowing that they >are working against the same sources the maintainer has on their hard >drive, and 2) using git-based workflows. To have this actually work, I'd like to have published best-practice things such like "branches with a 'wip-' prefix can have their history rewritten any time" so that I can use git rebase --autosquash --interactive to fix my commit errors even on branches that I have already pushed without feeling bad for doing so. >dgit is both a Web interface to browse git repositories as wells as a >system to access the Debian archive as if it were a git repository, so >you can "dgit push" a branch and have the resulting binary uploaded to >the archive. (Yes, I'm simplifying here, but that's the gist.) It is also not well documented for a beginner. I think that the dgit docs are fine for someone who is already familiar with the tool and has been using it for some time, but I have tried to read myself into dgit multiple times and utterly failed with that. >Salsa is a forge, i.e. a combination of a Web interface, a git server, >and a set of integrated features. In comparison to dgit, salsa has, like >most forges: > >* Merge requests: where people can suggest changes and discuss them with >line-based comments (accessible via email, no need to use the Web interface) > >* Continuous integration pipelines: as soon as you push a commit, >Salsa-CI will try to build a package, cross build it, test it against >piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI >developers). > >* Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla, >but funnily enough not BTS). > >* Project specific wikis, snippets, Docker images. > >* And with tag2upload salsa fulfills 50% of dgit functionality. And, a web interface which make the learning curve a lot less steep. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: finally end single-person maintainership
On 12/04/24 15:00, Marc Haber wrote: On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel wrote: Also regarding gbp, my packaging workflow does not require it (debian/-folder-only in Git). Being enforced to use some other pkg'ing style would reduce my fun and end up with less productivity, I fear. The gbp workflow has its pros, but for me it is a too complex overhead without much gain to the end result (the uploaded package). The debian/-only layout was quite common in the svn days and back then we had adequate tooling to support that but those tools have rotted away, it feels unnatural to me, and, frankly, exim's debian/-only layout (that I introduced myself fifteen^wtwenty years ago) is the main reason why I am a mostly inactive member on the exim team since I still don't know any more how to properly build the package. This is not an endorsement of debian/-only repos, but building debian/-only packages using gbp is not hard: $ git clone https://salsa.debian.org/exim-team/exim4.git $ cd exim4 $ cat < debian/gbp.conf [DEFAULT] export-dir = ../ overlay = True debian_branch = master EOF $ origtargz $ gbp buildpackage --git-ignore-new --git-no-create-orig (This is more a praise of gbp rather than a defense of debian/-only repos.) -- Gioele Barabucci
Bug#1068868: ITP: python3-pyzmq -- Python bindings for 0MQ
Package: wnpp Severity: wishlist Owner: Cody Scott X-Debbugs-Cc: debian-devel@lists.debian.org, cody.sc...@giatec.ca * Package name: python3-pyzmq Version : 25.1.2 Upstream Contact: ZeroMQ * URL : https://pyzmq.readthedocs.io/en/latest/ * License : BSD Programming Lang: Python Description : Python bindings for 0MQ This will be used by Python applications that use ZeroMQ. There doesn't appear to be any other Python bindings for ZeroMQ. I plan to maintain it and I'm looking for a sponsor.
Re: Debian Policy 4.7.0.0 released
Please do it yourself by following the instructions here: https://lists.debian.org/debian-devel/ Maycon Antônio wrote on 08/04/2024 at 17:44:20+0200: > Please cancel my name from this list, thank you. > > On Sun, 7 Apr 2024 at 12:32, Sean Whitton wrote: >> >> Hello everyone, >> >> I just pushed version 4.7.0.0 of the Debian Policy Manual and related >> documents to sid. Below you will find the significant normative changes >> from the previously-announced release of Policy (4.6.2.0). >> >> Thank you to everyone who contributed to this release, including those >> named in the changelog who formally proposed and seconded wording, and >> also those who otherwise participated in the discussions leading up to >> the wording change proposals. >> >> I would particularly like to call out Guillem Jover for a big chunk of >> work standardising the usage of dpkg-related terminology, and Stéphane >> Blondon for a new Debian-specific Sphinx theme for our html edition. >> Holger Wansing and Dmitry Shachnev did a lot of follow-up work to get >> that format published properly on the web mirrors. >> >> =*=*=*= >> >> 2.2.1 >> Document that source packages in the *main* archive area may build >> binary packages in the *contrib* archive area, although this is >> discouraged unless the source package is inconvenient to split. >> This does not relax the requirement that source packages in *main* >> must not have build dependencies outside of *main*. >> >> 2.2.2 >> The ``non-free-firmware`` archive area has been added. >> >> 3.9 >> Maintainer scripts should use native overriding mechanisms instead >> of dpkg-divert, wherever possible. Maintainer scripts must not >> divert configuration files used by systemd components. >> >> Maintainer scripts must not use the alternatives system for systemd >> configuration files. >> >> 4.8 >> Hard links are permitted in source packages. >> >> 4.9 >> For packages in contrib, and for packages in non-free with >> ``Autobuild: yes``, required targets in d/rules are no longer >> permitted to attempt network access. Previously, only packages in >> main had this restriction. >> >> 5.6.13 >> The ``Description`` field is not present in ``.changes`` files if no >> binary packages are being uploaded. >> >> 5.6.19 >> The ``Binary`` field is not present in ``.changes`` files if no >> binary packages are being uploaded. >> >> 6.3 >> Packages that automatically start or stop system services must >> include ``systemd`` units unless the service is only intended for >> use on systems running alternative init systems. >> Previously, ``systemd`` also supported init scripts, but that >> support is being removed. >> >> -- >> Sean Whitton
Re: finally end single-person maintainership
On Wed, 10 Apr 2024 22:44:25 +0200, Andreas Tille wrote: >'Require' is probably the wrong word. I simply have heard from several >potential young contributors that they feel blocked by the tooling and >specifically not everything in Git. That does not only apply to young contributors. I am an old fart and I still shy back from packages where I need to familiarize myself with an uncommon packaging toolchain. >> then pull them, >> maybe into different branches, > >git-buildpackage maintains two or three branches: The main packaging >branch and an upstream branch. The pristine-tar branch is optional (but >default in the teams I'm working in) And not (any more?) default in the tools, thus easily forgotten. Greetings MArc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: finally end single-person maintainership
Hi, On 13.04.24 00:19, Marc Haber wrote: 'Require' is probably the wrong word. I simply have heard from several potential young contributors that they feel blocked by the tooling and specifically not everything in Git. That does not only apply to young contributors. I am an old fart and I still shy back from packages where I need to familiarize myself with an uncommon packaging toolchain. We cannot help people who want Debian packaging to work like Git, because Git is not a packaging tool, and neither are the forges. We're not even doing anyone a favour by introducing the git based workflows first, because about half of the techniques people know from git will conflict with something git-buildpackage or dgit does, and without a mental model of how Debian packaging is supposed to work standalone, they have no chance of solving even the simplest problem. For example, any repository that does not list debian/files and debian/*.substvars in the gitignore will fail to build twice in a row, because these files are created and are subsequently untracked. Only Debian packaging knowledge can tell you that these should never be checked in and can be ignored -- or we make people reliant on a magic tool to set it up properly for them. Once people are familiar with how Debian packaging works, we can introduce the git interfaces on top. Before that, git is more of a hindrance than a benefit to new contributors, precisely because it looks familiar, but the knowledge is not transferable. Simon OpenPGP_signature.asc Description: OpenPGP digital signature
Re: finally end single-person maintainership
On Fri, 12 Apr 2024 at 17:17, Simon Richter wrote: > > Hi, > > On 13.04.24 00:19, Marc Haber wrote: > > >> 'Require' is probably the wrong word. I simply have heard from several > >> potential young contributors that they feel blocked by the tooling and > >> specifically not everything in Git. > > > That does not only apply to young contributors. I am an old fart and I > > still shy back from packages where I need to familiarize myself with > > an uncommon packaging toolchain. > > We cannot help people who want Debian packaging to work like Git, > because Git is not a packaging tool, and neither are the forges. > > We're not even doing anyone a favour by introducing the git based > workflows first, because about half of the techniques people know from > git will conflict with something git-buildpackage or dgit does, and > without a mental model of how Debian packaging is supposed to work > standalone, they have no chance of solving even the simplest problem. > > For example, any repository that does not list debian/files and > debian/*.substvars in the gitignore will fail to build twice in a row, > because these files are created and are subsequently untracked. Only > Debian packaging knowledge can tell you that these should never be > checked in and can be ignored -- or we make people reliant on a magic > tool to set it up properly for them. > > Once people are familiar with how Debian packaging works, we can > introduce the git interfaces on top. Before that, git is more of a > hindrance than a benefit to new contributors, precisely because it looks > familiar, but the knowledge is not transferable. New contributors won't start in a vacuum, most will start contributing first to existing projects on Salsa, which are already set up and configured to do what is needed, if it is needed. Git is the bare minimum these days, and has been for years. Salsa is the best thing that has happened to Debian the past decade, and the Salsa team will forever have my gratitude for the great job they have done and continue to do.
Re: finally end single-person maintainership
On Tue, Apr 09, 2024 at 06:37:23PM +, Holger Levsen wrote: > - I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. We still like those VCS-in-VCS workflows over everything else. Those debian/patches, where you need to call something special and can't just re-use upstreams CI tests. And which conflict outside of git with the next upstream version. I just stopped that and use git alone. > - I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. What would that even mean? What is a team anyway? Bastian -- Beam me up, Scotty, there's no intelligent life down here!
Bug#1068899: ITP: qtrvsim -- RISC-V CPU simulator for education purposes
Package: wnpp Severity: wishlist Owner: Bo YU X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ri...@lists.debian.org * Package name: qtrvsim Version : 0.9.7 Upstream Contact: p...@cmp.felk.cvut.cz * URL : https://github.com/cvut/qtrvsim * License : GPL-3.0 Programming Lang: C++, Python, shell Description : RISC-V CPU simulator for education This is a widely recommended riscv emulator in the riscv community so I want to bring it to Debian also. The simulator accepts ELF statically linked executables compiled for RISC-V target (--march=rv64g). The simulator will automatically select endianness based on the ELF file header. Simulation will execute as XLEN=32 or XLEN=32 according to the ELF file header. 64-bit RISC-V ISA RV64IM and 32-bit RV32IM ELF executables are supported. Compressed instructions are not yet supported. You can use compile the code for simulation using specialized RISC-V GCC/Binutils toolchain (riscv32-elf) or using unified Clang/LLVM toolchain with LLD. -- Regards, -- Bo YU signature.asc Description: PGP signature
