Re: Bug#1065078: Question about the debian group on Salsa

[Fred]

PLEASE REMOVE ME FROM ALL LISTS!

I tried to remove myself. It didn't work.

I tried to contact the list admin. I did not get an answer.

I'M GONNA SPAM YOUR LISTS UNTIL YOU REMOVE ME!



On 05.03.24 21:34, Soren Stoutner wrote:

Peter,

That’s a good point.  When I granted the access I actually selected
Maintainer, but for some reason I wrote Developer in the email.

On Tuesday, March 5, 2024 5:44:51 AM MST Peter B wrote:

On 01/03/2024 04:12, Soren Stoutner wrote:

I have created a repository named planner under debian and have granted

you

Developer access.  :)

F.Y.I.   'Developer' access on Salsa does not allow to Manage CI/CD
settings.

If required, 'Maintainer' or 'Owner' is needed to do that.
https://docs.gitlab.com/ee/user/permissions.html

BTDTGTTS,
Peter

Re: Bug#1065078: Question about the debian group on Salsa

[Soren Stoutner]

Peter,

That’s a good point.  When I granted the access I actually selected 
Maintainer, but for some reason I wrote Developer in the email.

On Tuesday, March 5, 2024 5:44:51 AM MST Peter B wrote:
> On 01/03/2024 04:12, Soren Stoutner wrote:
> > I have created a repository named planner under debian and have granted 
you
> > Developer access.  :)
> 
> F.Y.I.   'Developer' access on Salsa does not allow to Manage CI/CD
> settings.
> 
> If required, 'Maintainer' or 'Owner' is needed to do that.
> https://docs.gitlab.com/ee/user/permissions.html
> 
> BTDTGTTS,
> Peter


-- 
Soren Stoutner
so...@debian.org

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

Re: Bug#1065078: Question about the debian group on Salsa

[Peter B]

On 01/03/2024 04:12, Soren Stoutner wrote:

I have created a repository named planner under debian and have granted you
Developer access.  :)


F.Y.I.   'Developer' access on Salsa does not allow to Manage CI/CD 
settings.


If required, 'Maintainer' or 'Owner' is needed to do that.
https://docs.gitlab.com/ee/user/permissions.html

BTDTGTTS,
Peter

Re: Bug#1065078: Question about the debian group on Salsa

[Soren Stoutner]

On Sunday, March 3, 2024 12:08:00 PM MST Loren M. Lang wrote:
> > There is certainly nothing wrong with keeping your project under your own
> > namespace, but if you would like to move it to the debian namespace, grant
> > me
> > full access to it (my Salsa username is soren) and I can then move it to 
the
> > debian namespace and grant you full access to the project there.
> 
> Thanks! I've granted you full access to
> 
> https://salsa.debian.org/penguin359/tiv
> 
> -Loren

Done.

-- 
Soren Stoutner
so...@debian.org

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

Re: Bug#1065078: Question about the debian group on Salsa

[Loren M. Lang]

On Sun, Mar 03, 2024 at 12:02:36AM -0700, Soren Stoutner wrote:
> Loren,
> 
> Yes, I would say that is generally correct.  If you have a package that is 
> team maintained, it is best under the team namespace.  If it is not team 
> maintained, it is generally best under the debian namespace (which is the 
> team 
> of all Debian Developers).  It makes it easier for others to pick up if 
> something happens to you.
> 
> However, there may be specific cases where you do want to keep it in your own 
> namespace.  I maintain one package where I am also the upstream developer.  I 
> keep the Debian packaging in my own namespace because I want to have a very 
> high threshold for other people making changes to it.  At this stage, if 
> something were to happen to me, both the Debian package and the upstream 
> project would need to be adopted by someone else, which would probably 
> necessitate a renaming of the project.  Down the road, I would like to get 
> more people involved in both the upstream development and the Debian 
> packaging.  When that happens I will probably move the Salsa project to a 
> team 
> namespace.
> 
> There is certainly nothing wrong with keeping your project under your own 
> namespace, but if you would like to move it to the debian namespace, grant me 
> full access to it (my Salsa username is soren) and I can then move it to the 
> debian namespace and grant you full access to the project there.

Thanks! I've granted you full access to

https://salsa.debian.org/penguin359/tiv

-Loren

> 
> Soren
> 
> On Saturday, March 2, 2024 11:34:14 PM MST Loren M. Lang wrote:
> > On Sat, Mar 02, 2024 at 01:11:46AM +0100, Salvo Tomaselli wrote:
> > > In data venerdì 1 marzo 2024 05:12:51 CET, Soren Stoutner ha scritto:
> > > > Generally you should create the repository under the debian namespace
> > > 
> > > You need to ask a DD to do that. Non DD don't have permissions for this.
> > 
> > So is having all packages (at least those not maintained by a team)
> > under the debian/ namespace considered a best practice for all but the
> > most sensitive of packages? Should I actually have my own package
> > transfered to this namespace?
> > 
> > I just have a small, CLI package that I maintain alone and, since I
> > don't have DD permissions, just assumed that I should put it under my
> > own namespace. Is it recommended to just keep it under the neutral
> > debian namespace just in case I am no longer able to keep it maintained
> > in the future?
> > 
> > My current package is https://salsa.debian.org/penguin359/tiv
> > 
> > -Loren
> 
> -- 
> Soren Stoutner
> so...@debian.org



-- 
Loren M. Lang
lor...@north-winds.org
http://www.north-winds.org/


Public Key: http://www.north-winds.org/lorenl_pubkey.asc
Fingerprint: 7896 E099 9FC7 9F6C E0ED  E103 222D F356 A57A 98FA


signature.asc
Description: PGP signature

Re: Bug#1065078: Question about the debian group on Salsa

[Soren Stoutner]

Loren,

Yes, I would say that is generally correct.  If you have a package that is 
team maintained, it is best under the team namespace.  If it is not team 
maintained, it is generally best under the debian namespace (which is the team 
of all Debian Developers).  It makes it easier for others to pick up if 
something happens to you.

However, there may be specific cases where you do want to keep it in your own 
namespace.  I maintain one package where I am also the upstream developer.  I 
keep the Debian packaging in my own namespace because I want to have a very 
high threshold for other people making changes to it.  At this stage, if 
something were to happen to me, both the Debian package and the upstream 
project would need to be adopted by someone else, which would probably 
necessitate a renaming of the project.  Down the road, I would like to get 
more people involved in both the upstream development and the Debian 
packaging.  When that happens I will probably move the Salsa project to a team 
namespace.

There is certainly nothing wrong with keeping your project under your own 
namespace, but if you would like to move it to the debian namespace, grant me 
full access to it (my Salsa username is soren) and I can then move it to the 
debian namespace and grant you full access to the project there.

Soren

On Saturday, March 2, 2024 11:34:14 PM MST Loren M. Lang wrote:
> On Sat, Mar 02, 2024 at 01:11:46AM +0100, Salvo Tomaselli wrote:
> > In data venerdì 1 marzo 2024 05:12:51 CET, Soren Stoutner ha scritto:
> > > Generally you should create the repository under the debian namespace
> > 
> > You need to ask a DD to do that. Non DD don't have permissions for this.
> 
> So is having all packages (at least those not maintained by a team)
> under the debian/ namespace considered a best practice for all but the
> most sensitive of packages? Should I actually have my own package
> transfered to this namespace?
> 
> I just have a small, CLI package that I maintain alone and, since I
> don't have DD permissions, just assumed that I should put it under my
> own namespace. Is it recommended to just keep it under the neutral
> debian namespace just in case I am no longer able to keep it maintained
> in the future?
> 
> My current package is https://salsa.debian.org/penguin359/tiv
> 
> -Loren

-- 
Soren Stoutner
so...@debian.org

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

Re: Bug#1065078: Question about the debian group on Salsa

[Soren Stoutner]

Generally you should create the repository under the debian namespace unless 
you really don’t want anyone else making any changes to it, even if the 
changes are urgent and you are AFK for some reason.

I have created a repository named planner under debian and have granted you 
Developer access.  :)

On Thursday, February 29, 2024 7:28:59 AM MST Shriram Ravindranathan wrote:
> Dear mentors,
> 
> I'm curious about the guidelines for putting a package under the debian 
> namespace on Salsa . I wasn't able to 
> find much discourse about this online.
> 
> This package didn't have a salsa repository created for it, I am unsure 
> whether I should create a repository under my own namespace or if the 
> package should be placed under the debian namespace.
> 
> Thank you,
> 
> -- 
> Shriram Ravindranathan
> 


-- 
Soren Stoutner
so...@debian.org

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

Bug#1065078: Question about the debian group on Salsa

[Shriram Ravindranathan]

Dear mentors,

I'm curious about the guidelines for putting a package under the debian 
namespace on Salsa . I wasn't able to 
find much discourse about this online.


This package didn't have a salsa repository created for it, I am unsure 
whether I should create a repository under my own namespace or if the 
package should be placed under the debian namespace.


Thank you,

--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Question on why package was rebuilt

[Sebastian Ramacher]

Hi

On 2024-02-16 21:32:49 +0100, Jérémy Lal wrote:
>   When a package is uploaded to NEW, you have to upload both the source
> > and binary package(s) for review. After the package is accepted, the
> > buildds auto-build for any other architectures that don't already have
> > a binary package. Migration policy requires all packages to be built on
> > official buildds from their source package[1]. Since the amd64 binary
> > package already existed from the upload to NEW, it wouldn't be auto-
> > built and would block migration of your package to testing.
> >
> 
> This isn't what happened, I suppose, since we all debian maintainers need
> to do source-only uploads after a package has been accepted through the NEW
> process.
> Unless I'm mistaken, that source-only upload cannot be replaced by a
> binNMU, can it ?
> What happened is more likely to be a standard rebuild against a new version
> of a dependent library.

A binNMU is enough if the source package only builds architecture
dependent packages. If Architecture: all packages are involved, a source
only upload is required.

Cheers
-- 
Sebastian Ramacher

Re: Question on why package was rebuilt

[Jérémy Lal]

Le ven. 16 févr. 2024 à 04:03, Mathias Gibbens  a écrit :

> On Thu, 2024-02-15 at 16:20 -0800, Loren M. Lang wrote:
> > Hello,
> >
> > I recently had a package sponsors and entered into unstable called tiv.
> > It can be seen here:
> >
> > https://packages.debian.org/sid/tiv
> >
> > Everything went OK, but I see that the amd64 arch package appears to
> > have been re-built for some reason. It's version is showing up with a
> > +b1. I am curious if there is some long to indicate what the issue might
> > have been that led to a rebuild. Could there have been a compilation
> > issue or other things I should be concerned about or is it likely
> > something harmless? Is there a log for this case?
>
>   There's no cause for concern -- it's a normal part of a new package
> entering the archive.
>

Indeed...

  When a package is uploaded to NEW, you have to upload both the source
> and binary package(s) for review. After the package is accepted, the
> buildds auto-build for any other architectures that don't already have
> a binary package. Migration policy requires all packages to be built on
> official buildds from their source package[1]. Since the amd64 binary
> package already existed from the upload to NEW, it wouldn't be auto-
> built and would block migration of your package to testing.
>

This isn't what happened, I suppose, since we all debian maintainers need
to do source-only uploads after a package has been accepted through the NEW
process.
Unless I'm mistaken, that source-only upload cannot be replaced by a
binNMU, can it ?
What happened is more likely to be a standard rebuild against a new version
of a dependent library.

  The "+b1" indicates a binBMU was performed[2,3]. If you look at the
> buildd logs (https://buildd.debian.org/status/package.php?p=tiv),
> you'll see the relevant changelog entry for the amd64 package: "Rebuild
> on buildd".
>

A binNMU, but right.


>
> Mathias
>
> [1] --
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-and-binary-uploads
> [2] --
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-nmus-vs-binary-only-nmus-binnmus
> [3] --
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#recompilation-or-binary-only-nmu
>

Re: Question on why package was rebuilt

[Mathias Gibbens]

On Thu, 2024-02-15 at 16:20 -0800, Loren M. Lang wrote:
> Hello,
> 
> I recently had a package sponsors and entered into unstable called tiv.
> It can be seen here:
> 
> https://packages.debian.org/sid/tiv
> 
> Everything went OK, but I see that the amd64 arch package appears to
> have been re-built for some reason. It's version is showing up with a
> +b1. I am curious if there is some long to indicate what the issue might
> have been that led to a rebuild. Could there have been a compilation
> issue or other things I should be concerned about or is it likely
> something harmless? Is there a log for this case?

  There's no cause for concern -- it's a normal part of a new package
entering the archive.

  When a package is uploaded to NEW, you have to upload both the source
and binary package(s) for review. After the package is accepted, the
buildds auto-build for any other architectures that don't already have
a binary package. Migration policy requires all packages to be built on
official buildds from their source package[1]. Since the amd64 binary
package already existed from the upload to NEW, it wouldn't be auto-
built and would block migration of your package to testing.

  The "+b1" indicates a binBMU was performed[2,3]. If you look at the
buildd logs (https://buildd.debian.org/status/package.php?p=tiv),
you'll see the relevant changelog entry for the amd64 package: "Rebuild
on buildd".

Mathias

[1] -- 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-and-binary-uploads
[2] -- 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-nmus-vs-binary-only-nmus-binnmus
[3] -- 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#recompilation-or-binary-only-nmu


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

Question on why package was rebuilt

[Loren M. Lang]

Hello,

I recently had a package sponsors and entered into unstable called tiv.
It can be seen here:

https://packages.debian.org/sid/tiv

Everything went OK, but I see that the amd64 arch package appears to
have been re-built for some reason. It's version is showing up with a
+b1. I am curious if there is some long to indicate what the issue might
have been that led to a rebuild. Could there have been a compilation
issue or other things I should be concerned about or is it likely
something harmless? Is there a log for this case?

-- 
Loren M. Lang
lor...@north-winds.org
http://www.north-winds.org/


Public Key: http://www.north-winds.org/lorenl_pubkey.asc
Fingerprint: 7896 E099 9FC7 9F6C E0ED  E103 222D F356 A57A 98FA


signature.asc
Description: PGP signature

Re: Regarding: New contributor question, where to start

[Darren Tomblin]

73,
Darren Tomblin KC9JJJ

> On Feb 13, 2024, at 3:12 AM, Geert Stappers  wrote:
> 
> Hello Darren,
> 
>> On Tue, Feb 13, 2024 at 02:58:48AM -0500, Darren Tomblin wrote:
>>> On Feb 12, 2024, at 1:20 AM, Geert Stappers  wrote:
>>> Mon, Feb 12, 2024 at 07:07:55AM +0100, Geert Stappers wrote:
> On Sun, Feb 11, 2024 at 05:04:41PM -0500, Darren Tomblin wrote:
> Hi
> 
> I’m wondering what I have to do to say I want to work on a bug I’ve
> searched for this and can’t find anything I don’t know if I was
> searching for the right thing
 
 Just start somewhere.
>>> 
>>> If the first "thingy" is too heavy to lift, try a next "thingy".
>>> If also too heavy, try the next. Do know that you learn with each
>>> attempt. Allow yourself to start small and to fail often.
>>> Having fun with finding how to contribute to libre software
>>> is already contributing to libre software.
>>> 
>>> Welcome
>>> 
>> 
>> I’m wanting to work on ones already reported
> 
> 
> Share that information with the mailinglist.
> 
> You did sent it only to me. My time, our time, will be more effective
> if we discuss this non-private stuff at the Debian Mentors mailinglist.
> 
> 
> Another advice:
> Make it possible that people can read in the discussion order,
> reply below previous text.
> 
> 
> Still feel welcome.
> hi sorry about that I’m blind and wasn’t paying attention.  I’m wanting to 
> work on bugs already reported thanks
> 
>> 73,
>> Darren Tomblin KC9JJJ
> 
> 
> Groeten
> Geert Stappers
> Debian Developer
> --
> Silence is hard to parse

Re: New contributor question

[Charalampos Mitrodimas]

Hi Daren,

On 2/12/24 00:04, Darren Tomblin wrote:

Hi I’m wondering what I have to do to say I want to work on a bug I’ve searched 
for this and can’t find anything I don’t know if I was searching for the right 
thing thanks


Just to clarify, have you found a bug that has already been
reported and are you trying to figure out how to claim it, or
are you looking to report a new bug?

--

Charalampos Mitrodimas

Re: New contributor question

[Shriram Ravindranathan]

Hi Darren,
Is your bug already in the Bug Tracking System 
? If not, you might want to start by using 
the reportbug  tool.


On 12/02/24 3:34 am, Darren Tomblin wrote:

Hi I’m wondering what I have to do to say I want to work on a bug I’ve searched 
for this and can’t find anything I don’t know if I was searching for the right 
thing thanks
73,
Darren Tomblin KC9JJJ


--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: New contributor question

[Paul Wise]

On Sun, 2024-02-11 at 17:04 -0500, Darren Tomblin wrote:

> I’m wondering what I have to do to say I want to work on a bug

Which bug report are you looking at?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: New contributor question, where to start

[Geert Stappers]

On Mon, Feb 12, 2024 at 07:07:55AM +0100, Geert Stappers wrote:
> On Sun, Feb 11, 2024 at 05:04:41PM -0500, Darren Tomblin wrote:
> > Hi
> >
> > I’m wondering what I have to do to say I want to work on a bug I’ve
> > searched for this and can’t find anything I don’t know if I was
> > searching for the right thing
> 
> Just start somewhere.

If the first "thingy" is too heavy to lift, try a next "thingy".
If also too heavy, try the next. Do know that you learn with each
attempt. Allow yourself to start small and to fail often.
Having fun with finding how to contribute to libre software
is already contributing to libre software.

Welcome


Regards
Geert Stappers
Doesn't care much about age
Does know that having a radio call sign implies skill
-- 
Silence is hard to parse

Re: New contributor question

[Geert Stappers]

On Sun, Feb 11, 2024 at 05:04:41PM -0500, Darren Tomblin wrote:
> Hi
>
> I’m wondering what I have to do to say I want to work on a bug I’ve
> searched for this and can’t find anything I don’t know if I was
> searching for the right thing

Just start somewhere.

 
Groeten
Geert Stappers
-- 
Silence is hard to parse

New contributor question

[Darren Tomblin]

Hi I’m wondering what I have to do to say I want to work on a bug I’ve searched 
for this and can’t find anything I don’t know if I was searching for the right 
thing thanks 
73,
Darren Tomblin KC9JJJ

Re: Debian versioning question

[Guillem Jover]

Hi!

On Sat, 2023-11-11 at 03:28:21 +, Wookey wrote:
> On 2023-11-10 23:44 +0100, Preuße, Hilmar wrote:
> > On 10.11.2023 03:10, Wookey wrote:
> > > I think your options are
> > > 1) add an epoch (which exists to deal with this sort of problem)
> > > 
> > Well, would like to avoid it, if possible.
> 
> There is no real reason to avoid epochs

Oh, but there are! See .

> but they always feel a bit
> 'ugly' so people do tend to avoid them if they can.

That's the lesser of the issues with epochs. :)

Thanks,
Guillem

Re: Question about non-responsive key-signing mate

[Maarten van Geijn]

Thank you all for your replies. That is a good sign and I will just take 
this as an experience to get better and move on.


Regards
Maarten

On 14/11/2023 19:11, Maarten van Geijn wrote:

Dear mentors,

I turn to you with this question: is there any procedure to persuade an 
individual to sign a key he promised to sign during a key-signing 
meeting? I refrain from mentioning specific names here, but here is what 
happened:


On October 7, I met a Debian developer in Tilburg, NL in an attempt to 
get acquainted and sign each other's keys.
After some coffee and a decent conversation, exchanging business cards, 
and key fingerprints, we left and indicated that we will sign each 
other's keys.
I signed his key as soon as I got home, the same day. My counterpart 
told me it could take a week or so. (pretty strange for a seasoned 
debian developer, but alright, I am happy to give someone the benefit of 
the doubt.


After 3 weeks I started to email him, no response. I tried this several 
times, even phoning him, but even though we are now more than 5 weeks 
down the road, still life signs.


Of course it could be anything, but I am starting to feel hoodwinked. 
Does this happen more often? Any recommendation from you?


Thanks for your advice.

Regards
Maarten


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Question about non-responsive key-signing mate

[Wookey]

On 2023-11-14 19:11 +0100, Maarten van Geijn wrote:
> I turn to you with this question: is there any procedure to persuade an
> individual to sign a key he promised to sign during a key-signing meeting?

No. It is always entirely up to them.

[key was not signed]

> Does this happen more often?

Yes, lots of people you swap material/ID with may never sign your key.

I am a very unreliable key-signer for instance. I often never get round to
signing, or never uploading the sig, or not sending an email with the
sig back, or sign things months or years later when I find the
fingerprint stash collection.

It's not personal.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Question about non-responsive key-signing mate

[David Kalnischkies]

Hi,

On Tue, Nov 14, 2023 at 07:11:56PM +0100, Maarten van Geijn wrote:
> Of course it could be anything, but I am starting to feel hoodwinked. Does
> this happen more often? Any recommendation from you?

In big signing parties its pretty usual that a sizeable chunk never
signs your key, I suppose less so in small meetings, but the important
thing to remember here is that nobody has any obligation to sign a key
and there certainly is no handle to "force" someone to sign you back
even if they said they would.

Its not how signing a key works: You sign that you are reasonably sure
that this person is who they claim to be and are linked to certain keys.
It doesn't say anything about what they believe about you and your keys.
And if they sign you or not should have no bearing on your signature.


I can certainly understand that you are frustrated and feel cheated,
especially if you need (more) signatures to e.g. apply for DD status
and somehow the world seems to have conspired into making it especially
hard for you … but the world hasn't. There is probably a very easy and
reasonable explanation – my cat ate it –, but perhaps you will never
get to know them – my cat is very sorry but I am way too embarrassed to
tell anyone – and while it is frustrating to not know, it isn't very
healthy to dwell on it either.

If I were you, I would just let it rest and look for other signing
opportunities. Perhaps even key endorsements are an option.

As the saying goes: a watched pot never boils.
I have received signatures months later… and I wasn't always the fasted
signer either [surprisingly, trying to keep your certification key off-
line and air-gapped somehow makes it a bit of a time-consuming ordeal to
actual use it, so I might end up putting it off and off and …].


 TRIGGER WARNING 
Imagine for a moment we weren't talking about key signing, but you two
had meet for a date. Terms like ghosting and stalking come to mind and
so this thread reads like a very dark and scary place to be in.
Lets get the hell out of here…



Best regards

David Kalnischkies, who – full disclosure – isn't even a domestic
 servant for a cat currently nor did he sign a key in a long while


signature.asc
Description: PGP signature

Re: Question about non-responsive key-signing mate

[Geert Stappers]

On Tue, Nov 14, 2023 at 07:11:56PM +0100, Maarten van Geijn wrote:
> Dear mentors,
> 
> I turn to you with this question: is there any procedure to persuade an
> individual to sign a key he promised to sign during a key-signing meeting? I
> refrain from mentioning specific names here, but here is what happened:
> 
> On October 7, I met a Debian developer in Tilburg, NL in an attempt to get
> acquainted and sign each other's keys.
> After some coffee and a decent conversation, exchanging business cards, and
> key fingerprints, we left and indicated that we will sign each other's keys.
> I signed his key as soon as I got home, the same day. My counterpart told me
> it could take a week or so. (pretty strange for a seasoned debian developer,
> but alright, I am happy to give someone the benefit of the doubt.
> 
> After 3 weeks I started to email him, no response. I tried this several
> times, even phoning him, but even though we are now more than 5 weeks down
> the road, still life signs.
> 
> Of course it could be anything, but I am starting to feel hoodwinked. Does
> this happen more often?

Yes


> Any recommendation from you?

Do key-signing with more people.


 
> Regards
> Maarten


Groeten
Geert Stappers
DD, Woont in Breda, Werkt in Tilburg, is a.s. zaterdag in Utrecht.
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Question about non-responsive key-signing mate

[Maarten van Geijn]

Dear mentors,

I turn to you with this question: is there any procedure to persuade an 
individual to sign a key he promised to sign during a key-signing 
meeting? I refrain from mentioning specific names here, but here is what 
happened:


On October 7, I met a Debian developer in Tilburg, NL in an attempt to 
get acquainted and sign each other's keys.
After some coffee and a decent conversation, exchanging business cards, 
and key fingerprints, we left and indicated that we will sign each 
other's keys.
I signed his key as soon as I got home, the same day. My counterpart 
told me it could take a week or so. (pretty strange for a seasoned 
debian developer, but alright, I am happy to give someone the benefit of 
the doubt.


After 3 weeks I started to email him, no response. I tried this several 
times, even phoning him, but even though we are now more than 5 weeks 
down the road, still life signs.


Of course it could be anything, but I am starting to feel hoodwinked. 
Does this happen more often? Any recommendation from you?


Thanks for your advice.

Regards
Maarten


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian versioning question

[Andreas Metzler]

On 2023-11-10 "Preuße, Hilmar"  wrote:
> On 10.11.2023 03:10, Wookey wrote:
>> I think your options are
>> 1) add an epoch (which exists to deal with this sort of problem)
>> 
> Well, would like to avoid it, if possible.

I think it is also not the right solutions, epochs are imho intended to
fix one-off errors, but this is problem recurring with every non-major
release.

[...]
>> 3) upload a 'nobbled' version number, which is often done to deal
>> with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
>> dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $?
>> 
> You mean upload the 1.3.8a as 1.3.8+really1.3.8a, 1.3.8+really1.3.8b,
> 1.3.8+really1.3.8c etc. until we are at 1.3.9 und we can return to normal
> versioning?

>> I'd probably go with option 3 in this case. Ugly but temporary.
>> 
> Sounds like an option for now. Thanks!

I think 1.3.8-a+dfsg-1 would work and you could swith to ~dfsg with
1.3.9 like Mattia suggested:
ametzler@argenau:~$ dpkg --compare-versions '1.3.8+dfsg-8' '<<' 1.3.8-a+dfsg-1 
&& echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.8-a+dfsg-2 '<<' 1.3.8-b+dfsg-1 
&& echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.8-b+dfsg-3 '<<' 1.3.9~dfsg-1 && 
echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.9~dfsg-3 '<<' 1.3.9a~dfsg-1 && 
echo yes
yes

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'

Re: Debian versioning question

[Wookey]

On 2023-11-10 23:44 +0100, Preuße, Hilmar wrote:
> On 10.11.2023 03:10, Wookey wrote:
> 
> Hi Wookey,
> 
> > I think your options are
> > 1) add an epoch (which exists to deal with this sort of problem)
> > 
> Well, would like to avoid it, if possible.

There is no real reason to avoid epochs but they always feel a bit
'ugly' so people do tend to avoid them if they can.

> > 3) upload a 'nobbled' version number, which is often done to deal
> > with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
> > dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $?
> > 
> You mean upload the 1.3.8a as 1.3.8+really1.3.8a, 1.3.8+really1.3.8b,
> 1.3.8+really1.3.8c etc. until we are at 1.3.9 und we can return to normal
> versioning?

Yes, exactly (sorry my example was a bit confused - I had the 1.3.8
and 1.3.8a ordering backwards in my head, but it doesn't affect the
mechanism). And yes, once you get to 1.3.9 you can go back to normal
version numbering.


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Debian versioning question

[Preuße , Hilmar]

On 10.11.2023 00:37, Mattia Rizzolo wrote:

On Thu, Nov 09, 2023 at 11:06:32PM +0100, Hilmar Preuße wrote:


Hello Mattia,


Can we override that anyhow?


Even if it was possible, how would that be of any help?  You do realize
that versioning order matters for much more than whatever is shown on a
web page, right?  Like, apt policy.  Or what dpkg does.

Not sure, why I did not recognize the severity of that issue earlier. 
Until yesterday it was just a display issue.



I can open an issue at upstream trying to
remove the RfC files, but I guess he's not really interested in these Debian
internals. Further it does not solve the issue for this particular upload.


You seem to have skipped the last paragraph of my last email.  What
about that?



Sorry. I'll talk to my co-workers about that. I got another suggestion, 
so let's see what we do.


Hilmra
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian versioning question

[Preuße , Hilmar]

On 10.11.2023 03:10, Wookey wrote:

Hi Wookey,


I think your options are
1) add an epoch (which exists to deal with this sort of problem)


Well, would like to avoid it, if possible.



2) wait till the next (numerical) release 1.3.9 and upload that.
Do releases happen often? This approach only really makes sense
if you/your users can put up with the old version until a
higher-versioned one appears


About every two years, so not uploading is not really in option.



3) upload a 'nobbled' version number, which is often done to deal
with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $?

You mean upload the 1.3.8a as 1.3.8+really1.3.8a, 1.3.8+really1.3.8b, 
1.3.8+really1.3.8c etc. until we are at 1.3.9 und we can return to 
normal versioning?



I'd probably go with option 3 in this case. Ugly but temporary.


Sounds like an option for now. Thanks!

Hilmar

--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian versioning question

[Wookey]

On 2023-11-09 23:06 +0100, Hilmar Preuße wrote:
> On 10/13/23 01:32, Mattia Rizzolo wrote:
> > On Thu, Oct 12, 2023 at 11:52:30PM +0200, Preuße, Hilmar wrote:
> 
> Hi Mattia,
> 
> > > The upstream minor versions are always determined by letters, so I'm 
> > > unsure
> > > how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints?

> I just noticed that it is not just a display issue on the web page, but a
> real issue: my latest uploaded was rejected telling me:
> 
> Your upload included the source package proftpd-dfsg, version 1.3.8a+dfsg-1,
> however testing already has version 1.3.8+dfsg-8.
> Uploads to unstable must have a higher version than present in testing.
> 
> Can we override that anyhow?

No. What's in the archive is in the archive. (Well I think you can ask
FTPmasters to remove something but that usually needs a better reason,
like "it contains illegal stuff").

> I can open an issue at upstream trying to
> remove the RfC files, but I guess he's not really interested in these Debian
> internals. Further it does not solve the issue for this particular upload.

Right this is a Debian problem not upstream.

I think your options are
1) add an epoch (which exists to deal with this sort of problem)
2) wait till the next (numerical) release 1.3.9 and upload that.
   Do releases happen often? This approach only really makes sense
   if you/your users can put up with the old version until a higher-versioned 
one appears 
3) upload a 'nobbled' version number, which is often done to deal
   with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
   dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $?

I'd probably go with option 3 in this case. Ugly but temporary.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Debian versioning question

[Mattia Rizzolo]

On Thu, Nov 09, 2023 at 11:06:32PM +0100, Hilmar Preuße wrote:
> I just noticed that it is not just a display issue on the web page, but a
> real issue: my latest uploaded was rejected telling me:
> 
> Your upload included the source package proftpd-dfsg, version 1.3.8a+dfsg-1,
> however testing already has version 1.3.8+dfsg-8.
> Uploads to unstable must have a higher version than present in testing.

I mean, of course.  What were you even expecting...?

> Can we override that anyhow?

Even if it was possible, how would that be of any help?  You do realize
that versioning order matters for much more than whatever is shown on a
web page, right?  Like, apt policy.  Or what dpkg does.

> I can open an issue at upstream trying to
> remove the RfC files, but I guess he's not really interested in these Debian
> internals. Further it does not solve the issue for this particular upload.

You seem to have skipped the last paragraph of my last email.  What
about that?


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Debian versioning question

[Hilmar Preuße]

On 10/13/23 01:32, Mattia Rizzolo wrote:

On Thu, Oct 12, 2023 at 11:52:30PM +0200, Preuße, Hilmar wrote:


Hi Mattia,


The upstream minor versions are always determined by letters, so I'm unsure
how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints?


This is a real sad interaction between the letters and the + in this
case.
Clearly the best solution would be to not need to repack anymore, this
would throw the problem away.  What's even the point of carrying the RFC
in the tarball nowadays?

Another solution would be to change the character used to separate the
'dfsg' string.  + tends to be preferred, but you could use ~ with the
same result most of the time, and it would likewise fix the problem:
 % dpkg --compare-versions 1.3.8a~dfsg-1 gt 1.3.8~dfsg-1
 => TRUE

I just noticed that it is not just a display issue on the web page, but 
a real issue: my latest uploaded was rejected telling me:


Your upload included the source package proftpd-dfsg, version 1.3.8a+dfsg-1,
however testing already has version 1.3.8+dfsg-8.
Uploads to unstable must have a higher version than present in testing.

Can we override that anyhow? I can open an issue at upstream trying to 
remove the RfC files, but I guess he's not really interested in these 
Debian internals. Further it does not solve the issue for this 
particular upload. Thanks!


Hilmar
--
Testmail



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian versioning question

[Mattia Rizzolo]

On Thu, Oct 12, 2023 at 11:52:30PM +0200, Preuße, Hilmar wrote:
> The upstream minor versions are always determined by letters, so I'm unsure
> how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints?

This is a real sad interaction between the letters and the + in this
case.
Clearly the best solution would be to not need to repack anymore, this
would throw the problem away.  What's even the point of carrying the RFC
in the tarball nowadays?

Another solution would be to change the character used to separate the
'dfsg' string.  + tends to be preferred, but you could use ~ with the
same result most of the time, and it would likewise fix the problem:
% dpkg --compare-versions 1.3.8a~dfsg-1 gt 1.3.8~dfsg-1
=> TRUE

Lastly, you could convince upstream to *always* release their first
release with the trailing character, so there are not release that end
with a number, similar to tzdata.



That said, for this 1.3.8 case you are quite stuck, as you can't do any
of the above.  The only option that comes to my mind is to just mess up
the upstream version string to something like 1.3.8.a+dfsg, and keep at
that until 1.3.9 comes out.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Debian versioning question

[Preuße , Hilmar]

Hello,

dumb question. Currently the vcswatch for proftpd-dfsg [1] reports:

"OLD: VCS is behind the version in the archive: 1.3.8a+dfsg-1 < 
1.3.8+dfsg-8."


According to deb-version(7) this is absolutely correct:

 First the initial part of each string consisting entirely of non-digit
 characters is determined.  These two parts (one of which may be empty)
 are compared lexically.  If a difference is found it is returned.  The
 lexical comparison is a comparison of ASCII values modified so that all
 the letters sort earlier than all the non-letters and so that a tilde
 sorts before anything, even the end of a part.

The upstream minor versions are always determined by letters, so I'm 
unsure how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints?


Hilmar

[1] https://qa.debian.org/cgi-bin/vcswatch?package=proftpd-dfsg
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Question about upload

[Preuße , Hilmar]

On 04.09.2023 13:30, Preuße, Hilmar wrote:

Hi,


I signed the package now correctly, the processing E-Mail said:

dvisvgm_3.1.1+ds-1.debian.tar.xz has incorrect size; deleting it

Do I have to re-upload or remove the "associated files" in any way?


The ACCEPTED mail just rolled in. Many thanks!

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Re: Question about upload

[Preuße , Hilmar]

On 04.09.2023 12:42, Andrey Rakhmatullin wrote:

On Mon, Sep 04, 2023 at 12:28:01PM +0200, Preuße, Hilmar wrote:


Hi all,


I'm trying to upload a new package for dvisvgm[1]. Unfortunately this does
not work: the dput command runs fine, but I did not even got the E-Mail that
the upload was successful and the package is processed.
In the meantime I could upload a new revision of texlive-bin, so there is no
general issue with my account. I'm using the upload server
"ftp.eu.upload.debian.org".



From usper:/srv/upload.debian.org/queued/run/log:


Sep  3 22:22:33 processing /dvisvgm_3.1.1+ds-1_source.changes
Sep  3 22:22:33 GnuPG signature check failed on 
dvisvgm_3.1.1+ds-1_source.changes
Sep  3 22:22:33 (Exit status 2)
Sep  3 22:22:33 /dvisvgm_3.1.1+ds-1_source.changes has bad PGP/GnuPG signature!
Sep  3 22:22:33 Removing /dvisvgm_3.1.1+ds-1_source.changes, but keeping its 
associated files for now.

Which is indeed the most frequent cause of "I did not even got the
E-Mail".

Umm, ooh. I just typed dput, which in turn called debsign to sign the 
package. Unfortunately it used the wrong key. Not sure why; 
DEBSIGN_KEYID in ~/.devscripts has the correct value.


I signed the package now correctly, the processing E-Mail said:

dvisvgm_3.1.1+ds-1.debian.tar.xz has incorrect size; deleting it

Do I have to re-upload or remove the "associated files" in any way?

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Re: Question about upload

[Timothy M Butterworth]

On Mon, Sep 4, 2023 at 6:43 AM Andrey Rakhmatullin  wrote:

> On Mon, Sep 04, 2023 at 12:28:01PM +0200, Preuße, Hilmar wrote:
> > Hi all,
> >
> > I'm trying to upload a new package for dvisvgm[1]. Unfortunately this
> does
> > not work: the dput command runs fine, but I did not even got the E-Mail
> that
> > the upload was successful and the package is processed.
> > In the meantime I could upload a new revision of texlive-bin, so there
> is no
> > general issue with my account. I'm using the upload server
> > "ftp.eu.upload.debian.org".
>
> >From usper:/srv/upload.debian.org/queued/run/log:
>
> Sep  3 22:22:33 processing /dvisvgm_3.1.1+ds-1_source.changes
> Sep  3 22:22:33 GnuPG signature check failed on
> dvisvgm_3.1.1+ds-1_source.changes
> Sep  3 22:22:33 (Exit status 2)
> Sep  3 22:22:33 /dvisvgm_3.1.1+ds-1_source.changes has bad PGP/GnuPG
> signature!
>

 "has bad PGP/GnuPG signature!"

Did you digitally sign the package?


> Sep  3 22:22:33 Removing /dvisvgm_3.1.1+ds-1_source.changes, but keeping
> its associated files for now.
>

The package is removed due to the bad signature.


> Which is indeed the most frequent cause of "I did not even got the
> E-Mail".
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Question about upload

[Andrey Rakhmatullin]

On Mon, Sep 04, 2023 at 12:28:01PM +0200, Preuße, Hilmar wrote:
> Hi all,
> 
> I'm trying to upload a new package for dvisvgm[1]. Unfortunately this does
> not work: the dput command runs fine, but I did not even got the E-Mail that
> the upload was successful and the package is processed.
> In the meantime I could upload a new revision of texlive-bin, so there is no
> general issue with my account. I'm using the upload server
> "ftp.eu.upload.debian.org".

>From usper:/srv/upload.debian.org/queued/run/log:

Sep  3 22:22:33 processing /dvisvgm_3.1.1+ds-1_source.changes
Sep  3 22:22:33 GnuPG signature check failed on 
dvisvgm_3.1.1+ds-1_source.changes
Sep  3 22:22:33 (Exit status 2)
Sep  3 22:22:33 /dvisvgm_3.1.1+ds-1_source.changes has bad PGP/GnuPG signature!
Sep  3 22:22:33 Removing /dvisvgm_3.1.1+ds-1_source.changes, but keeping its 
associated files for now.

Which is indeed the most frequent cause of "I did not even got the
E-Mail".

Question about upload

[Preuße , Hilmar]

Hi all,

I'm trying to upload a new package for dvisvgm[1]. Unfortunately this 
does not work: the dput command runs fine, but I did not even got the 
E-Mail that the upload was successful and the package is processed.
In the meantime I could upload a new revision of texlive-bin, so there 
is no general issue with my account. I'm using the upload server 
"ftp.eu.upload.debian.org".


How should I proceed? Thanks!

Hilmar

[1] https://tracker.debian.org/pkg/dvisvgm
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Re: Short question to Debian backports

[Bastian Germann]

Am 01.08.23 um 09:22 schrieb Gylstorff Quirin:

Hi,

I have a question related to Debian backports.

How are packages added to backports? From my understanding this depends 
on the package maintainer.


That is true generally. But as a non-DD you have to find a sponsor for 
that as well. Just use dch --bpo to generate a valid version number and 
target release.



Also can packages still added to bullseye backports?


Yes. You can upload a version based on the bookworm release version to 
bullseye-backports. Oy you can add a version based on testing to 
bullseye-backports-sloppy.



Thanks Kind regards

Quirin

Short question to Debian backports

[Gylstorff Quirin]

Hi,

I have a question related to Debian backports.

How are packages added to backports? From my understanding this depends 
on the package maintainer.


Also can packages still added to bullseye backports?

Thanks Kind regards

Quirin

Demands Question Demandon

[Simeone Dominique]

 Chers amis, dear friends, kara amikoj,
exist package for anarkist on Debian, il existe un paquet anarchiste pour 
Debian, ekzitas pakon pri anarkisno ĉe Debian.
Is-it possible to create a package for freemasonry(history,time,calendar...)? 
Est-il possible de créer un paquet sur la franc-maçonnerie (histoire, temps, 
calendrier...)? Ĉu estas eblo krei pakaĝon pri framasonismo (historio, tempo, 
kalendaro...)?
Plej Debiane, Le plus Debian, Best Debian.
Mr.Dominique SimeonePS : Calendrier Républicain, Calendar French 
Revolution,kalendaron de la Franca Revolucio. You can create it for Linŭx? Le 
créer pour linŭx. Krei por linŭx?

Bug#1025274: Bug#819332: License question about sf2 soundfont in Tuxguitar

[tony mancill]

On Mon, Jan 16, 2023 at 08:33:07AM -0800, tony mancill wrote:
> On Sun, Jan 15, 2023 at 10:02:55PM +0100, Helmar Gerloni wrote:
> > > https://lists.debian.org/debian-legal/2023/01/msg5.html
> > > https://lists.debian.org/debian-mentors/2023/01/msg00097.html
> > Roberto, Tobias, thanks for your answers.
> > 
> > I have removed MagicSFver2.sf2 from the package and added a note to 
> > README.Debian.
> > The new package now depends on fluid-soundfont-gm, see
> > https://mentors.debian.net/package/tuxguitar/
> > 
> > The package builds and runs on amd64 and in Qemu for arm64. It looks pretty 
> > good to me now.
> > Maybe someone can take a look and upload it?
> > If there is anything more I can do, just let me know.
> 
> Hello Helmar,
> 
> I am reviewing the updated package now and will either sponsor an upload
> if everything looks good or provide feedback.

The update looks great!  I have updated debian/copyright to document
the files that are licensed under a license other than the LGPL, but
otherwise everything looks good.  I will upload today.

For the time-being, I will push the updated sources and tag to the
current java-team repo [1], but we may want adjust that before the
bullseye release since the package is no longer team-maintained.

Thank you for your work on this!
tony

[1] https://salsa.debian.org/java-team/tuxguitar

Bug#1025274: Bug#819332: License question about sf2 soundfont in Tuxguitar

[tony mancill]

On Sun, Jan 15, 2023 at 10:02:55PM +0100, Helmar Gerloni wrote:
> > https://lists.debian.org/debian-legal/2023/01/msg5.html
> > https://lists.debian.org/debian-mentors/2023/01/msg00097.html
> Roberto, Tobias, thanks for your answers.
> 
> I have removed MagicSFver2.sf2 from the package and added a note to 
> README.Debian.
> The new package now depends on fluid-soundfont-gm, see
> https://mentors.debian.net/package/tuxguitar/
> 
> The package builds and runs on amd64 and in Qemu for arm64. It looks pretty 
> good to me now.
> Maybe someone can take a look and upload it?
> If there is anything more I can do, just let me know.

Hello Helmar,

I am reviewing the updated package now and will either sponsor an upload
if everything looks good or provide feedback.

Thank you!
tony


signature.asc
Description: PGP signature

Bug#1025274: License question about sf2 soundfont in Tuxguitar

[Helmar Gerloni]

> https://lists.debian.org/debian-legal/2023/01/msg5.html
> https://lists.debian.org/debian-mentors/2023/01/msg00097.html
Roberto, Tobias, thanks for your answers.

I have removed MagicSFver2.sf2 from the package and added a note to 
README.Debian.
The new package now depends on fluid-soundfont-gm, see
https://mentors.debian.net/package/tuxguitar/

The package builds and runs on amd64 and in Qemu for arm64. It looks pretty 
good to me now.
Maybe someone can take a look and upload it?
If there is anything more I can do, just let me know.

Bug#1025274: License question about sf2 soundfont in Tuxguitar

[Tobias Frost]

On Sat, Jan 14, 2023 at 11:02:46AM +0100, Helmar Gerloni wrote:
> Hello legal team,
> 
> I am trying to update the Tuxguitar package from version 1.2 to 1.5.6.
> 
> The new version includes the soundfont "Magic Sound Font v2.0". While
> Tuxguitar is licensed under LGPL-2.1+, the license of the soundfont file
> (MagicSFver2.sf2) is not 100% clear.
> 
> The issue was discussed in
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819332
> https://sourceforge.net/p/tuxguitar/support-requests/13/
> 
> In the SF ticket, the Tuxguitar author states that the author of the
> soundfont, Dennis, "allowed us redistribute the soundfont with tuxguitar".  I
> tried to email Dennis to ask about the license of the soundfont, but did not
> receive a reply.
> 
> The soundfont file can also be downloaded as "free soundfont" in the
> "Community Audio" collection on archive.org:
> 
> https://archive.org/details/opensource_audio?query=free-soundfonts-sf2-2019-04
> https://archive.org/download/free-soundfonts-sf2-2019-04/MagicSFver2.sf2
> 
> There are already a few other sf2 soundfonts in Debian. sf2 files can be
> edited with open source soundfont editors like Polyphone, so the format
> should not be a problem.
> 
> Do you think it is possible to add the file MagicSFver2.sf2 to the Debian
> package, maybe under LGPL-2.1+, like the Tuxguitar sources? Or maybe as
> "public domain"?

Disclaimer: IANAL.
I don't think neither of the two is appropiate:
- That the upstream author allowed tuxguitar to distribute does not mean it is 
LGPL.
- You cannot claim it is "Public Domain" [2] without the consent of the author, 
and
  the link you pasted [1] says that the author "wants some credits", and a 
Public Domain
  licenses would allow me to drop those credits. 

The "Dennis allowed us redistribute the soundfont with tuxguitar" [1] could be
a tuxguitar specific license, and only to *distribute*. Unclear if it would
apply to us so, but would still be non-free. 

The  "But he never mentioned anything about license" [1] part, could be even a
"all rights reservered." otherwise.

I would drop the file and ship without if Dennis is not answering.


[1] https://sourceforge.net/p/tuxguitar/support-requests/13/ 
[2] Public Domain has other problems too, especiall outside of the USA. 
For example, in my country, I could not place my work in "public domain",
as my country does not allow me to surrender my own copyright. (any
expression of me doing so would just be void).  The closest I can get is by
using something like CC0.

-- 
tobi

Bug#1025274: License question about sf2 soundfont in Tuxguitar

[Helmar Gerloni]

Hello legal team,

I am trying to update the Tuxguitar package from version 1.2 to 1.5.6.

The new version includes the soundfont "Magic Sound Font v2.0". While Tuxguitar 
is licensed under LGPL-2.1+, the license of the soundfont file 
(MagicSFver2.sf2) is not 100% clear.

The issue was discussed in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819332
https://sourceforge.net/p/tuxguitar/support-requests/13/

In the SF ticket, the Tuxguitar author states that the author of the soundfont, 
Dennis, "allowed us redistribute the soundfont with tuxguitar".
I tried to email Dennis to ask about the license of the soundfont, but did not 
receive a reply.

The soundfont file can also be downloaded as "free soundfont" in the "Community 
Audio" collection on archive.org:

https://archive.org/details/opensource_audio?query=free-soundfonts-sf2-2019-04
https://archive.org/download/free-soundfonts-sf2-2019-04/MagicSFver2.sf2

There are already a few other sf2 soundfonts in Debian. sf2 files can be edited 
with open source soundfont editors like Polyphone, so the format should not be 
a problem.

Do you think it is possible to add the file MagicSFver2.sf2 to the Debian 
package, maybe under LGPL-2.1+, like the Tuxguitar sources? Or maybe as "public 
domain"?

Regards,   Helmar.

Question about dh_icons and update-icon-caches

[Fabio Fantoni]

Hi, working on mint-y-icons packaging 
(https://salsa.debian.org/cinnamon-team/mint-y-icons) I saw 2 strange thing.


One about dh_icons that don't automatically add update-icon-caches for 
any theme but only some, upstream packaging seems add it manually for 
all theme as workaround 
(https://github.com/linuxmint/mint-y-icons/blob/master/debian/postinst). 
Is it a dh_icons issue or these themes don't really need update-icon-caches?


The second thing is related to theme removed in recent version, don't 
clean remove theme folder (/usr/share/icons/Mint-Y-Yellow) on upgrade 
for cache file still present, on package remove instead remove it and 
any other theme folder (with update-icon-caches in postrm added by 
dh_icons). The missed case of executing it on packaging upgrade is an 
issue? upstream workaround it with "rm -rf 
/usr/share/icons/Mint-Y-Yellow" in the postinst, don't seems good to me, 
is there a better alternative that I don't know?


Thanks for any reply and sorry for my bad english



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017588: Your autotools copyright question

[Bastian Germann]

Copyright info from these two files is missing:

libdrgn/arch_ppc64.c
libdrgn/kdump.c

Bug#1017588: Your autotools copyright question

[Michel Alexandre Salim]

On Fri, Aug 19, 2022 at 10:13:00AM +0200, Bastian Germann wrote:
> Am 19.08.22 um 03:41 schrieb Michel Alexandre Salim:
> > Quick question (applies to drgn, not libkdumpfile) - if the tarball
> > contains some m4 rules copied verbatim from autotools, do I have to list
> > them in d/copyright?
> 
> The answer is tricky: Per Debian Policy you have to include every license 
> that appears.
> You do not have to include the Copyright statements because the files are not 
> a compiled part of the binary.
> 
> Legally, it is okay to leave the licenses out of d/copyright and I have
> never seen ftpmaster reject a package because the FSF All Permissive License
> was missing. I do not think there is an official exception for it but there
> is certainly an unwritten exception.
> 
> So the official answer is: include them. The unofficial answer is: it is okay 
> not to.
> 
Got it, thanks! So if a unique license appears in the files that are not
a compiled part, the argument in favor of listing it in d/copyright gets
stronger, but if the license is the same and only the copyright is
different I'll probably lean towards skipping unless someone insists
they are included.

I fixed libkdumpfile last night per your feedback, but there's a minor
update just uploaded (2022-08-19 16:05) that refreshed the
patches - one replaced by the upstream commit fixing a bug I reported,
the other is now merged so I updated the header to include the fixed
commit.

Best,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature

Bug#1017588: Your autotools copyright question

[Bastian Germann]

Am 19.08.22 um 03:41 schrieb Michel Alexandre Salim:

Quick question (applies to drgn, not libkdumpfile) - if the tarball
contains some m4 rules copied verbatim from autotools, do I have to list
them in d/copyright?


The answer is tricky: Per Debian Policy you have to include every license that 
appears.
You do not have to include the Copyright statements because the files are not a 
compiled part of the binary.

Legally, it is okay to leave the licenses out of d/copyright and I have never seen ftpmaster reject a package because 
the FSF All Permissive License was missing. I do not think there is an official exception for it but there is certainly 
an unwritten exception.


So the official answer is: include them. The unofficial answer is: it is okay 
not to.

Re: Debuild question

[Marc Haber]

On Wed, Apr 20, 2022 at 10:53:53AM +0800, あきら wrote:
> I'm new to debian packaging, so I have a question troubling me for a long
> time, which is about debuild -Inothing, what does this do, and its effect.
> I can't find it on Google.

Using a search engine to find Debian docs is likely to find incomplete
and/or outdate docs, so you would probably be better off with searching
/usr/share/doc and the manual pages on your system. Other people have
pointed you to relevant docs that help novice packagers with their steep
learning curve.

That being said, debuild calls dpkg-buildpackage which in turn calls
many other tools, handing off options to the called utilities in a
sensible way as documented in the manual pages. So you might want to
sift through other manual pages as well to find out which tool
eventually processes that -Inothing option in your command.

In over 20 years as Debian Developer, I have never seen this.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Debuild question

[Andrey Rahmatullin]

On Wed, Apr 20, 2022 at 10:53:53AM +0800, あきら wrote:
> Hellow,
> I'm new to debian packaging, so I have a question troubling me for a long
> time, which is about debuild -Inothing, what does this do, and its effect.
What is the context of this question? If you don't know what is this,
don't use it?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debuild question

[Ko Ko Ye`]

Dear あきら

Can you share more detail ?
your code repo or build log



https://www.debian.org/doc/manuals/maint-guide/
https://www.debian.org/doc/manuals/debmake-doc/
https://www.debian.org/doc/devel-manuals

On Wed, Apr 20, 2022 at 9:42 AM あきら  wrote:

> Hellow,
> I'm new to debian packaging, so I have a question troubling me for a long
> time, which is about debuild -Inothing, what does this do, and its effect.
> I can't find it on Google.
> Thank you in advance.
>


-- 

with regards *Ko Ko Ye` *


kokoye2...@gmail.com
kokoye2...@ubuntu.com

https://www.linkedin.com/in/kokoye2007
https://ubuntu-mm.net
https://kokoye2007.github.io

Debuild question

[あきら]

Hellow,
I'm new to debian packaging, so I have a question troubling me for a long
time, which is about debuild -Inothing, what does this do, and its effect.
I can't find it on Google.
Thank you in advance.

Re: A question about "non official" debian packages

[Albert van der Horst]

> Op 04-03-2022 01:10 schreef Paul Wise :
> 
>  
> On Thu, 2022-03-03 at 16:30 +0100, Albert van der Horst wrote:
> 
> > Is it frowned upon by the Debian community to use the .deb format to
> > publish these packages? 
> 
> While it is fine to publish .deb packages outside of Debian, it is
> usually better for everyone and recommended by Debian to get them
> included in Debian itself. Take a look at this if you are interested:
> 
> https://mentors.debian.net/intro-maintainers/

I tried it and failed. I leave it to others to do the red taping if and when 
the packages get notoriety.
 
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Re: A question about "non official" debian packages

[Paul Wise]

On Thu, 2022-03-03 at 16:30 +0100, Albert van der Horst wrote:

> Is it frowned upon by the Debian community to use the .deb format to
> publish these packages? 

While it is fine to publish .deb packages outside of Debian, it is
usually better for everyone and recommended by Debian to get them
included in Debian itself. Take a look at this if you are interested:

https://mentors.debian.net/intro-maintainers/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: A question about "non official" debian packages

[Michael Stehmann]

Hello,

there are a lot of packages in deb format published outside the Debian 
community (esp. by some distributions, but also by some so called 
upstream projects).


The deb format is an open standard.

But there are some differences between Debian packages and packages 
using the deb format.


So it may be usefull (but not easy) to study what a Debian package 
really is. It increases the quality.


Kind regards
Michael, who is still studying how to package software for Debian

Re: A question about "non official" debian packages

[Geert Stappers]

On Thu, Mar 03, 2022 at 05:29:47PM +0100, Ali Mezgani wrote:
> On 03/03/2022, at 17:27, Andrey Rahmatullin  wrote:
> > On Thu, Mar 03, 2022 at 04:30:35PM +0100, Albert van der Horst wrote:
> >> Dear mentors,
> >> I plan to publish (at least) 4 Debian packages. 
> >> 
> >> The format is ideal for my users to install, and the .deb format
> >> takes care of installing .info files at the right place,
> >> something I find impossible to do.
> >> 
> >> Is it frowned upon by the Debian community to use the .deb format
> >> to publish these packages?
> > No, you may do anything you want.
> > 
> >> (And what are the sanctions?) 
> > Huh?

Yeah, I had also a hard time with understanding the by the way question.
I allow myself to read / to understand the original question as:

May I publish software in the Debian packaging format outside Debian?

 
> There are no sanction as well as sanctions of community.


Please be aware of trademarks and reputation.


Groeten
Geert Stappers
DD
-- 
Silence is hard to parse

Re: A question about "non official" debian packages

[Ali Mezgani]

Rahmatullin,

I remember you and I remember you contributions.

> On 03/03/2022, at 17:27, Andrey Rahmatullin  wrote:
> 
> On Thu, Mar 03, 2022 at 04:30:35PM +0100, Albert van der Horst wrote:
>> Dear mentors,
>> I plan to publish (at least) 4 Debian packages. 
>> 
>> The format is ideal for my users to install, and the .deb format takes care 
>> of installing .info files at the right place, something I find impossible to 
>> do. 
>> 
>> Is it frowned upon by the Debian community to use the .deb format to publish 
>> these packages? 
> No, you may do anything you want.
> 
>> (And what are the sanctions?) 
> Huh?
> 
There are no sanction as well as sanctions of community.

> -- 
> WBR, wRAR

Re: A question about "non official" debian packages

[Andrey Rahmatullin]

On Thu, Mar 03, 2022 at 04:30:35PM +0100, Albert van der Horst wrote:
> Dear mentors,
> I plan to publish (at least) 4 Debian packages. 
> 
> The format is ideal for my users to install, and the .deb format takes care 
> of installing .info files at the right place, something I find impossible to 
> do. 
> 
> Is it frowned upon by the Debian community to use the .deb format to publish 
> these packages? 
No, you may do anything you want.

> (And what are the sanctions?) 
Huh?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

A question about "non official" debian packages

[Albert van der Horst]

Dear mentors,
I plan to publish (at least) 4 Debian packages. 

The format is ideal for my users to install, and the .deb format takes care of 
installing .info files at the right place, something I find impossible to do. 

Is it frowned upon by the Debian community to use the .deb format to publish 
these packages? 
(And what are the sanctions?) 

Groetjes Albert

Re: Question about building a deb package

[Steffen Möller]

On 25.02.22 07:32, Andrey Rahmatullin wrote:

On Fri, Feb 25, 2022 at 11:44:46AM +0800, Yunmei Li wrote:

I am new to building deb packages, and I would like some help with a
question.
I am trying to build a deb package for Milvus(https://milvus.io/) on
Ubuntu18.04 or Ubuntu 20.04. Building Milvus requires Cmake 3.18 or higher,
but the latest version of cmake is 3.16 on Ubuntu 20.04 (golang has the
same situation). Could I directly use the cmake binary when building my
package? Or is there any other solution?


As others have already replied, for your local packages you are
completely free to do just anything, really. However, if you want
others, the automated builders of the release in particular, to rebuild
your package then this is not helpful.

If you are stuck with these older versions of Ubuntu then you could
backport cmake 3.18 to these releases. How exactly this works in Ubuntu
I cannot tell. You may want to start here
https://help.ubuntu.com/community/UbuntuBackports

Best,
Steffen

Re: Question about building a deb package

[Marc Haber]

On Fri, Feb 25, 2022 at 09:59:02AM +0100, Geert Stappers wrote:
> I don't understand what the "directly use the cmake binary" means.
> When cmake is needed, have cmake in the build environment ...

I think the OP meant manually putting a cmake 3.18 binary in the search
path of the system that doesnt have that version packaged, totally
missing the fact that automated building exists.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Question about building a deb package

[Sascha Steinbiss]

Hi,

>>> [...] Could I directly use the cmake binary when building my
>>> package?
> 
> I don't understand what the "directly use the cmake binary" means.
> When cmake is needed, have cmake in the build environment ...

I think this might refer to CMake directly being able to build .deb
packages (see https://cmake.org/cmake/help/latest/cpack_gen/deb.html)
without going through a source package?
This might work for personal use but would not be OK for inclusion into
the 'official' Debian archive.

Cheers
Sascha

Re: Question about building a deb package

[Geert Stappers]

On Fri, Feb 25, 2022 at 11:32:55AM +0500, Andrey Rahmatullin wrote:
> On Fri, Feb 25, 2022 at 11:44:46AM +0800, Yunmei Li wrote:
> > I am new to building deb packages, and I would like some help with a
> > question.
> > I am trying to build a deb package for Milvus(https://milvus.io/) on
> > Ubuntu18.04 or Ubuntu 20.04. Building Milvus requires Cmake 3.18 or higher,
> > but the latest version of cmake is 3.16 on Ubuntu 20.04 (golang has the
> > same situation). Could I directly use the cmake binary when building my
> > package?

I don't understand what the "directly use the cmake binary" means.
When cmake is needed, have cmake in the build environment ...


> > Or is there any other solution?

And I don't understand the problem  :-/

Is the problem

   Upstream saying "cmake 3.18 meter long works for us" and
   Yunmei asking "Will cmake of size 3.16 meter be long enough?"

or

   Upstream saying "We us features from cmake that first appeared in 3.18"
   and Yunmei reporting "I did one attempt and got some build error"

?


> As this mailing list is specifically about Debian contributions, this is
> offtopic here (both because the question is about Ubuntu and because it's
> about packaging for local use).

There is no need for alienating people that have a question
about building .debs

In http://www.catb.org/~esr/faqs/smart-questions.html is documented
that it is OK to ignore questions that don't deserve your time.

Show the world that you understand
that this is the mailinglinglist  debian-mentors@lists.debian.org


> For official packages the only common option would be to not build it on
> systems where the required dependency versions are not available.

Do not tell it can't be done to people who are already doing it.
More thruths in https://datatracker.ietf.org/doc/html/rfc1925



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Question about building a deb package

[Andrey Rahmatullin]

On Fri, Feb 25, 2022 at 11:44:46AM +0800, Yunmei Li wrote:
> I am new to building deb packages, and I would like some help with a
> question.
> I am trying to build a deb package for Milvus(https://milvus.io/) on
> Ubuntu18.04 or Ubuntu 20.04. Building Milvus requires Cmake 3.18 or higher,
> but the latest version of cmake is 3.16 on Ubuntu 20.04 (golang has the
> same situation). Could I directly use the cmake binary when building my
> package? Or is there any other solution?
As this mailing list is specifically about Debian contributions, this is
offtopic here (both because the question is about Ubuntu and because it's
about packaging for local use).
For official packages the only common option would be to not build it on
systems where the required dependency versions are not available.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Question about building a deb package

[Yunmei Li]

Hi,
I am new to building deb packages, and I would like some help with a
question.
I am trying to build a deb package for Milvus(https://milvus.io/) on
Ubuntu18.04 or Ubuntu 20.04. Building Milvus requires Cmake 3.18 or higher,
but the latest version of cmake is 3.16 on Ubuntu 20.04 (golang has the
same situation). Could I directly use the cmake binary when building my
package? Or is there any other solution?

Kind regards,
Yunmei LI

Re: Question regarding adding my application to Debian

[Leon Styhre]

Thanks again for your response.
Sorry that I was not clear with my initial message, no I'm not able to 
maintain the package myself.


The application will be packaged as Snap, Flatpak, and for 
Debian/Ubuntu/Mint, Arch/Manjaro, Fedora, FreeBSD, NetBSD, OpenBSD, 
macOS, Windows, Steam and probably more platforms.
I'm afraid that it's not realistic that I do all of this packaging on my 
own for all these platforms.

I also need to do the actual application development after all!

I've just filed the RFP, I'll now hope for the best and that someone 
picks it up.


Regards,

Leon

Re: Question regarding adding my application to Debian

[Andrey Rahmatullin]

On Wed, Aug 11, 2021 at 02:41:03PM +0200, Leon Styhre wrote:
> Thank you for your quick reply!
> 
> Yes there is a software package automatically generated when creating a
> release on GitLab.
> For example 
> https://gitlab.com/leonstyhre/emulationstation-de/-/archive/v1.1.0/emulationstation-de-v1.1.0.tar.gz
> It's as simple as running "cmake . && make" to build it, assuming all
> dependencies (which are all part of Debian) are fulfilled.
> There are also detailed build instructions available at
> https://gitlab.com/leonstyhre/emulationstation-de/-/blob/master/INSTALL.md
Yup, that doesn't use Debian source packages.

> I'm not sure what "good enough" means in this context 
In the contex of Debian source packages "good enough to be ready for
reviewing" means "mostly conformant to Debian packaging practices. But you
don't have a Debian source package.

> The reason I mention that there is already a .deb package available is that
> the software is working fine on Debian-based systems, is following the
> Debian directory structure, contains a proper man page etc.
Sure, but until you have a Debian source package that builds those debs
you have nothing to be reviewed and uploaded, so you should start with
making one.

> I will then proceed to file a WNPP bug report of the type RFP.
> It is good quality software and there is currently nothing equivalent on
> Debian so I hope someone will be able to support with maintaining the
> package!
> 
> If I understood the documentation correctly, since I'm asking for help for
> someone to maintain the Debian package, I should not proceed with the other
> steps such as publishing the package, look for a sponsor etc?
> Thanks!
It wasn't clear from your initial message that you don't intend to
maintain it yourself. In this case you indeed can only file an RFP (though
that doesn't mean anybody will act on it and an RFP is not needed for
someone to package something).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Question regarding adding my application to Debian

[Leon Styhre]

Thank you for your quick reply!

Yes there is a software package automatically generated when creating a 
release on GitLab.
For example 
https://gitlab.com/leonstyhre/emulationstation-de/-/archive/v1.1.0/emulationstation-de-v1.1.0.tar.gz
It's as simple as running "cmake . && make" to build it, assuming all 
dependencies (which are all part of Debian) are fulfilled.
There are also detailed build instructions available at 
https://gitlab.com/leonstyhre/emulationstation-de/-/blob/master/INSTALL.md


I'm not sure what "good enough" means in this context though, from a 
software perspective it definitely is, as this is a stable and 
well-tested release that works on multiple operating systems.
But maybe it's not good enough when it comes to Debian packaging? It's 
regarding this part that I'm a bit lost.


The reason I mention that there is already a .deb package available is 
that the software is working fine on Debian-based systems, is following 
the Debian directory structure, contains a proper man page etc.


I will then proceed to file a WNPP bug report of the type RFP.
It is good quality software and there is currently nothing equivalent on 
Debian so I hope someone will be able to support with maintaining the 
package!


If I understood the documentation correctly, since I'm asking for help 
for someone to maintain the Debian package, I should not proceed with 
the other steps such as publishing the package, look for a sponsor etc?

Thanks!

Regards,

Leon

Re: Question regarding adding my application to Debian

[Andrey Rahmatullin]

On Wed, Aug 11, 2021 at 11:25:05AM +0200, Leon Styhre wrote:
> I'm a little bit lost though regarding the process, should I go ahead and
> create a Request For Sponsor report right away, or should I first get in
> contact with someone in the Debian Games team for example?
First you should create a source package that is good enough to be ready
for reviewing. Finding a sponsor is only the next step. Please follow
https://mentors.debian.net/intro-maintainers and then
https://mentors.debian.net/sponsors/

> FYI, I already distribute the application as a .deb package via the project
> website 
Unless you already have a source package (which you didn't mention) this
is not that useful.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Question regarding adding my application to Debian

[Leon Styhre]

Hi!

I have been working on a fork of EmulationStation (the front-end used by 
the RetroPie project) for around 1,5 years and would like to add this 
application to Debian.
The name of the project is ES-DE (EmulationStation Desktop Edition) and 
it runs on Linux, BSD Unix, macOS and Windows.


I'm a little bit lost though regarding the process, should I go ahead 
and create a Request For Sponsor report right away, or should I first 
get in contact with someone in the Debian Games team for example?
I have read the DebianMentorsFaq document but I'm still a bit confused 
regarding the proper steps to take.


FYI, I already distribute the application as a .deb package via the 
project website and it has been tested on Ubuntu and Linux Mint, but I 
propably don't fulfill all the Debian packaging requirements.


The website for ES-DE is:
https://es-de.org

The source code is hosted on GitLab:
https://gitlab.com/leonstyhre/emulationstation-de

Many thanks in advance!

Regards,

Leon

Re: Question about writing systemd unit for old package

[Richard Hector]

On 20/05/21 1:59 pm, Alec Leamas wrote:

Hi,

On 20/05/2021 03:35, Paul Wise wrote:

On Wed, May 19, 2021 at 8:51 AM Richard Hector wrote:


Does that not depend on whether it does anything before dropping
privileges? For example, a webserver can bind to low ports before
dropping privilege. I imagine if the systemd service unit specified
running as (eg) www-data, that wouldn't work.


I don't know the details, but I think systemd can open the ports and
transparently pass them to the unprivileged process when it is spawned
without any data loss, in a similar way to the inetd stuff used to
work.



http://0pointer.de/blog/projects/socket-activation.html


I confess I haven't read all that, and don't know the details of socket 
activation. But I think the service in question needs to be aware of it, 
doesn't it? It doesn't apply to wrapping a systemd service unit around 
an existing server. The nginx unit, for example, doesn't set a user, but 
a user is set in the nginx config file so it can drop privs.


I'm happy to be corrected :-)

Richard

Re: Question with packaging for non-free

[Mechtilde Stehmann]

Hello Hunter

Am 21.05.21 um 08:51 schrieb Hunter Wittenborn:
> Hello,
> 
> I've recently been working on a project called
> https://github.com/hwittenborn/makedeb that converts Arch Linux
> packages into Debian packages. More specifically, it takes the Arch
> Linux build format, PKGBUILDs, and uses them to make Debian
> packages.
> 
> As of recent, I've been wanting to package it for the Debian
> repositories, but makedeb itself only makes binary packages (makedeb
> is also self-building).

Do you want to have the package "makedeb" in the Debian Repo?

If yes, then try to build it from its source. Then it can be published
in main

> As a result of that, I've decided that the best course of action
> would be to publish it to the
> https://www.debian.org/doc/debian-policy/ch-archive#s-non-free, but I
> haven't been able to find where I would start for that. I've looked
> at the https://mentors.debian.net/intro-maintainers/ page, but it
> looked like the guide was written up for people creating source
> packages.
> 
> Is there anywhere I should look at, or anyone I should contact?
> 

Kind regards
-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

Re: Question with packaging for non-free

[Polyna-Maude Racicot-Summerside]

Hi!

On 2021-05-21 2:51 a.m., Hunter Wittenborn wrote:
> Hello,
> 
> I've recently been working on a project called makedeb
>  that converts Arch Linux
> packages into Debian packages. More specifically, it takes the Arch
> Linux build format, PKGBUILDs, and uses them to make Debian packages.
> 
> As of recent, I've been wanting to package it for the Debian
> repositories, but makedeb itself only makes binary packages (makedeb is
> also self-building).
> 

Why are you putting the package in non-free ?
What license did you put your software under ?

There's rule regarding GPL software and packaging that must be followed...

> As a result of that, I've decided that the best course of action would
> be to publish it to the non-free archive
> , but I
> haven't been able to find where I would start for that. I've looked at
> the Debian Mentors  page,
> but it looked like the guide was written up for people creating source
> packages.
> 
> Is there anywhere I should look at, or anyone I should contact?
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Question with packaging for non-free

[Polyna-Maude Racicot-Summerside]

Hi,


On 2021-05-21 2:51 a.m., Hunter Wittenborn wrote:
> Hello,
> 
> I've recently been working on a project called makedeb
>  that converts Arch Linux
> packages into Debian packages. More specifically, it takes the Arch
> Linux build format, PKGBUILDs, and uses them to make Debian packages.
> 
> As of recent, I've been wanting to package it for the Debian
> repositories, but makedeb itself only makes binary packages (makedeb is
> also self-building).
> 
> As a result of that, I've decided that the best course of action would
> be to publish it to the non-free archive
> , but I
> haven't been able to find where I would start for that. I've looked at
> the Debian Mentors  page,
> but it looked like the guide was written up for people creating source
> packages.
> 
> Is there anywhere I should look at, or anyone I should contact?
> 

I'd start by looking at the Debian Developer Handbook / Reference if you
already have a feet in the house.

https://www.debian.org/doc/manuals/developers-reference/index.en.html

 I doubt it's the case so I'd suggest you read the Debian New Maintainer
guide.

https://www.debian.org/doc/manuals/maint-guide/index.en.html

Now, I'll talk only on my own behalf...
Take into account that even if you software may seem pretty useful, it
doesn't mean it will make it's way into Debian distribution. At first,
maybe you shall start by getting yourself known from the community, get
to know people, this way we'll see that you are serious in what you are
doing. You are not the first one interested in giving time or having a
package integrated into the repository. And as we are all human, people
have different reason to do so. Some of them is because they want the
software to be included as it will benefit visibility for their business
in some way, some people just want to do it so they can say they did,
etc. But one thing also is that even if you have done some work, it will
require much work from other developers in the community too. Time is
scarce and rare, so there's not much interest in trying to help someone
publish a package and that the person stop doing updates or doesn't have
the knowledge to support bugs that may arise.

People don't want to end up needing to finish others work, already have
their own.

So there's the reason I say, get yourself known.

I'd also suggest that you publish your package somewhere on a public
server. You can just put the package in a folder and sign it with your
PGP key, publish the public key on a keyserver too.

This way, at first we'll get a first hard test, what will lintian say
about compliance !

As you may have noticed, some software that exist in Kali or Ubuntu will
never end up in Debian. There's a huge reason for this, all the
specifications regarding to build of packages. This way we can also
ensure that the software will build on many architectures and will be
somewhat safe (for example compile flag to protect stack smash).

Here's a start... Hope this help you out.

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Question with packaging for non-free

[Hunter Wittenborn]

Hello,



I've recently been working on a project called 
https://github.com/hwittenborn/makedeb that converts Arch Linux packages into 
Debian packages. More specifically, it takes the Arch Linux build format, 
PKGBUILDs, and uses them to make Debian packages.



As of recent, I've been wanting to package it for the Debian repositories, but 
makedeb itself only makes binary packages (makedeb is also self-building).



As a result of that, I've decided that the best course of action would be to 
publish it to the 
https://www.debian.org/doc/debian-policy/ch-archive#s-non-free, but I haven't 
been able to find where I would start for that. I've looked at the 
https://mentors.debian.net/intro-maintainers/ page, but it looked like the 
guide was written up for people creating source packages.



Is there anywhere I should look at, or anyone I should contact?

Re: Question about writing systemd unit for old package

[Alec Leamas]

Hi,

On 20/05/2021 03:35, Paul Wise wrote:
> On Wed, May 19, 2021 at 8:51 AM Richard Hector wrote:
> 
>> Does that not depend on whether it does anything before dropping
>> privileges? For example, a webserver can bind to low ports before
>> dropping privilege. I imagine if the systemd service unit specified
>> running as (eg) www-data, that wouldn't work.
> 
> I don't know the details, but I think systemd can open the ports and
> transparently pass them to the unprivileged process when it is spawned
> without any data loss, in a similar way to the inetd stuff used to
> work.


http://0pointer.de/blog/projects/socket-activation.html



Cheers!
--alec

Re: Question about writing systemd unit for old package

[Paul Wise]

On Wed, May 19, 2021 at 8:51 AM Richard Hector wrote:

> Does that not depend on whether it does anything before dropping
> privileges? For example, a webserver can bind to low ports before
> dropping privilege. I imagine if the systemd service unit specified
> running as (eg) www-data, that wouldn't work.

I don't know the details, but I think systemd can open the ports and
transparently pass them to the unprivileged process when it is spawned
without any data loss, in a similar way to the inetd stuff used to
work.

http://0pointer.de/blog/projects/inetd.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Question about writing systemd unit for old package

[Richard Hector]

On 18/05/21 11:58 am, Paul Wise wrote:

On Mon, May 17, 2021 at 12:51 PM Khoa Tran Minh wrote:




A related question: The binary itself can drop privilege and run as
non-root, then should I use that native feature or use systemd User= when
writing a default config/unit ?


I would suggest to use systemd features for this.


Does that not depend on whether it does anything before dropping 
privileges? For example, a webserver can bind to low ports before 
dropping privilege. I imagine if the systemd service unit specified 
running as (eg) www-data, that wouldn't work.


Cheers,
Richard

Re: Question about writing systemd unit for old package

[Paul Wise]

On Mon, May 17, 2021 at 12:51 PM Khoa Tran Minh wrote:

> I'm trying to write a new systemd unit for mini-httpd package, which is
> using lsb-base to init. Can I replace the old init script straight up, or
> do I have to maintain both the systemd unit and the old init script ?

Please make sure you send the systemd unit upstream too.

Users of init systems other than systemd would probably appreciate it
if you didn't remove the old init script.

If the old init script is crufty, you could rebase it onto the
init-d-script tool, but I am not sure how portable that is to
non-Debian distros.

https://manpages.debian.org/init-d-script

> A related question: The binary itself can drop privilege and run as
> non-root, then should I use that native feature or use systemd User= when
> writing a default config/unit ?

I would suggest to use systemd features for this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Question about writing systemd unit for old package

[Khoa Tran Minh]

Hi everyone,

I'm trying to write a new systemd unit for mini-httpd package, which is
using lsb-base to init. Can I replace the old init script straight up, or
do I have to maintain both the systemd unit and the old init script ?

A related question: The binary itself can drop privilege and run as
non-root, then should I use that native feature or use systemd User= when
writing a default config/unit ?

Regards,
Khoa

Re: Question on rm_conffile

[Sven Joachim]

On 2021-02-22 09:09 -0500, Tong Sun wrote:

>> On Mon, Feb 22, 2021 at 12:33 AM Tong Sun wrote:
>>
>> > Can I use rm_conffile to remove a (conffile) directory?
>> >
>> > I checked the man page but am still not too sure about that.
>
> I am still not too sure about the above yet.

If you want to remove the directory, you need to do it yourself.
Something like

rmdir --ignore-fail-on-non-empty /etc/whatever

after the #DEBHELPER# line in the postinst script should do it, I think.
Unfortunately, dpkg-maintscript-helper is not very helpful here, see
https://bugs.debian.org/584185.

Cheers,
   Sven

Re: Question on rm_conffile

[Sebastiaan Couwenberg]

On 2/22/21 3:08 PM, Tong Sun wrote:
> A follow up question, dpkg-maintscript-helper(1) suggests to use
> 
> Pre-Depends: dpkg (>= 1.17.14)
> 
> But of the several packages that use rm_conffile that I checked, none
> of them is using `Pre-Depends: dpkg (>= 1.17.14)` in their control
> file. Was I not looking at the correct place or there is something
> else (e.g., it's pretty safe not to do that nowadays)?

dpkg 1.17.27 is in oldoldstable, so the version requirement is met with
any reasonably recent Debian release:

 $ rmadison -a amd64 dpkg
 dpkg   | 1.17.27   | oldoldstable | amd64
 dpkg   | 1.18.25   | oldstable| amd64
 dpkg   | 1.19.7| stable   | amd64
 dpkg   | 1.20.7.1  | testing  | amd64
 dpkg   | 1.20.7.1  | unstable | amd64

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Question on rm_conffile

[Tong Sun]

> On Mon, Feb 22, 2021 at 12:33 AM Tong Sun wrote:
>
> > Can I use rm_conffile to remove a (conffile) directory?
> >
> > I checked the man page but am still not too sure about that.

I am still not too sure about the above yet.

Re: Question on rm_conffile

[Tong Sun]

On Mon, Feb 22, 2021 at 8:45 AM Sebastiaan Couwenberg -
sebas...@xs4all.nl
 wrote:
>
> On 2/22/21 2:23 PM, Tong Sun wrote:
> > However, when I did some research, I found that most packages put
> > rm_conffile in the  .maintscript file. Where does that come from? It
> > is even not in the man page. OK that I put rm_conffile in the
> > .maintscript file as well, instead of in all 3 scripts (preinst,
> > postinst, postrm)?
>
> dpkg-maintscript-helper(1) refers to dh_installdeb(1) which documents
> the .maintscript files, see:
>
>  https://manpages.debian.org/buster/dpkg/dpkg-maintscript-helper.1.en.html
>  https://manpages.debian.org/buster/debhelper/dh_installdeb.1.en.html

Got it. Thanks

A follow up question, dpkg-maintscript-helper(1) suggests to use

Pre-Depends: dpkg (>= 1.17.14)

But of the several packages that use rm_conffile that I checked, none
of them is using `Pre-Depends: dpkg (>= 1.17.14)` in their control
file. Was I not looking at the correct place or there is something
else (e.g., it's pretty safe not to do that nowadays)?

Re: Question on rm_conffile

[Sebastiaan Couwenberg]

On 2/22/21 2:23 PM, Tong Sun wrote:
> However, when I did some research, I found that most packages put
> rm_conffile in the  .maintscript file. Where does that come from? It
> is even not in the man page. OK that I put rm_conffile in the
> .maintscript file as well, instead of in all 3 scripts (preinst,
> postinst, postrm)?

dpkg-maintscript-helper(1) refers to dh_installdeb(1) which documents
the .maintscript files, see:

 https://manpages.debian.org/buster/dpkg/dpkg-maintscript-helper.1.en.html
 https://manpages.debian.org/buster/debhelper/dh_installdeb.1.en.html

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Question on rm_conffile

[Tong Sun]

On Mon, Feb 22, 2021 at 12:33 AM Tong Sun wrote:

> Can I use rm_conffile to remove a (conffile) directory?
>
> I checked the man page but am still not too sure about that.

Moreover, in

The right way to remove an obsolete conffile in a Debian package
https://raphaelhertzog.com/2010/10/07/the-right-way-to-remove-an-obsolete-conffile-in-a-debian-package/

it says to put rm_conffile in the 3 relevant scripts (preinst, postinst, postrm)

However, when I did some research, I found that most packages put
rm_conffile in the  .maintscript file. Where does that come from? It
is even not in the man page. OK that I put rm_conffile in the
.maintscript file as well, instead of in all 3 scripts (preinst,
postinst, postrm)?

Re: Question about lintian bad-whatis-entry warning

[Aaron Boxer]

On Wed, Dec 23, 2020 at 1:36 PM Robin Gustafsson  wrote:

> Hi Aaron,
>
> > How can I get more insight into the problem?
>
> Lintian's explanation for bad-whatis-entry [1] mentions that it's
> "lexgrog" that fails to parse your header. (Looking at Lintian source
> [2], it's indeed just running lexgrog on your file and checking the
> exit code.)
>
> The lexgrog man page contains more info about how specifically the
> NAME section is parsed and some requirements for it to work. Perhaps
> that could help. The part about "\-" might be of particular interest.
> It also mentions a "--debug" option that could perhaps provide you
> with some leads if you try running lexgrog on your file manually.
>
> [1] https://lintian.debian.org/tags/bad-whatis-entry.html
> [2]
> https://salsa.debian.org/lintian/lintian/-/blob/c9601fc5/lib/Lintian/Check/Documentation/Manual.pm#L241


Thanks! I did look deeper into lexgrog, turned out it doesn't like fancy
en-dash and em-dash characters that pandoc
was generating.

Re: Question about lintian bad-whatis-entry warning

[Aaron Boxer]

On Wed, Dec 23, 2020 at 1:36 PM The Wanderer  wrote:

> On 2020-12-23 at 13:04, Aaron Boxer wrote:
>
> > On Wed, Dec 23, 2020 at 11:42 AM The Wanderer 
> > wrote:
> >
> >> On 2020-12-23 at 11:25, Aaron Boxer wrote:
> >>
> >>> Hi,
> >>> I have some questions about a lintian warning I am getting from my
> package.
> >>> It complains that the NAME section of the man page can't be parsed.
> >>> Here is how the section appears in my man page:
> >>>
> >>> NAME
> >>>grk_compress — compresses images to JPEG 2000 format
> >>>
> >>> Note: I generate the man page from markdown files via pandoc.
> >>>
> >>> How can I get more insight into the problem?
> >>
> >> I have no particular relevant expertise, but one thing I notice
> >> instantly is that that doesn't quite look like a standard hyphen.
> >>
> >> Indeed, copying it into a text file and examining it with a hex viewer
> >> shows that — is apparently 0x8094, whereas - is 0x2d.
>
> (Correction: that's 0xe28094, which in UTF-8 is
> https://www.fileformat.info/info/unicode/char/2014/index.htm.)
>
> >> It might be worth checking whether that one character is the cause of
> >> this.
> >
> > Unfortunately, switching to en dash does not fix the problem
>
> What's the hex value of the generated character?
>
> Again, I could be barking up a completely wrong tree. However, as I
> understand matters there are Unicode emdash and endash characters
> (U+2014 and U+2013 respectively), both of which are distinct from the
> ASCII hyphen (U+002D). It's not impossible that the system involved may
> understand the latter but not the two former.
>

Yes, correct, thanks. I switched to good old ASCII hyphen and the warning
is now gone!



>
> --
>The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>
>

Re: Question about lintian bad-whatis-entry warning

[The Wanderer]

On 2020-12-23 at 13:04, Aaron Boxer wrote:

> On Wed, Dec 23, 2020 at 11:42 AM The Wanderer 
> wrote:
>
>> On 2020-12-23 at 11:25, Aaron Boxer wrote:
>>
>>> Hi,
>>> I have some questions about a lintian warning I am getting from my package.
>>> It complains that the NAME section of the man page can't be parsed.
>>> Here is how the section appears in my man page:
>>>
>>> NAME
>>>grk_compress — compresses images to JPEG 2000 format
>>>
>>> Note: I generate the man page from markdown files via pandoc.
>>>
>>> How can I get more insight into the problem?
>>
>> I have no particular relevant expertise, but one thing I notice
>> instantly is that that doesn't quite look like a standard hyphen.
>>
>> Indeed, copying it into a text file and examining it with a hex viewer
>> shows that — is apparently 0x8094, whereas - is 0x2d.

(Correction: that's 0xe28094, which in UTF-8 is
https://www.fileformat.info/info/unicode/char/2014/index.htm.)

>> It might be worth checking whether that one character is the cause of
>> this.
> 
> Unfortunately, switching to en dash does not fix the problem

What's the hex value of the generated character?

Again, I could be barking up a completely wrong tree. However, as I
understand matters there are Unicode emdash and endash characters
(U+2014 and U+2013 respectively), both of which are distinct from the
ASCII hyphen (U+002D). It's not impossible that the system involved may
understand the latter but not the two former.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Question about lintian bad-whatis-entry warning

[Robin Gustafsson]

Hi Aaron,

> How can I get more insight into the problem?

Lintian's explanation for bad-whatis-entry [1] mentions that it's
"lexgrog" that fails to parse your header. (Looking at Lintian source
[2], it's indeed just running lexgrog on your file and checking the
exit code.)

The lexgrog man page contains more info about how specifically the
NAME section is parsed and some requirements for it to work. Perhaps
that could help. The part about "\-" might be of particular interest.
It also mentions a "--debug" option that could perhaps provide you
with some leads if you try running lexgrog on your file manually.

[1] https://lintian.debian.org/tags/bad-whatis-entry.html
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/c9601fc5/lib/Lintian/Check/Documentation/Manual.pm#L241

Re: Question about lintian bad-whatis-entry warning

[Aaron Boxer]

On Wed, Dec 23, 2020 at 12:56 PM Aaron Boxer  wrote:

>
>
> On Wed, Dec 23, 2020 at 11:42 AM The Wanderer 
> wrote:
>
>> On 2020-12-23 at 11:25, Aaron Boxer wrote:
>>
>> > Hi,
>> > I have some questions about a lintian warning I am getting from my
>> package.
>> > It complains that the NAME section of the man page can't be parsed.
>> > Here is how the section appears in my man page:
>> >
>> > NAME
>> >grk_compress — compresses images to JPEG 2000 format
>> >
>> > Note: I generate the man page from markdown files via pandoc.
>> >
>> > How can I get more insight into the problem?
>>
>> I have no particular relevant expertise, but one thing I notice
>> instantly is that that doesn't quite look like a standard hyphen.
>>
>> Indeed, copying it into a text file and examining it with a hex viewer
>> shows that — is apparently 0x8094, whereas - is 0x2d.
>>
>> It might be worth checking whether that one character is the cause of
>> this.
>>
>

Unfortunately, switching to en dash does not fix the problem



>
>
> Thanks! Yes, this is an em dash
>
> https://www.thesaurus.com/e/grammar/em-dash/
>
> troff symbol is
>
> \[em]
>
>
>
>> --
>>The Wanderer
>>
>> The reasonable man adapts himself to the world; the unreasonable one
>> persists in trying to adapt the world to himself. Therefore all
>> progress depends on the unreasonable man. -- George Bernard Shaw
>>
>>

Re: Question about lintian bad-whatis-entry warning

[Aaron Boxer]

On Wed, Dec 23, 2020 at 11:42 AM The Wanderer  wrote:

> On 2020-12-23 at 11:25, Aaron Boxer wrote:
>
> > Hi,
> > I have some questions about a lintian warning I am getting from my
> package.
> > It complains that the NAME section of the man page can't be parsed.
> > Here is how the section appears in my man page:
> >
> > NAME
> >grk_compress — compresses images to JPEG 2000 format
> >
> > Note: I generate the man page from markdown files via pandoc.
> >
> > How can I get more insight into the problem?
>
> I have no particular relevant expertise, but one thing I notice
> instantly is that that doesn't quite look like a standard hyphen.
>
> Indeed, copying it into a text file and examining it with a hex viewer
> shows that — is apparently 0x8094, whereas - is 0x2d.
>
> It might be worth checking whether that one character is the cause of this.
>


Thanks! Yes, this is an em dash

https://www.thesaurus.com/e/grammar/em-dash/

troff symbol is

\[em]



> --
>The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>
>

Re: Question about lintian bad-whatis-entry warning

[The Wanderer]

On 2020-12-23 at 11:25, Aaron Boxer wrote:

> Hi,
> I have some questions about a lintian warning I am getting from my package.
> It complains that the NAME section of the man page can't be parsed.
> Here is how the section appears in my man page:
> 
> NAME
>grk_compress — compresses images to JPEG 2000 format
> 
> Note: I generate the man page from markdown files via pandoc.
> 
> How can I get more insight into the problem?

I have no particular relevant expertise, but one thing I notice
instantly is that that doesn't quite look like a standard hyphen.

Indeed, copying it into a text file and examining it with a hex viewer
shows that — is apparently 0x8094, whereas - is 0x2d.

It might be worth checking whether that one character is the cause of this.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Question about lintian bad-whatis-entry warning

[Aaron Boxer]

Hi,
I have some questions about a lintian warning I am getting from my package.
It complains that the NAME section of the man page can't be parsed.
Here is how the section appears in my man page:

NAME
   grk_compress — compresses images to JPEG 2000 format

Note: I generate the man page from markdown files via pandoc.

How can I get more insight into the problem?

Thanks,
Aaron

Bug#976120: (QAbc packaging) debhelper version question

[Andrey Rahmatullin]

On Fri, Dec 04, 2020 at 10:08:29PM +0100, Benoît Rouits wrote:
> Thank you for your reply.
> 
> I used to put this line:
> Build-Depends: debhelper-compat (= 12), ...
> 
> Should I then remove "-compat" like this ?
> Build-Depends: debhelper (= 13), ...
No. Build-Depends: debhelper is a normal build-depends while
Build-Depends: debhelper-compat is both a build-depends on debhelper (with
a >=) and a declaration of the compat level.
Please read the "COMPATIBILITY LEVELS" section in debhelper(7) for more
information.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#976120: (QAbc packaging) debhelper version question

[Benoît Rouits]

Thank you for your reply.

I used to put this line:
Build-Depends: debhelper-compat (= 12), ...

Should I then remove "-compat" like this ?
Build-Depends: debhelper (= 13), ...

Le 04/12/2020 à 21:29, Andrey Rahmatullin a écrit :

On Fri, Dec 04, 2020 at 08:39:26PM +0100, Benoît Rouits wrote:

I use debhelper but I don't use specific features
of debhelper 13.
Anyway, should I set debhelper = 13 as build dependency

Yes.


or can I set debhelper >= 12 to be more flexible
for transition from sid to testing and to stable ?

It won't help "for transition from sid to testing" and there is no
"transition to stable".

Bug#976120: (QAbc packaging) debhelper version question

[Andrey Rahmatullin]

On Fri, Dec 04, 2020 at 08:39:26PM +0100, Benoît Rouits wrote:
> I use debhelper but I don't use specific features
> of debhelper 13.
> Anyway, should I set debhelper = 13 as build dependency
Yes.

> or can I set debhelper >= 12 to be more flexible
> for transition from sid to testing and to stable ?
It won't help "for transition from sid to testing" and there is no
"transition to stable".

-- 
WBR, wRAR


signature.asc
Description: PGP signature