Re: Simpler git workflow for packaging with upstreamless repositories
On Sat, Dec 07, 2024 at 10:39:43PM +0500, Andrey Rakhmatullin wrote: > No, there is clearly no consensus on unifying any workflows. Everyone > thinks their workflow is superior and canneeds to stay. I agree with the first sentence but I think the 2nd sentence is too much drama. Those many workflows exists for reasons, some good, some not so good. Even if we agreed on the one superiour workflow tomorrow (which won't happen just because some people think that would be a good idea, but let's assume so), it would still take years to achieve. Which is not to say that cannot be done, but changing 30k source packages takes years, probably rather a decade. Changing 2000 people decades old habbits will probably take even longer. What could be done much more easily however, would be to agree on one default recommended workflow & toolchain for NEW packages and people. Maybe. OTOH, some of us do this already, eg the rust team. And because we are the Debian rust team, we also have exceptions to this rule... ;) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Klimakatastrophe bedeutet kompletter sozialer Kollaps. signature.asc Description: PGP signature
Re: Should l10n packages be Recommends or Suggests?
On 12/6/24 6:40 AM, Helmut Grohne wrote: > I no longer buy the argument for conserving space when a typical NixOS > installation takes 100GB and people are happy with it. As long as we > provide the mechanisms to trim installations, those who need to conserve > space should be doing the work of opting out. While I had many problems with too small disks on Cloud servers running NixOS, we are also talking about closer to 20-25 GB than 100 GB. (For servers with a couple of services running and also having been upgraded a couple of times - albeit with GC running regularly.) Kind regards Philipp Kern
Re: Simpler git workflow for packaging with upstreamless repositories
On Sat, Dec 07, 2024 at 02:34:20PM +0100, Andrea Pappacoda wrote: > Hi all, I've tried catching up with the whole thread, but didn't fully yet. > So excuse me if this has been asked/answered before. > > On Tue Dec 3, 2024 at 3:40 AM CET, Sean Whitton wrote: > > Then just make one: 'git deborig'. > > > > I appreciate not everyone is happy with this, but it solves the problem. > > It seems that we're all agreeing on trying to unify our different workflows > as much as possible. No, there is clearly no consensus on unifying any workflows. Everyone thinks their workflow is superior and canneeds to stay. > Why do we have `git deborig`, `gbp export-orig`, `origtargz`, etc.? They are parts of different incompatible workflows. > Couldn't we decide to unify on a single "front end" command, which > chooses different backends automatically depending on the situation? That seems unlikely. It can't be a command that runs the full workflow and it can't be a set of separate commands that run separate parts of different workflows because the parts themselves are unlikely to be possible to uinify. > It would be a starting point. To new contributors, we could say, for > example, "to generate the tarball, just run origtargz", independently of > whether they use gbp, git-debrebase, no git at all, etc. Ideally one shouldn't need to run any separate commands to generate the tarball from a repo. E.g. the gbp workflow doesn't require this. Additionally, e.g. gbp expects the tarball to be in the build-dir, while no unrelated tools could know the location of the gbp build-dir. See? -- WBR, wRAR signature.asc Description: PGP signature
Re: Simpler git workflow for packaging with upstreamless repositories
On 07/12/2024 14:34, Andrea Pappacoda wrote: It seems that we're all agreeing on trying to unify our different workflows as much as possible. Why do we have `git deborig`, `gbp export-orig`, `origtargz`, etc.? Couldn't we decide to unify on a single "front end" command, which chooses different backends automatically depending on the situation? It would be a starting point. To new contributors, we could say, for example, "to generate the tarball, just run origtargz", independently of whether they use gbp, git-debrebase, no git at all, etc. Bye! https://xkcd.com/927/ --alec
Bug#1089490: ITP: ibus-varnam -- IBus engine for Varnam input method
Package: wnpp Severity: wishlist Owner: Subin Siby X-Debbugs-Cc: debian-devel@lists.debian.org, m...@subinsb.com * Package name: ibus-varnam Version : 1.6.4 Upstream Contact: Subin Siby * URL : https://github.com/varnamproject/govarnam-ibus * License : MPL Programming Lang: Go Description : IBus engine for Varnam input method IBus engine for Varnam (https://www.varnamproject.com). Easily type Indian languages on Linux desktops. fcitx wrapper for Varnam is already packaged: https://salsa.debian.org/input-method-team/fcitx5-varnam I am part of Debian Input Method Team. I will package and maintain it. I would need a sponsor to upload it.
Bug#1089218: ITP: node-svgdotjs-svg.draggable.js -- plugin for the library node-svgdotjs-svg.js
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-svgdotjs-svg.draggable.js Version : 3.0.4 Upstream Author : Wout Fierens * URL : https://github.com/svgdotjs/svg.draggable.js * License : Expat Programming Lang: JavaScript Description : plugin for node-svgdotjs-svg.js to make elements draggable. This plugin makes it easy to make any element created with SVG() draggable. The plugin fires 4 different events * beforedrag (cancelable) * dragstart * dragmove (cancelable) * dragend . node-svgdotjs-svg.js is a library for Node.js which provides support for the SVG spec. . Node.js is an event-based server-side JavaScript engine. There currently no package in Debian to support SVG graphics in web page with an easy API. I shall use packages node-svgdotjs-svg.js and node-svgdotjs-svg.draggable.js to implement a lightweight interactive editor for digraphs expressing dependencies between students' registered options and books to be lent from the high school library, for the package slm, which I own. Besides, the goal of packages node-svgdotjs-svg.js and node-svgdotjs-svg.draggable.js are much more general. I uploaded this package to https://salsa.debian.org/js-team/node-svgdotjs-svg.draggable.js signature.asc Description: PGP signature
Re: Should l10n packages be Recommends or Suggests?
Hi Ted, On Thu, Dec 05, 2024 at 01:28:11PM -0500, Theodore Ts'o wrote: > In the case of e2fsprogs, server and container image *really* don't > have any need of translations --- and in fact, from my perspective, > it's often actively harmful, when users send me e2fsck logs in > Vietnamese and I have to try to figure out was going on. I suggest that you completely ignore containers and servers for the purpose of judging Recommends vs Suggests, but take them into account for judging Depends vs Recommends. Basically all of the container image creation tools I've interacted with immediately turn off installation of Recommends so to them Recommends and Suggests behave the same. The slim image variant for docker/podmand goes beyond and deletes much of /usr/share/doc. For server deployments, what is in charge of deciding whether to install e2fsprogs-l10n is probably Ansible, Chef, Puppet or something along those lines. To these areas, the crucial step has been separating the translations into an optional component. Thank you. If you disregard these deployments, e2fsprogs-l10n suddenly becomes relevant to most usual installations. Admittedly, I never install it. The primary values in action I see here are: * Enable advanced people to trim their installations by separating non-essential space consuming parts into optional packages (i.e. exactly what happened with e2fsprogs-l10n). * Have it just work by default (i.e. Recommends). I no longer buy the argument for conserving space when a typical NixOS installation takes 100GB and people are happy with it. As long as we provide the mechanisms to trim installations, those who need to conserve space should be doing the work of opting out. My impression of earlier discussions of this matter is that this opinion should achieve at least rough consensus, but maybe things changed. Helmut
Re: Simpler git workflow for packaging with upstreamless repositories
Hi all, I've tried catching up with the whole thread, but didn't fully yet. So excuse me if this has been asked/answered before. On Tue Dec 3, 2024 at 3:40 AM CET, Sean Whitton wrote: Then just make one: 'git deborig'. I appreciate not everyone is happy with this, but it solves the problem. It seems that we're all agreeing on trying to unify our different workflows as much as possible. Why do we have `git deborig`, `gbp export-orig`, `origtargz`, etc.? Couldn't we decide to unify on a single "front end" command, which chooses different backends automatically depending on the situation? It would be a starting point. To new contributors, we could say, for example, "to generate the tarball, just run origtargz", independently of whether they use gbp, git-debrebase, no git at all, etc. Bye!
