[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1074498: RFS: baby/1.0.55-1 [ITP] -- Abbreviate long commands in terminal



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.


Reply to: