Re: Q: Ubuntu PPA induced version ordering mess.
IOhannes m zmölnig (Debian GNU|Linux) writes: > anyhow here's my 2¢: > according to you¹, upstream have simply botched their package > versioning, which i would consider *a bug*. > bugs cause pain. AIUI the botching was done by whoever put the PPA together. If that's the same as upstream, fair enough, but it seemed to me (having glanced at the repo) that upstream has been using sane versions throughout. FWIW I'd say that people that installed from a PPA probably know they did that, so can be left to sort themselves out -- especially if they've been pulling Ubuntu PPAs into a Debian install. Well, at least they'll have followed some sort of HOWTO to get it installed. If you could get that HOWTO to be updated with a Debian section that points out that they'll need to remove the PPA as a source, and force ``downgrade'' the package to restore sanity, then that seems like it deals with the problem. It would probably be good to also document the fix on upstream's and/or Debian's wikis. Then you can cheerfully ignore the broken PPA versions. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Q: Ubuntu PPA induced version ordering mess.
Alec Leamas writes: > On 02/07/2024 20:46, Gunnar Wolf wrote: >> Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]: >>> So, at least three possible paths: >>> >>> 1. Persuade users to uninstall PPA packages before installing official >>> packages and also generation 2 PPA packages with sane versions like 5.10.x >>> >>> 2. Use versions like 9000.5.10, 9000.5.12. etc. >>> >>> 3. Use an epoch. >> >> You can also consider a third possible path: Pick a different package >> name. >> >> I am unfamiliar with opencpn to be able to suggest an alternative. But >> given opencpn has never been part of Debian, you could just name your >> package "opencpn-deb". Just to be sure users don't get surprised by >> having two different versions of the same package, it can "Conflict: >> opencpn". Then, you get a blank slate from which you can work your >> versioning as you deem adequate. >> >> It does, yes, introduce some confusion, but I think is the least evil >> option. > > opencpn is part of Debian since many years. However, the major > distribution is through an Ubuntu PPA, the official Debian package is > not that visible and of course outdated in Ubuntu. > > opencpn users are counted in at least thousands. We are trying to > convince the developer community that it's a good idea to use a package > created as an official Debian package rather than an auto-generated > cmake package distributed using the Ubuntu PPA. If someone has gone to the effort of configuring a PPA source, it seems slightly abusive to try and override that choice by playing games with versions. If you do that, and the user has any problem as a result, then the user may be upset enough to "downgrade" to the PPA and pin it, which will burn their goodwill towards Debian, and further entrench the problem you are trying to fix. Alternatively, the PPA maintainer may just adopt the epoch:upstream version now that they are aware of the problem, and then the user gets to flap back and forth between versions from Debian and the PPA as new versions come out and are packaged at differing rates. It seems better to take an "If we build it, they will come" approach. New installs will likely get the Debian version without ever needing to discover the PPA, and the rumour will spread (assuming the Debian package works at least as well) that there's no need to bother with the PPA, and then people will do the work to remove the PPA from their configs, at a time of their choosing. Might it be worth chatting to the PPA maintainer to see it they'd like to be included in the effort to maintain the Debian package? They may discover that it's less effort for all involved doing it as a team. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Q: Ubuntu PPA induced version ordering mess.
On Wed, Jul 03, 2024 at 09:27:03AM +0200, Philip Hands wrote: > IOhannes m zmölnig (Debian GNU|Linux) writes: > > > anyhow here's my 2¢: > > according to you¹, upstream have simply botched their package > > versioning, which i would consider *a bug*. > > bugs cause pain. > > AIUI the botching was done by whoever put the PPA together. > > If that's the same as upstream, fair enough, but it seemed to me (having > glanced at the repo) that upstream has been using sane versions > throughout. <83d8755d-5f57-47e1-bda3-5536b7563...@gmail.com> said it's the upstream. -- WBR, wRAR signature.asc Description: PGP signature
Re: Q: Ubuntu PPA induced version ordering mess.
On 03/07/2024 10:10, Philip Hands wrote: Alec Leamas writes: It seems better to take an "If we build it, they will come" approach. New installs will likely get the Debian version without ever needing to discover the PPA, and the rumour will spread (assuming the Debian package works at least as well) that there's no need to bother with the PPA, and then people will do the work to remove the PPA from their configs, at a time of their choosing. The truth is rather that the rumour will be the current: "Don't use the heavily outdated official package, at least not on Ubuntu" Please see https://lists.debian.org/debian-devel/2024/07/msg00031.html --alec
Re: Q: Ubuntu PPA induced version ordering mess.
hi Alec, please stop mailing this thread and just use an epoch. Before adding^wintroducing an epoch one should consult debian-devel@l.d.o, you have done this, arguments were exchanged and (IMNSHO) no better solution was found, so please do what has done to >1000 source packages in the archive already, and add an epoch. Thanks for caring about free software and it's users. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "A fundamentalist gender binary was a key feature of Nazi racial politics and genocide. (...) It must be said that the reality of transgender identity cannot be challenged. Transgender people have existed throughout history." https://www.lemkininstitute.com/statements-new-page/statement-on-the-genocidal-nature-of-the-gender-critical-movement%E2%80%99s-ideology-and-practice signature.asc Description: PGP signature
Bug#1074793: ITP: git-ubuntu -- maintain an Ubuntu source package in a git tree
Package: wnpp Severity: wishlist Owner: Benjamin Drung X-Debbugs-Cc: debian-devel@lists.debian.org, bdr...@debian.org * Package name: git-ubuntu Version : 1.1 Upstream Contact: ubuntu-devel-disc...@lists.ubuntu.com * URL : https://launchpad.net/git-ubuntu * License : GPL-3 Programming Lang: Python Description : maintain an Ubuntu source package in a git tree git-ubuntu is tooling that provides unified git-based workflows for the development of Ubuntu source packages. . The git-ubuntu importer service maintains a view of the entire packaging version history of Ubuntu source packages using git repositories with a common branching and tagging scheme. The git-ubuntu CLI provides tooling and automation that understands these repositories to make the development of Ubuntu itself easier. . Since Ubuntu's packaging architecture pre-dates git, different packages have evolved to use different mechanisms to achieve the same thing. Developers had to learn them all in order to be effective when working across a wide range of packages. git-ubuntu's unification of these mechanisms allows for simpler, more general tooling, which results in faster onboarding of new developers and easier "drive-by" contributions. . git-ubuntu is useful for those inspecting, working on, or looking to contribute to Ubuntu source packages themselves. I am using this package and plan to maintain it as part of the Debian Python Team. -- Benjamin Drung Debian & Ubuntu Developer
Vendoring an unmaintained library?
Hi, Unvendoring libraries that are already in Debian seems like the pragmatic approach to lower code duplication and be closer to better packaging pratices. #1073005 asks for the vendoring back of an unvendored library, arguing that this particular library is unmaintained upstream, implying that the vendored fork is better maintained. My view on this is that if the vendored fork is better maintained, the vendored fork should become the upstream of the Debian package. I've read through https://bugs.debian.org/907051 (policy bug: Say much more about vendoring of libraries) and do feel I understand the rules and the philosophy behind those rules. On the other side I do not want to make it harder for downstream distributions packagers to do their work for no good reason. Seeking additional advice here. Thanks, Alex
Bug#1075715: ITP: cppi/1.18 -- adjusts or checks indentation of C and C++ preprocessor directives
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: cppi Version : 1.18-1 Upstream Author : Jim Meyering, FSF, et al * URL : https://www.gnu.org/software/cppi/ * License : GPL-3+ Programming Lang: C Description : adjusts or checks indentation of C and C++ preprocessor directives GNU cppi adjusts or checks the indentation of C and C++ preprocessor directives in a file. . Indent the C preprocessor directives in FILE to reflect their nesting and ensure that there is exactly one space character between each #if, #elif, #define directive and the following token, and write the result to standard output. The number of spaces between the `#' and the following directive must correspond to the level of nesting of that directive. I intend to maintain this package on Salsa at https://salsa.debian.org/debian/cppi /Simon signature.asc Description: PGP signature
Re: Vendoring an unmaintained library?
Enriching original email: This is about whether packages transmission-gtk should use embedded copy of libb64 or depend on the outdated Debian package libb64. Upstream for libb64 seems dead and transmission devs have improved their embedded/vendored copy of libb64. Direct link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073005 First question: Are the libb64 improvements by Transmission devs generic, could they be copied as patches to the Debian libb64 package for everyone's benefit?
Re: Vendoring an unmaintained library?
On 2024-07-03 Alexandre Rossi wrote: [...] > #1073005 asks for the vendoring back of an unvendored library, arguing > that this particular library is unmaintained upstream, implying that the > vendored fork is better maintained. > My view on this is that if the vendored fork is better maintained, the > vendored fork should become the upstream of the Debian package. [...] FWIW both FreeBSD and Gentoo have switched to the suggested fork (last commit 2020), while the original source on sf is quite dead (last change 2013). cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Q: Create non-free package
Dear list, The opencpn program can use an usb dongle to administrate commercial chart licenses. Most opencpn users purchases licenses locked to a specific computer and don't use this dongle. Using a dongle users can use one license on several machines by just moving the dongle. The dongle interface is a small, closed-source solib. I guess it could be described as a sort of user-space driver. Since it is closed source it cannot go to the main archive. From here, I have some questions: 1. Is it possible to package such a solib in the non-free section? 2. opencpn would have a weak Suggests: or Recommends: on this package. Would it mean it has to move to contrib? 3. If it is possible to package in non-free, how is this done? I don't find much on this topic googling around Cheers! --alec
Re: Q: Create non-free package
On Jul 03, Alec Leamas wrote: > 1. Is it possible to package such a solib in the non-free section? Is it actually redistributable? > 2. opencpn would have a weak Suggests: or Recommends: on this package. Would > it mean it has to move to contrib? Suggests, no. Recommends, yes. See policy 2.2.1. > 3. If it is possible to package in non-free, how is this done? I don't find > much on this topic googling around You set "Section: non-free/misc" in debian/control. See policy 2.4. Since there is no source then you will also need to set an appropriate value for the Architecture field. -- ciao, Marco signature.asc Description: PGP signature
Re: Q: Create non-free package
Hi Marco, thanks for taking time On 04/07/2024 00:56, Marco d'Itri wrote: On Jul 03, Alec Leamas wrote: 1. Is it possible to package such a solib in the non-free section? Is it actually redistributable? Yes 2. opencpn would have a weak Suggests: or Recommends: on this package. Would it mean it has to move to contrib? Suggests, no. Recommends, yes. See policy 2.2.1. 3. If it is possible to package in non-free, how is this done? I don't find much on this topic googling around You set "Section: non-free/misc" in debian/control. See policy 2.4. Since there is no source then you will also need to set an appropriate value for the Architecture field. Seems to boil down to that this is possible. Thanks! --alec
