Files-Excluded with DEP-14
Hi. DEP-14 states under "About repacked upstream sources" that files that are removed from repacked sources should not be in the upstream branches. This does however create modify/delete conflicts when upstream modifies the removed files. Is there a smart way to handle this? Sincerely, Joachim
Re: Files-Excluded with DEP-14
Hi! On Tue, 15 Oct 2024 at 00:05, Joachim Zobel wrote: > > Hi. > > DEP-14 states under "About repacked upstream sources" that files that > are removed from repacked sources should not be in the upstream > branches. > > This does however create modify/delete conflicts when upstream modifies > the removed files. Is there a smart way to handle this? Can you be specific on what conflicts you are getting? What package, what operation? I suspect you have something wrong with the branch structure, perhaps you are trying to remove files in actual upstream branch and not the "upstream import" branch that has only one-way changes.
lintian deps in current Sid
Hello all, After a quick apt update && apt upgrade on my Sid laptop: lintian bash: lintian: command not found worker@sid:~/gits$ which lintian worker@sid:~/gits$ sudo apt install lintian Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: Unsatisfied dependencies: libberkeleydb-perl : Depends: perlapi-5.38.2 but it is not installable libtext-xslate-perl : Depends: perlapi-5.38.2 but it is not installable Error: Unable to correct problems, you have held broken packages. As of today, 15th of October, I can't install lintian on current Sid. sources.list: deb https://deb.debian.org/debian/ unstable main contrib non-free non-free-firmware. If I can help with an apt list --installed or something, let me know. Cheers, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Re: lintian deps in current Sid
Alexandru, You will find the information you are looking for in the following list mail: https://lists.debian.org/debian-devel-announce/2024/10/msg1.html[1] On Tuesday, October 15, 2024 9:12:57 AM MST Alexandru Mihail wrote: > Hello all, > > After a quick apt update && apt upgrade on my Sid laptop: > lintian > bash: lintian: command not found > worker@sid:~/gits$ which lintian > worker@sid:~/gits$ sudo apt install lintian > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > Unsatisfied dependencies: > libberkeleydb-perl : Depends: perlapi-5.38.2 but it is not installable > libtext-xslate-perl : Depends: perlapi-5.38.2 but it is not > installable > Error: Unable to correct problems, you have held broken packages. > > As of today, 15th of October, I can't install lintian on current Sid. > sources.list: deb https://deb.debian.org/debian/ unstable main contrib > non-free non-free-firmware. > If I can help with an apt list --installed or something, let me know. > > Cheers, > Alexandru Mihail -- Soren Stoutner so...@debian.org [1] https://lists.debian.org/debian-devel-announce/2024/10/msg1.html signature.asc Description: This is a digitally signed message part.
Re: lintian deps in current Sid
Quoting Alexandru Mihail (2024-10-15 18:12:57) > As of today, 15th of October, I can't install lintian on current Sid. > sources.list: deb https://deb.debian.org/debian/ unstable main contrib > non-free non-free-firmware. If I can help with an apt list --installed or > something, let me know. this is the mailinglist for the development of Debian, not a user support list. For that, send your mail to debian-u...@lists.debian.org That being said, it is called "unstable" for a reason. This kind of issue can happen regularly. If it persists, you should file a bug. In this case, the mail that should explain the situation you are facing is this one: https://lists.debian.org/Zw1l0hF1-r3Z6Z8e@birgitta.local.invalid Thanks! cheers, josch signature.asc Description: signature
Re: signify and signify-openbsd names
Hi! On Wed, 2024-10-09 at 19:42:45 +0200, Ben Hutchings wrote: > On Wed, 2024-10-09 at 10:26 +0100, Jonathan Dowland wrote: > > On Mon Oct 7, 2024 at 8:58 AM BST, Marc Haber wrote: > > > P.S.: Isnt it about time to rename exim4 to exim? > > > > Or apache2 to apache? > The ASF is responsible for a lot more than httpd now, and is also > (gradually) moving away from using the Apache name, so if that package > is to be renamed then something like "asf-httpd" would be better. Ah, I was thinking something similar (re httpd) when reading the original rename proposal, but forgot about the contention on the "apache" name itself. :) While I think a rename would be nice, to avoid confusion that would also imply renaming at least also pathnames (/etc/apache2/, /usr/lib/apache2/, /usr/share/apache2/, /usr/lib/include/apache2/), and package names (libapache2-mod-*, *-apache2), which seems like some work. So better have a good name before embarking on this kind of change (which I'd applaud TBH). Thanks, Guillem
Re: ITS: aiocoap
Hi! On Tue, 2024-10-08 at 11:37:52 +0200, Mazen Neifer wrote: > Source: aiocoap > Severity: important > I would like to salvage this package because it is no more maintained. > > Last maintainer upload was more than 5 years ago. > Last commit to git on salsa was on February 2019. > > If no objection, I will proceed to upload of latest upstream version in 21 > days. While you are at it, please renamed the source package to something like python-aiocoap (AFAIR that did not imply having to go through NEW again if things have not changed?). So that the source package is properly namespaced (to avoid taking on the global namespace), it's easier to see what it is about when doing archive-wide analysis from Sources, or even reading changelogs via stuff like apt-listchangs. :) Thanks, Guillem
Re: Files-Excluded with DEP-14
Am Dienstag, dem 15.10.2024 um 00:09 -0700 schrieb Otto Kekäläinen: > I suspect you have something wrong with the branch structure, perhaps > you are trying to remove files in actual upstream branch and not the > "upstream import" branch that has only one-way changes. The repository has an upstream branch and a debian branch. The upstream branch is pulled via git from upstream. Sinerely, Joachim This is about https://salsa.debian.org/debian-iot-team/mosquitto (Send to list separately because I forgot to cc)
Re: signify and signify-openbsd names
On October 15, 2024 12:20:27 PM UTC, Guillem Jover wrote: >Hi! > >On Tue, 2024-10-08 at 09:01:06 +0200, Simon Josefsson wrote: >> 1) Take current non-OpenBSD 'signify' source package and upload NEW >> 'signify-mail' with d/control modified as: >> >> Source: signify-mail >> ... >> Package: signify-mail >> Replaces: signify (<= 1.14-7) >> >> Do we need 'Breaks: signify (<= 1.14-7)' too? Conflicts? >> >> I've re-read chapter 7 of the policy manual again, but I have read it so >> many times before and still don't feel confident about what it actually >> means. https://www.debian.org/doc/debian-policy/ch-relationships.html >> >> 2) Once 'signify-mail' has entered testing, open a ftp.debian.org RM bug >> for 'signify' to get the binary packages removed from testing. >> >> 3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a >> 'Package: signify' that has /usr/bin/signify and to add: >> >> Conflicts: signify (<= 1.14-7), signify-mail >> >> Is a similar Breaks needed too? >> >> The 'signify-openbsd' binary package should be left around as a empty >> dummy package for transitions to the new 'signify' binary package. >> >> 4) Uploading source package 'signify-openbsd' to NEW as 'signify', and >> then ask for removal of the old 'signify-openbsd' source package. This >> is nice but optional. It was suggested this can trigger BTS bugs. It >> may be best to wait until at least trixie+1. This doesn't affect users >> so is more of an developer aesthetic concern, which may suggest it isn't >> worth doing at all. > >Not digging into the packaging side of things, but I think you can >probably optimize/reduce NEW trips and archive admins intervention, by >taking into account that (AFAIR and if things have not changed?) source >package renames do not go through NEW. That you can take over (also >AFAIR if things have not changed) a binary package from another source >package. And that binaries no longer produced by any source get >automatically garbage collected (https://wiki.debian.org/Glossary#nbs). > >So depending on the timelines, the process could be reduced by staging >the binary package moves/take-overs and source package renames in >different ordered uploads. They do go through New. Scott K
Re: signify and signify-openbsd names
Hi! On Tue, 2024-10-08 at 09:01:06 +0200, Simon Josefsson wrote: > 1) Take current non-OpenBSD 'signify' source package and upload NEW > 'signify-mail' with d/control modified as: > > Source: signify-mail > ... > Package: signify-mail > Replaces: signify (<= 1.14-7) > > Do we need 'Breaks: signify (<= 1.14-7)' too? Conflicts? > > I've re-read chapter 7 of the policy manual again, but I have read it so > many times before and still don't feel confident about what it actually > means. https://www.debian.org/doc/debian-policy/ch-relationships.html > > 2) Once 'signify-mail' has entered testing, open a ftp.debian.org RM bug > for 'signify' to get the binary packages removed from testing. > > 3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a > 'Package: signify' that has /usr/bin/signify and to add: > > Conflicts: signify (<= 1.14-7), signify-mail > > Is a similar Breaks needed too? > > The 'signify-openbsd' binary package should be left around as a empty > dummy package for transitions to the new 'signify' binary package. > > 4) Uploading source package 'signify-openbsd' to NEW as 'signify', and > then ask for removal of the old 'signify-openbsd' source package. This > is nice but optional. It was suggested this can trigger BTS bugs. It > may be best to wait until at least trixie+1. This doesn't affect users > so is more of an developer aesthetic concern, which may suggest it isn't > worth doing at all. Not digging into the packaging side of things, but I think you can probably optimize/reduce NEW trips and archive admins intervention, by taking into account that (AFAIR and if things have not changed?) source package renames do not go through NEW. That you can take over (also AFAIR if things have not changed) a binary package from another source package. And that binaries no longer produced by any source get automatically garbage collected (https://wiki.debian.org/Glossary#nbs). So depending on the timelines, the process could be reduced by staging the binary package moves/take-overs and source package renames in different ordered uploads. Thanks, Guillem
Re: Bug#1085127: ITP: go-nmap -- Nmap XML parsing library for Go (library)
Hi! On Mon, 2024-10-14 at 22:20:11 -0300, Marcos Rodrigues de Carvalho (aka oday) wrote: > Package: wnpp > Severity: wishlist > Owner: "Marcos Rodrigues de Carvalho (aka oday)" > X-Debbugs-Cc: debian-devel@lists.debian.org, marcosrcarvalh...@gmail.com > > * Package name: go-nmap > Version : 0.0~git20191202.3507e0b-1 > Upstream Contact: Tom Steele > https://github.com/lair-framework/go-nmap/issues/new > * URL : https://github.com/lair-framework/go-nmap/issues/new > * License : Expat > Programming Lang: Golang > Description : Nmap XML parsing library for Go (library) > > The Nmap XML Parsing Library for Go is a specialized tool designed to > facilitate the processing and analysis of Nmap scan results formatted > in XML. This library provides a robust and efficient way to extract > meaningful data from Nmap's output, making it easier for developers > to integrate network scanning capabilities into their Go applications. If this is really intended to be a library only golang package (no addition binary packages for tools for example), then please follow the current golang team convention on naming the source package and the git repo. It would be best to use something like this, if you have not done that already: $ dh-make-golang make -type l -wrap-and-sort ast \ github.com/lair-framework/go-nmap (And then follow its instructions.) Thanks, Guillem
Re: Files-Excluded with DEP-14
On Tue, Oct 15, 2024 at 02:44:59PM +0200, Joachim Zobel wrote: > Am Dienstag, dem 15.10.2024 um 00:09 -0700 schrieb Otto Kekäläinen: > > I suspect you have something wrong with the branch structure, perhaps > > you are trying to remove files in actual upstream branch and not the > > "upstream import" branch that has only one-way changes. > > The repository has an upstream branch and a debian branch. The upstream > branch is pulled via git from upstream. I don't see a sane way to continue using this workflow but repack the orig.tar. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1085150: ITP: boulder -- Boulder Dash clone
Package: wnpp Severity: wishlist Owner: Andreas Rönnquist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: boulder Version : 1.0.1 Upstream Contact: Ronnie Hedlund * URL : https://rh-galaxy.itch.io/boulder * License : Public Domain Programming Lang: C++ Description : Boulder Dash clone Collect diamonds and reach the exit - complete with level editor. There are some new elements and a level editor to create more levels. Local high-score. --- I intend to maintain this in the Games team. I have noticed that there's a package libboulder-perl - naming this simply "boulder" wouldn't cause any problem, right? Also, I have also noticed that there's already (at least) one boulder dash-clone in Debian, primarily epiphany but that seems dead upstream, and based on SDL1.2, while this is SDL2, and in active development. /Andreas Rönnquist gus...@debian.org
Re: Files-Excluded with DEP-14
On 15/10/2024 08:09, Otto Kekäläinen wrote: Hi! On Tue, 15 Oct 2024 at 00:05, Joachim Zobel wrote: Hi. DEP-14 states under "About repacked upstream sources" that files that are removed from repacked sources should not be in the upstream branches. This does however create modify/delete conflicts when upstream modifies the removed files. Is there a smart way to handle this? Can you be specific on what conflicts you are getting? What package, what operation? I suspect you have something wrong with the branch structure, perhaps you are trying to remove files in actual upstream branch and not the "upstream import" branch that has only one-way changes. One useful operation is additional sources. I have one package that upstream downloads additional git repos as dependencies. Capturing the tarball (I have a patch to disable git actions) and _how_ additional sources were added would be useful. -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie @amckins...@mastodon.ie Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Re: lintian deps in current Sid
Thanks, I skipped it ! Alexandru Mihail
Re: Files-Excluded with DEP-14
Am Dienstag, dem 15.10.2024 um 18:20 +0500 schrieb Andrey Rakhmatullin: > I don't see a sane way to continue using this workflow but repack the > orig.tar. Thanks, this means that for us there is no easy way to remove files. Luckily there is no very important reason (copyright) for that. So we simply won't remove them. Thanks, Joachim -- Papier ist gebundenes CO2. Bitte drucken Sie diese EMail aus und archivieren Sie sie.
Re: Files-Excluded with DEP-14
On Tue, Oct 15, 2024 at 07:30:57PM -0700, Otto Kekäläinen wrote: > If you need to repack, you should have a spearate branch > 'upstream/latest' as the targets for merges from upstream tags, and > then from 'upstream/latest' you merge on 'debian/master' (which > following DEP-14 should be 'debian/latest' btw). And if upstream/latest has a file removed while master has that file modified, there will be a conflict. > Note that the upstream-branch and upstream-tag refers to things > created by Debian to reference the incoming upstream stuff. Only the > upstream-vcs-tag should point to something that actually already > exists in the upstream repository > https://github.com/eclipse/mosquitto/ you are pulling from. To make it > more clear, perhaps git-buildpackage should rename these to > import-branch and import-tag so people won't use > upstream-branch=master like you did, as it isn't supposed to mean the > actual upstream master branch, only the branch used for the package in > Debian. Using the upstream tags directly is officially supported: https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html#gbp.import.upstream.git.notarball -- WBR, wRAR signature.asc Description: PGP signature
Re: Files-Excluded with DEP-14
Hi! On Tue, 15 Oct 2024 at 05:47, Joachim Zobel wrote: > > Am Dienstag, dem 15.10.2024 um 00:09 -0700 schrieb Otto Kekäläinen: > > I suspect you have something wrong with the branch structure, perhaps > > you are trying to remove files in actual upstream branch and not the > > "upstream import" branch that has only one-way changes. > > The repository has an upstream branch and a debian branch. The upstream > branch is pulled via git from upstream. > > Sinerely, > Joachim > > This is about https://salsa.debian.org/debian-iot-team/mosquitto I can see https://salsa.debian.org/debian-iot-team/mosquitto/-/blob/debian/master/debian/gbp.conf that has: [DEFAULT] debian-branch=debian/master upstream-branch=master filter=*/.git upstream-tag=v%(version)s There is no README.source so I am not sure how you do the import, but based on https://salsa.debian.org/debian-iot-team/mosquitto/-/commit/5d08142299dc7a7db79883a2fcdc615eb326817c you merged branch 'master' directly on 'debian/master'. If you need to repack, you should have a spearate branch 'upstream/latest' as the targets for merges from upstream tags, and then from 'upstream/latest' you merge on 'debian/master' (which following DEP-14 should be 'debian/latest' btw). [DEFAULT] debian-branch = debian/latest upstream-branch = upstream/latest upstream-tag = upstream/%(version)s upstream-vcs-tag = v%(version%~%.)s Note that the upstream-branch and upstream-tag refers to things created by Debian to reference the incoming upstream stuff. Only the upstream-vcs-tag should point to something that actually already exists in the upstream repository https://github.com/eclipse/mosquitto/ you are pulling from. To make it more clear, perhaps git-buildpackage should rename these to import-branch and import-tag so people won't use upstream-branch=master like you did, as it isn't supposed to mean the actual upstream master branch, only the branch used for the package in Debian. Note: I didn't test this setup, I am just writing about what I assume the setup should be, but it should still be tested to validate it works in your use case.
Bug#1085180: ITP: mcds -- Mutt CardDav search program
Package: wnpp Severity: wishlist Owner: Andrew Bower X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mcds Version : 1.6 Upstream Contact: Timothy Brown * URL : https://github.com/t-brown/mcds * License : GPL-3.0 Programming Lang: C Description : Mutt CardDav search program mcds is a command line tool primarily used as a search query plugin for mutt to query a CardDav server. This utility would supply Debian with the missing functionality of live contact search for the mutt MUA against CardDav servers such as Nextcloud and ownCloud. It is also handy for quick contact searches from the command line. The most obvious candidate alternative is vdirsyncer but this adopts a different model, syncing a local contact store with a remote one, which does not suit all users. Packages for mcds-1.6 are currently available in the openSUSE and OpenBSD distributions. I use mcds and am prepared to maintain it but would need a sponsor. Proposed gbp-style repository: https://salsa.debian.org/abower/mcds Thank you!
