Re: finally end single-person maintainership
On 12.04.24 19:28, Luca Boccassi wrote: 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. +1 here 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. Yepp - a very special thanks to the complete Salsa team. After seeing the numbers from Ganneff yesterday their work to set this up and keep it running is really impressive. Furthermore I think that not only salsa was the best thing which happened to debian, but github/gitlab for open source in general. Just have a look how many projects are nowadays hosted on github/gitlab. Greetings Patrick (winnie) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ win...@debian.org/patr...@winnertz.eu ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 8D208172388840811B85DA1CC6D50A4188C70E43 ⠈⠳⣄ The people who refer to the pandemic in the past tense and climate change in the future tense are the reason everything is going to shit.
Re: finally end single-person maintainership
Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter: > > 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. Sorry, no. We should teach people to build in a chroot which does not leave this stuff inside local debian/ dir. > 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. >From my mentoring work I can confirm this sequence is not necessary for everyone. You might have different experience, but I would not subscribe this as a general rule. Kind regards Andreas. -- https://fam-tille.de
Re: finally end single-person maintainership
On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote: > > 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. > > Sorry, no. We should teach people to build in a chroot which does > not leave this stuff inside local debian/ dir. I was afraid that's what "or we make people reliant on a magic tool to set it up properly for them" means. (technically, the way to not touch the workdir at all is gbp's --export-dir, which *is* a magic mode of a magic tool in the world where neither are parts of the default workflow but at the same time it's so much better than not doing this) -- WBR, wRAR signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote: > Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter: > > > > 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. > > Sorry, no. We should teach people to build in a chroot which does > not leave this stuff inside local debian/ dir. True. Or add relevant files and stash (which is what I do for non-chroot builds). > > 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. > > >From my mentoring work I can confirm this sequence is not necessary for > everyone. You might have different experience, but I would not subscribe > this as a general rule. To add in more perspective to it -- I started contributing to debian in 2019. I don't think I would have the motivation to contribute further had it not been for a git based workflow and salsa. In the sense that it'd have made it an uphill journey for me to know how to send patches. Git was something I was familiar with so I did not have to spend time struggling with basic things. Like Andreas, I have mentored many new comers too, advocated them to be DMs/DDs and I never found any of them complaining about git workflow so what is quoted above is not true as a general rule. People who did debian packaging without git for a long time and then had to switch/use a git based workflow might find it a little counter-intuitive which also stems from the fact that people generally resist change. But the same is not necessarily true for new contributors. On Sat, Apr 13, 2024 at 01:16:37AM +0900, Simon Richter wrote: > 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. I did not have a solid understanding of how debian packaging works standalone, and had only very little idea about most of the things when I started -- it only gets better with time. But I believe I did solve at least some simple problems to qualify for becoming a DD :-) Best, Nilesh signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Sat, 13 Apr 2024 at 10:11, Salvo Tomaselli wrote: > > > New contributors won't start in a vacuum, most will start contributing > > first to existing projects on Salsa > > Or maybe they start with an ITP+RFS… was that an informed statement or a > supposition? It is my experience in receiving patches from non-project members. It is also my experience that every such contributor I talked to rated the ITP/RFS and other mail-based bug reporting on a range from hilarious (in a bad way, as in: "it's 202x and you still do that? seriously?") to infuriatingly frustrating and confusing.
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
On Thu, 2024-04-11 at 16:46 +, mYnDstrEAm wrote:
>
> For example, I think a good approach to this would be something like
> this (if the user is low on root partition disk space):
> 1. asking for *at least* 400MB to be available
> 2. if a parameter for stepwise is set or it detected low free disk
> space:
> 3. downloading the first 300 MB or so of packages
> 4. installing these
> 5. deleting the cached packages from /var/cache/apt/archives/
> 6. downloading the next batch up to the storage limit set at start
> 7. and so on (without exiting in-between)
>
quick and dirty and not tested:
while apt -s upgrade | grep '^Inst' | head -1 | awk '{print $2}' |
xargs apt install; do apt clean; done
Use head -10 or whatever fits for more/less packages.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
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-
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
On Thu, Apr 11, 2024 at 04:46:03PM +, mYnDstrEAm wrote: > With the two commands above one can already split it up into two steps but > especially the second command still requires a lot of disk space. I am going to assume that your "a lot of disk space" stems from the *.deb files that are downloaded. If so, you can e.g. attach an USB disk/ drive and mount it e.g. under /media/apt-archives Tell apt to use that directory instead of /var/cache/apt/archives, e.g.: apt upgrade -o dir::cache::archives=/media/apt-archives (for some more free MBs you could 'apt clean' and then move dir::cache elsewhere, but for that you need to create some directories in the target location and the binary caches are not THAT large to make it really worthwhile in practice. Similar for other files like /var/lib/apt aka dir::state::lists) Instead of an USB drive you could do the same with e.g. an SD card, drop them into RAM (if your device has surprisingly more RAM than disk) or even use a network share (NFS, sshfs, … you name it). The filesystem is not usually a concern (as in: even fat32 should work given we encode away the : in epochs). Note that whoever has write access to the files on the storage (or in case of unencrypted transfer, also everyone who can meddle with transfer over the network) could use that to attack you as apt (well, apt will casually check them first, but after that and dpkg, who actually interacts with them the most) will assume that the files in /var/cache/apt/archives (or where ever else you stored them and told apt to use them) are valid & trusted. Note also that apt uses for its space check statvfs(3) f_bavail, as in, depending on how you configured your disk, it should have a couple of additional free blocks in reserve (typically 5%, see tune2fs(8) -m). If you know what you are doing, you could decrease that value. Note that the value apt displays is only an estimate, powered by what the individual packages claim (via dpkg), which is an estimate. Also, if you happen to have a 2GB installed, the upgrade will roughly take an additional 2GB as dpkg would first extract the new files along the old ones and then replace them in one swoop – so for a bit, you have that package installed two times. Multiple this by group size, divide by unchanged files and sprinkle some salt over it for flavour. Predictions are hard, especially about the future. I would in general not recommend to try approaches like upgrading individual packages as that easily leads unsuspecting users into situations that nobody else has encountered before: aka bugs in packages that nobody else will encounter as they are either hidden by the involved set usually being upgraded together as intended™ or – which tends to be even worse – the breakage is known but ignored on purpose as the solution is far worse than the problem (at least for everyone doing upgrades the normal way – example: usrmerge). Also, but that is just an aside, people grossly overestimate how easy it is for packages to be upgraded individually (compare: t64 testing migration). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068823: (No Subject)
Thanks guys, these are very useful methods and I'll mention these as alternatives to disk cleanups recommended at https://unix.stackexchange.com/q/774199/233262 (this would probably very useful to have at places about upgrades failing due to disk space issues even though people only look these up once the problems already occurred). However, the problem of the upgrade requiring more disk space than displayed at first remains and the command by Zeimetz can't be used with a built-in rememberable well-known command like sudo apt-get upgrade --stepwise I don't think peripheral devices would be the common case for personal computers, rather one would simply specify a directory on a partition that is larger than the root partition. Upgrading individual packages is not what this is about in case that wasn't clear. It's one upgrade but it's separated into several steps where one batch of packages are download and installed, the cache deleted, and then the next batch. If the upgrade breaks in between due to disk space, because the user aborted it, a crash, or an error, then only some packages are upgraded...a stepwise upgrade could if anything be a way to *avoid* that (or at least interruptions due to disk space problems) and to make them less problematic. The key thing is that it would be usable with a simple command (such as by adding --stepwise)...if that command only executes a few already existing commands with no apt changes required for the basic functionality of this, that's all the better.
Bug#1068823: (No Subject)
Control: reassign -1 src:apt Control: severity -1 wishlist On Sat, Apr 13, 2024 at 1:00 PM mYnDstrEAm wrote: > Thanks guys, these are very useful methods and I'll mention these as > alternatives to disk cleanups recommended at > https://unix.stackexchange.com/q/774199/233262 (this would probably very > useful to have at places about upgrades failing due to disk space issues even > though people only look these up once the problems already occurred). > > However, the problem of the upgrade requiring more disk space than displayed > at first remains and the command by Zeimetz can't be used with a built-in > rememberable well-known command like sudo apt-get upgrade --stepwise Personally, I don't think a machine that has that limited storage ought to be upgraded using apt from one Debian stable release to another. I suggest upgrading the storage first. If that's not possible, I recommend replacing the OS with a new image of Debian rather than trying to use apt to upgrade a few packages at a time. As has already been mentioned, it is not supported to arbitrarily break apt updates up like that to upgrade from say Debian 12 to the not-yet-released Debian 13. Thank you, Jeremy Bícha
Processed: Re: Bug#1068823: (No Subject)
Processing control commands: > reassign -1 src:apt Bug #1068823 [general] Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device" Bug reassigned from package 'general' to 'src:apt'. Ignoring request to alter found versions of bug #1068823 to the same values previously set Ignoring request to alter fixed versions of bug #1068823 to the same values previously set > severity -1 wishlist Bug #1068823 [src:apt] Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device" Severity set to 'wishlist' from 'normal' -- 1068823: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068823 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1068945: ITP: rust-names -- generator for random names suitable for containers, projects, applications etc.
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-names Version : 0.14.0 Upstream Contact: Fletcher Nichol * URL : https://crates.io/crates/names * License : MIT Programming Lang: Rust Description : generator for random names suitable for containers, projects, applications etc. A random name generator with names suitable for use in container instances, project names, application instances, etc. This is a dependency for zellij-utils, in turn a dependency that will be needed to package zellij.
Re: finally end single-person maintainership
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel wrote: > Debian is about freedom, so let's apply that to free choice of the tooling > to be usable. I disagree. "Freedom" is about Free Software, so-called freedom in packaging has high costs as people (who look at more than their "own" favourite packages) need to known and learn a plethora of packaging helper and styles and modes etc. This causes energy drains and slows down the whole project. Let's please stop this. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1068948: ITP: hiredict -- minimalistic C client library for Redict
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian-devel@lists.debian.org * Package name: hiredict Version : 1.3.1 Upstream Contact: Drew DeVault * URL : https://codeberg.org/redict/hiredict * License : LGPL-3.0-only Programming Lang: C Description : minimalistic C client library for Redict hiredict is a minimalistic C client library for the Redict database. It is minimalistic because it just adds minimal support for the protocol, but at the same time it uses an high level printf-alike API in order to make it much higher level than otherwise suggested by its minimal code base and the lack of explicit bindings for every Redict command. . Apart from supporting sending commands and receiving replies, it comes with a reply parser that is decoupled from the I/O layer. It is a stream parser designed for easy reusability, which can for instance be used in higher level language bindings for efficient reply parsing. . The library comes with multiple APIs. There is the synchronous API, the asynchronous API and the reply parsing API. Replacement for hiredis, intended for use with new redict package. Will be maintained within the redict-team. Will need a sponsor. -- Kind regards, Maytham Alsudany signature.asc Description: This is a digitally signed message part
