Manuel, On Monday, July 29, 2024 3:18:33 PM MST Manuel Guerra wrote: > Soren > > I see in your output version 1.0.55, actual version is 1.0.57, please use > the repository at https://github.com/manuwarfare/baby.git > > By this way I actually build good using sbuild > > I (re)moved the package files from Salsa to Github :-( I’m curious as to why you decided to do this (see more discussion below). > Please advise me if the issues was solved. Thanks! This did resolve the build problem. However, it introduced a new problem. W: baby source: no-debian-changes N: N: This non-native package makes no changes to the upstream sources in the N: Debian-related files. N: N: Maybe a mistake was made when the upstream tarball was created, or maybe N: this package is really a native package but was built non-native by N: mistake. N: N: Debian packaging is sometimes maintained as part of upstream, but that is N: not recommended as best practice. Please make this package native, if the N: software is only for Debian. Otherwise, please remove the debian directory N: from upstream releases and add it in the Debian packaging. N: N: Format 1.0 packages are subject to the restriction that the diff cannot N: remove files from the debian directory. For Format 3.0 packages, the N: debian directory is automatically purged during unpacking. N: N: Visibility: warning N: Show-Always: no N: Check: files/artifact N: Renamed from: empty-debian-diff Basically, a non-native package like yours should not contain a debian directory in the orig.tar.gz. That directory should only exist in the debian.tar.xz. That means that uscan needs to point to a repository or a tarball that doesn’t contain a debian directory. There are several ways you can do this (the following is probably not an exhaustive list). 1. Use a separate branch in your upstream repository for the Debian packaging. 2. Use a separate repository on github for the Debian packaging. 3. Handle the Debian packaging on Salsa. For the purposes of sponsoring your package, it doesn’t matter to me which of these solutions you choose. For me personally, where I am both upstream and the package maintainer, I have gone with option 3. https://gitweb.stoutner.com/?p=PrivacyBrowserPC.git;a=tree https://salsa.debian.org/soren/privacybrowser However, it is fine if you decide not to use Salsa for any reasons that are important to you. Soren -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.