[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,


Everything looks good to me.  I submitted the package.  Because it is a new package, it will go through the NEW queue to be manually reviewed by one of the FTP Masters.  If we have done our work well it should be accepted without comment.


You will receive an email shortly notifying you it has been processed into the NEW queue.  You can follow the NEW queue status at:


https://ftp-master.debian.org/new.html


Once your package has been approved, you will be able to see an overview of the health of the package in Debian at:


https://tracker.debian.org/pkg/baby


(currently this URL is not valid)


In the future, when you have updates, just shoot me an email and I can sponsor them.  Also, I would recommend you consider becoming a Debian Maintainer (DM).  It is a bit of work, and you probably want to become involved with several different packages, but it is rewarding.  DMs can be granted upload rights to specific packages they have a track record of handling with expertise.  So, as a DM you could be granted permissions to update baby and other packages your work on without the need of having to get a DD to sponsor them.


https://wiki.debian.org/DebianMaintainer


Soren


On Monday, July 29, 2024 10:05:24 PM MST Manuel Guerra wrote:

> Soren

>

> Sorry, I was very confused!

>

> I will implement this: 3.  Handle the Debian packaging on Salsa.

>

> The package has a new upload 1.0.58 with all the changes aplied, please

> when you have a free time take a look on it.

>

> Regards,

> Manuel

>

> El lun, 29 de jul. de 2024 19:54, Soren Stoutner <soren@debian.org>

>

> escribió:

> > 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



--

Soren Stoutner

soren@debian.org

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: