Re: Usage of DEP5

[Andreas Tille]

On Tue, Nov 12, 2019 at 11:32:09PM +0100, gregor herrmann wrote:
> > I'd like to suggest this recommendation could be of the same strength as
> > the "use salsa" recommendation, i.e., weaker than the dh recommendation,
> > and directed at people with no reasons to prefer either who are
> > wondering which to use.
>  
> I was not aware of a difference in strength between the two
> recommendation [0]

I also was not aware that there are different strengths of
recommendation. ;-)

> but yes, the "people with no reason to prefer
> either" was the direction I was heading at.

Definitely.  Moreover, may be I have missed it but the question to some
example where the free form text is easier to read than the machine
readable one was not answered yet.  I'm keen on reading this.

Kind regards

 Andreas.

> [0] I'm probably not in the target group as I'm doing it anyway

-- 
http://fam-tille.de

Re: Usage of DEP5

[Sam Hartman]

> "Andreas" == Andreas Tille  writes:

Andreas> On Tue, Nov 12, 2019 at 11:32:09PM +0100, gregor herrmann wrote:
>> > I'd like to suggest this recommendation could be of the same
>> strength as > the "use salsa" recommendation, i.e., weaker than
>> the dh recommendation, > and directed at people with no reasons
>> to prefer either who are > wondering which to use.
>> 
>> I was not aware of a difference in strength between the two
>> recommendation [0]

Andreas> I also was not aware that there are different strengths of
Andreas> recommendation. ;-)

I think we'd all be kind of confused if someone started filing bugs
because a package was not in salsa.

There are cases where not using dh is a non-RC bug, and there are
probably cases where having someone other than the maintainer file that
bug makes sense.

>> but yes, the "people with no reason to prefer either" was the
>> direction I was heading at.

Andreas> Definitely.  Moreover, may be I have missed it but the
Andreas> question to some example where the free form text is easier
Andreas> to read than the machine readable one was not answered yet.
Andreas> I'm keen on reading this.


It sounds like there's a proposal here with some support.
does someone want to facilitate this discussion?

* Pay attention to any issues that get brought up

* Summarize at the end

* If there is consensus to make a recommendation, figure out where it
  should go and file a bug  pointing to the summary.

I don't think facilitating the discussion should obligate someone to
write text for dev ref or policy or Shepherd things through those
processes.
Although obviously, the more work you put into it, the faster things
might happen.

Re: Usage of DEP5

[Andreas Tille]

On Wed, Nov 13, 2019 at 06:07:46AM -0500, Sam Hartman wrote:
> > "Andreas" == Andreas Tille  writes:
> 
> Andreas> On Tue, Nov 12, 2019 at 11:32:09PM +0100, gregor herrmann wrote:
> >> > I'd like to suggest this recommendation could be of the same
> >> strength as > the "use salsa" recommendation, i.e., weaker than
> >> the dh recommendation, > and directed at people with no reasons
> >> to prefer either who are > wondering which to use.
> >> 
> >> I was not aware of a difference in strength between the two
> >> recommendation [0]
> 
> Andreas> I also was not aware that there are different strengths of
> Andreas> recommendation. ;-)
> 
> I think we'd all be kind of confused if someone started filing bugs
> because a package was not in salsa.

OK, I agree that this makes a technical difference between the two
recommendations.
 
> Andreas> Definitely.  Moreover, may be I have missed it but the
> Andreas> question to some example where the free form text is easier
> Andreas> to read than the machine readable one was not answered yet.
> Andreas> I'm keen on reading this.
> 
> 
> It sounds like there's a proposal here with some support.
> does someone want to facilitate this discussion?
> 
> * Pay attention to any issues that get brought up
> 
> * Summarize at the end
> 
> * If there is consensus to make a recommendation, figure out where it
>   should go and file a bug  pointing to the summary.
> 
> I don't think facilitating the discussion should obligate someone to
> write text for dev ref or policy or Shepherd things through those
> processes.
> Although obviously, the more work you put into it, the faster things
> might happen.

Since I somehow started the discussion I would draw some kind of
obligation out of it.  Unfortunately I'm suffering from some vacation
backlog and will enter a Bioinformatics sprint next week which will
probably not leave me any spare minute for this.

In short: I'm not up for this for the next two weeks but I'd happily
support by proof-reading if somebody would be faster than me.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Usage of DEP5

[Andreas Tille]

On Sun, Nov 10, 2019 at 09:49:26PM +0100, Daniel Leidert wrote:
> Am Donnerstag, den 07.11.2019, 13:40 + schrieb Thorsten Glaser:
> 
> [snip]
> > If forcing machine-readable copyright is required for UMEGAYA,
> > then I’m sorry to say I will be removing debian/upstream/metadata
> > from some of my packages rather.
> 
> Why is a machine-readable debian/copyright (DEP5, accepted) mixed with
> debian/upstream/metadata (DEP12, just a draft) here?
> 
> debian/upstream/metadata is completely optional. This draft has not even been
> accepted yet. I see heavy issues making this mandatory. It contains almost 
> only
> non-packaging relevant information, which is not really necessary to provide
> that package. And the data contained can change at any time.

The connection is that I was arguing that fields that are in DEP5 should
not be in DEP12.  Those who refuse to use DEP5 might like to put that
into DEP12 (see my first mail in this thread about the Wiki change[1]).
I basically started the thread here since I disagree.  To say it
clearly:  If you want to ship the information that is shiped in DEP5 you
should use DEP5.  Sticking to the old copyright format and sneaking in
the information "somewhere else" does not make any sense to me.
 
> But if we don't ship the projects license(s) files, debian/copyright IS
> mandatory. JFTR: I don't understand why a formalized format of 
> debian/copyright
> is that hard to realize.

+1

I could understand "I don't have time"-like excuses.  I have not seen
any example yet, that would be hard to re-phrase as valid copyright
format 1.0.

Kind regards

  Andreas.

[1] https://lists.debian.org/debian-devel/2019/11/msg00096.html

-- 
http://fam-tille.de

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

[Andreas Tille]

On Tue, Nov 12, 2019 at 11:23:08AM +0100, Thomas Goirand wrote:
> 
> If you're rebuilding a package which is already in the archive, you're
> supposed to take the .orig.tar.xz from the archive, and if not, you're
> supposed to generate it with git archive (or with the shortcut for that
> command: ./debian/rules gen-orig-xz). Either ways, you don't need to set
> pristine-tar to do that.

... but there are teams that rely successfully on pristine-tar which
solves the problem you describe at least to my experience perfectly.
 
> I also think this should become the default too:
> no-create-orig = True

Please don't.
 
> because otherwise, you easily get a generated wrong file, which will not
> be the same as the archive one (because pristine-tar is broken in many
> ways, as many of us know already).

>From time to time I hear this statement.  I can confirm that in all
teams I'm working on pristine-tar belongs to the team policy and I never
experienced in those > 2000 packages I've touched any problem with this.
For me this makes some statistically relevant set which makes me believe
that blaming pristine-tar to be broken in many ways is exaggerating and
should not become a reason to force standard options that would really
break pristine-tar.

> Besides this, nobody is forced to use gbp. Just typing "sbuild" to build
> a package is also perfectly valid. So why adding preferences for one set
> of tooling, when there's many alternatives? It doesn't make sense.

Except for not agreeing with your opinion about pristine-tar I agree that
debian/gbp.conf is frequently not very helpful and flooded with unneeded
options sometimes.  It really makes sense to use ~/.gbp.conf instead.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: please avoid writing useless/annoying stuff in debian/gbp.conf

[Andreas Tille]

On Mon, Nov 11, 2019 at 11:37:06AM -0800, Russ Allbery wrote:
> "Theodore Y. Ts'o"  writes:
> 
> > Yes, and that's why I use debian/master instead of debian/buster or
> > debian/bullseye.  :-)
> 
> > When I do create debian/buster (once it became the stable branch), the
> > first thing I did after I branched off debian/buster from debian/master
> > was to edit debian/gbp.conf was to have:
> 
> > debian-branch=debian/buster
> 
> > I only do this when I need to do the first stable backport of a
> > serious/security bug, such that I have to create the debian/buster
> > branch in the first place.  So it hasn't been all that annoying for me.
> 
> +1 this is my approach too.

I fully agree that

debian-branch=debian/RELEASE
debian-branch=debian/RELEASE-backports

is in the (partly unwritten) team policy of all teams I know for
backports and security updates.  Otherwise it is master (sometimes
debian/master).

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#944674: ITP: tarmux -- A tool to multiplex and demultiplex streams from pipes to tar and back again.

[Graham Leggett]

Package: wnpp
Severity: wishlist
Owner: Graham Leggett 

* Package name: tarmux
  Version : 1.0.2
  Upstream Author : Graham Leggett 
* URL : https://github.com/minfrin/tarmux
* License : ASL2
  Programming Lang: C
  Description : A tool to multiplex and demultiplex streams from pipes to 
tar and back again.

Tarmux attempts to solve the problem of handling streamed data where there is 
insufficient temporary
space on disk to hold the data, as is forced by tar.

In the simplest invocation, tarmux takes a stream from stdin, and creates a tar 
file consisting of
sequential numbered file fragments one after the other. This can be reversed by 
the tardemux tool,
which will untar the fragments and reassemble the stream to stdout.

The tardemux tool only reads a single tar stream before exiting. This allows 
multiple streams to be
concatenated in the same stream, and then split out by each invocation of 
tardemux.

(Happy to maintain the package, but need a co-maintainer or sponsor to
show me what to do)

Re: Usage of DEP5

[Thorsten Glaser]

gregor herrmann dixit:
>On Tue, 12 Nov 2019 15:08:56 -0700, Sean Whitton wrote:
>> optimising for writing these files, I don't think we should be expecting
>> people to come up with a package-specific reason if they find themselves

Thanks.

>> I'd like to suggest this recommendation could be of the same strength as
>> the "use salsa" recommendation, i.e., weaker than the dh recommendation,
>> and directed at people with no reasons to prefer either who are
>> wondering which to use.
>
>I was not aware of a difference in strength between the two
>recommendation [0] but yes, the "people with no reason to prefer
>either" was the direction I was heading at.

Fine with me. (As I said, I do have packages with either, and I agree
the new format can be more suitable.)

Thanks,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)

Re: please avoid writing useless/annoying stuff in debian/gbp.conf

[Russ Allbery]

Andreas Tille  writes:

> From time to time I hear this statement.  I can confirm that in all
> teams I'm working on pristine-tar belongs to the team policy and I never
> experienced in those > 2000 packages I've touched any problem with this.
> For me this makes some statistically relevant set which makes me believe
> that blaming pristine-tar to be broken in many ways is exaggerating and
> should not become a reason to force standard options that would really
> break pristine-tar.

My understanding is that most of the problems with pristine-tar come with
time.  If the tarballs and delta files are created and then read by
software versions reasonably close in time to each other, it generally
works.  The more obscure or ancient the versions of tar and xz were, or
the more options were used, to create the tarballs, the more likely that
if you go back to oldstable and try to recreate the tarballs, you may have
problems.

I'm personally fine with that as a pristine-tar user since I consider it a
convenience rather than a primary data store.  If it works, I don't have
to go find the upstream tarball.  If it doesn't work, I can download the
upstream tarball from the archive and use it directly, and all that
pristine-tar failing costs me is some time.

-- 
Russ Allbery (r...@debian.org)  

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

[Thomas Goirand]

On 11/13/19 1:53 PM, Andreas Tille wrote:
> Except for not agreeing with your opinion about pristine-tar I agree that
> debian/gbp.conf is frequently not very helpful and flooded with unneeded
> options sometimes.  It really makes sense to use ~/.gbp.conf instead.

This was the single and only point I was trying to make, and I wasn't
trying to convince anyone about anything else! :)

Cheers,

Thomas Goirand (zigo)

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

[Jeremy Bicha]

On Tue, Nov 12, 2019 at 5:23 AM Thomas Goirand  wrote:
> On 11/11/19 12:50 PM, Jeremy Bicha wrote:
> > It is absolutely not possible to set the correct
> > pristine-tar=True/False in ~/.gbp.conf to work with your packages
> > (which avoid pristine-tar) and the vast majority of gbp packages in
> > Debian which do use pristine-tar. Those settings are specific to the
> > workflow for that repo, and everyone using that repo needs to use
> > those same settings to avoid issues.
>
> I don't think what you wrote above is correct. None of the options you
> mentioned are mandatory. If GBP doesn't see the use of pristine-tar, it
> will assume that we're using an upstream tag, which is fine.
> ...
> Besides this, nobody is forced to use gbp. Just typing "sbuild" to build
> a package is also perfectly valid. So why adding preferences for one set
> of tooling, when there's many alternatives? It doesn't make sense.

Let me try to be more specific. Many packages are maintained by people
who use gbp. Many packages have pristine-tar branches but do not have
"pristine-tar = True" set. When I work on one of these packages (and I
work on many packages with many maintainers), I need to have
"pristine-tar = True" set in my ~/.gbp.conf. However, when I then want
to work on an OpenStack package, I have to change my user config to
set "pristine-tar = False". This is a very manual process and I'm
likely to make a mistake.

Ideally, packages maintained by someone who wants to consistently use
pristine-tar will have that set in debian/gbp.conf and the minority of
maintainers who don't will have that set in debian/gbp.conf too.

While you could use sbuild to build gnome-calculator for instance, you
do have to use gbp to **maintain** gnome-calculator -- especially when
packaging new versions. That is because gnome-calculator is
team-maintained by the Debian GNOME team and we have guidelines for
how our packages are maintained [1]. To make life easier for
contributors, we enforce as many of those guidelines as possible in
debian/gbp.conf.

Similarly, you have guidelines for how OpenStack packaging updates and
bugfixes are handled and it seems to me like it would make a whole lot
more sense for you to explicitly "forbid" pristine-tar from being used
in your packages, as long as you are the maintainer and you believe
that pristine-tar is unsuitable for those packages.

[1] https://wiki.debian.org/Gnome/Git

Thanks,
Jeremy Bicha

Bug#944704: ITP: org-html-themes -- export Emacs Org mode files into awesome HTML in 2 minutes or less

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

* Package name: org-html-themes
  Version : 1.0.0
  Upstream Author : 
* URL : https://github.com/fniessen/org-html-themes
* License : GPL-3+
  Programming Lang: Org_style_markdown, HTML, CSS, js vs Debian's libjs-foos
  Description : export Emacs Org mode files into awesome HTML in 2 minutes

 Org-HMTL themes is an open source framework that enables the
 exportation of Org documents to beautiful cross-browser HTML. Use
 this to style your docs, and your colleagues will come up to tell you
 that you are a genius!  Whether it's for a web page, something like
 an IOT frame that displays TODO lists and project progress, or
 something else this package elevates Org export and publication to
 something truly impressive.
 .
 At this time the following themes are included:
   * Bigblow, a modern and minimal theme with pastel colours and a clean design.
   * ReadTheOrg, a clone of the well known and loved Read The Docs theme.

This package lowers the barrier to entry to professional-looking
Org-mode export/publish results.  In the future I'd like to see it
extended via conveniences like yasnippet and/or some sort of template
selection menu.  I discovered this package when working on generating
Ivy/Counsel/Swiper's HTML docs (now with no invariants section!)  The
most similar type of package would probably be the various Sphinx
themes.

I plan to maintain it on the Debian Emacsen Team, and I look forward
to navigating between the requirements of users who are using it for
offline docs and those who will use it to publish to a web server.  I
will require a sponsor for the initial upload.

If someone would like to work on porting Sphinx themes to this
framework, please speak up :-)  A publication kit that provides unified
look & feel between Sphinx and Org could be a fun project.

I anticipate it will become popular with fans of Org-mode.


Sincerely,
Nicholas